برنامه‌ریزی تست

سند استراتژی تست؛ از Risk و Evidence تا Gate و تصمیم انتشار

انتشار در تاریخ توسط محمد عسکری

یک تیم برای انتشار نسخه پرداخت، Dashboard سبزی داشت: ۹۶٪ Test پاس و ۹۰٪ Requirement پوشش داده شده بود؛ بنابراین مدل ساده گفت «Release». اما وقتی همان نتایج به ریسک‌ها وصل شدند، یک Failure بحرانی در Callback تکراری و دو Unknown درباره Timeout-after-commit و Restore دفترکل آشکار شد. پوشش شواهد ریسک فقط ۵۳٪ بود و تصمیم درست «Hold» شد.

این همان مسئله‌ای است که سند استراتژی تست باید حل کند: نه فهرست‌کردن Unit، API، UI و ابزارها، بلکه توضیح اینکه برای کدام Outcome و Risk، چه سؤال شواهدی را در کدام Boundary، با چه Oracle و Fidelity، در چه Lane و Budgetی پاسخ می‌دهیم؛ چه کسی Evidence را می‌سازد و چه کسی Residual risk را می‌پذیرد.

پاسخ کوتاه: سند استراتژی تست خوب چه دارد؟

یک Strategy خوب Context و هدف کسب‌وکار را به Quality attribute و Risk متصل می‌کند، سپس برای هر Risk سطح/نوع/تکنیک تست، محیط و داده، Oracle، Coverage، Lane، Entry/Exit/Gate، Evidence، Owner و Exception تعریف می‌کند. سند باید کوتاه، Versioned، قابل‌اجرا و دارای Trigger بازبینی باشد. Schedule و Task روزانه در Test Plan می‌مانند.

Test Strategy چیست و چه چیزی نیست؟

Test Strategy یک Decision architecture برای تولید شواهد کافی درباره کیفیت و ریسک است. می‌تواند در سطح سازمان، محصول، Program یا پروژه تعریف شود؛ دامنه و Authority آن باید صریح باشد. Strategy «تضمین نبودن Bug» یا «تعهد QA به کیفیت» نیست، زیرا Testing کامل نیست و کیفیت نتیجه تصمیم‌های کل تیم و عملیات است.

ISO/IEC/IEEE 29119-2:2021 فرایندهای عمومی برای حاکمیت، مدیریت و اجرای تست را در مدل‌های مختلف SDLC تعریف می‌کند. ISO/IEC/IEEE 29119-3:2021 Templateهای مستندات خروجی آن فرایندها را ارائه می‌دهد. این استانداردها مبنای Tailoring هستند، نه دستور تولید یک سند ۱۰۰‌صفحه‌ای برای هر تیم.

Strategy، Plan، Policy و Test Case

Artifact سؤال اصلی افق/تغییر مالک نمونه
Quality/Test Policy اصول و الزام‌های سازمان چیست؟ سازمانی/کم‌تغییر Engineering/Quality leadership
Test Strategy برای این Context/Risk چه Evidence و چگونه؟ محصول/پروژه، با Trigger Cross-functional، با facilitator تست
Test Plan این Release چه کاری، چه زمان و با چه منابع؟ Release/Iteration، پرتغییر Test/Delivery lead
Test Case/Charter چه Condition/Action/Oracle/Evidence؟ Scenario/Session Tester/Developer/Domain expert
Release memo Evidence فعلی و Residual risk چه تصمیمی می‌سازد؟ Snapshot تصمیم Recommendation owner / decision owner

برای مثال و مرزبندی عمیق‌تر، تفاوت Test Plan، Test Strategy و Test Case را ببینید. Schedule، برآورد و Assignment اجرایی نیز در راهنمای Test Plan در STLC جای درست خود را دارند.

Definition of Done جای Strategy نیست

Scrum Guide 2020 Definition of Done را توصیف رسمی وضعیت Increment هنگام برآورده‌شدن معیارهای کیفیت محصول می‌داند. DoD حداقل مشترک و شفافیت می‌سازد؛ اما Risk portfolio، Non-functional evidence، release exception، rollout و production learning را به‌تنهایی تعریف نمی‌کند.

قبل از نوشتن: Strategy Brief

Decision horizon: product / program / project / release
Business outcomes: value, users, transactions, obligations
Context: architecture, lifecycle, dependencies, change cadence
Quality risks: condition -> event -> impact
Evidence questions: what must be learned before which decision?
Constraints: time, people, environment, data, legal, suppliers
Authorities: recommendation, release, exception, stop, rollback
Review triggers: risk, architecture, incident, SLO, regulation, scale

Strategy بدون Decision horizon یا آن‌قدر کلی می‌شود که هیچ‌کس نمی‌تواند آن را اجرا کند، یا آن‌قدر ریز که با هر Sprint منسوخ می‌شود. یک Core پایدار برای محصول و Overlayهای Release/initiative بسازید.

بخش اول سند: Context قابل‌ردیابی

یک پاراگراف معرفی کافی نیست. Context باید انتخاب Approach را توضیح دهد:

  • Outcome، کاربران، Journeyهای بحرانی و زیان شکست؛
  • Architecture، trust boundary، data flow و dependencyها؛
  • Deployment/rollback، Feature flag، mobile/web/backend/data/AI؛
  • Change cadence و الگوی Release؛
  • Production SLO/incident/support signal؛
  • قانون، قرارداد، Privacy، Security و Accessibility obligation؛
  • Legacy/unknown، محدودیت Testability، محیط، داده و Tool؛
  • مالک Domain و تصمیم‌های مهم.

فرض را به Validation/Expiry وصل کنید

«Sandbox درگاه رفتار Production را نمایندگی می‌کند» یک Fact نیست. برای هر فرض، Owner، Evidence، Validation date و Expiry داشته باشید. اگر فرض شکست، Risk و Approach باید بازبینی شوند.

بخش دوم: Quality Model و Trade-off

فقط Functional correctness ننویسید. ISO/IEC 25010:2023 یک مدل مرجع نه‌ویژگی برای Specification و ارزیابی کیفیت محصول فراهم می‌کند. از آن به‌عنوان Prompt استفاده کنید؛ همه ویژگی‌ها برای هر محصول وزن برابر ندارند.

Quality Attribute Scenario

Attribute: reliability / security / performance / accessibility / ...
Source: actor or stimulus source
Stimulus: event/failure/load/action
Environment: normal, peak, degraded, recovery
Artifact: component/journey/data/dependency
Response: expected behavior and forbidden side effects
Measure: threshold/window/percentile/uncertainty
Owner: requirement and residual-risk authority

نمونه: «در فروش جمعه، پس از Timeout درگاه بعد از Commit، Order باید ظرف ۳۰ ثانیه به وضعیت نهایی قابل‌تشخیص برسد؛ Charge دوم و پیام موفقیت کاذب ممنوع است.» این جمله مستقیماً به Test، Oracle، Telemetry و Gate تبدیل می‌شود.

Trade-off را پنهان نکنید

امنیت بیشتر ممکن است Latency یا Usability را تغییر دهد؛ Evidence بیشتر ممکن است Feedback را کند کند؛ Fidelity بالاتر ممکن است هزینه و Data risk بسازد. Strategy باید Trade-off، Decision owner و Guardrail را ثبت کند، نه اینکه همه صفات را «بالاترین کیفیت» بخواهد.

بخش سوم: Risk Register تصمیم‌محور

Risk را به شکل Condition→Event→Impact بنویسید، نه «ریسک Performance». Inherent risk، کنترل‌های فعلی و Residual risk را جدا کنید. Probability×Impact یک رتبه ordinal است، نه حقیقت دقیق؛ uncertainty و evidence age را نشان دهید.

روش کامل Identification، Scale، Mapping و Residual memo در راهنمای تست مبتنی بر ریسک (RBT) آمده است. Strategy فقط خروجی عملی آن را مصرف می‌کند.

ID Risk statement Impact/Likelihood/Uncertainty Owner Treatment
R1 Callback تکراری PSP باعث Charge دوم شود ۵/۳/medium Payment owner idempotency + API/concurrency evidence
R2 Order Tenant دیگر خوانده شود ۵/۲/low Security/Product authorization matrix + negative probes
R3 Timeout-after-commit نتیجه مبهم بسازد ۵/۴/high Payment/SRE state probe + reconciliation + UX
R4 Restore دفترکل و Outbox را ناهمسان کند ۵/۲/high Data/SRE restore rehearsal + invariant

بخش چهارم: Evidence Question، نه Test Type list

برای هر Risk بپرسید چه چیزی باید معلوم شود: «آیا Duplicate در همان Process دفع می‌شود؟»، «آیا DB unique constraint و transaction درست است؟»، «آیا Callback واقعی/Out-of-order رفتار می‌کند؟»، «آیا کاربر Outcome را می‌فهمد؟» سپس کوچک‌ترین Boundary را انتخاب کنید که Failure mechanism را حفظ می‌کند.

risk_id / decision
evidence_question
failure_mechanism
test_level + interface + technique
dependency_fidelity + environment + data
oracle + negative side effect
coverage model + repetitions/uncertainty
lane + feedback budget
evidence artifact + owner + expiry

Level، Type، Interface و Lane را قاطی نکنید. «Security UI nightly» چهار محور متفاوت است. سبد Unit/Component/Integration/Contract/System/E2E و اقتصاد Boundary در راهنمای عملی هرم تست تشریح شده است.

بخش پنجم: Test Portfolio و تخصیص شواهد

Strategy نسبت جهانی ۷۰/۲۰/۱۰ یا «همه‌چیز را Automate کنید» تعیین نمی‌کند. برای هر Failure mechanism، Boundary، Fidelity، Oracle، سرعت، نگه‌داری و Resource budget را Trade-off می‌کند.

Evidence family سؤال نمونه Lane نمونه Owner
Static/review Rule/secret/schema/unsafe change؟ editor/PR fast Developer + specialist
Unit/component domain transition/invariant؟ local/PR fast Feature team
Integration DB/queue/cache/protocol behavior؟ PR/merge Feature/platform
Contract consumer/provider compatibility؟ PR/event-driven Interface owners
System/E2E critical journey across boundaries؟ merge/nightly/release Cross-functional
Exploratory unknown interaction/UX/risk؟ story/release session Tester + domain expert
Non-functional capacity/security/accessibility/recovery؟ event/nightly/release Specialist + product team
Production real config/traffic/dependency outcome؟ canary/probe/monitoring SRE/Product

Overlap هدفمند است، Duplicate نه

یک Idempotency invariant ممکن است در Unit، DB integration، API concurrency و System journey تکرار شود؛ هر سطح Failure mechanism متفاوتی را می‌گیرد. اگر چهار Test همان Input/Oracle/Boundary را تکرار می‌کنند، هزینه بدون Evidence جدید ساخته‌اند.

بخش ششم: Oracle و Verdict contract

«Expected result مطابق Requirement» کافی نیست. Requirement ممکن است مبهم یا اشتباه باشد و UI سبز می‌تواند Backend خراب را پنهان کند. Strategy باید Oracleهای مستقل و Failure semantics را تعریف کند.

  • Contract/schema/protocol؛
  • Domain rule و invariant؛
  • State transition و persistence؛
  • Side effect و absence of forbidden effect؛
  • Security/authorization/tenant؛
  • Performance/SLO/statistical threshold؛
  • Accessibility/UX human judgment؛
  • Telemetry/reconciliation/production outcome.

نتیجه‌های معتبر را از Status اجرایی جدا کنید

Passed، Failed، Blocked، Not run، Skipped، Inconclusive، Invalid، Quarantined و Unknown معناهای جدا دارند. Retry-pass باید first-attempt را حفظ کند. Blocked/Invalid در Denominator Pass rate پنهان نشوند و نبود Evidence به‌صورت Passed تفسیر نشود.

بخش هفتم: Coverage Model

Requirement coverage، Code coverage، Scenario coverage، Data coverage، Device coverage و Risk evidence coverage پاسخ‌های متفاوت‌اند. عدد درصد فقط با Scope، Baseline، Denominator، Exclusion و freshness معنا دارد.

risk_evidence_coverage =
  sum(weight of risks with valid current evidence)
  / sum(weight of all in-scope risks)

passed_risk_evidence =
  sum(weight of risks whose required evidence passed)
  / sum(weight of all in-scope risks)

این فرمول‌ها مدل محلی‌اند، نه استاندارد جهانی. Critical gateها را خارج میانگین نگه دارید؛ وزن نباید Failure امنیتی یا Unknown بازیابی را خنثی کند. Evidence age و uncertainty را کنار درصد بیاورید.

بخش هشتم: محیط، داده و Dependency Fidelity

Strategy باید بگوید هر سؤال در چه Fidelity پاسخ می‌گیرد: in-memory/fake، container واقعی، sandbox، shared staging، device، production canary. «Production-like» بدون Manifest بی‌معناست.

برای قرارداد Manifest، Drift، health، booking و ownership به راهنمای مدیریت محیط تست مراجعه کنید. چرخه Classification، Synthetic/Masked data، isolation، reset و retention نیز در راهنمای مدیریت داده تست آمده است.

Dependency fidelity matrix

Dependency Fast lane Deep lane Drift control
PSP stateful simulator authorized sandbox contract traces + periodic calibration
PostgreSQL container per run release topology version/config/schema manifest
Queue real broker container cluster failure drill ordering/retry/DLQ contract
Notification sink/allowlist provider sandbox template/callback contract

بخش نهم: Testability و Observability requirements

Strategy باید نیازهای Clock/ID/randomness control، seed/reset، correlation ID، state probe، fault injection، safe logs/traces، sandbox و feature flag را به Backlog تبدیل کند. اگر Oracle یا Control وجود ندارد، نوشتن «تست خواهد شد» وعده نامعتبر است.

Test hook نباید Production backdoor باشد. Access، build flag، audit، data redaction و removal policy لازم‌اند. هر Testability requirement مالک، ارزش ریسک و Acceptance evidence داشته باشد.

بخش دهم: Pipeline lane و Feedback budget

Strategy سطح/نوع Test را به Event و Deadline وصل می‌کند. Engineer باید Signal سریع را پیش از Context switch بگیرد؛ Evidence سنگین نیز باید پیش از تصمیم مرتبط آماده باشد.

Lane Trigger Evidence Budget/Gate
Local/editor change static/small/targeted seconds، developer feedback
PR commit impacted unit/component/contract/security minutes، merge gate
Merge main integration/system smoke/migration tens of minutes، artifact qualify
Nightly schedule broad matrix/fuzz/performance trend hours، triage by morning
Release candidate critical journey/recovery/security/perf decision deadline
Production deploy/traffic/event canary/probe/SLO/business outcome pause/rollback threshold

Google SRE Testing for Reliability Testing را بخشی از کاهش uncertainty در تغییر و Production probes را مکمل محیط Hermetic می‌داند؛ همان منبع نیز تصریح می‌کند Pass شدن Test اثبات قطعی Reliability نیست. راهنمای Continuous Testing در CI/CD قرارداد lane، gate و artifact promotion را عملی‌تر می‌کند.

بخش یازدهم: Entry، Exit، Gate و Stop policy

Entry/Exit را با Evidence تعریف کنید، نه تاریخ یا Pass rate تنها. Gate باید Decision، Scope، threshold، data source، stale behavior، Owner، exception و action را مشخص کند.

Gate: payment release readiness
scope: artifact SHA + config + migration + environment manifest
must pass: R1-R4 critical evidence, no unknown critical risk
health: valid runs only; retry history visible
thresholds: named source/window/percentile
decision owner: release owner
failure action: hold / rollback / reduce scope
exception: approver + rationale + compensating control + expiry

Entry نمونه

  • Test basis reviewed و Riskها Versioned؛
  • Artifact/config/schema identity ثابت؛
  • Environment health و Dataset manifest معتبر؛
  • Dependency fidelity و limitation معلوم؛
  • Oracle/Evidence pipeline آماده؛
  • Known blocker و exception ثبت‌شده.

Exit نمونه

  • همه Riskهای بحرانی Evidence معتبر و تازه دارند؛
  • Failure، Unknown و Inconclusive triage شده‌اند؛
  • Residual risk و coverage gap با Owner روشن است؛
  • Rollback/monitoring/support readiness تأیید شده؛
  • Release recommendation به Decision owner تحویل شده است.

بخش دوازدهم: Exception و Residual Risk

Exception نباید Test شکست‌خورده را سبز کند. شامل Risk، missing/failed evidence، علت، impact، compensating control، scope reduction، monitoring، rollback trigger، approver و expiry باشد. Exception منقضی باید خودکار دوباره Gate را قرمز کند.

تیم تست Evidence و Recommendation می‌دهد؛ مالک کسب‌وکار/محصول یا Release owner نام‌گذاری‌شده Residual risk را می‌پذیرد. QA نباید به‌تنهایی صاحب زیان کسب‌وکار یا تصمیم نهایی باشد.

بخش سیزدهم: نقش‌ها و Decision Rights

نقش Contribution Authority
Product/Business Outcome، impact، acceptance، scope Residual business risk/release
Developer/Architect design controls، unit/component evidence، testability technical design/change
QA/QE risk facilitation، evidence design، challenge، report evidence sufficiency recommendation/stop trigger
Security/Privacy threat/legal-control evidence specialist gate/exception input
SRE/Operations SLO، recovery، rollout، production signal pause/rollback operationally
Data/Platform environment/data/pipeline reliability platform health and access
Release owner integrated evidence and trade-off final release/hold/scope decision

RACI کافی نیست؛ stop authority، escalation path، exception authority و rollback trigger را نیز بنویسید. «کیفیت مسئولیت همه است» بدون مسئول پاسخ‌گو، تصمیم را مبهم می‌کند.

بخش چهاردهم: Configuration و Evidence identity

هر نتیجه باید به Commit/Artifact، Config، Schema/migration، Environment، Dataset، dependency/driver/tool version، Test suite و Attempt متصل باشد. «نسخه ۲ تست شد» بدون این Identity برای Release یا Retest قابل‌استفاده نیست.

evidence_manifest:
  decision_scope: release-2026.08-payment
  artifact_sha: ...
  config_version: ...
  schema_migration: ...
  environment_manifest: ...
  dataset_manifest: ...
  suite/test_version: ...
  tool/driver/dependency_versions: ...
  run/attempt/timestamps: ...
  results/attachments/redaction/retention: ...

بخش پانزدهم: Monitoring، Control و Adaptation

Strategy یک PDF امضاشده و فراموش‌شده نیست. Plan-versus-actual، Risk change، Evidence freshness، Environment/Data health، Flake/Invalid، escaped learning و production SLO باید اقدام کنترلی بسازند.

ISTQB CTAL Test Management v3.0 Project Test Strategy را در Context برنامه‌ریزی، RBT، monitoring/control و completion قرار می‌دهد. کنترل فقط گزارش انحراف نیست؛ باید Scope، Approach، Resource یا Risk treatment را تغییر دهد.

Triggerهای بازبینی Strategy

  • تغییر Outcome، Journey یا Risk appetite؛
  • معماری، dependency، data flow یا trust boundary جدید؛
  • Incident، escaped defect یا near miss؛
  • SLO/Error budget یا رفتار ترافیک تازه؛
  • قانون/قرارداد/Privacy/Security requirement؛
  • Tool/Driver/OS/Browser/Device/AI model upgrade؛
  • Environment/Data fidelity drift؛
  • تغییر تیم، skill، supplier یا Release cadence؛
  • Metric gaming یا Evidence cost نامتناسب.

بخش شانزدهم: Reporting و Decision interface

Strategy باید Outputهای ارتباطی را تعریف کند: Progress، Completion، Release-readiness memo، Dashboard و Incident learning. Audience، تصمیم، freshness، denominator، drill-down و Owner هرکدام روشن باشد.

راهنمای گزارش تست و تصمیم انتشار Templateهای Snapshot، Risk register، recommendation و residual risk را پوشش می‌دهد. گزارش نباید Test count، Bug count یا Pass rate را جای کیفیت و confidence بنشاند.

یک Release memo کوتاه

Decision requested + owner + deadline
Scope identity: artifact/config/schema/environment/data
Business outcomes and critical risks
Evidence: passed / failed / unknown / stale / invalid
Coverage: model + denominator + exclusions + age
Residual risks/exceptions: owner + control + expiry
Operational readiness: rollout, monitoring, rollback, support
Recommendation: release / conditional / reduce scope / hold
Decision log: who, when, rationale, review trigger

بخش هفدهم: Security، Privacy و Supply Chain

«Security test انجام می‌شود» Strategy نیست. Threat/requirement source، Asset/trust boundary، SAST/SCA/secret/IaC/API/auth/business-logic/pentest/fuzz lanes، safe RoE، Finding semantics، Gate/exception و Retest را مشخص کنید.

NIST SSDF 1.1 Secure development practices را قابل ادغام با هر SDLC معرفی می‌کند. OWASP ASVS نیز Requirement catalog برای Verification امنیت اپلیکیشن ارائه می‌دهد. هیچ‌کدام بدون Scope/Tailoring و Evidence محلی، «Compliance achieved» نمی‌سازند.

  • Security/privacy requirement ID به Risk/Test/Evidence وصل شود؛
  • PII/Secret در Log، Screenshot، Trace و Report Redact شود؛
  • Test account/data، scanning و failure injection مجاز و محدود باشند؛
  • Tool/plugin/container/package provenance و access بررسی شود؛
  • Finding با Owner/SLA/exception/retest بسته شود؛
  • Production probe fail-safe و بدون side effect ناخواسته باشد.

بخش هجدهم: Accessibility و Human evidence

Automation همه کیفیت را نمی‌بیند. Screen reader journey، Keyboard/focus، zoom/reflow، language clarity، cognitive load، usability و exploratory discovery به انسان/کاربر نماینده نیاز دارند. Strategy باید Recruitment، device/assistive-tech matrix، consent/privacy، task، observation rubric و decision owner را بنویسد.

یک Scanner سبز فقط Ruleهای قابل‌خودکارسازی را پوشش می‌دهد. «Accessibility not run» باید Unknown/Residual risk باشد، نه حذف از Coverage.

بخش نوزدهم: Performance، Resilience و Recovery

Workload model، traffic mix، data volume/skew، concurrency، think time، dependency behavior، percentile، saturation، error budget، graceful degradation، recovery objective و steady-state invariant را ثبت کنید. Performance lab با Production capacity/config اختلاف دارد؛ Calibration و production observation لازم است.

راهنمای رسمی DORA metrics سنجه‌های Delivery performance را روی توان تحویل ایمن، سریع و کارآمد متمرکز می‌کند. این سنجه‌ها Test metric یا KPI فردی نیستند؛ Strategy می‌تواند آنها و SLO/incident signal را به‌عنوان Feedback سیستم بگیرد، نه امتیاز QA.

سناریوی کامل ایرانی: Strategy پرداخت و استرداد

محصول یک بازارگاه چندفروشنده است. پرداخت از PSP، موجودی/تخفیف، Ledger، Outbox، Notification و Refund عبور می‌کند. مبلغ Backend ریال است، UI تومان نمایش می‌دهد، ورودی می‌تواند ارقام فارسی/عربی/لاتین داشته باشد و زمان Backend UTC ولی نمایش Asia/Tehran است.

Outcome و Quality priorities

  • هیچ Charge یا Refund تکراری؛
  • هیچ دسترسی بین Tenantها؛
  • Outcome پرداخت حتی پس از Timeout قابل‌تشخیص؛
  • دفترکل، Order، Refund و Outbox قابل Reconcile؛
  • فروش جمعه در SLO و با degradation معلوم؛
  • رسید و مسیر Refund برای Screen reader/Keyboard قابل‌استفاده؛
  • PII فقط در Scope مجاز و Evidence پاک؛
  • Rollback/Restore بدون از‌دست‌رفتن اثر مالی.

Risk-to-Evidence map

Risk Evidence portfolio Oracle/Gate
Duplicate callback domain unit + DB unique/transaction + API concurrency + E2E callback one logical payment→one charge/ledger/order transition
Timeout after commit simulator fault + API state probe + UI recovery + reconciliation no false success/failure؛ eventual terminal state
Cross-tenant read authorization matrix + negative API + cache-key test deny and no existence/data leakage
Rial/toman/digits property/boundary + API serialization + localized UI canonical IRR invariant and explicit display conversion
Restore inconsistency backup/restore rehearsal + ledger/outbox query state/event parity and controlled replay
Friday peak calibrated load/stress + dependency degradation p95/p99/error/saturation and graceful response
Receipt accessibility static rule + keyboard + screen reader task critical flow completion without loss of meaning

Lane و decision

Unit/Component و Contract در PR، DB/queue integration و smoke در Merge، Matrix/Accessibility/Performance trend در Nightly، PSP sandbox/Recovery/Restore/Security critical در Release و Canary/SLO/Reconciliation در Production اجرا می‌شوند. Release gate به Artifact/Config/Schema/Data identity بسته است؛ Critical Failed/Unknown اجازه میانگین‌گیری ندارد.

آزمایش قطعی: Pass rate در برابر Risk Evidence

یک برنامه مستقل Node.js ۲۴.۱۸.۰، ۱۰۰ نتیجه ساختگی و هشت Risk وزن‌دار را محاسبه کرد. مدل ساده بر اساس Pass rate و Requirement coverage تصمیم گرفت؛ مدل Strategy، Valid evidence، Critical failure و Critical unknown را جدا کرد.

naive_pass_rate=96.0% requirement_coverage=90% decision=release
risk_evidence_before=53% passed_risk_evidence=35% critical_failed=R1 critical_unknown=R3,R4 decision=hold
targeted_treatments=api_idempotency,timeout_state_probe,restore_reconciliation
risk_evidence_after=82% passed_risk_evidence=82% critical_failed=none critical_unknown=none decision=conditional_release
residual_risks=R6_invalid_performance_run,R7_accessibility_not_run owner_and_expiry_required

چرا تصمیم عوض شد؟

۹۶ Test پاس‌شده ممکن بود عمدتاً Riskهای کم‌اثر یا یک Boundary تکراری را پوشش دهد. یک Failure بحرانی R1 و نبود Evidence برای R3/R4 در Pass rate دیده نشد. سه Treatment هدفمند Evidence بحرانی را کامل کرد؛ اما Performance invalid و Accessibility اجرا‌نشده باقی ماند، بنابراین نتیجه فقط Release مشروط با Owner/Expiry شد.

محدودیت‌ها: Testها، Riskها، وزن‌ها و Thresholdها ساختگی‌اند؛ این آزمایش کیفیت واقعی، احتمال Risk یا سود Strategy را ثابت نمی‌کند. مدل فقط نشان می‌دهد Mapping نتیجه به Risk/Validity می‌تواند تصمیم متفاوتی از Aggregate percentage بسازد. وزن و Gate باید پیش از دیدن نتیجه و با Stakeholderها تعریف شود.

Strategy را برای Context Tailor کنید

Template ثابت نباید تفاوت محصول و Lifecycle را پاک کند. Core fields مانند Outcome، Risk، Evidence، Owner و Review همیشه می‌مانند؛ عمق، Artifact و Approval بر اساس Context تغییر می‌کنند.

Agile و Continuous Delivery

  • Core Strategy محصول + Overlay سبک برای Initiative/Release؛
  • Risk/Evidence در Backlog و Definition of Done قابل‌ردیابی؛
  • Lane/Gate/exception تا حد ممکن executable؛
  • Review در Refinement، Architecture review، Incident و Retrospective؛
  • Production feedback بخشی از Evidence، نه مرحله جدا پس از تست.

Sequential یا Regulated

  • Traceability رسمی‌تر میان Requirement/Risk/Test/Evidence؛
  • Baseline، review independence، signature و change control؛
  • Qualification ابزار/محیط/داده و retention دقیق؛
  • Completion report و deviation/waiver رسمی؛
  • Tailoring record برای هر بخش حذف/ادغام‌شده.

Legacy

  • Unknown inventory و characterization evidence؛
  • تغییرات کوچک با impact analysis و production observation؛
  • Seam/Testability roadmap به‌جای وعده پوشش فوری؛
  • Golden master با محدودیت و independent business invariant؛
  • Rollback/restore و data migration پررنگ‌تر.

Microservice/Event-driven

  • Contract compatibility و ownership مرزها؛
  • Ordering، duplicate، retry، DLQ و eventual consistency؛
  • Component/contract evidence بیشتر و E2E محدود اما حیاتی؛
  • Trace/correlation و version skew matrix؛
  • Failure/dependency simulation و production reconciliation.

Mobile، Data/ML و AI

Mobile به Device/OS/lifecycle/permission/network matrix، Data platform به schema/lineage/quality/reconciliation و AI به dataset/model/prompt/version، statistical/metamorphic oracle، variance، safety و human review نیاز دارد. Strategy باید Evidence model را با System type تغییر دهد، نه فقط Tool را.

ISTQB CTFL 4.0 Planning، Risk management، Monitoring/Control، Completion، Configuration و Defect management را در چرخه مدیریت تست قرار می‌دهد و آن را برای Agile، DevOps و Continuous Delivery نیز مرتبط می‌داند. Strategy باید این فعالیت‌ها را برای Context خود متصل کند.

Strategy-as-code؛ چه چیزی را اجرایی کنیم؟

سند Markdown/YAML در Version control می‌تواند Risk ID، lane، gate، threshold، owner، exception expiry و evidence link را ماشین‌خوان کند. اما Narrative، uncertainty و trade-off را حذف نکنید. Code فقط بخش‌های دارای semantics پایدار را enforce کند.

risk: R1
question: duplicate PSP callback creates one logical effect?
required_evidence:
  - suite: api-idempotency
    lane: pull_request
  - suite: payment-concurrency
    lane: release
gate:
  critical: true
  allowed: passed
  max_age_hours: 24
owner: payment-team
exception:
  approver: release-owner
  max_days: 3
  compensating_control: callback reconciliation alert

Lint و Drift check

  • Risk بدون Owner/Evidence/Gate؛
  • Suite حذف‌شده اما هنوز referenced؛
  • Threshold بدون source/window؛
  • Exception منقضی یا بدون compensating control؛
  • Environment/Data manifest ناسازگار؛
  • Critical evidence stale یا Unknown؛
  • Strategy version متفاوت از Pipeline policy.

Machine gate باید Fail closed و قابل‌توضیح باشد. تغییر وزن یا threshold نیاز به Review همانند Code دارد؛ Dashboard admin نباید بدون Audit semantics تصمیم را عوض کند.

ابزار و Automation در سند چه جایگاهی دارند؟

Tool از Evidence question می‌آید. برای هر Tool، مسئله، Boundary، Protocol، Oracle، CI/API، artifact، امنیت، داده، skill، support، TCO و Exit را ثبت کنید. «Selenium برای UI، JMeter برای Performance» Strategy نیست.

  • Tool name + edition/version/plugin/driver؛
  • Use cases مجاز و خارج Scope؛
  • Owner، upgrade و deprecation policy؛
  • Credential/data/network/telemetry boundary؛
  • Result/evidence format و retention؛
  • Fallback و خروج؛
  • PoC/requalification trigger.

Automation باید Feedback یا Evidence را بهتر کند، نه Script count را. Test دستی/اکتشافی، review، simulation و production observation نیز بخشی از Strategy هستند.

معیارهای سلامت خود Strategy

تعداد صفحه یا درصد تکمیل Template معیار ارزش نیست. Trendها را با Scope و Denominator ببینید:

  • Critical risk evidence coverage: معتبر، تازه و قابل‌ردیابی؛
  • Unknown/invalid evidence age: مخصوص Riskهای بحرانی؛
  • Decision lead time: از Candidate تا Evidence کافی؛
  • Feedback latency p50/p95: به تفکیک Lane؛
  • First-attempt valid rate: بدون Retry/تعمیر دستی؛
  • Finding effectiveness: کشف Risk مهم پیش از Impact، با attribution محتاطانه؛
  • Escaped learning: Incident/defect تازه چه شکاف Strategy را نشان داد؟
  • Change amplification: تغییر محصول چند Evidence asset را می‌شکند؟
  • Quarantine/exception debt: عمر، Risk و compensating evidence؛
  • Test cost per risk signal: compute + labor + delay؛
  • Stale assumption rate: فرض‌های گذشته از Validation/Expiry؛
  • Decision reversal/rollback learning: چه Evidence غایب یا گمراه‌کننده بود؟

Metric را KPI فردی نکنید

Bug count، Automation percentage، Test count، Code coverage، Pass rate یا DORA metric وقتی هدف فرد/تیم شوند، رفتار را منحرف می‌کنند. Metric dictionary شامل purpose، formula، denominator، source، frequency، exclusions، owner و gaming risk باشد. چند Signal متوازن برای یادگیری استفاده کنید.

فرایند Review و Approval عملی

  1. Draft: facilitator Context/Risk/Evidence map اولیه را می‌سازد.
  2. Challenge: Product، Dev، Security، SRE، Data و QA فرض‌ها و gapها را نقد می‌کنند.
  3. Feasibility: Environment/Data/Tool/Skill/Budget evidence بررسی می‌شود.
  4. Decision-right review: Gate، exception، stop و release authority نام‌گذاری می‌شوند.
  5. Approval: Approverها Scope/version/residual gaps را می‌پذیرند.
  6. Publish: سند و machine policy به Repository/portal متصل می‌شوند.
  7. Exercise: یک Risk و Release memo انتها‌به‌انتها آزمایش می‌شوند.
  8. Adapt: Trigger/Incident/Retrospective تغییر را آغاز می‌کند.

Approval به‌معنای «Quality guaranteed» نیست

Approval تأیید می‌کند Approach برای Context و اطلاعات فعلی پذیرفته شده است. Unknown، constraint و residual gap باید در همان Baseline باقی بمانند. امضا نباید نقد مستقل یا adaptation را متوقف کند.

Rollout سی‌روزه برای سند موجود یا جدید

هفته اول: Inventory و Risk

  • سندها، suiteها، pipelineها، reports و ownerها را فهرست کنید؛
  • Outcome/Journey/Quality attribute و ۵–۱۰ Risk مهم را Workshop کنید؛
  • Evidence فعلی را با Valid/Unknown/Stale/Invalid علامت بزنید؛
  • یک تصمیم Release نماینده انتخاب کنید.

هفته دوم: Evidence map و gap

  • Risk→Question→Boundary→Oracle→Fidelity→Lane را بسازید؛
  • Duplicate/vanity Testها و Critical gapها را پیدا کنید؛
  • Environment/Data/Testability prerequisiteها را Backlog کنید؛
  • Owner و decision rights را تأیید کنید.

هفته سوم: Gate و اجرای Pilot

  • یک Gate بحرانی و Exception workflow را Machine-readable کنید؛
  • Evidence manifest و Release memo بسازید؛
  • Failure/Unknown/Retry/Stale را عمداً وارد کنید؛
  • Reviewer دوم Decision را بازتولید کند.

هفته چهارم: Baseline و Governance

  • Strategy core و Overlay را Approve/Version کنید؛
  • Review triggers و quarterly/incident cadence را تعیین کنید؛
  • سه Metric سلامت و Goodhart guardrail انتخاب کنید؛
  • Gapها را با Owner/priority/expiry به Roadmap ببرید.

۱۵ ضدالگوی سند استراتژی تست

  1. فهرست Test type: Risk، سؤال و Decision گم است.
  2. Template صدصفحه‌ای: تکمیل Artifact جای تفکر Contextual را می‌گیرد.
  3. کپی پروژه قبلی: معماری، Risk و Constraint متفاوت پنهان می‌شود.
  4. مالکیت کامل QA: Product/Dev/SRE از کیفیت و Risk جدا می‌شوند.
  5. همه‌چیز In-scope: Priority و Trade-off وجود ندارد.
  6. همه Riskها High: هیچ تصمیم تخصیص منابعی ساخته نمی‌شود.
  7. نسبت جهانی Pyramid: Failure mechanism و معماری نادیده می‌روند.
  8. Pass rate gate: Blocked/Unknown/Invalid و Risk weight پنهان‌اند.
  9. Coverage بی‌Denominator: عدد قابل‌بازی و غیرقابل‌تفسیر است.
  10. Tool-first: Capability ابزار سؤال تست را شکل می‌دهد.
  11. Production-like مبهم: Fidelity و Drift Evidence ندارند.
  12. Retry سبز: Test-system health و first failure حذف می‌شود.
  13. Exception بدون Expiry: Gap موقت به سیاست دائمی تبدیل می‌شود.
  14. امضا و فراموشی: تغییر/Incident هیچ Adaptationی نمی‌سازد.
  15. Strategy=تضمین کیفیت: Unknown و Residual risk از دید تصمیم‌گیر پنهان می‌شود.

چک‌لیست ۲۰‌مرحله‌ای سند استراتژی تست

  1. Decision horizon، Scope و audience مشخص‌اند.
  2. Strategy از Policy، Plan، Case و Report جدا شده است.
  3. Outcome، Journey و impact کسب‌وکار نوشته شده‌اند.
  4. Architecture/data flow/trust boundary/dependency ثبت شده‌اند.
  5. Quality attributeها Scenario و Measure دارند.
  6. Trade-offها و authority صریح‌اند.
  7. Riskها Condition→Event→Impact و Owner دارند.
  8. Inherent/current/residual و uncertainty جدا هستند.
  9. هر Risk به Evidence question متصل است.
  10. Boundary، Type، Technique، Interface و Lane قاطی نشده‌اند.
  11. Oracle شامل State/Side effect/absence است.
  12. Coverage model، denominator، exclusion و age معلوم‌اند.
  13. Environment/Data/Fidelity manifest و Drift control دارند.
  14. Testability requirementها مالک و Backlog دارند.
  15. Feedback budget و Pipeline gate اجرایی‌اند.
  16. Result semantics، Retry و Quarantine شفاف‌اند.
  17. Entry/Exit/Stop/Exception/rollback action دارند.
  18. Recommendation، release، exception و stop authority مشخص‌اند.
  19. Evidence identity، report و decision log قابل‌ممیزی‌اند.
  20. Review trigger، version، expiry و adaptation cadence تعریف شده‌اند.

سؤالات متداول سند استراتژی تست

سند استراتژی تست چند صفحه باشد؟

تعداد صفحه معیار نیست. Core باید به‌اندازه‌ای کوتاه باشد که تصمیم‌گیر بخواند و به‌اندازه‌ای دقیق که تیم بتواند Risk→Evidence→Gate را اجرا کند. One-page map با Annexهای Machine-readable/تخصصی اغلب بهتر از متن طولانی است؛ پروژه regulated ممکن است Traceability و Approval بیشتری بخواهد.

تفاوت Test Strategy و Test Plan چیست؟

Strategy منطق Context، Risk، Evidence portfolio، Oracle، Fidelity، Gate و decision rights را تعریف می‌کند. Plan این منطق را برای Scope/Release مشخص به Schedule، effort، resource، task، milestone و deliverable تبدیل می‌کند. Strategy می‌تواند چند Plan را هدایت کند و Plan با هر Iteration تغییر بیشتری دارد.

چه کسی باید سند استراتژی تست را بنویسد؟

یک Test lead/architect/QE می‌تواند facilitator و editor باشد، اما Product، Development، Security/Privacy، Data، SRE/Operations و Domain expert باید Risk، Evidence و Trade-off را مشترک بسازند. Release owner مسئول تصمیم نهایی و پذیرش Residual risk است؛ QA تنها مالک کیفیت نیست.

آیا تیم Agile هم به Test Strategy نیاز دارد؟

بله، ولی Strategy می‌تواند سبک، Versioned و executable باشد: Core محصول، Risk/Evidence map، lane/gate در Repository و Overlay کوتاه Release. Scrum event یا Definition of Done جای تصمیم درباره Non-functional risk، exception، rollout و Production evidence را نمی‌گیرد.

هر چند وقت یک‌بار Strategy را به‌روز کنیم؟

تقویم ثابت به‌تنهایی کافی نیست. Quarterly review مفید است، اما تغییر Outcome/Risk/Architecture/Dependency/Tool/Regulation/Scale، Incident، escaped defect، SLO breach یا stale assumption باید فوراً Review را Trigger کند. هر تغییر Version، rationale، approver و اثر روی Pipeline/Plan داشته باشد.

جمع‌بندی؛ Strategy قرارداد تولید Evidence است

سند استراتژی تست جامع فهرست فعالیت‌های QA یا وعده کیفیت نیست. این سند Context و Risk را به سؤال، Boundary، Oracle، Fidelity، Coverage، Lane، Evidence، Owner و Decision وصل می‌کند؛ Unknown و Residual risk را آشکار نگه می‌دارد و با تغییر و Production learning سازگار می‌شود.

اگر از سند موجود فقط یک چیز را اصلاح می‌کنید، جدول Risk→Evidence بسازید. برای هر Risk بحرانی بپرسید Evidence معتبر و تازه چیست، کجا تولید می‌شود، چه Side effectی را نفی می‌کند و چه کسی نتیجه را می‌پذیرد. همین تبدیل، Pass rate سبز را به تصمیم قابل‌دفاع نزدیک‌تر می‌کند.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید