برنامه تست زمانی خوانده میشود که خواننده برای تصمیم واقعی به آن نیاز داشته باشد. رنگ، جدول و خلاصه میتوانند اصطکاک را کم کنند، اما سندی که نمیگوید «چه تصمیمی، تا چه زمانی، بر پایهٔ کدام ریسک و شواهد و با مسئولیت چه کسی» حتی اگر زیبا و کوتاه باشد، مصرف نمیشود. نوشتن برنامه تست یعنی طراحی یک قرارداد تصمیم زنده؛ نه پرکردن قالب و نه نوشتن رمان.
این راهنما مالک معماری اطلاعات و چرخهٔ مصرف Test Plan است: Decision → Audience → Risk/Scope → Approach/Evidence → Entry/Exit → Assumption/Dependency → Change/Acknowledgement → Gate/Archive. برای تفاوت مفهومی Test Strategy، Test Plan و Test Summary به راهنمای سه سند کلیدی تست و برای ارائهٔ نتایج اجرا به راهنمای ارائه نتایج تست مراجعه کنید.
پاسخ کوتاه: برنامه تست خوب چیست؟
یک Artifact نسخهدار است که برای یک Scope و بازهٔ مشخص، ریسکها و ادعاهای کیفیت را به رویکرد تست، منابع، محدودیتها، معیارهای تصمیم و مسئولان وصل میکند. نسخهٔ خوب در یک نگاه وضعیت تصمیم را نشان میدهد، برای جزئیات به Sourceهای معتبر پیوند دارد، با تغییر Context بهروزرسانی میشود و پس از تصمیم قابل بازسازی است.
| پرسش | پاسخ Plan | شاهد |
|---|---|---|
| چرا تست میکنیم؟ | Outcome، تصمیم و Failureهای مهم | Decision Brief |
| چه چیزی؟ | In/Out scope، نسخه و مرز | Scope Manifest |
| چگونه؟ | Risk response و Evidence strategy | Risk-to-Evidence Map |
| با چه چیزی و چه کسی؟ | Environment، data، capability و owner | Readiness Matrix |
| چه زمانی کافی است؟ | Entry/Exit/Gate با مخرج و استثنا | Decision Criteria |
| اگر تغییر کرد چه؟ | Trigger، impact review و acknowledgement | Change Log |
خواندنیبودن Outcome است، نه آرایش صفحه
خواننده سند را برای سرگرمی باز نمیکند. مدیر Release دنبال تصمیم و Exposure است؛ توسعهدهنده مرز و Oracle را میخواهد؛ QA رویکرد و Fixture؛ عملیات Dependency و Rollback؛ متخصص امنیت یا دسترسپذیری Scope حوزهٔ خود را. اگر اطلاعات بر اساس Task مخاطب قابل یافتن نباشد، Whitespace هم آن را نجات نمیدهد.
| مخاطب | Task | نمای نخست | Drill-down |
|---|---|---|---|
| Release owner | Go/Conditional/Hold | Decision، risk، gaps، expiry | Evidence packet |
| Product owner | Trade-off Scope/Value | Outcome و residual risk | Risk register |
| Engineering | Testability/Fix/Debug | Boundaries، oracle، dependency | contracts/logs |
| QA | طراحی و اجرای Evidence | approach، matrix، environment | cases/charters/runs |
| Operations | آمادگی و پاسخ | monitoring، support، rollback | runbook |
| Auditor/client | ردیابی ادعا | version، scope، approvals | immutable evidence refs |
Test Plan را با Strategy، Case و Summary یکی نگیرید
| Artifact | افق | پرسش اصلی | تغییر معمول |
|---|---|---|---|
| Organizational Test Policy | سازمان | تعهد و حاکمیت چیست؟ | کمتکرار |
| Test Strategy | محصول/برنامه | الگو و اصول کلی انتخاب Evidence چیست؟ | دورهای |
| Test Plan | Release/پروژه/سطح | برای این تصمیم چه میکنیم؟ | با Context |
| Test Design/Case/Charter | Feature/Risk | چه آزمون مشخصی اجرا میشود؟ | با طراحی |
| Test Run/Evidence | Build/اجرا | چه رخ داد؟ | هر اجرا |
| Test Summary/Release Memo | نقطه تصمیم | نتیجه و Exposure باقیمانده چیست؟ | هر Gate |
Plan نباید متن Strategy، Requirement یا همهٔ Test Caseها را کپی کند. باید نسخهٔ مورد اتکا را لینک کند و تصمیمهای Tailoring این Release را ثبت کند. صفحهٔ ۱۸۳۹ مالک شرح کامل سه سند است؛ اینجا روی مصرفپذیری و Trace میان آنها تمرکز داریم.
استاندارد قالب اجباری واحدی برای همهٔ تیمها نیست
ISO/IEC/IEEE 29119-2:2021 فرایندهای عمومی برای حاکمیت، مدیریت و اجرای تست در مدلهای مختلف چرخهٔ عمر تعریف میکند. ISO/IEC/IEEE 29119-3:2021 قالبهای مستنداتی را توصیف میکند که خروجی آن فرایندها هستند. صفحهٔ عمومی ISO متن کامل استاندارد را جایگزین نمیکند و این مقاله نیز ادعای انطباق ندارد؛ از منابع برای مرزبندی نسخه و Tailoring استفاده میکنیم، نه تحمیل یک سند ۵۰ صفحهای.
کاملبودن یعنی اطلاعات لازم برای تصمیم و تعهد موجود و قابل ردیابی باشد؛ نه اینکه هر عنوان ممکن در یک فایل تکرار شود.
در Scrum، Test Plan Artifact رسمی جداگانه نیست
Scrum Guide 2020 سه Artifact یعنی Product Backlog، Sprint Backlog و Increment و تعهدهای Product Goal، Sprint Goal و Definition of Done را تعریف میکند؛ Artifact رسمی مستقلی به نام Test Plan یا نقش جداگانهٔ QA تعریف نمیکند. تیم Scrum میتواند اطلاعات برنامهریزی تست را در Backlog، Definition of Done، Risk board و View زنده نگه دارد. راهنمای تخصصی نقش QA در Scrum مالک مشارکت در رویدادهاست.
Document، Data و Conversation را جدا اما متصل کنید
| لایه | نقش | نمونه | ریسک |
|---|---|---|---|
| Conversation | کشف ابهام و توافق | workshop/review | بدون ثبت فراموش میشود |
| Plan View | نمای تصمیم و navigation | one-pager/wiki | اگر دستی کپی شود drift میکند |
| Structured Data | Source of Truth | risk/scope/criteria registry | بدون context ناخوانا میشود |
| Evidence | اثبات اجرا/نتیجه | runs/logs/reports | بدون identity قابل ردیابی نیست |
| Decision record | پذیرش/اقدام/expiry | release memo | بدون owner غیرقابل اجراست |
جلسه جای Source of Truth نیست و Wiki نیز جای گفتگو را نمیگیرد. تصمیم جلسه باید در Plan/Decision Log ثبت شود؛ View باید از Registry مشترک بخواند؛ Evidence باید به Build و Plan version اشاره کند.
Plan Identity و وضعیت نسخه را در بالا قرار دهید
Living Test Plan Identity plan_id / version / status: draft | reviewed | active | superseded | closed product / release / build-range / target decision owner / contributors / approvers / decision_owner created_at / facts_as_of / last_reviewed / next_review source_registry / evidence_workspace / decision_log applicable_strategy / policy / requirement baselines change_summary / supersedes / archive_uri
last_updated بهتنهایی کافی نیست. facts_as_of میگوید داده و فرضها تا چه لحظهای معتبر بودهاند؛ Plan ممکن است امروز فقط از نظر نگارشی ویرایش شده باشد ولی Sourceهای هفتهٔ قبل را نمایش دهد.
از Decision Question شروع کنید
| فیلد | نمونهٔ ضعیف | نمونهٔ تصمیمپذیر |
|---|---|---|
| هدف | تست Checkout | تصمیم درباره ورود Build X به rollout کنترلشده |
| زمان | تا پایان تست | Gate در ۱۴:۰۰ با Evidence تا ۱۲:۰۰ |
| مالک | تیم | Release owner مشخص |
| گزینه | Pass/Fail | Go/Conditional/Hold + rollback |
| Exposure | باگهای باز | Risk claims، untested scope و uncertainty |
| بعد از تصمیم | انتشار | actions، monitoring، review و expiry |
Decision Brief question / options / decision_owner / decision_at business_outcome / critical_users / failure_consequences minimum_evidence / unavailable_evidence / uncertainty constraints / reversible_or_irreversible conditional_controls / rollback_trigger record_uri / review_or_expiry
Executive Summary را با Status Report اشتباه نگیرید
خلاصه Plan پیش از اجرا میگوید تصمیم، ریسک، Scope و روش شواهد چیست. Status Report در طول اجرا میگوید چه پیش رفته و چه مانعی هست. Test Summary پس از Cutoff، نتیجه و Exposure را میگوید. اگر همه در یک پاراگراف دستی ادغام شوند، زمان و منبع داده مخلوط میشود.
| نمای یکصفحهای | محتوا |
|---|---|
| Decision | سؤال، مالک، موعد، گزینهها |
| Top risks | Claim، Exposure، owner، planned evidence |
| Scope delta | داخل/خارج/تغییر از نسخه قبل |
| Readiness | محیط، داده، Build، dependency |
| Criteria | Entry/Exit و blockers با denominator |
| Gaps | Untested، unavailable، uncertainty |
| Next actions | owner، due، escalation |
| Freshness | Plan version، facts-as-of، links |
Scope را با Identity و Boundary بنویسید
«ماژول پرداخت در Scope است» معلوم نمیکند کدام نسخه، Channel، Role، State، Integration یا داده. Scope باید مرز رفتار و Artifact را نشان دهد. تحلیل Requirement و Testability پیشنیاز این کار است و در راهنمای تحلیل نیازمندی STLC بهتفصیل آمده است.
| بعد Scope | نمونه |
|---|---|
| Release identity | code/schema/config/flag/rule versions |
| User/role | guest/member/operator/admin |
| Journey/state | happy/error/timeout/retry/recovery |
| Surface | web/mobile/API/email/PDF/job |
| Boundary | provider/queue/database/cache |
| Data/locale | empty/typical/boundary/fa-IR |
| Quality characteristic | functional/performance/security/a11y |
| Operational phase | deploy/migrate/rollback/monitor |
Out of Scope حذف مسئولیت نیست
هر مورد خارج Scope باید دلیل، Exposure باقیمانده، Dependency، مالک ریسک و تاریخ/شرط بازبینی داشته باشد. «بدون تغییر» دلیل کافی نیست؛ تغییر وابستگی، داده، پیکربندی یا مسیر مجاور میتواند Regression بسازد. Out of Scope پنهان، عدم پوشش است؛ Out of Scope ثبتشده، ورودی تصمیم است.
Scope Item Contract scope_id / object / version / boundary / states classification: in | out | conditional | unknown reason / source / change_since_last planned_evidence_or_existing_evidence residual_exposure / risk_owner dependency / revisit_trigger / expiry approver / acknowledgement
ریسک را بهصورت Claim قابل ابطال بنویسید
«ریسک پرداخت بالاست» نه طراحی تست میدهد و نه تصمیم. Claim باید Failure، Trigger، Impacted outcome و Mechanism فرضی را مشخص کند. اولویت میتواند Likelihood/Impact/Detectability/Change/Uncertainty را ببیند، اما عدد جای تحلیل و مالک را نمیگیرد. تست مبتنی بر زمینه و Tailoring در راهنمای Context-Driven Testing مالک مستقل دارد.
| Risk Claim | Evidence response | Oracle |
|---|---|---|
| Retry پس از timeout سفارش تکراری میسازد | failure injection + replay | یک business effect |
| Migration تخفیف فعال را حذف میکند | pre/post population reconcile | identity/rule lineage |
| Role شعبه دادهٔ شعبه دیگر را میبیند | object/action authorization matrix | server decision + audit |
| Queue lag Promise را کهنه میکند | lag/ordering/expiry scenarios | version/freshness state |
| RTL شناسه را مبهم نمایش میدهد | mixed text + copy/AT review | logical identity preserved |
Risk-to-Evidence Map قلب Plan است
| فیلد | پرسش |
|---|---|
| risk_id/claim | چه چیزی ممکن است شکست بخورد؟ |
| priority rationale | چرا اکنون مهم است؟ |
| prevention/mitigation | فقط تست است یا کنترل دیگری هم هست؟ |
| test objective | چه عدمقطعیتی را کم میکنیم؟ |
| method/layer | review/unit/contract/system/exploratory/monitoring |
| oracle/invariant | چه چیزی نتیجه را معتبر میکند؟ |
| coverage boundary | کدام variant/state خارج میماند؟ |
| evidence owner/cutoff | چه کسی تا چه زمان؟ |
| residual exposure | پس از Evidence چه نامعلومی میماند؟ |
Approach را فهرست انواع تست ننویسید
لیست «Functional، Integration، Performance، Security، Usability» بدون هدف، Scope، روش، ابزار و Oracle اطلاعات کمی دارد. Approach باید توضیح دهد هر Risk در چه لایهای، با چه مدل/داده/محیطی و چرا آزمون میشود؛ چه چیزی خودکار نیست و چه Evidence دیگری آن Gap را پوشش میدهد.
| تصمیم Approach | ثبت لازم |
|---|---|
| Static/review | artifact، checklist/rule، reviewer |
| Unit/property/model | boundary، generator/model، invariant |
| Contract/integration | consumer/provider/version/failure |
| System/E2E | critical journey، environment، external boundary |
| Exploratory | charter، mission، timebox، notes |
| Non-functional specialist | profile، target، applicability، expert owner |
| Production control | canary، monitoring، alert، rollback |
Test Basis و Source Registry بسازید
بهجای کپی Requirement و Design، مرجع نسخهدار ثبت کنید. لینک بدون Version یا Baseline با تغییر مقصد ممکن است Plan تاریخی را بازنویسی کند. برای Sourceهای پویا، snapshot/hash یا release tag نگه دارید.
Source Registry source_id / type / owner / canonical_uri version_or_hash / approved_at / status scope_or_requirements_covered expected_update / freshness_rule conflicts / unresolved_questions snapshot_uri / access_classification consumers / change_notification
Assumption را حقیقت پنهان نکنید
Assumption ادعایی موقت است که Plan بر آن تکیه میکند. باید Validator، روش راستیآزمایی، Status، موعد و پیامد ابطال داشته باشد. عبارت «Sandbox پایدار است» تا زمانی که Health evidence و مالک ندارد، Fact نیست. فرض منقضی باید Gate را دوباره باز کند.
| وضعیت | معنا | اقدام |
|---|---|---|
| Proposed | هنوز پذیرفته نشده | Validator تعیین شود |
| Confirmed | برای Context/زمان مشخص شاهد دارد | Evidence link |
| Unverified | Plan به نامعلومی متکی است | Gap/contingency |
| Invalidated | شاهد خلاف آمده | Impact review |
| Expired | بازهٔ اعتبار تمام شده | revalidate یا HOLD |
| Superseded | فرض تازه جایگزین شده | history حفظ شود |
Assumption Contract assumption_id / claim / rationale owner / validator / validation_method status / evidence_ref / confirmed_at valid_for_builds / expires_at dependent_plan_items / invalidation_impact fallback / escalation / history
Dependency را با Deliverable و SLA تعریف کنید
| Dependency | Deliverable | Ready evidence | Fallback |
|---|---|---|---|
| Platform | Environment build X | health + config manifest | local stack |
| Data | synthetic fixture v3 | seed checksum | reduced dataset |
| Provider | sandbox callback v6 | contract + status | deterministic stub |
| Product | decision on refund policy | approved rule | scope conditional |
| Security | threat review | signed findings | HOLD risk owner |
| Operations | alert/runbook | dry run | no rollout |
«وابسته به تیم API» قابل مدیریت نیست. Delivery، owner، due، status source، notification، impact و contingency لازم است. مانع باید پیش از موعد Gate به مخاطب دارای اختیار Escalate شود؛ راهنمای ۱۸۴۳ مالک جزئیات ارتباط پیشرفت و مانع است: اطلاعرسانی مؤثر وضعیت تست.
Environment را با نام «Stage» تعریف نکنید
Environment Readiness environment_id / owner / purpose code / schema / config / flag / dependency versions data_fixture / seed / reset / clock network / auth / certificates / secrets source observability / log access / correlation capacity / known differences from production health checks / ready_at / expiry change freeze / incident contact
Plan نباید Secret را داخل خود نگه دارد؛ فقط منبع کنترلشده و سطح دسترسی را ارجاع دهد. تفاوت Environment با Production، مانند Stub، حجم داده، topology و schedule job، مستقیماً محدودیت Evidence است.
Test Data را به Risk و Reset وصل کنید
| Dataset | هدف | Lineage/کنترل |
|---|---|---|
| Minimal | Smoke و isolation | generated seed |
| Typical | journey عادی | fictional personas/entities |
| Boundary | limits/rounding/length/time | explicit generator |
| Failure | timeout/retry/conflict | deterministic fault |
| Dense | search/performance/UI | volume manifest |
| Migration | pre/post semantics | versioned source snapshot |
«دادهٔ واقعینما» کافی نیست. مالک، ساخت، PII classification، expiry، reset، concurrent isolation و expected invariant را ثبت کنید. Copy ناشناسسازینشده از Production یک میانبر مجاز نیست.
Entry Criteria را Readiness Checklist پویا کنید
Entry Criteria نباید مانع مصنوعی Handoff میان Dev و QA بسازد. هر Criteria باید دلیل، Evidence source، owner، deadline و رفتار در صورت عدم تحقق داشته باشد. بعضی فعالیتهای تست مثل review و طراحی پیش از Build آغاز میشوند؛ Entry مربوط به هر لایه را جدا کنید.
| لایه | Entry نمونه | اگر آماده نیست |
|---|---|---|
| Review | Requirement version و decision owner | سؤال/assumption ثبت |
| Component | contract و runnable story | testability task |
| Integration | provider contract/stub | conditional evidence |
| System | build identity/environment health | blocked با owner |
| Performance | profile/target/monitoring | نتیجه غیرقابل تفسیر |
| Release gate | cutoff و evidence snapshot | تصمیم defer/HOLD |
Exit Criteria را با درصد جادویی نسازید
«۹۵٪ تستها Pass» بدون مخرج، Risk distribution، Blocked/Not run، اهمیت Test و Build identity ممکن است گمراهکننده باشد. همین موضوع در صفحهٔ ۱۶۷۸ برای نتایج بهتفصیل بررسی شده است. Exit باید Evidence لازم برای Decision را تعریف کند، نه فقط فعالیت انجامشده.
| بعد Exit | قرارداد |
|---|---|
| Population | planned/executed/eligible tests و snapshot |
| Outcome vocabulary | pass/fail/blocked/not run/inconclusive |
| Risk coverage | Riskهای critical و evidence minimum |
| Defects/findings | severity + user impact + workaround + owner |
| Non-functional | target/profile/applicability |
| Residual gaps | untested/invalid/stale evidence |
| Operations | monitoring/canary/rollback/support |
| Decision | who may waive/condition/hold |
Exit Criterion Contract criterion_id / decision_supported / rationale population / denominator / cutoff / build formula_or_rule / outcome_treatment required_risk_evidence / forbidden_gaps data_source / owner / evaluator waiver_authority / conditional_control status / evidence_ref / evaluated_at
Schedule را از فهرست تاریخ به Flow تبدیل کنید
| Milestone | ورودی | خروجی | Decision |
|---|---|---|---|
| Plan review | scope/risk/source | active plan | کفایت approach |
| Environment ready | manifest/health | run-ready | شروع لایه system |
| Evidence checkpoint | runs/findings | gap/actions | re-scope/escalate |
| Cutoff | frozen snapshot | decision packet | Go/Conditional/Hold |
| Canary review | production signals | continue/rollback | expand/stop |
| Closure | decision/actions | archive/lessons | plan closed |
Deadline تست نباید فقط «روز قبل Release» باشد. زمان Fix، Retest، environment recovery، specialist review، data refresh و تصمیم را صریح کنید. Schedule باید Buffer و contingency داشته باشد، نه وعدهٔ قطعیت کاذب.
Capacity را با Availability اشتباه نگیرید
| محور | پرسش |
|---|---|
| Capability | مهارت Performance/Security/A11y/domain موجود است؟ |
| Availability | چه بازه و چه درصدی واقعاً آزاد است؟ |
| Throughput | با setup/retest/triage چه حجمی ممکن است؟ |
| Constraint | محیط، داده، review یا specialist گلوگاه است؟ |
| Interruption | support/incident/on-call چه ظرفیتی میگیرد؟ |
| Contingency | در غیبت یا تأخیر چه Scope/روش تغییر میکند؟ |
نام افراد و ساعت اسمی تضمین Evidence نیست. Capability gap را با آموزش لحظه آخری پنهان نکنید؛ Scope، specialist support یا Decision confidence را متناسب کنید.
RACI را جای Accountability واقعی نگذارید
| Decision/Artifact | Owner نمونه | Approver/Authority |
|---|---|---|
| Plan integrity | Test lead/quality engineer | program/release owner |
| Scope/value | product/process owner | release governance |
| Risk response | cross-functional owner | risk acceptor |
| Environment/data | platform/data owner | test lead for readiness |
| Specialist evidence | security/performance/a11y owner | domain gate |
| Residual risk | named business/technical owner | release decision owner |
| Go/Hold | release owner | defined governance |
QA نباید بهطور پیشفرض مالک همهٔ ریسکها یا تنها تأییدکنندهٔ کیفیت باشد. مسئول Plan مسئول صداقت و Traceability اطلاعات است؛ مسئول پذیرش Risk باید اختیار اثر آن را داشته باشد.
Information Architecture سهلایه بسازید
| لایه | هدف | محتوا |
|---|---|---|
| Layer 1: Decision View | خواندن در ۲–۵ دقیقه | decision/top risks/scope delta/readiness/gaps/actions |
| Layer 2: Plan Contract | اجرای هماهنگ | identity/scope/risk/approach/criteria/dependencies/change |
| Layer 3: Evidence Sources | بازسازی و drill-down | requirements/models/cases/charters/runs/logs/reports/runbooks |
هر Claim در Layer ۱ باید به Contract و Evidence برسد. هر جزئیات Layer ۳ لازم نیست در View کپی شود. این معماری میتواند در Wiki، repository، issue tracker یا ابزار مدیریت تست پیاده شود؛ ابزار باید رفتار تیم و نیاز Trace را پشتیبانی کند، نه اینکه قالب را تعیین کند.
Progressive Disclosure را برای مخاطب طراحی کنید
- در بالای صفحه: Decision، Facts-as-of و Owner؛
- پس از آن: Top risks، Scope delta و Critical gaps؛
- بخشهای جمعشونده: جزئیات Approach، Matrix و Environment؛
- جداول با ستونهای ثابت و شناسههای لینکپذیر؛
- تعریف اصطلاح در نخستین استفاده و Glossary برای واژهٔ دامنهای؛
- لینک مستقیم به Section، نه فقط صفحهٔ اصلی ابزار؛
- نمای متنمحور و دسترسپذیر برای دیاگرامها و رنگها؛
- تاریخ/نسخه در خود View، نه فقط History پنهان ابزار.
رنگ و دیاگرام باید معنای افزوده داشته باشند
سبز/قرمز بهتنهایی Status یا Scope را منتقل نکند؛ متن و Icon/label لازم است. دیاگرام وقتی مفید است که Boundary، Flow یا Dependency را فشرده کند و Source version داشته باشد. Screenshot معماری که قابل جستوجو، بهروزرسانی یا خواندن با فناوری کمکی نیست، Source of Truth ضعیفی است.
لینکدادن از کپیکردن بهتر است—اگر Link Contract داشته باشد
| خطر لینک | کنترل |
|---|---|
| مقصد تغییر میکند | version/tag/hash/snapshot |
| دسترسی ندارند | audience access check/summary |
| لینک میشکند | link validation/owner |
| ابهام مقصد | descriptive label + section anchor |
| چند Source متعارض | canonical source registry |
| حذف تاریخی | retention/archive policy |
| داده حساس | classification/access/minimized view |
Plan Review را بر پرسش تصمیم اجرا کنید
- آیا سؤال تصمیم، مالک و موعد روشن است؟
- آیا مهمترین Failureها به Risk Claim تبدیل شدهاند؟
- آیا Scope و Out-of-Scope با Exposure و owner ثبتاند؟
- آیا Approach برای هر Risk شواهد معنادار میسازد؟
- آیا Environment/Data/Dependency واقعاً آماده و نسخهدارند؟
- آیا Exit criteria مخرج، cutoff و Blocked treatment دارند؟
- آیا فرض یا منبع منقضی وجود دارد؟
- آیا مخاطب میتواند بخش مورد نیازش را سریع پیدا کند؟
- آیا تغییر از نسخه قبل و اثر آن مشخص است؟
- آیا Gap و disagreement بهجای حذف، ثبت شدهاند؟
Review جلسهٔ امضا برای اثبات خواندهشدن نیست. Comment، question، decision و action باید شناسه، owner و closure داشته باشند. سکوت ذینفع را موافقت تلقی نکنید مگر Governance صریحاً چنین قاعدهای دارد.
Acknowledgement با Approval یکسان نیست
| عمل | معنا |
|---|---|
| Viewed | صفحه باز شده؛ فهم یا توافق ثابت نیست |
| Acknowledged | تغییر/اطلاع دریافت شده |
| Reviewed | بخش مسئولیت بررسی شده و Comment ثبت است |
| Approved | فرد دارای اختیار نسخه را پذیرفته |
| Risk accepted | Exposure مشخص با شرایط/Expiry پذیرفته شده |
| Decision recorded | گزینه، دلیل، actions و follow-up تثبیت شده |
Change Trigger تعریف کنید
Living بودن به معنای ویرایش بیپایان و بیردپا نیست. Triggerها را از قبل مشخص کنید: Scope، Requirement، Architecture، Contract، Config/Flag، Risk، Environment، Schedule، Capacity، Finding بحرانی یا External dependency. هر تغییر باید Impact، affected sections/evidence، reviewer و acknowledgement داشته باشد.
Plan Change Record change_id / detected_at / source / initiator old_value / new_value / reason affected_risks / scope / approach / criteria / schedule evidence_invalidated / retest_needed impact_assessment / owner / due reviewers / acknowledgements / dissent plan_version / effective_at / notification decision_or_follow_up
Versioning و Snapshot از Drift جلوگیری میکند
برای Gate، Snapshot غیرقابلابهام از Plan، Source versions و Evidence cutoff بسازید. بعد از تصمیم، Plan active را بیردپا ویرایش نکنید؛ Correction یا نسخهٔ تازه با تاریخ مؤثر بسازید. تاریخچه ابزار اگر فقط Diff فنی باشد، Decision history را جایگزین نمیکند.
| وضعیت Plan | ویرایش | استفاده |
|---|---|---|
| Draft | آزاد با attribution | گفتگو |
| Reviewed | با change note | آماده activation |
| Active | Trigger + impact + version | اجرای جاری |
| Frozen for decision | فقط correction جدا | Gate snapshot |
| Superseded | غیرقابل جایگزینی | history |
| Closed | archive/correction policy | audit/learning |
Plan Drift را ماشینی پایش کنید
- Source version مورد انتظار با نسخهٔ جاری؛
- Scope item بدون Risk owner یا expiry؛
- Assumption منقضی یا بدون Validator؛
- Dependency overdue و بدون contingency؛
- Exit criterion بدون denominator/cutoff؛
- Environment manifest ناسازگار با Build اجرا؛
- Change تأثیرسنجینشده یا بیاطلاع؛
- Evidence متعلق به Plan/Build دیگر؛
- لینک شکسته یا دسترسیناپذیر برای مخاطب؛
- Decision/waiver منقضی.
اتوماسیون Plan جای قضاوت را نمیگیرد
Schema میتواند فیلد اجباری، شناسه یکتا، تاریخ، لینک و Version mismatch را پیدا کند. نمیتواند خوببودن Risk Claim، کفایت Evidence، واقعیبودن Mitigation یا اختیار Risk owner را بهتنهایی تعیین کند. Validation ماشینی برای completeness و drift است؛ Review انسانی برای معنا و تصمیم.
آزمایش بازتولیدپذیر: سند کامل، قرارداد ناقص
Fixture ساختگی SYN-LIVING-PLAN-01 یک سند با هشت بخش متداول، ۱۱۸۰ واژه، پنج جدول و دو دیاگرام دارد. کنترل سطحی فقط حضور بخشها، کوتاهی نسبی و عنصر بصری را میسنجد. کنترل دوم روی Decision/Scope/Risk/Assumption/Exit/Source/Change contract اجرا میشود.
$ node .post-1825-experiment.js runtime: Node.js v24.18.0 fixture: SYN-LIVING-PLAN-01 superficial.requiredSections = 8 superficial.presentSections = 8 superficial.readableLength = true superficial.visualElements = 7 superficial.decision = PASS decision contract findings: decision-without-owner out-of-scope-without-risk-owner: refund risk-without-owner-or-response: SYN-R2 invalid-or-expired-assumption: SYN-A2 ambiguous-exit-denominator: 95% passed stale-source-reference: checkout-api v5 vs v6 unreviewed-unacknowledged-change: SYN-C17 decisionContract.decision = HOLD
PASS نخست ثابت نمیکند سند در دنیای واقعی خواندنی یا مفید است؛ فقط شروط ساختگی قالب را برآورده میکند. HOLD دوم نیز الگوریتم عمومی کیفیت Plan نیست؛ هفت Contract عمداً ناقص Fixture را بازتاب میدهد. نتیجه نشان میدهد Section count و ظاهر، پرسش تصمیم را پوشش نمیدهند.
حدود اعتبار آزمایش مصنوعی
- هیچ پروژه، تیم، Requirement، محیط، Test Case یا Release واقعی بررسی نشده است.
- ۱۱۸۰ واژه، هشت بخش، پنج جدول، دو دیاگرام و ۹۵٪ Benchmark یا توصیهٔ عمومی نیستند.
- اسکریپت خوانایی انسانی، صحت Risk، کیفیت Strategy یا انطباق ISO را نمیسنجد.
- Source، Scope، Assumption، Risk و Change همگی عمداً ساختگیاند.
- PASS/HOLD گواه، استاندارد، تخمین موفقیت یا مدل Release نیست.
- آزمایش فقط حسابداری قرارداد نوشتهشده را بازتولید میکند.
آزمایشگاه فارسی کاملاً ساختگی
در یک repository محلی، Plan خیالی SYN-PLAN-FA-01 برای Release خیالی فروشگاه بسازید. همه Entityها، Riskها، تاریخها، مبلغها و کاربران با SYN-* باشند؛ External service با Stub بدون اینترنت جایگزین شود. هیچ نام، شماره، شرکت، حساب، پرداخت، Token، Secret، قرارداد یا دادهٔ Production وارد نشود.
| Lab fault | کنترل | خروجی |
|---|---|---|
| Decision owner حذف شده | schema + review | unowned decision |
| Refund خارج Scope بیمالک | scope contract | residual-risk gap |
| API v5 در Plan و v6 در registry | source diff | stale reference |
| Assumption تاریخگذشته | expiry job | revalidation action |
| Exit «۹۵٪ Pass» | denominator validator | ambiguous criterion |
| Change بدون acknowledgement | change gate | notification gap |
| لینک فارسی شکسته | link/access check | unreachable source |
| Evidence Build دیگر | identity match | invalid reuse |
Lab فقط Traceability، Versioning و Information Architecture را تمرین میکند؛ دربارهٔ بازار ایران، تیم واقعی، طول مناسب سند یا صحت Release ادعایی ندارد.
قالب One-Page Decision View
[Plan ID/version/status] [facts as of] [owner] Decision question / owner / due / options Outcome and critical users Top risks: claim | exposure | response | owner | evidence state Scope delta: in | out | conditional | unknown Approach summary by risk/layer Readiness: build | environment | data | dependencies | capability Entry/Exit and evidence cutoff Open gaps / assumptions / disagreements Actions: owner | due | escalation Links: full contract | source registry | evidence | decision log Change since previous / acknowledgement / next review
قالب Full Living Test Plan
| بخش | حداقل محتوای تصمیمساز |
|---|---|
| Identity | version/status/facts-as-of/owners/sources |
| Decision | question/options/deadline/authority/reversibility |
| Context | outcome/users/architecture/change/constraints |
| Scope | in/out/conditional/unknown + exposure |
| Risks | claims/priorities/owners/responses |
| Approach | risk-to-evidence/oracles/layers/gaps |
| Basis | versioned source registry |
| Readiness | environment/data/dependency/capability |
| Flow | milestones/checkpoints/cutoff/contingency |
| Criteria | entry/exit/denominator/waiver/controls |
| Governance | review/approval/risk acceptance/escalation |
| Change | triggers/diff/impact/acknowledgement/versioning |
| Closure | decision/actions/monitoring/archive/lessons |
Plan در تیم کوچک و محصول کمریسک
ممکن است One-page بههمراه Risk board و لینک به Evidence کافی باشد. حذف بخش زمانی مجاز است که اطلاعات لازم جای دیگری نسخهدار و قابل دسترسی باشد یا برای Decision کاربرد نداشته باشد. «کوچک» بودن تیم دلیل حذف Scope، owner، assumption یا Exit نیست؛ فقط شکل ثبت را سبکتر میکند.
Plan در محصول پرریسک یا چندتیمی
Plan میتواند Hierarchy داشته باشد: Master decision view، planهای سطح/حوزه و evidence workspace. Parent/child scope، shared dependencies، cross-plan risks، common release identity و aggregation rule را تعریف کنید. جمعکردن چند «سبز» مستقل لزوماً تصمیم کل سامانه را سبز نمیکند؛ Integration و complete workflow evidence لازم است.
| سطح | مالکیت | Aggregation |
|---|---|---|
| Program/Master | release decision و cross-cutting risk | گپ/وابستگی و veto rules |
| Product/System | journey/integration/environment | risk evidence |
| Specialist | security/performance/a11y/data | domain gate + limitations |
| Team/Component | change-specific tests | identity + source links |
| Operations | deploy/canary/monitor/rollback | runtime gate |
Plan Quality را با Outcomeهای مصرف بسنجید
| Metric | پرسش | دام |
|---|---|---|
| Decision retrieval time | مالک تصمیم/Gap را چقدر سریع مییابد؟ | سرعت بدون صحت |
| Unowned item rate | ریسک/Dependency/Action بیمالک چند است؟ | مالک اسمی بدون اختیار |
| Stale-source rate | مرجع نسخه قدیمی چند است؟ | تازگی بدون relevance |
| Change acknowledgement latency | افراد مسئول چه زمان آگاه میشوند؟ | Viewed بهجای understood |
| Decision surprise | چه Gapی در Gate تازه کشف شد؟ | مقصرسازی |
| Evidence trace success | Claim تا Build/Run قابل پیگیری است؟ | لینک بدون identity |
| Plan rework | کدام ابهام باعث بازطراحی دیرهنگام شد؟ | کاهش مستندات بهجای علت |
View count، طول سند و تعداد Comment میتوانند Signal باشند، نه Outcome. سند ممکن است زیاد باز شود و تصمیم غلط بسازد یا کم باز شود چون تیم از API/board همان Source را مصرف میکند.
Closure و Archive را فراموش نکنید
- نسخهٔ frozen Plan و Source registry؛
- Evidence cutoff و Release identity؛
- تصمیم، دلیل، dissent و Risk acceptance؛
- شرایط Conditional release و Monitoring؛
- Actions باز با owner/due؛
- Correctionهای بعدی بدون بازنویسی تاریخ؛
- Retention/classification و حذف داده حساس؛
- Lessonهایی که Strategy/Template/DoD را تغییر میدهند؛
- Superseding plan و لینک دوطرفه.
آمادگی عملیاتی، Support، Rollback و Monitoring دامنهای فراتر از خود Plan دارند؛ برای آنها به راهنمای تست آمادگی عملیاتی ارجاع دهید و فقط تعهد/شاهد مربوط را در Plan پیوند دهید.
برنامهٔ Pilot سیروزه
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۳ | انتخاب یک Release و Decision question | Decision Brief |
| روز ۴–۶ | Audience task و Source inventory | View map/registry |
| روز ۷–۱۰ | Scope/Risk/Assumption workshop | contracts v1 |
| روز ۱۱–۱۳ | Risk-to-Evidence و criteria | Plan v1 |
| روز ۱۴–۱۶ | Environment/data/dependency readiness | readiness matrix |
| روز ۱۷–۱۹ | One-page view و accessibility review | Decision View |
| روز ۲۰–۲۲ | Review/acknowledgement workflow | active Plan |
| روز ۲۳–۲۵ | Change trigger و drift checks | version/change evidence |
| روز ۲۶–۲۸ | Freeze/Gate/decision dry run | snapshot + memo |
| روز ۲۹–۳۰ | مصاحبه مصرف و retrospective | template/strategy improvements |
ضدالگوهای نوشتن برنامه تست
- شروع از قالب قدیمی پیش از سؤال تصمیم؛
- یک سند برای همه بدون Audience task؛
- Executive Summary بدون owner و facts-as-of؛
- کپی Strategy، Requirement و Test Case داخل Plan؛
- Scope در حد نام ماژول؛
- Out of Scope بدون Exposure و risk owner؛
- Risk در حد «بالا/متوسط/کم»؛
- Approach به شکل فهرست انواع تست؛
- انتخاب ابزار پیش از Evidence need؛
- Source link بدون version/hash؛
- Assumption بدون Validator و expiry؛
- Dependency بدون deliverable و fallback؛
- Environment فقط با نام Stage؛
- قرار دادن Secret و داده واقعی در Plan؛
- Entry criteria بهعنوان دیوار Dev→QA؛
- Exit «۹۵٪ Pass» بدون denominator؛
- برابرگرفتن Test count با Risk coverage؛
- تاریخ پایان بدون Fix/Retest/Decision buffer؛
- Availability اسمی بهجای Capability؛
- QA بهعنوان مالک همهٔ Riskها؛
- رنگ بهعنوان تنها حامل Status؛
- دیاگرام screenshot بینسخه؛
- Wiki بهعنوان Sourceهای کپیشده و متناقض؛
- Viewed بهعنوان Approval؛
- سکوت بهعنوان Risk acceptance؛
- Living document بدون Change Log؛
- ویرایش Snapshot بعد از تصمیم؛
- Automation برای قضاوت معنای Risk؛
- اندازهگیری کیفیت با طول/View count؛
- بستن Plan بدون archive، action و expiry.
چکلیست برنامه تست زنده و خواندنی
- Plan ID، version و status دارد.
- Facts-as-of جدا از last-edited است.
- Decision question، owner و موعد روشناند.
- گزینههای Go/Conditional/Hold تعریفاند.
- Outcome و کاربران/عملیات بحرانی ثبتاند.
- مخاطب و Task هر View معلوم است.
- Strategy و Summary از Plan جدا هستند.
- Tailoring و دلیل آن ثبت است.
- Scope دارای release identity است.
- Role، State، Surface و Boundary در Scope است.
- Out of Scope reason و risk owner دارد.
- Conditional/Unknown scope پنهان نشده است.
- Risk بهصورت Failure claim نوشته شده است.
- Priority rationale و owner دارد.
- هر Risk به Evidence response وصل است.
- Oracle/Invariant روشن است.
- Evidence gap و residual exposure ثبتاند.
- Approach فقط لیست نوع تست نیست.
- Source registry canonical و نسخهدار است.
- لینکها section-level و دسترسپذیرند.
- Assumption validator/status/expiry دارد.
- ابطال Assumption impact و fallback دارد.
- Dependency deliverable/owner/due دارد.
- Contingency و Escalation روشناند.
- Environment manifest با Build سازگار است.
- Data lineage/reset/privacy ثبت است.
- Entry criteria برای هر لایه Tailor شده است.
- Entry Handoff مصنوعی ایجاد نمیکند.
- Exit population/denominator/cutoff دارد.
- Blocked/Not run/Inconclusive treatment معلوم است.
- Risk evidence از Test pass rate جداست.
- Waiver authority و control روشناند.
- Schedule شامل Fix/Retest/Decision است.
- Capacity، capability و constraint جدا هستند.
- Risk acceptor اختیار متناسب دارد.
- Decision View به Contract/Evidence drill-down دارد.
- رنگ تنها حامل معنا نیست.
- دیاگرام Source/version و text alternative دارد.
- Review بر پرسش تصمیم متمرکز است.
- Comment/action owner و closure دارند.
- Acknowledgement از Approval جداست.
- Change triggerها تعریف شدهاند.
- Impact و evidence invalidation ثبت میشوند.
- Gate snapshot پس از تصمیم بازنویسی نمیشود.
- Drift check برای source/assumption/criteria اجرا میشود.
- Quality metrics Outcome مصرف را میسنجند.
- Closure شامل archive/actions/monitoring/expiry است.
- دقیقاً پنج FAQ و Meta پیش از انتشار کنترل شدهاند.
جمعبندی: Plan باید تصمیم را کوتاه کند، نه حقیقت را
برنامه تست خواندنی از حذف جزئیات بهدست نمیآید؛ از معماری درست بهدست میآید. Decision View کوتاه است، Plan Contract تعهدها و مرزها را نگه میدارد و Evidence layer امکان بررسی را میدهد. Risk، Scope، Assumption، Source، Criteria و Change نسخهدار میشوند تا تیم هنگام تغییر Context بداند چه شواهدی دیگر معتبر نیست و چه کسی باید تصمیم بگیرد.
سؤالات متداول درباره نوشتن برنامه تست
تفاوت Test Strategy و Test Plan چیست؟
Strategy الگوها، اصول و رویکردهای نسبتاً پایدار محصول یا سازمان را تعیین میکند؛ Plan آنها را برای یک Release، پروژه، سطح یا تصمیم مشخص Tailor میکند و Scope، Risk، منابع، Criteria و مسئولان همان Context را میسازد. Plan باید Strategy نسخهدار را ارجاع دهد و استثنا/تغییر خود را ثبت کند.
برنامه تست باید چند صفحه باشد؟
عدد ثابتی ندارد. یک Decision View میتواند یک صفحه باشد و جزئیات در Contract و Sourceهای پیوندی قرار گیرند. کفایت را با یافتن پاسخ تصمیم، Traceability، Freshness و نبود Gap پنهان بسنجید، نه تعداد صفحه یا واژه. محصول پرریسک ممکن است Plan سلسلهمراتبی بخواهد.
آیا تیم Agile یا Scrum به Test Plan نیاز دارد؟
Scrum Guide Test Plan را Artifact رسمی جدا نمیداند. بااینحال تیم برای شفافیت Risk، Scope، Evidence، Dependency و تصمیم به اطلاعات برنامهریزی نیاز دارد. این اطلاعات میتواند در Backlog، Definition of Done، Wiki و Registry مشترک بهشکل سبک و زنده باشد؛ یک فایل سنگین اجباری نیست.
چه کسی باید برنامه تست را بنویسد و تأیید کند؟
یک مالک مشخص باید انسجام و Versioning Plan را حفظ کند، اما محتوا محصول همکاری Product، Engineering، QA، Operations و متخصصان حوزه است. Approval و Risk acceptance باید به افراد دارای اختیار مربوط برسد؛ QA بهتنهایی مالک همهٔ Riskها یا تصمیم Release نیست.
چگونه بفهمیم برنامه تست واقعاً خوانده و استفاده میشود؟
View count کافی نیست. ببینید مخاطب میتواند Decision owner، Scope، Top risk، Gap و Action را درست و سریع بازیابی کند؛ تغییرها acknowledgement میگیرند؛ Surprise در Gate کم میشود؛ Sourceهای stale و موارد بیمالک کاهش مییابد؛ و Claim تا Build/Evidence قابل ردیابی است. مصرف میتواند از View، board یا API مشترک باشد.
