مدیریت تست

استراتژی، برنامه و خلاصه تست؛ طراحی Control Loop سه‌سندی

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

ممکن است تیم یک Test Strategy شیک، یک Test Plan کامل و یک Test Summary پر از نمودار داشته باشد، اما هنوز نتواند به یک سؤال ساده جواب دهد: آیا Summary دقیقاً همان Objectiveها، Riskها، Build، Outcome vocabulary و Evidence policy را گزارش می‌کند که Plan از Strategy گرفته بود؟ اگر پاسخ قابل ردیابی نباشد، سه سند داریم اما سیستم کنترل تست نداریم.

این راهنما تفاوت استراتژی تست، برنامه تست و گزارش خلاصه تست را نه به‌صورت سه فهرست جدا، بلکه به‌عنوان یک Control Loop نسخه‌دار توضیح می‌دهد: Strategy قواعد و انتخاب‌های پایدارتر را تعریف می‌کند؛ Plan آن‌ها را برای Initiative/Release/Scope مشخص Tailor می‌کند؛ Execution واقعیت را تولید می‌کند؛ Summary شواهد، انحراف‌ها و ریسک باقی‌مانده را در Snapshot منجمد می‌کند؛ و Learning فقط از مسیر Change Proposal و Authority مناسب به Strategy یا Plan بعدی برمی‌گردد.

پاسخ کوتاه: Test Strategy، Test Plan و Test Summary چه فرقی دارند؟

سند/Viewپرسش غالبافق و Scopeخروجی تصمیم
Test Strategyبا چه اصول، Risk model، Evidence policy و Decision rules تست را هدایت می‌کنیم؟سازمان، محصول، Portfolio یا Initiative؛ نسبتاً پایدارقواعد Tailoring، حداقل‌ها، Authority و Exception
Test Planبرای Scope و تصمیم مشخص چه چیزی، چرا، چگونه، چه وقت و با چه منابعی انجام می‌شود؟Release/Project/Iteration/Level/Activity مشخصRisk-to-evidence commitments، readiness، schedule و control baseline
Test Summaryتا Cutoff مشخص چه چیزی واقعاً انجام شد و چه Evidence/Gap/Risk باقی است؟Build/Release/Population/Window منجمدClosure assessment، recommendation، actions و correction history

Strategy «همیشه سازمانی و ثابت»، Plan «همیشه پروژه‌ای و مفصل» و Summary «همیشه فقط پایان کار» نیست. نام و افق باید در Document Contract روشن شود. یک تیم کوچک می‌تواند هر سه View را از یک Registry مشترک تولید کند، اما معنا، وضعیت و Authority آن‌ها نباید مخلوط شود.

مالکیت این مقاله و مرز با راهنماهای تخصصی

این صفحه مالک Interface Contract و Control Loop میان Strategy، Plan و Summary است. برای عمق هر سند یا موضوع مجاور به مقالهٔ مالک آن بروید.

نیازمالک محتواییمرز این راهنما
مقایسه ساده Plan، Strategy و Test Caseتفاوت Test Plan، Test Strategy و Test Caseاینجا چرخه و Handoff سه سند مدیریتی را می‌سازیم.
طراحی عمیق Living Test Planنوشتن برنامه تست زندهاینجا فقط Contract ورودی/خروجی Plan را تعریف می‌کنیم.
قالب و حسابداری Test Summaryگزارش خلاصه تستاینجا اتصال Summary به Plan/Strategy و feedback مطرح است.
Freshness و Documentation Driftمستندات تست زندهاینجا Cross-document consistency را اعمال می‌کنیم.
Risk model و اولویت‌بندی تستتست مبتنی بر ریسکاینجا Risk taxonomy را میان سه سند هم‌تراز می‌کنیم.
Status و گزارش تصمیم انتشارگزارش تست حرفه‌ایSummary منجمد را از Status جاری جدا می‌کنیم.
Run، Retest و Closure workflowچرخه اجرای تستExecution بین Plan و Summary است، نه بخشی از متن Strategy.
Decision rights و مالکیت کیفیترهبری تضمین کیفیتاینجا Author، Reviewer و Risk/Release authority تفکیک می‌شوند.
Evidence Packet و ارائه به مخاطبارائه نتایج تستاینجا Source identity و lineage سه سند مطرح است.

سه Template کافی نیست؛ Interface لازم است

Template فقط می‌گوید هر سند چه فیلدهایی دارد. Interface Contract می‌گوید فیلدهای مشترک چگونه منتقل، Tailor، اندازه‌گیری و reconciled می‌شوند. اگر Strategy پنج Outcome داشته باشد ولی Plan و Summary فقط Pass/Fail را بفهمند، یا Plan برای Build B17 باشد و Summary داده B16 را جمع کند، کامل‌بودن هر فایل مستقل فایده‌ای ندارد.

InterfaceتعهدFailure نمونه
Strategy→Planنسخه، Objective، Risk class، Evidence policy، vocabulary، AuthorityPlan از Strategy قدیمی Tailor شده
Plan→ExecutionScope/Build/Data/Environment، Artifact versions، Run policyRun روی Build یا Config خارجی
Execution→SummaryAttempt normalization، Population، Cutoff، Evidence provenanceرویداد تکراری یا Not Run حذف شده
Plan→Summaryهمان Objective/Risk/Exit/Deviation baselineSummary به Plan Release دیگری ارجاع می‌دهد
Summary→LearningFinding، causal limit، action، change proposalیک شکست محلی Strategy را بی‌Review عوض می‌کند
Learning→Strategy/PlanAuthority، review، effective version، affected scopeslesson learned بدون owner/decision می‌ماند

مدل Control Loop سه‌سندی

Context / obligations / product risks
        ↓
TEST STRATEGY: objectives, risk/evidence rules, vocabulary, authority
        ↓ inheritance + explicit tailoring/exception
TEST PLAN: scoped commitments, sources, resources, readiness, exit policy
        ↓ versioned run manifests
EXECUTION / MONITORING / CONTROL: actuals, changes, deviations, evidence
        ↓ normalized closure snapshot
TEST SUMMARY: reconciliation, risk closure, limitations, recommendation
        ↓ proposals—not silent mutation
LEARNING / CHANGE DECISION: keep, revise, retire, experiment
        ↺ effective Strategy or next Plan version

این جریان الزاماً Waterfall یا مرحله‌ای نیست. Monitoring و Control مداوم‌اند؛ Plan می‌تواند در پاسخ به Risk تازه نسخه بخورد؛ Summary می‌تواند برای Milestone یا Closure تولید شود؛ و Strategy نیز با Evidence تجمیعی و تصمیم مجاز تغییر کند. Loop ترتیب منطقی روابط را نشان می‌دهد، نه یک فرایند ثابت جهانی.

منابع رسمی چه می‌گویند و چه نمی‌گویند؟

صفحه عمومی ISO/IEC/IEEE 29119-2:2021 فرایندهای عمومی برای Governance، Management و Implementation تست را در مدل‌های مختلف چرخه عمر توصیف می‌کند. صفحه عمومی ISO/IEC/IEEE 29119-3:2021 می‌گوید Templateهای مستندات تست خروجی فرایندهای بخش ۲ هستند. این Abstractها متن کامل استاندارد، Template آمادهٔ این مقاله، الزام به سه فایل یا مدرک انطباق نیستند.

ISTQB CTAL Test Management v3.0 برنامه‌ریزی، Monitoring/Control، مدیریت Deviation و Risk جدید و Completion بر پایه Exit Criteria را به Plan و Strategic objectives مرتبط می‌کند. این منبع آموزشی است؛ نقش‌ها، واژگان و فرایند آن باید Tailor شوند و گواهی شخص یا استفاده از اصطلاحات، کفایت Strategy یا کیفیت محصول را ثابت نمی‌کند.

Test Policy را با Test Strategy مخلوط نکنید

Artifactافقپرسشنمونه
Quality/Test Policyسازمانی و هنجاریچه تعهدها و اصولی الزام‌آورند؟حفاظت داده، independence، retention
Test Strategyسازمان/محصول/Program/Initiativeبرای Context چه رویکرد و Evidence modelی داریم؟Risk classes، test levels، exception policy
Test PlanScope/Release/Activityبرای تصمیم مشخص چه تعهد اجرایی داریم؟B17 risk-to-evidence، environment، cutoff
Test DesignCondition/Featureادعا چگونه آزموده می‌شود؟Scenario، Case، Charter، Script
Status Reportجاری و تکرارشوندهاکنون نسبت به Plan کجاییم؟progress، blocker، forecast
Test SummarySnapshot/Closureچه Evidence و Gapی تا Cutoff داریم؟reconciliation، residual risk، actions
Decision Recordرویداد تصمیمچه کسی چه گزینه‌ای را چرا پذیرفت؟Go/Hold/conditional + expiry

Test Strategy چیست؟

Test Strategy یک قرارداد جهت‌دهنده است که برای دامنه و افق مشخص، Objectives، Quality/Risk model، Evidence policy، Test approach، shared constraints، Vocabulary، Governance و Tailoring/Exception rules را تعیین می‌کند. Strategy نباید کاتالوگ ابزار و Test Type باشد؛ باید نشان دهد انتخاب‌ها برای چه مسئله‌ای و با چه محدودیتی انجام شده‌اند.

Strategy «قانون اساسی ثابت» نیست

Strategy نسبت به Plan پایدارتر است، اما immutable نیست. معماری، ریسک، بازار، Dependency، Incident، Capability تیم و Obligation می‌توانند آن را تغییر دهند. تغییر باید Proposal، Evidence، Scope اثر، Authority، effective version و migration داشته باشد. عبارت «معمولاً ایستا» باعث می‌شود Ruleهای منسوخ سال‌ها به Planهای جدید ارث برسند.

محرک Strategy reviewEvidenceتصمیم‌های ممکن
تغییر معماری/Interfacedependency map و failure historyرویکرد/لایه/فیدلیتی جدید
Incident یا escaped risktimeline و control gapEvidence profile یا prevention change
False confidencegreen signal در برابر outcomeOracle/metric/gate redesign
هزینه/کندی Suitefeedback/resource/reworkmove/split/retire/experiment
Obligation جدیدauthorized applicability interpretationmandatory evidence/retention
Capability changeskills/tool/platform constraintsphased adoption یا exception

حداقل Strategy Contract

TEST-STRATEGY: SYN-STRAT-v3
Applies-to: Marketplace checkout product / releases B17–until superseded
Objectives: SYN-O1 correctness; SYN-O2 recoverability
Quality/Risk model: critical / material / routine; rules RISK-v2
Evidence policy: critical → invariant + fault-recovery + reconciliation
Approach: smallest responsible boundary; selected composition evidence
Shared contracts: outcome vocabulary, severity semantics, identity, time, money
Decision rights: release-owner-a; evidence challenge=qa-governance
Tailoring: rationale + compensating evidence + owner + expiry
Change triggers: architecture, obligation, incident, signal failure, cost threshold
Facts-as-of / review-by: 2026-08-13 / 2026-11-13

Strategy باید چه چیزهایی را به Plan ارث دهد؟

FieldInheritanceTailoring مجازEvidence تغییر
Objective IDsهمه Applicable objectivesخارج Scope با دلیل/ownerapplicability record
Risk taxonomyنام/تعریف/authority مشترکLocal risk اضافه شودmapping بدون بازتعریف خاموش
Evidence profilesحداقل براساس Risk classقوی‌تر یا compensating exceptionexception record
Outcome vocabularyیکسان برای aggregationLocal substatus با mappingnormalization contract
Identity/time/unitCanonical semanticsView محلی، نه معنای جدیدconversion/locale contract
Decision authorityRole و delegation ruledelegation صریح و محدودauthority record
Hard obligationsبدون حذف خاموشفقط تفسیر مجاز/عدم applicabilityauthorized decision
Change/exceptionstatus، owner، expiryPlan-specific controlacknowledgement

Test Plan چیست؟

Test Plan یک قرارداد اجرایی و تصمیم‌محور برای Subject، Scope، Build/Release، Window و Audience مشخص است. Strategy را کپی نمی‌کند؛ نسخهٔ آن را reference و Applicable ruleها را به Risk-to-evidence، Source، Environment/Data، Schedule، Resource/Capability، Entry/Exit و Control action تبدیل می‌کند.

Plan باید هنگام اجرا baseline قابل مقایسه بسازد، اما تغییرناپذیر نیست. با Scope، Risk، Dependency یا Evidence تازه نسخه می‌خورد و Deviationها را ثبت می‌کند. جزئیات نوشتن این سند در راهنمای Living Test Plan آمده است؛ اینجا تمرکز روی Handoff است.

Plan Adapter: Strategy را برای یک Release Tailor کنید

PLAN-ADAPTER: SYN-PLAN-B17-v2
Strategy reference: SYN-STRAT-v3
Decision/subject: B17 release evidence; checkout artifact SHA-17
Applicable objectives: SYN-O1, SYN-O2
Scope/out-of-scope: versioned code/schema/config/flags + residual owners
Risk-to-evidence: SYN-R1 repeatable-case; SYN-R2 invariant/fault/reconciliation
Sources: API-v6, RULES-v3, UI-v4, LEDGER-v2
Environment/data: disconnected-lab-v3 / SYN-PAY-v4 / seed 42017
Outcome vocabulary: passed/failed/blocked/not-run/inconclusive
Exit assessment: planned population + risk evidence + forbidden gaps
Decision authority: release-owner-a
Exceptions/deviations: explicit owner, compensating control, expiry
Summary contract: cutoff, populations, source/run identities, corrections

Entry Criteria پایان کدنویسی نیست

شرط «Coding complete» یک Gate مرحله‌ای و اغلب نامناسب برای جریان‌های تکرارشونده است. Readiness باید به Activity/Layer وابسته باشد: Static analysis پیش از Build، Contract test با interface version، Component test با Stub معتبر و E2E با Environment/Data/Dependency آماده. اگر آماده نیست، رفتار باید صریح باشد: continue with limitation، switch evidence، block، escalate یا reschedule.

ActivityReadiness evidenceاگر آماده نیست
Static/unitsource/build/dependency resolvefail lane یا محدودیت ثبت‌شده
Contractconsumer/provider version و statesunknown compatibility
Integrationreal/virtual dependency fidelityfallback با claim محدود
System/E2Eartifact/config/schema/env/data healthblock affected claims
ExploratoryCharter، testability، safe datarevise mission/timebox
Specialistscope، qualified reviewer، evidence toolreschedule/escalate

Exit Criteria پایان تست یا اجازه انتشار نیست

Exit Criteria شرایط ارزیابی Completion یک Scope/Activity است؛ Release decision ممکن است Hard Obligation، Operations readiness، commercial timing و Residual Risk دیگری داشته باشد. رسیدن به Exit به‌خودی‌خود Go نیست، و نرسیدن نیز گاهی با Decision مشروط و Authority مناسب مدیریت می‌شود. QA recommendation را از Risk acceptance و Release authority جدا نگه دارید.

EXIT-CRITERION: SYN-EXIT-R2
Population: planned coverage items for Risk SYN-R2 / Plan B17-v2
Build/cutoff: B17 / 2026-08-13T14:00:00+03:30
Required evidence: invariant + fault-recovery + reconciliation
Outcome treatment: Passed/Failed/Blocked/Not Run/Inconclusive all separate
Forbidden gap: no unowned Unknown after fake commit
Assessment authority: test-completion-owner
Release authority: release-owner-a (separate)
If unmet: HOLD assessment or time-boxed exception with control/expiry

درصدهای ثابت ۹۵٪ و ۹۸٪ را حذف کنید

«۹۵٪ Case اجرا شده» یا «۹۸٪ Passed» بدون Population، denominator، Risk distribution، Outcome treatment، Build و forbidden gaps قابل تصمیم نیست. نوزده Passed از بیست Executed می‌تواند ۹۵٪ باشد، در حالی‌که دو Test بحرانی Not Run و یک مورد Inconclusive خارج مخرج مانده‌اند. Threshold باید از Claim و Decision بیاید، نه مثال عمومی اینترنت.

عبارت مبهمContract لازمخطر
95% passedpassed/planned یا passed/executed + countsحذف Not Run/Blocked
100% critical testscritical population/source/versionبرچسب‌گذاری گزینشی
No critical defectscanonical defect snapshot و severity authorityunknown/unreported gaps
Coverage completecoverage model/items/evidenceشمارش Case به‌جای Risk
Environment readymanifest/health/differences/cutoffBuild یا Config خارجی

Monitoring و Control پل زندهٔ Plan و Summary هستند

Summary نباید در پایان از حافظه ساخته شود. Monitoring وضعیت واقعی Work productها، Evidence و منابع را با Plan مقایسه می‌کند؛ Control دربارهٔ Deviation، Risk تازه، reprioritization، environment failure، scope change و corrective action تصمیم می‌گیرد. هر Control action باید Plan baseline یا Exception را version کند تا Summary بتواند Planned و Actual را منصفانه reconcile کند.

Signalمقایسه با PlanControl actionSummary trace
Scope changein/out/conditional itemsapprove/reject/deferbaseline/deviation
New riskrisk taxonomy/evidence capacityadd evidence/accept/mitigaterisk closure
Environment blockreadiness/critical pathrepair/fallback/reschedulelimitation and lost coverage
High failure clusterforecast/stop rulediagnose/suspend/replanfinding and effect
Capacity losscommitments/cutoffreduce scope with ownernot-run rationale
Signal distrustevidence validityquarantine/revalidateinvalid/inconclusive treatment

Deviation Record قرارداد تغییر حین اجراست

DEVIATION: SYN-DEV-12
Plan baseline: SYN-PLAN-B17-v2
Detected: 2026-08-13T11:20:00+03:30
Planned: fault-recovery on callback API v6 / disconnected-lab-v3
Actual: environment queue reset unavailable
Affected: SYN-R2 / FP-04 / planned cutoff
Evidence invalidated/lost: recovery attempt not executable
Control decision: reschedule before cutoff; no substitute screenshot
Owner/authority: env-owner / test-control-owner
Acknowledged: release-owner-a
Summary treatment: Not Run + limitation; never silently excluded

Test Summary چیست؟

Test Summary یک Snapshot منجمد از Scope، Sources، Runs، Population، Outcomes، Risk evidence، Deviation، Limitation و Residual Risk تا Cutoff است. Summary کیفیت کل محصول را «در یک سطح» اعلام نمی‌کند و خود Release decision نیست؛ Evidence و Recommendation را برای Authority نام‌برده آماده می‌کند.

Summary باید Plan را reconcile کند، نه بازنویسی

Plan baselineSummary actualReconciliation
Objective IDsevaluated/not evaluatedهر Objective وضعیت و Evidence دارد
Scope populationexecuted/changed/excludedadded/removed/unknown با authority
Risk-to-evidenceevidence present/rejected/missingClosure map و limitations
Environment/Dataactual manifest/snapshotdifference و applicability
Schedule/cutoffactual attempts تا cutofflate/excluded data
Exit policycounts/formulas/gapsmet/not met/exception
Decision authorityrecommendation/decisionنقش‌ها و timestamps جدا

Summary Contract برای Handoff

TEST-SUMMARY-INTERFACE: SYN-SUM-B17-v2
Strategy/Plan: SYN-STRAT-v3 / SYN-PLAN-B17-v2
Subject/build/config: checkout SHA-17 / B17 / CFG-4
Facts-as-of/cutoff: 2026-08-13T14:00:00+03:30
Population: planned items + explicit changes; no silent exclusions
Outcomes: passed/failed/blocked/not-run/inconclusive
Risk closure: R1 evidence present; R2 review pending
Deviations/limitations: SYN-DEV-12 and environment fidelity limits
Exit assessment: unmet pending R2 fault-recovery evidence
Recommendation: HOLD_PENDING_R2_REVIEW
Authorized decision: PENDING / release-owner-a
Actions/correction/archive: owners, dates, immutable source manifest
Learning proposals: SYN-SP1 (not yet Strategy change)

Recommendation و Decision را جدا کنید

QA/Test Lead می‌تواند Evidence sufficiency و Test completion را ارزیابی و Go/Hold/Conditional recommendation ارائه کند، اما Release یا Residual Risk acceptance به صاحب اختیار نام‌برده تعلق دارد. در تیمی ممکن است همان شخص هر دو نقش را داشته باشد؛ باز هم Role hat، دلیل، زمان، Scope و expiry باید روشن باشد.

رکوردصاحبمعنا
Test completion assessmentTest completion ownerExit و Evidence نسبت به Plan
RecommendationQA/Test/Risk advisorپیشنهاد مبتنی بر Evidence و limitation
Residual risk acceptanceNamed risk authorityپذیرش exposure برای Scope/Window
Release decisionRelease authorityگزینه Go/Hold/Conditional با controls
Operational acceptanceOperations/service ownerتوان monitor/rollback/respond
CorrectionReport/decision authorityاصلاح Snapshot یا پیامد تصمیم

Summary چگونه به Strategy بازخورد می‌دهد؟

یک Cycle شکست‌خورده یا موفق به‌تنهایی Strategy را اثبات یا رد نمی‌کند. Summary باید Observation را از Interpretation و Change Proposal جدا کند. Proposal سپس با داده چند Cycle، Context، Cost، counterevidence و Authority بازبینی می‌شود. Lesson learned بدون owner، experiment یا decision فقط نثر آرشیوی است.

STRATEGY-CHANGE-PROPOSAL: SYN-SP1
Triggered-by: summaries B15–B17 and Incident SYN-I4
Observation: fault-recovery profile applied inconsistently to timeout-after-commit risks
Hypothesis: applicability wording lacks commit-boundary distinction
Proposed change: add pre/post-commit decision table to EVIDENCE-POLICY-v4
Expected benefit: fewer ambiguous Plans; no quality guarantee
Costs/risks: migration of 14 active Plan mappings; reviewer load
Counterevidence/unknowns: only one product domain sampled
Experiment: two-release pilot with false-positive/coverage review
Authority/review-by: strategy-owner / 2026-09-15

سه سند را با Identity و Lineage به هم وصل کنید

هویتStrategyPlanSummary
Documentstrategy_id/versionplan_id/versionsummary_id/version
Subjectproduct/domain applicabilityrelease/build/scopeactual artifact/build/population
Sourcepolicy/obligation/risk modelstrategy + versioned test basesplan + run/evidence manifests
Timeeffective/review-byfacts-as-of/window/cutoffcutoff/published/corrected
StatusDraft/Active/SupersededDraft/Active/Frozen/ClosedDraft/Published/Corrected
Authoritystrategy ownerplan/control ownerreport/release/risk roles
Integrityrevision/hashrevision/hashimmutable manifest/correction

Cross-Document Contract قابل کپی

CROSS-DOCUMENT-CONTRACT: SYN-XDOC-v1
Strategy: SYN-STRAT-v3
Plan: SYN-PLAN-B17-v2
Summary: SYN-SUM-B17-v2
Shared objective IDs: SYN-O1, SYN-O2
Shared risk/vocabulary/unit/time contracts: RISK-v2 / OUTCOME-v3 / IRR / ISO+zone
Required plan mappings: objectives, risks, evidence profiles, authority, exceptions
Required summary reconciliation: scope, build, populations, outcomes, risks, deviations
Foreign source/run behavior: reject or disclose with applicability review
Change behavior: impact decision; no silent rewrite
Closure behavior: freeze sources/evidence/decision; explicit correction
Audit result vocabulary: HOLD / READY_FOR_CROSS_DOCUMENT_REVIEW
Limit: structural consistency is not adequacy or release proof

آزمایش بازتولیدپذیر: سه سند کامل، چهارده ناسازگاری

برای آزمودن Interface، Fixture کاملاً ساختگی و آفلاین SYN-THREE-DOC-CONTROL-LOOP-01 را ساختیم. Strategy، Plan و Summary هر سه وجود دارند و ID دارند؛ پس Template checker سطحی PASS می‌دهد. Cross-document audit، referenceها، Objectiveها، Evidence profiles، Outcome vocabulary، Plan/Build identity، Authority و Exit semantics را مقایسه می‌کند.

ContractStrategy v3Draft Plan/Summaryناسازگاری
ReferenceSYN-STRAT-v3Plan→v2؛ Summary→Plan B16stale/foreign documents
ObjectivesSYN-O1, SYN-O2فقط SYN-O1Objective برنامه‌ریزی/گزارش نشده
Critical evidenceinvariant+fault+reconciliationفقط invariantPlan و Summary هر دو ناقص
Outcomesپنج وضعیت با Inconclusiveچهار وضعیتواژگان و شمارش ناسازگار
BuildPlan B17Summary B16Evidence خارجی
Authorityrelease-owner-aqa-lead-xAuthority drift در Plan/Summary
ExitRisk evidence و vocabulary۹۵% executed، Inconclusive نامعلومdenominator مبهم
{
  "runtime": "v24.18.0",
  "fixture": "SYN-THREE-DOC-CONTROL-LOOP-01",
  "superficialDraft": {
    "requiredDocuments": 3,
    "documentsPresent": 3,
    "eachHasId": true,
    "decision": "PASS"
  },
  "draftLoop": {
    "findings": [
      "stale-strategy-reference:SYN-STRAT-v2->SYN-STRAT-v3",
      "objective-not-planned:SYN-O2",
      "objective-not-summarized:SYN-O2",
      "plan-missing-required-evidence:SYN-R2:fault-recovery",
      "summary-missing-risk-evidence:SYN-R2:fault-recovery",
      "plan-missing-required-evidence:SYN-R2:reconciliation",
      "summary-missing-risk-evidence:SYN-R2:reconciliation",
      "plan-outcome-vocabulary-gap:inconclusive",
      "summary-outcome-vocabulary-gap:inconclusive",
      "foreign-plan-summary:SYN-PLAN-B16-v4->SYN-PLAN-B17-v2",
      "foreign-build-summary:B16->B17",
      "plan-authority-drift:qa-lead-x->release-owner-a",
      "summary-authority-drift:qa-lead-x->release-owner-a",
      "ambiguous-exit-policy:executed-denominator-without-inconclusive-treatment"
    ],
    "decision": "HOLD"
  },
  "correctedLoop": {
    "findings": [],
    "decision": "READY_FOR_CROSS_DOCUMENT_REVIEW"
  }
}

نسخه اصلاح‌شده چه چیزی را هم‌تراز کرد؟

  • Plan به Strategy v3 وصل شد و هر دو Objective را گرفت.
  • Risk بحرانی R2 هر سه Evidence Profile را در Plan و Summary دریافت کرد.
  • Inconclusive به Vocabulary Plan و counts Summary اضافه شد.
  • Summary به Plan B17-v2 و Build B17 متصل شد.
  • Decision authority در هر سه سند روی release-owner-a هم‌تراز شد.
  • Exit از «۹۵٪ executed» به Population برنامه‌ریزی‌شده و treatment صریح Inconclusive تبدیل شد.
  • Finding درباره Evidence policy به Strategy Change Proposal رفت، نه تغییر خاموش.

READY_FOR_CROSS_DOCUMENT_REVIEW فقط یعنی قواعد ساختاری این Fixture یافته‌ای ندارند. این نتیجه مناسب‌بودن Strategy، کفایت Plan/Test، صحت Summary، کیفیت محصول، پذیرش Risk، آمادگی Release یا انطباق را ثابت نمی‌کند.

روش بازتولید آزمایش

اسکریپت مستقل از شبکه و کتابخانه است. سه Object را می‌گیرد و Contractهای مشترک را پیمایش می‌کند. برای بازتولید، Fixture، Runtime و تمام نسخه‌ها را ثابت نگه دارید و خروجی JSON را با Expected snapshot مقایسه کنید. این آزمایش semantic review، کیفیت Risk model یا Execution واقعی را شبیه‌سازی نمی‌کند.

audit Strategy→Plan:
  strategy reference, objectives, risk evidence, vocabulary, authority, exit semantics
audit Plan→Summary:
  plan/build identity, objectives, risk evidence, outcomes, deviations
audit Summary→Learning:
  proposals remain proposals until authorized Strategy/Plan revision
decision = findings.empty ? READY_FOR_CROSS_DOCUMENT_REVIEW : HOLD

همه Strategyها، Planها، Summaryها، Buildها، Objectiveها، Riskها، درصدها، نقش‌ها، یافته‌ها و تصمیم‌ها عمداً ساختگی‌اند. هیچ سازمان، تیم، ابزار، Release یا محصول واقعی ارزیابی یا Benchmark نشده است.

لابراتوار فارسی برای Checkout ایرانی ساختگی

لابراتوار SYN-XDOC-FA-01 محلی و بدون شبکه است. Checkout، PSP، Ledger و Notification همگی بدل‌اند. هیچ مشتری، بانک، حساب، تراکنش یا پول واقعی وجود ندارد. هدف فقط آزمون Handoff و Cross-document reconciliation است.

Risk ساختگیStrategy rulePlan commitmentSummary reconciliation
Duplicate Callbackcritical؛ invariant+reconciliationEvent ID و fake Ledger Populationunique effects/gaps/limitations
Timeout after commitcritical؛ fault-recoverypredeclared injection point و Unknown stateattempt/state/recovery evidence
Amount boundarymaterial؛ repeatable-caseRULES-v3 و canonical IRRboundary matrix actuals
Persian RTL receiptspecialist profileUI-v4، RTL/LTR، digit variantsspecialist findings/limits
Order-Ledger driftcritical؛ reconciliationsnapshots/keys/units/cutoffmatched/missing/extra/unknown

هویت پول، رقم و زمان باید میان سه سند یکی باشد

ContractStrategyPlanSummary
Moneycanonical unit=IRR؛ View تومان صریحDataset و Oracle با واحدcounts/amounts با همان unit
DigitsUnicode/normalization policyPersian/Arabic/Latin fixturesنتیجه بدون تغییر هویت/مقدار
TimeISO instant + zone semanticsclock/window/cutofffacts-as-of و late result
CalendarJalali presentation-only اگر مقررboundary fixturesنمایش با canonical instant
DirectionRTL/accessibility expectationspecialist evidence profilescope/limitations صریح
IdentityOrder/Attempt/Event/Run schemafixture/manifestsdedupe/reconciliation keys

لابراتوار هیچ نام، موبایل، ایمیل، IP، حساب، سفارش، PAN، CVV2، OTP، Cookie، Token، Secret، Screenshot، Log یا Endpoint واقعی ندارد و توصیه حقوقی، بانکی، مالی، امنیتی یا حریم خصوصی درباره ایران ارائه نمی‌کند.

Small Team: سه View، یک Registry

تیم کوچک مجبور نیست سه فایل بزرگ بسازد. می‌تواند یک Registry ساختاریافته با سه View داشته باشد: Strategy card یک‌صفحه‌ای، Release Plan board و Closure Summary snapshot. شرط این است که ID، Status، Authority و زمان هر View جدا باشد و تغییر Summary تاریخ Strategy را بازنویسی نکند.

Viewحداقلزمان مصرفFreeze
Strategy Cardobjectives/risk/evidence/authority/exceptionsRefinement/architecture/reviewversioned effective snapshot
Plan Boardscope/risk mappings/readiness/cutoff/ownersdaily control و schedulingbaselines on changes
Summary Snapshotactuals/gaps/risks/recommendation/actionsclosure/decisionimmutable + correction

Multi-team و Portfolio: Parent-child با Roll-up Contract

در چند تیم، Master Strategy می‌تواند Vocabulary و حداقل Evidence را تعریف کند؛ Product/Domain Strategy آن را Tailor کند؛ Level/Release Planها scope محلی داشته باشند؛ و Summaryها فقط با aggregation contract roll up شوند. جمع ساده درصدها یا Defectها، Population و Risk را تحریف می‌کند.

ROLL-UP-CONTRACT: SYN-ROLL-v1
Parent strategy: ORG-STRAT-v4
Child strategies: CHECKOUT-v3, LEDGER-v2
Shared vocabulary: OUTCOME-v3, RISK-v2, IRR, ISO instant
Local extensions: mapped explicitly; no name collision
Summary population: deduplicated by test/risk/build identities
Aggregation: counts + support/denominator; no average-of-percentages
Cross-domain risk: separate owner and evidence map
Unknown/inconclusive: preserved, never coerced to pass
Correction: propagate to affected roll-up snapshots

Agile و Scrum سه سند اجباری ندارند

Scrum Guide رسمی نوامبر ۲۰۲۰ Product Backlog، Sprint Backlog و Increment و Commitmentهای آن‌ها را تعریف می‌کند؛ Test Strategy، Test Plan و Test Summary را به‌عنوان Artifact رسمی یا Test Manager/QA Lead را به‌عنوان نقش Scrum تعریف نمی‌کند. تیم می‌تواند این Viewها را برای شفافیت و تصمیم خود بسازد، اما نباید آن‌ها را الزام Scrum بنامد.

در جریان Iterative، Strategy ممکن است Product-level باشد، Plan در Backlog/board و Registry توزیع شود، Monitoring پیوسته باشد و Summary برای Release/Milestone به‌صورت Snapshot ساخته شود. شکل Artifact می‌تواند تغییر کند؛ Interface و Authority نباید گم شود.

ابزار انتخاب نکنید؛ قابلیت Interface را بسنجید

قابلیتپرسش PoCFailure خطرناک
Version/identityسه سند و Sources را immutable resolve می‌کند؟latest-only reference
Typed linksinherits/tailors/evidences/deviates را فرق می‌گذارد؟لینک بی‌معنا
Schema/vocabularyOutcome/Risk/Unit مشترک enforce می‌شود؟mapping دستی پنهان
Query/auditObjective یا Evidence گمشده پیدا می‌شود؟review با Spreadsheet
Change workflowImpact/acknowledgement/correction دارد؟ویرایش خاموش
Evidence lineageRun→Build→Plan→Strategy trace دارد؟foreign evidence
Access/retentionمصرف‌کننده می‌بیند و history حفظ می‌شود؟shadow copies
Export/APIاز Vendor قابل انتقال/بازسازی است؟lock-in و broken history

Cross-Document Review Gate

GateپرسشHOLD نمونه
Identityنسخه‌های Strategy/Plan/Summary resolve می‌شوند؟latest alias یا foreign Plan
ObjectivesApplicable objectives plan/report شده‌اند؟Objective بی‌Plan/Summary
Risk/evidenceحداقل Policy Tailor و reconcile شده؟critical profile ناقص
VocabularyStatus/Severity/Unit/Time هم‌معناست؟Inconclusive گمشده
SubjectBuild/Config/Scope/Population یکی است؟Summary B16 برای B17
DeviationPlan changes و lost Evidence ثبت شده؟silent exclusion
AuthorityAssessment/Recommendation/Risk/Release روشن‌اند؟QA self-approves release
Closure/learningSnapshot frozen و Proposal جداست؟Summary Strategy را بازنویسی می‌کند

اتوماسیون ممیزی چه کند و چه نکند؟

اتوماسیون می‌تواند reference قدیمی، Objective گمشده، Evidence Profile ناقص، Vocabulary gap، foreign Build/Plan، Authority mismatch، denominator ناقص، owner/expiry مفقود و Correction منتشرنشده را پیدا کند. نمی‌تواند مناسب‌بودن Strategy، کفایت Risk model، صحت Oracle، حقیقت Summary یا قابل‌پذیرش‌بودن Residual Risk را به‌تنهایی تصمیم بگیرد.

XDOC CI POLICY
ERROR: broken identity, duplicate canonical document, invalid schema
HOLD: stale strategy, missing applicable objective/evidence, foreign build/plan
WARN: review-by/exception expiring, acknowledgement pending, metric drift
INFO: non-impact decision, historical snapshot, accepted local extension
HUMAN: strategic adequacy, semantic fit, evidence sufficiency, risk/release decision

استفاده امن از AI در سه سند

کارAI می‌تواندReview لازمممنوع
Strategy draftRisk/approach candidate از Sources مجازDomain/strategy authorityساخت obligation یا policy
Plan mappingobjective/risk/evidence candidatePlan/Test ownersحذف silent hard obligation
Monitoringcluster deviation و forecast questionControl ownerدستکاری Outcome
Summary narrativeخلاصه از frozen structured factsEvidence/report reviewerساخت metric/cause/quality claim
Cross-doc auditناسازگاری candidatemeaning/authority ownersاعلام خودکار Go/Compliance
Learningproposal و counterquestionStrategy change boardتغییر خودکار Strategy

هر خروجی AI باید model/tool version، template/prompt، input source versions، زمان، scope، limitations و Reviewer داشته باشد. داده حساس، Secret یا Evidence کنترل‌شده نباید به سرویس تأییدنشده ارسال شود.

نقش‌ها و Decision Rights

رکورد/تصمیمResponsibleAuthorityConsulted
Strategy integrityTest/quality strategistProduct/quality governance ownerArchitecture/Product/Engineering/Ops
Risk taxonomy/evidence policyRisk/Test architectDomain/risk authoritySpecialists/Consumers
Plan baselinePlan/Test ownerInitiative decision ownerTeam/dependencies
Monitoring/controlControl ownerDelegated plan authorityWork/evidence owners
Completion assessmentTest completion ownerPlan governanceEvidence reviewers
Summary publicationReport ownerClosure/report authorityConsumer representatives
Residual risk/releaseRisk advisorNamed risk/release ownerQA/Product/Engineering/Ops
Strategy changeProposal ownerStrategy authorityAffected Plan/Domain owners

Metricها و Countermetricهای Control Loop

MetricکاربردCountermetricبازی احتمالی
Applicable objectives mappedStrategy→Plan completenessobjective quality/applicability reviewکم‌کردن Objectiveها
Risk evidence reconciliationPlan→Summary closureevidence validity/unknownsلینک مصنوعی
Deviation decision latencyControl responsivenessbad/late decision rateبستن عجولانه
Foreign evidence findingsIdentity disciplineuseful historical evidenceحذف Evidence به‌جای review
Authority mismatchGovernance claritydecision quality/latencyتمرکز قدرت برای سبزشدن
Strategy proposal lead timeLearning throughputadoption outcome/rollbackتغییر زیاد بدون Evidence
Plan rework from strategy ambiguityStrategy usabilitynecessary tailoringسخت‌کردن Strategy
Decision retrieval timeConsumptionwrong-answer rateجواب سریع اما غلط

Pilot سی‌روزه برای سه‌سندِ متصل

روزتمرکزخروجیGate
۱–۵یک Product/Release و سه سند موجودIdentity/lineage mapنسخه و Authority resolve
۶–۱۰Shared contractsObjective/Risk/Evidence/Outcome/Unit/Timeبدون competing semantics
۱۱–۱۵Strategy→Plan adapterinherit/tailor/exception mappingApplicable gaps visible
۱۶–۲۰Monitoring/control drillScope/Risk/Env deviation recordsPlan baseline versioned
۲۱–۲۵Summary reconciliationactuals/risks/limits/decision rolesforeign/silent data rejected
۲۶–۳۰Learning and auditchange proposal + metrics + Tailoringcontinue/adjust/stop record

۳۰ Anti-pattern در Strategy، Plan و Summary

  1. سه Template را سیستم مدیریت دانستن.
  2. Strategy را قانون اساسی ثابت نامیدن.
  3. Strategy را فهرست Test Type/Tool کردن.
  4. Plan را کپی Strategy کردن.
  5. Summary را کپی Plan با عددهای جدید کردن.
  6. Test Policy و Strategy را یکی‌گرفتن.
  7. Status جاری و Summary منجمد را یکی‌گرفتن.
  8. Decision Record را داخل Recommendation دفن‌کردن.
  9. Strategy version را در Plan ثبت‌نکردن.
  10. Objective را بی‌ID انتقال‌دادن.
  11. Risk taxonomy را محلی و خاموش بازتعریف‌کردن.
  12. Evidence policy را بدون Exception حذف‌کردن.
  13. Outcome vocabulary متفاوت داشتن.
  14. Inconclusive/Blocked/Not Run را Pass/Fail فشرده‌کردن.
  15. Entry را Coding complete دانستن.
  16. Exit را Release permission دانستن.
  17. درصد ۹۵/۹۸ را معیار جهانی گذاشتن.
  18. Executed را مخرج بدون Treatment گرفتن.
  19. Deviation را در چت نگه‌داشتن.
  20. Scope change را در Summary مخفی‌کردن.
  21. Run خارجی را بی‌Review مصرف‌کردن.
  22. Summary را ارزیابی کیفیت کل محصول نامیدن.
  23. QA/Test Lead را Authority طبیعی Go/No-Go دانستن.
  24. Lesson learned را بی‌Owner/Proposal رهاکردن.
  25. یک Cycle را دلیل تغییر Strategy دانستن.
  26. جمع درصد Summary تیم‌ها را Roll-up کردن.
  27. اسناد Agile را الزام Scrum نامیدن.
  28. AI narrative را Source of fact کردن.
  29. ویرایش خاموش Strategy/Plan/Summary مصرف‌شده.
  30. READY_FOR_CROSS_DOCUMENT_REVIEW را Release proof دانستن.

چک‌لیست ۴۸ نقطه‌ای Cross-Document Audit

  1. Strategy ID/version/effective ثبت شده است.
  2. Plan ID/version/baseline ثبت شده است.
  3. Summary ID/version/cutoff ثبت شده است.
  4. Scope Strategy روشن است.
  5. Subject/Build Plan روشن است.
  6. Actual Build Summary روشن است.
  7. Plan به Strategy دقیق وصل است.
  8. Summary به Plan دقیق وصل است.
  9. Summary به Strategy دقیق وصل است.
  10. Objectiveها ID مشترک دارند.
  11. Applicable Objectiveها در Plan mapped هستند.
  12. Objectiveها در Summary reconciled هستند.
  13. Risk taxonomy مشترک است.
  14. Local Risk mapping صریح است.
  15. Evidence policy نسخه‌دار است.
  16. Critical minimumها در Plan هستند.
  17. Summary Evidence را به Risk وصل می‌کند.
  18. Missing/rejected Evidence حفظ شده است.
  19. Outcome vocabulary مشترک است.
  20. Passed/Failed جدا هستند.
  21. Blocked/Not Run جدا هستند.
  22. Inconclusive/Invalid policy روشن است.
  23. Population و denominator روشن‌اند.
  24. Threshold زمینه و دلیل دارد.
  25. Forbidden gaps مشخص‌اند.
  26. Readiness activity-specific است.
  27. رفتار Not-ready روشن است.
  28. Entry فازگرای مبهم نیست.
  29. Exit از Release decision جدا است.
  30. Plan Monitoring baseline دارد.
  31. Deviationها ID و Owner دارند.
  32. Scope change authority دارد.
  33. Risk تازه Control action دارد.
  34. Environment/Data actual ثبت شده است.
  35. Foreign Build/Evidence رد یا محدود شده است.
  36. Late/duplicate Result normal شده است.
  37. Summary Planned/Actual را reconcile می‌کند.
  38. Limitations و Unknownها صریح‌اند.
  39. Residual Risk صاحب دارد.
  40. Recommendation صاحب دارد.
  41. Risk acceptance صاحب دارد.
  42. Release decision صاحب دارد.
  43. Correction تاریخچه را حفظ می‌کند.
  44. Lesson از Observation جدا است.
  45. Strategy proposal Evidence/unknown دارد.
  46. Tailoring/Exception owner/expiry دارد.
  47. اتوماسیون محدودیت خود را اعلام می‌کند.
  48. Gate فقط نتیجهٔ ساختاری مجاز می‌دهد.

منابع رسمی و دامنه استفاده

  • ISO/IEC/IEEE 29119-2:2021: Abstract فرایندهای عمومی Governance/Management/Implementation؛ نه متن کامل یا Workflow اجباری این مقاله.
  • ISO/IEC/IEEE 29119-3:2021: Abstract Templateهای مستندات خروجی فرایندها؛ نه سه فایل اجباری، Template کامل یا اثبات انطباق.
  • ISTQB CTAL-TM v3.0: منبع آموزشی Planning/Monitoring/Control/Completion و Project Test Strategy؛ نه مدل سازمانی جهانی یا Release authority.
  • Scrum Guide 2020: Artifactها و Commitmentهای رسمی Scrum؛ نه Test Strategy/Plan/Summary یا QA/Test Manager role.

جمع‌بندی: سه سند را به یک زنجیره شواهد تبدیل کنید

Test Strategy جهت و قواعد مشترک را تعیین می‌کند؛ Test Plan آن‌ها را برای Scope و تصمیم مشخص Tailor و به commitment تبدیل می‌کند؛ Monitoring/Control واقعیت و Deviation را ثبت می‌کند؛ Test Summary همان Plan را با Actual، Evidence، Gap و Residual Risk reconcile می‌کند؛ و Learning فقط با Proposal و Authority به نسخه بعدی برمی‌گردد.

برای شروع، به‌جای نوشتن دوباره سه سند، یک Cross-Document Contract بسازید و سه Query اجرا کنید: Strategy reference قدیمی کجاست؟ کدام Objective/Risk Evidence در Plan یا Summary گم شده؟ کدام Summary از Plan/Build خارجی استفاده می‌کند؟ پاسخ این سه سؤال کیفیت رابطه‌ها را بسیار بهتر از تعداد صفحه‌ها نشان می‌دهد.

سؤالات متداول درباره Test Strategy، Plan و Summary

۱. تفاوت اصلی Test Strategy و Test Plan چیست؟

Strategy برای Scope و افق وسیع‌تر، Objectives، Risk/Evidence rules، Vocabulary، Governance و Tailoring policy را تعیین می‌کند. Plan نسخه مشخص Strategy را برای Initiative/Release/Activity به Scope، منابع، readiness، risk-to-evidence، schedule، cutoff و control baseline تبدیل می‌کند.

۲. آیا Test Summary همان Status Report یا Go/No-Go است؟

خیر. Status Report نمای جاری و تکرارشونده است؛ Summary Snapshot منجمدِ Actual/Evidence/Gap/Risk تا Cutoff است. Summary می‌تواند Recommendation بدهد، اما Authorized release/risk decision باید در Decision Record جدا با صاحب اختیار ثبت شود.

۳. آیا تیم کوچک به سه فایل جدا نیاز دارد؟

نه لزوماً. یک Registry با سه View سبک می‌تواند کافی باشد، به شرط اینکه Identity، Scope، Status، Authority، Facts/Cutoff و Freeze/Correction جدا بمانند و روابط Strategy→Plan→Summary قابل ممیزی باشند.

۴. چه کسی Strategy، Plan و Summary را می‌نویسد و تصویب می‌کند؟

عنوان شغلی جهانی وجود ندارد. Test/Quality strategist، Plan owner و Report owner می‌توانند نویسنده باشند؛ Domain/Product/Engineering/Ops مشارکت می‌کنند؛ اما Strategy approval، Plan baseline، Evidence assessment، Residual Risk acceptance و Release decision باید Authorityهای نام‌برده و متناسب داشته باشند.

۵. آیا Exit Criteria برآورده‌شده یعنی محصول آماده انتشار است؟

خیر. Exit وضعیت Completion و Evidence نسبت به Plan را ارزیابی می‌کند. Release decision ممکن است Obligations، Operational readiness، Residual Risk، controls و شرایط دیگری داشته باشد. Assessment، Recommendation، Risk acceptance و Release authority را جدا ثبت کنید.

محمد عسکری

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

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