سناریوی تست و تست‌کیس؛ تفاوت و انتخاب Artifact

وقتی تیم می‌گوید «برای پرداخت سناریوی تست نوشته‌ایم»، دقیقاً چه چیزی آماده است: یک هدف پوشش، یک سفر کاربر، Charter اکتشافی، تست‌کیس سطح‌بالا یا دستور اجرای تکرارپذیر؟ اگر پاسخ افراد متفاوت باشد، تعداد سندها زیاد می‌شود اما Coverage، مالکیت و اثر تغییر همچنان مبهم می‌ماند. مسئلهٔ اصلی تفاوت سناریوی تست و تست‌کیس فقط «چه چیزی» در برابر «چگونه» نیست؛ مسئله انتخاب Artifact مناسب برای یک تصمیم، ریسک، Oracle، مخاطب و فاصلهٔ تحویل است.

این راهنما یک Test Design Graph می‌سازد: Test Basis و Risk Claim به Test Condition و Coverage Item وصل می‌شوند؛ سپس Scenario، Charter، Checklist، Test Case، Procedure یا Script آن‌ها را پوشش می‌دهد و Run و Evidence نتیجهٔ اجرا را ثبت می‌کنند. این مدل سلسله‌مراتب اجباری «یک سناریو ← چند تست‌کیس» نیست؛ یک گراف نسخه‌دار و قابل ممیزی است که می‌گوید چرا هر Artifact وجود دارد، چه چیزی را پوشش می‌دهد و پس از تغییر کدام رابطه باید بازبینی شود.

پاسخ کوتاه: سناریوی تست و تست‌کیس چه تفاوتی دارند؟

Artifact	پرسش غالب	سطح معمول	خروجی‌ای که نباید با آن یکی شود
Test Condition / Coverage Item	چه شرط، ریسک یا تمایزی باید پوشش داده شود؟	تحلیل	روش اجرا یا نتیجه
Test Scenario	چه موقعیت، جریان یا توالی معناداری بررسی شود؟	طراحی سطح‌بالا	الزاماً E2E یا فقط کاربرمحور نیست
Test Charter	در یک Session چه مأموریتی با چه محدوده و Oracle کاوش شود؟	طراحی اکتشافی	سناریوی مبهم و بی‌زمان نیست
Test Case	با چه ورودی، پیش‌شرط و Expected Result یک ادعا آزموده شود؟	سطح‌بالا یا جزئی	Actual Result و Pass/Fail طراحی نیستند
Test Procedure / Script	Artifact طراحی چگونه و با چه ترتیب یا کدی اجرا شود؟	پیاده‌سازی تست	خود Test Case نیست
Test Run / Result / Evidence	چه چیزی، کجا، چه وقت و با چه مشاهده‌ای اجرا شد؟	اجرا	نسخهٔ طراحی را بازنویسی نمی‌کند

پس Test Scenario معمولاً یک موقعیت یا جریان معنادار را بیان می‌کند و Test Case یک ادعای آزمون‌پذیر را با پیش‌شرط، داده و نتیجهٔ مورد انتظار دقیق‌تر می‌کند؛ اما هیچ‌کدام ذاتاً «سبک» یا «سنگین» نیستند. سطح جزئیات را زمینه تعیین می‌کند، نه نام Artifact.

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

این صفحه مالک انتخاب نوع Artifact، سطح جزئیات و روابط Test Design Graph است. برای جلوگیری از مستندات تکراری، هر موضوع عمیق‌تر یک مالک جدا دارد.

پرسش	مالک محتوا	مرز
Test Basis و شرط آزمون‌پذیر را چگونه استخراج کنیم؟	تحلیل نیازمندی‌ها در STLC	اینجا فقط اتصال Basis به Condition را مدل می‌کنیم.
قالب و تکنیک نوشتن Test Case چیست؟	نوشتن تست‌کیس حرفه‌ای	اینجا تصمیم می‌گیریم اصلاً Case لازم است و در چه سطحی.
Charter و Session چگونه اجرا و گزارش شوند؟	تست اکتشافی ساختاریافته	اینجا Charter را از Scenario و Case تفکیک می‌کنیم.
Run، Result و Closure چگونه مدیریت شوند؟	چرخه اجرای تست	این مقاله Artifact طراحی را از رکورد اجرا جدا نگه می‌دارد.
Tailoring بر اساس زمینه چگونه است؟	تست مبتنی بر زمینه	اینجا عوامل انتخاب جزئیات را عملیاتی می‌کنیم.
آیا Scrum این سندها را الزام می‌کند؟	نقش QA در Scrum	Scrum نوع Test Artifact را تجویز نمی‌کند.
کدام Check برای اتوماسیون مناسب است؟	راهنمای اتوماسیون تست	Manual Case پیش‌نیاز جهانی Script نیست.
سندها چگونه همراه تغییر زنده بمانند؟	مستندسازی تست زنده	اینجا Version و Change Impact گراف را تعریف می‌کنیم.

چرا فرمول «Scenario = What، Case = How» کافی نیست؟

این فرمول برای شروع مکالمه مفید است، اما چهار خطا می‌سازد. نخست، پاسخ «چه چیزی» معمولاً متعلق به Test Analysis و Test Condition است، نه فقط Scenario. دوم، Case می‌تواند High-level باشد و Steps نداشته باشد. سوم، Scenario می‌تواند جریان فنی، شکست عملیاتی یا Quality Scenario باشد و الزاماً سفر کامل کاربر نیست. چهارم، «چگونه اجرا شود» ممکن است در Procedure یا Script نگهداری شود، نه در Case.

«پرداخت سفارش» به‌تنهایی ممکن است Objective، Scenario یا نام Suite باشد؛ نام بدون Contract معنا را تثبیت نمی‌کند.
«Callback تکراری نباید Ledger را دوبار ثبت کند» می‌تواند Condition، Invariant، Property یا Expected Result باشد.
«دکمه را بزن» یک Step است؛ اثبات نمی‌کند پیش‌شرط، Oracle و داده تعریف شده‌اند.
«PASS» ویژگی Test Case نیست؛ نتیجهٔ یک Attempt مشخص روی Build و Environment مشخص است.

Naming Contract: قبل از نوشتن، واژه‌ها را قرارداد کنید

واژهٔ Scenario در ابزارها، سازمان‌ها و حتی دو تیم یک شرکت معنای یکسانی ندارد. راه‌حل، بحث لغوی بی‌پایان نیست؛ یک Naming Contract کوتاه است که تعریف محلی، فیلدهای اجباری، مالک و رابطه‌های مجاز را نسخه‌دار می‌کند.

NAMING-CONTRACT: TD-NAME-v3
Scenario := موقعیت/جریان سطح‌بالا با Objective و Coverage links
Case := ادعای آزمون‌پذیر با Preconditions + Data + Expected
Charter := Mission + Scope + Risks + Oracles + Data + Timebox + Evidence
Procedure := ترتیب اجرایی یک یا چند Artifact طراحی
Script := پیاده‌سازی قابل اجرا یا نیمه‌خودکار یک Check
Result := مشاهدهٔ Attempt؛ هرگز داخل نسخهٔ Design بازنویسی نمی‌شود
Owner: Test Design Lead
Review-by: 2026-09-15

واژه	تعریف عملیاتی پیشنهادی	حداقل فیلد	ابهام رایج
Test Basis	منبعی که ادعا و انتظار از آن مشتق می‌شود	ID، نسخه، نوع، مالک، تاریخ اثر	فقط Requirement رسمی نیست
Risk Claim	ادعای مشخص دربارهٔ پیامد نامطلوب و زمینه	رویداد، پیامد، دامنه، مالک	امتیاز عددی بدون معنا
Test Objective	پرسشی که شواهد باید برای آن تولید شود	سؤال، تصمیم، محدوده	فهرست Feature
Test Condition	جنبه یا شرط آزمون‌پذیرِ اولویت‌دار	ID، Basis، Risk، Coverage criterion	Step اجرایی
Coverage Item	عضو قابل شمارشِ یک مدل پوشش تعریف‌شده	مدل، شناسه، وضعیت	درصد مبهم
Scenario	موقعیت، جریان یا توالی معنادار	Objective، actors/systems، start/end، links	همیشه E2E
Case	ادعای قابل اجرا با Setup، Inputs و Expected	ID، links، precondition، data، oracle	همیشه Steps جزئی
Run/Attempt	وقوع اجرای Artifact نسخه‌دار	Build، env، time، actor، outcome	Status خود Case

چهار لایه را از هم جدا کنید: Analysis، Design، Implementation، Execution

تفکیک مرحله‌ها برای دیوان‌سالاری نیست؛ برای جلوگیری از مخلوط شدن «چرا آزمون می‌کنیم»، «چه ادعایی را می‌آزماییم»، «چگونه قابل اجرا می‌کنیم» و «چه مشاهده شد» است. این فعالیت‌ها می‌توانند هم‌پوشان، تکرارشونده یا توسط یک نفر انجام شوند، اما خروجی‌هایشان یک معنا ندارند.

لایه	پرسش	نمونه خروجی	Gate نمونه
Test Analysis	چه چیزی و چرا باید آزموده شود؟	Condition، Coverage Item، Objective، Risk link	Basis و اولویت قابل ردیابی است
Test Design	چگونه ادعا را به آزمون تبدیل کنیم؟	Scenario، Case، Charter، Checklist، data requirement	Oracle و Evidence profile کافی است
Test Implementation	چه چیز برای اجرا آماده شود؟	Procedure، Suite، Script، Data set، Environment requirement	نسخه‌ها و Dependencyها resolve شده‌اند
Test Execution	چه اتفاقی در Attempt مشخص افتاد؟	Run، Result، Log، Evidence، Incident link	هویت Build/Env/Artifact و Outcome معتبر است

Test Analysis: «چه چیزی» قبل از Scenario آغاز می‌شود

در واژگان ISTQB CTFL v4.0.1، Test Analysis با تحلیل Test Basis، شناسایی و اولویت‌بندی Test Conditionها و تعریف Coverage Criteria به پرسش «چه چیزی را تست کنیم؟» می‌پردازد. این منبع یک چارچوب آموزشی است؛ استفاده از اصطلاحات آن به‌تنهایی مدرک بلوغ، کفایت پوشش یا انطباق نیست.

Condition خوب نه عنوان صفحه است و نه فهرست کلی قابلیت. باید تفاوتی را مشخص کند که Evidence بتواند درباره‌اش حرف بزند: «Callback با Event ID یکسان پس از commit دوباره تحویل می‌شود» از «پرداخت را تست کن» قابل سنجش‌تر است. Technique انتخاب‌شده، Coverage Itemهای کوچک و کافی را از مدل دامنه استخراج می‌کند؛ تعداد خام سناریوها جای این مدل را نمی‌گیرد.

CONDITION: SYN-C3
Basis: API-v5 / callback.delivery
Risk claim: redelivery may duplicate a ledger effect
Coverage model: delivery identity × commit boundary
Coverage item: same event_id, second delivery after prior commit
Oracle: one canonical ledger effect for one authorized event
Priority reason: financial reconciliation impact
Required evidence profile: invariant-check

Test Design: Condition را به آزمون تبدیل کنید

در Test Design، Conditionها به Test Case و Testware دیگر بسط پیدا می‌کنند. انتخاب Technique، داده، Environment، Oracle و نوع Evidence در این لایه رخ می‌دهد. یک Condition ممکن است به چند Artifact نیاز داشته باشد؛ مثلاً Boundary Case برای مبلغ، Property Check برای invariant و Charter برای رفتارهای پیش‌بینی‌نشدهٔ بازیابی.

طراحی سبک هم باید Objective، منبع انتظار و رابطهٔ پوشش را نگه دارد. حذف نثر تکراری خوب است؛ حذف Oracle یا هویت Basis صرفاً ابهام را به زمان اجرا منتقل می‌کند.

Test Implementation: Procedure، Suite و Script کجا قرار می‌گیرند؟

Implementation خروجی طراحی را قابل اجرا می‌کند: Caseها در Procedure یا Suite مرتب می‌شوند، Data و Environment آماده می‌گردد و Manual/Automated Script ساخته می‌شود. اگر ترتیب اهمیت ندارد، آن را بی‌دلیل در Case قفل نکنید. اگر Reset یا Seed مشترک است، Procedure نسخه‌دار مانع تکرار متناقض آن در ده‌ها Case می‌شود.

PROCEDURE: SYN-PROC-RETRY-v2
Implements: SYN-TC-12, SYN-P1
Setup: seed=SYN-PAY-04; fake_psp=timeout-after-commit
Order: reset → submit → wait window → retry → reconcile
Cleanup: destroy synthetic tenant and queue
Environment: local-disconnected-lab-v4
Prohibited: Production endpoint, real PSP, real money

Test Execution: Actual Result و Status را به Attempt متصل کنید

Expected Result بخشی از طراحی است؛ Actual Result، Pass/Fail/Blocked و Evidence به یک Attempt تعلق دارند. اگر Status را داخل Case نگه دارید، اجرای Build جدید تاریخچهٔ قبلی را پاک می‌کند و معلوم نیست «این تست PASS است» دربارهٔ کدام نسخه، محیط و زمان گفته شده است.

فیلد	Design Artifact	Run/Attempt
Expected	بله؛ Oracle و نتیجهٔ مورد انتظار نسخه‌دار	فقط reference به نسخهٔ Design
Actual observation	خیر	بله؛ مشاهده بدون تفسیر اضافی
Outcome	خیر	Passed، Failed، Blocked، Inconclusive، Not Run
Build/Environment	Requirement یا constraint ممکن است	هویت دقیق مورد اجرا الزامی
Evidence	Profile موردنیاز	Manifest واقعی و قابل دسترسی

Test Design Graph چیست؟

Test Design Graph نمایش نسخه‌دار Nodeها و Edgeهایی است که از منبع ادعا تا شواهد اجرا امتداد دارند. این گراف می‌تواند در Test Management Tool، Issue Tracker، فایل YAML یا پایگاه داده باشد؛ ارزش آن در نام ابزار نیست، در هویت پایدار و روابط قابل پرس‌وجو است.

Basis@v3 ─derives→ Condition C2 ─covered-by→ Boundary Case TC2@v2
Risk R7  ─motivates→ Condition C2
TC2@v2  ─implemented-by→ Procedure P4@v1
P4@v1   ─executed-as→ Run RUN-204 / Attempt A1
Attempt ─produced→ Evidence Manifest EM-204
Change CR-91 ─invalidates?→ Basis@v3 edges

علامت سؤال در invalidates? عمدی است: تغییر منبع، Test را خودکار باطل نمی‌کند؛ یک Impact Assessment لازم است. ممکن است رابطه همچنان معتبر، نیازمند اصلاح یا منسوخ باشد.

چرا رابطه‌ها چندبه‌چند هستند؟

یک Scenario می‌تواند چند Condition را پوشش دهد و یک Condition نیز با چند Artifact پوشش داده شود. همچنین یک Case ممکن است ترکیبی از چند Rule را بیازماید، یا یک Script یک Property را در صدها داده تولیدشده اجرا کند. تبدیل این شبکه به درخت ثابت، روابط واقعی را پنهان می‌کند.

Edge	از	به	معنای مجاز
derived-from	Condition	Basis version	منبع تفسیر Condition
motivated-by	Artifact	Risk Claim	دلیل انتخاب/اولویت، نه اثبات کاهش ریسک
covers	Scenario/Case/Charter/Check	Condition/Coverage Item	قصد پوشش در طراحی، نه Evidence اجرا
implements	Procedure/Script	Design Artifact	پیاده‌سازی نسخهٔ مشخص
executed-as	Artifact version	Attempt	وقوع اجرا
produced	Attempt	Evidence	منشأ Artifact شواهد
supersedes	نسخه جدید	نسخه قدیم	جایگزینی بدون حذف تاریخچه
invalidates	Change	Edge/Node	تصمیم ثبت‌شدهٔ اثر تغییر

سناریوی تست چیست؟ پنج شکل معتبر

سناریوی تست چیست؟ در قرارداد این مقاله، توصیف سطح‌بالای یک موقعیت، جریان یا توالی معنادار با Objective، مرز شروع/پایان و لینک‌های پوشش است. سناریو می‌تواند کاربرمحور باشد، اما فقط به User Journey محدود نیست.

نوع Scenario	نمونه ساختگی	نکته طراحی
User journey	کاربر از انتخاب کالا تا مشاهده رسید می‌رود	Actor، start/end و handoffها روشن
Event chain	Order→Attempt→Callback→Ledger→Receipt	هویت و ترتیب رویدادها مهم است
Operational failure	Timeout پس از commit و retry	Unknown state و recovery Oracle لازم است
Quality scenario	رسید فارسی در RTL و عرض موبایل	محرک، محیط، پاسخ و معیار مشخص
Cross-system reconciliation	جمع Attemptها با Ledger ساختگی تطبیق می‌یابد	Population و واحد پول باید قرارداد شود

SCENARIO: SYN-SC-RECOVERY-04
Objective: رفتار قابل مشاهده پس از timeout-after-fake-commit چیست؟
Actors/systems: Checkout, fake PSP, Callback worker, Ledger stub
Start: Attempt SYN-A4 created
End: one canonical state or explicit Unknown requiring reconciliation
Covers: SYN-C3, SYN-C4, SYN-C6
Excludes: real PSP, bank settlement, Production notification
Required evidence: event identity + state transitions + ledger reconciliation

سناریو الزاماً E2E، Happy Path یا کاربرمحور نیست

سناریوی «بازپخش Callback پس از Restart worker» یک جریان فنی است؛ «بازیابی پس از قطع ارتباط» عملیاتی است؛ «خوانایی رسید برای Screen Reader» یک Quality Scenario است. اگر تیم Scenario را فقط E2E بداند، شرایط مرزی و سازوکارهای میانی ممکن است بی‌مالک بمانند. اگر هر Case کوچک را Scenario بنامد، ارزش نگاه سطح‌بالا از بین می‌رود. Naming Contract باید دامنه را حل کند.

تست‌کیس چیست؟ از High-level تا Low-level

تست کیس چیست؟ یک ادعای آزمون‌پذیر است که به Condition متصل می‌شود و حداقل پیش‌شرط، داده/پارامتر، Action یا Trigger، Expected Result و Oracle را مشخص می‌کند. Case می‌تواند پارامتریک و کوتاه باشد یا Procedure دقیق داشته باشد؛ جزئیات بیشتر همیشه کیفیت بیشتر نیست.

سطح	چه چیزی صریح است؟	مناسب وقتی	ریسک
Intent/High-level Case	Condition، دادهٔ کلیدی، Expected/Oracle	اجراکننده ماهر، محصول متغیر، handoff کم	تفاوت اجرای پنهان
Parameterized Case	پارامترها و Expected mapping	مرزها/ترکیب‌ها یا اجرای داده‌محور	Explosion و Oracle سطحی
Detailed Case	Setup، Steps، checkpoints، cleanup	هماهنگی دقیق یا فرآیند حساس لازم است	هزینه تغییر و اجرای کورکورانه
Model/property-based Check	Generator، invariant، shrink/seed	فضای ورودی بزرگ یا رفتار حالتی	مدل/Generator ناقص

HIGH-LEVEL CASE: SYN-TC-BOUNDARY-02
Covers: SYN-C2
Given: amount unit=IRR; RULES-v3
Data: min-1, min, min+1, max-1, max, max+1
When: submit to disconnected checkout stub
Expected: acceptance exactly matches versioned boundary table
Oracle: RULES-v3 §amount-limits
Evidence: request/result matrix; no real transaction

LOW-LEVEL ADDENDUM: SYN-PROC-BOUNDARY-02
1. Load dataset SYN-AMOUNT-v2 and verify SHA-256 manifest.
2. Reset fake tenant and clock to declared fixture.
3. Submit each canonical IRR value once with unique attempt_id.
4. Capture response code and persisted synthetic state.
5. Compare to RULES-v3 table; do not convert toman implicitly.
6. Destroy fixture; attach run/evidence IDs.

Expected Result، Actual Result و Oracle را مخلوط نکنید

Expected Result باید پیش از مشاهده و با منبع قابل دفاع نوشته شود. Actual Result گزارش آن چیزی است که در Attempt دیده شد. Oracle سازوکار تشخیص تفاوت معنادار است و ممکن است Rule، مدل مستقل، invariant، مرجع انسانی مجاز یا مقایسهٔ متامورفیک باشد. کپی کردن خروجی فعلی سیستم در Expected، خطا را به «انتظار» تبدیل می‌کند.

عنصر	نمونه درست	نمونه مسئله‌دار
Expected	برای Event ID یکسان، یک اثر Canonical	سیستم باید درست کار کند
Oracle source	API-v5 §idempotency + Ledger invariant I-2	رفتار نسخه فعلی
Actual	دو Ledger row با event_id یکسان مشاهده شد	Idempotency خراب است
Outcome	Failed against TC@v2 on Build B17	این Case همیشه Fail است
Interpretation	ممکن است dedup قبل از commit اعمال نشده باشد	علت قطعی race condition است

Test Charter با Scenario مبهم چه فرقی دارد؟

Charter مجوز «هرچه شد امتحان کن» نیست. Mission، Scope، Risks، Oracles، Data، Timebox و نوع Evidence را برای یک Session تعیین می‌کند و در عین حال آزادی یادگیری و انشعاب را حفظ می‌کند. Scenario می‌تواند ورودی Charter باشد، اما جای Session record و Debrief را نمی‌گیرد.

CHARTER: SYN-CH-RTL-01
Mission: explore Persian receipt readability and semantic order
Scope: disconnected mobile viewport; fa-IR; RTL/LTR mixed tokens
Risks: clipped amount, reordered ID, ambiguous IRR/toman, digit mismatch
Oracles: approved content spec + semantic DOM order + exact value table
Data: synthetic names/IDs only; Persian/Arabic/Latin digits
Timebox: 45 minutes
Evidence: notes, viewport matrix, sanitized local screenshots
Debrief: findings, coverage notes, questions, next charter

Checklist با Scenario و Case چه فرقی دارد؟

Checklist یک حافظهٔ فشرده برای مجموعه‌ای از بررسی‌های شناخته‌شده است. برای بازرسی تجربه‌ای یا تکرار روی سطوح متعدد مفید است، اما اگر هر Item فاقد Oracle و Coverage link باشد، تیک خوردن آن Evidence معنادار تولید نمی‌کند. Checklist نباید پناهگاه Caseهای ناقص شود.

CHECKLIST: SYN-CL-FA-RECEIPT-v1
[ ] واحد canonical=IRR و نمایش toman صریح است
[ ] رقم‌های فارسی/عربی/لاتین بدون تغییر مقدار پردازش می‌شوند
[ ] شناسه LTR در متن RTL ترتیب بصری/معنایی درست دارد
[ ] زمان UTC ذخیره و Asia/Tehran صریح نمایش داده می‌شود
[ ] تاریخ جلالی فقط presentation است، نه هویت رخداد
[ ] Error و fallback نیز خوانا و قابل بازیابی‌اند
Each item → Oracle ID + Evidence reference

Procedure، Suite و Script را از Test Case جدا نگه دارید

Procedure ترتیب اجرا و Setup/Cleanup را هماهنگ می‌کند؛ Suite مجموعه‌ای برای هدف Run است؛ Script پیاده‌سازی یک Check است. یک Script می‌تواند چند Case را پیاده کند، یک Case می‌تواند Manual و Automated implementation داشته باشد و یک Suite می‌تواند بر اساس Risk، Component یا Regression slice ساخته شود. این روابط را Edge کنید، نه اینکه همه چیز را در عنوان Case بچپانید.

آیا هر Automated Script به Manual Test Case نیاز دارد؟

خیر. Script می‌تواند از Example، State Model، Contract، Invariant یا Property مشتق شود. تبدیل اجباری هر Check خودکار به Steps دستی معمولاً سند موازی و قدیمی می‌سازد. آنچه لازم است، Traceability از Script به Design intent، Oracle، Data/Generator، Environment و Coverage Item است. اگر اجرای دستی واقعاً برای تشخیص، fallback یا audit لازم است، Procedure دستی مستقل بسازید.

ماتریس انتخاب Artifact

نیاز غالب	Artifact شروع مناسب	افزودهٔ احتمالی	انتخاب نامناسب رایج
هم‌راستایی روی یک جریان	Scenario	Examples و Conditions	صدها Step زودهنگام
پوشش Rule یا Boundary	Parameterized Case	Decision table/data set	Scenario کلی
یادگیری در فضای ناشناخته	Charter	Session notes و follow-up Cases	Case خطی که انشعاب را ممنوع کند
بازرسی تکراری متخصص	Checklist	Oracle links	تیک بدون Evidence
هماهنگی Setup/ترتیب	Procedure	Case/Charter references	کپی Setup در همه Caseها
فضای داده بزرگ	Property/Model Check	Generator، seed، shrink record	چند مثال خوش‌مسیر
تحویل به اجراکننده دور	Detailed Case/Procedure	Environment/Data manifest	عنوان مبهم

سطح جزئیات را با چه عواملی انتخاب کنیم؟

یک «امتیاز جادویی» جهانی وجود ندارد. تیم باید عوامل را ثبت و درباره Trade-off تصمیم بگیرد. افزایش جزئیات وقتی مفید است که ابهام تصمیم یا هزینهٔ اجرای متفاوت را کاهش دهد؛ اگر فقط متن بیشتری برای نگهداری بسازد، ارزش ندارد.

عامل	نشانهٔ جزئیات بیشتر	نشانهٔ Artifact سبک‌تر	سؤال بازبینی
ریسک/اثر	پیامد بالا و بازیابی دشوار	اثر محدود و برگشت‌پذیر	کدام ادعا به Evidence قوی‌تر نیاز دارد؟
پیچیدگی Oracle	چند منبع/محاسبه/تحمل	Invariant روشن	دو اجراکننده همان Outcome را می‌دهند؟
State/Data	Seed، reset و هویت حساس	تابع خالص/داده ساده	حالت پنهان چیست؟
Volatility	منطق پایدار، handoff زیاد	UI متغیر، تیم هم‌مکان	هزینه تغییر در کدام لایه است؟
فاصله تحویل	زمان/زبان/سازمان متفاوت	نویسنده همان اجراکننده	چه Contextی در handoff گم می‌شود؟
مهارت Actor	روش حساس به دانش ضمنی	متخصص با Charter و Debrief	آزادی اجرا ارزش دارد یا Variance؟
تکرار/کادنس	Regression پرتکرار	تحقیق یک‌باره	Automation یا Procedure هزینه را کم می‌کند؟
تعهد Evidence	Review/audit مشخص	تصمیم داخلی کم‌اثر	دقیقاً چه شواهدی و برای چه کسی؟

Artifact Decision Card بسازید

ARTIFACT-DECISION: ADC-2026-17
Decision: Parameterized boundary case + shared procedure
Conditions: SYN-C2
Why: exact versioned limits; repeated regression; remote execution
Detail added: dataset manifest, reset, expected mapping
Detail omitted: UI click prose; selectors owned by automation layer
Evidence profile: input/output matrix + persisted state
Change triggers: RULES amount/version/unit; submission interface
Owner / reviewer / review-by: qa-a / product-rule-owner / 2026-09-01

سبک‌بودن سند به معنی کم‌دقت‌بودن نیست

یک Case هفت‌خطی با ID، Basis، Condition، داده، Oracle و Expected روشن می‌تواند دقیق‌تر از صفحه‌ای Steps کلی باشد. Rigour از صراحت ادعا، قابلیت تکرار تصمیم، کیفیت Oracle و provenance Evidence می‌آید؛ نه از تعداد کلمات. در مقابل، «Explore checkout» حتی اگر کوتاه و Agile نامیده شود، بدون Charter قابل پاسخ‌گویی نیست.

آیا صنایع تنظیم‌شده همیشه Detailed Case می‌خواهند؟

نسخهٔ جهانی و امنی برای این ادعا وجود ندارد. نوع مستند و شواهد به قانون، حوزه قضایی، طبقه محصول، Quality System، قرارداد، تصمیم و مرجع ارزیابی وابسته است. استاندارد ISO/IEC/IEEE 29119-3:2021 قالب‌هایی برای مستندات تست در سازمان‌ها، پروژه‌ها و مدل‌های چرخه عمر مختلف توصیف می‌کند؛ صفحهٔ عمومی استاندارد جای متن کامل، تفسیر حقوقی یا اثبات انطباق نیست.

به‌جای جملهٔ «بانکداری Case جزئی می‌خواهد»، منبع الزام، نسخه، محدوده، Approver، نگهداشت و Evidence مورد انتظار را ثبت کنید. در پروژهٔ ایرانی نیز ادعای قانونی/بانکی باید توسط مالک حقوقی و کیفیت مجاز تأیید شود؛ این مقاله مشاورهٔ حقوقی یا مالی نیست.

Compliance Evidence Contract

فیلد	سؤال	خطای رایج
Authority	کدام قانون/استاندارد/قرارداد و کدام بند؟	«طبق استاندارد» بدون مرجع
Applicability	چرا به این محصول/نسخه/بازار مربوط است؟	تعمیم از صنعت دیگر
Interpretation owner	چه کسی تفسیر را تصویب کرده؟	تفسیر شخصی QA
Required record	Design، Procedure، Result یا Signature کدام لازم است؟	جمع‌آوری همه چیز
Retention/access	تا چه وقت و برای چه نقشی؟	Evidence بدون کنترل دسترسی
Change trigger	با تغییر منبع چه چیز بازبینی می‌شود؟	سند ثابت و منقضی

حداقل Schema برای Test Design Graph

گروه	فیلدهای ضروری	هدف
Identity	artifact_id، type، version	ارجاع پایدار و تاریخچه
Meaning	objective، claim، scope/exclusions	جلوگیری از عنوان‌های مبهم
Trace	basis_ids@versions، condition_ids، risk_ids	چرایی و پوشش
Execution need	data/env/oracle/evidence_profile	آمادگی اجرا بدون مخلوط‌کردن Result
Governance	owner، reviewer، status، effective_at، review_by	تصمیم و تازگی
Integrity	content hash یا immutable revision ID	تشخیص نسخه، نه اثبات درستی
Edges	type، from@version، to@version، status، rationale	معنای رابطه و اثر تغییر

{
  "artifact_id": "SYN-P1",
  "type": "property-check",
  "version": 2,
  "basis": ["API-v5"],
  "covers": ["SYN-C3"],
  "oracle": "one canonical effect per authorized event_id",
  "generator": "SYN-CALLBACK-GEN-v2",
  "evidence_profile": "invariant-check",
  "owner": "qe-b",
  "status": "reviewed",
  "review_by": "2026-09-10"
}

Status طراحی را از Outcome اجرا جدا کنید

نوع	واژگان پیشنهادی	معنا
Design lifecycle	Draft، In Review، Reviewed، Active، Superseded، Archived	وضعیت خود Artifact
Readiness	Blocked for Design، Ready for Implementation، Ready for Run	Gate مرحله‌ای با دلیل
Execution outcome	Passed، Failed، Blocked، Inconclusive، Invalid، Aborted	نتیجه Attempt مشخص
Coverage evidence	No Run، Evidence Missing، Evidence Present، Evidence Rejected	وجود/اعتبار Evidence طبق Profile

Case «Active و Reviewed» می‌تواند در آخرین Run شکست خورده باشد؛ این تناقض نیست. برعکس، یک Attempt Passed روی Case منسوخ ممکن است برای Basis جدید بی‌اعتبار باشد.

Versioning و Change Impact را چگونه مدیریت کنیم؟

ویرایش خاموش Test Case، Evidence قبلی را بی‌معنا می‌کند. هر تغییر معنایی باید نسخه جدید بسازد و رابطهٔ supersedes را نگه دارد. تغییر نگارشیِ بدون اثر می‌تواند Revision جزئی باشد، اما معیار این تفکیک باید در Configuration Policy تیم تعریف شود.

تغییر Basis	Edgeهای مشکوک	تصمیم ممکن	Evidence لازم
حد مبلغ	Condition→Case/Data/Oracle	Revise و rerun	Boundary matrix جدید
نام UI	Procedure/selector	Implementation-only update	Render/interaction check
معنای Status	Condition/Expected/Report	Semantic invalidation	Migration و compatibility
Schema Callback	Script/Data/contract checks	نسخه جدید یا mixed-version test	Producer/consumer matrix
تفسیر الزام	Compliance edge	Re-review by authority owner	Decision record

Coverage با شمارش Artifact یکی نیست

شش Condition و شش Artifact به معنی ۱۰۰٪ پوشش نیست. ممکن است دو Artifact یک Condition را تکرار کنند، Condition دیگری بی‌پوشش باشد، لینک به Basis قدیمی باشد یا نوع Evidence با Risk Claim تناسب نداشته باشد. Coverage باید نسبت به مدل و Population نام‌گذاری‌شده محاسبه شود.

Metric	صورت	مخرج	محدودیت
Mapped condition coverage	Conditionهای دارای Edge معتبر	Conditionهای in-scope	کفایت Design یا Execution را ثابت نمی‌کند
Evidence-backed coverage	Itemهای دارای Evidence پذیرفته‌شده	Coverage Itemهای in-scope	فقط برای Snapshot و Build تعریف‌شده
Fresh trace ratio	Edgeهای بازبینی‌شده پس از تغییر	Edgeهای impacted	Review صوری ممکن است
Orphan rate	Artifactهای بدون upstream/downstream لازم	Artifactهای Active	کم‌شدن مصنوعی با حذف Artifact ممکن است

Evidence Profile را بر اساس ادعا تعریف کنید

وجود یک Screenshot برای همه ادعاها کافی نیست. Evidence Profile مشخص می‌کند چه نوع مشاهده‌ای باید از Attempt تولید شود تا Review ممکن باشد. Profile تضمین نمی‌کند ادعا درست است؛ فقط انتظار ساختاری را روشن می‌کند.

Profile	ادعا	حداقل Evidence ساختاری	آنچه ثابت نمی‌کند
repeatable-case	خروجی دقیق برای داده مشخص	Build/env/data/expected/actual	پوشش فضای داده
boundary-case	رفتار اطراف حد نسخه‌دار	Boundary table و source version	همه ترکیب‌ها
invariant-check	خاصیت در مجموعه اجراها	Generator/seed/population/failures	مدل کامل دامنه
fault-procedure	Recovery در نقطه خطای مشخص	fault timing، state transition، reconciliation	تاب‌آوری Production
specialist-checklist	بازرسی تخصصی	item/oracle/observation/reviewer	انطباق کامل
reconciliation-check	سازگاری دو Population	snapshots، keys، units، diffs	صحت هر دو منبع

Review Gateهای طراحی

Gate	پرسش	HOLD نمونه
Identity	ID/type/version یکتا است؟	دو Artifact با ID مشترک
Basis	منبع و نسخه معتبر است؟	RULES-v2 به‌جای v3
Coverage	Conditionها Edge معتبر دارند؟	Condition بی‌پوشش
Fitness	نوع Artifact/Evidence مناسب ادعاست؟	Scenario کلی برای fault recovery
Oracle	Expected قابل تصمیم است؟	«باید درست باشد»
Ownership	مالک و Review-by وجود دارد؟	بررسی تخصصی بدون متخصص
Implementation	Script/Procedure به نسخه موجود وصل است؟	Orphan Script
Safety/privacy	Data، محیط و دسترسی مجاز است؟	داده یا endpoint واقعی در Lab

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

برای آزمودن مکانیک گراف، یک Fixture کاملاً ساختگی و آفلاین با شناسه SYN-TEST-DESIGN-GRAPH-01 ساختیم. شش Condition و شش Artifact Draft وجود دارد. کنترل ساده فقط تعداد را مقایسه می‌کند؛ ممیزی گراف، Coverage edge، Basis version، Evidence profile، Owner و implements edge را بررسی می‌کند.

Condition	ادعای ساختگی	Profile لازم	Basis مورد انتظار	مالک
SYN-C1	پروفایل عادی Checkout	repeatable-case	RULES-v3	qa-a
SYN-C2	مرز مبلغ	boundary-case	RULES-v3	qa-a
SYN-C3	Callback تکراری	invariant-check	API-v5	qe-b
SYN-C4	Timeout پس از commit	fault-procedure	API-v5	qe-b
SYN-C5	رسید فارسی RTL	specialist-checklist	UI-v4	عمداً خالی
SYN-C6	تطبیق Order و Ledger	reconciliation-check	LEDGER-v2	finance-c

در Draft، Case مربوط به C2 به RULES-v2 قدیمی وصل است؛ C4 فقط Charter دارد و Profile بازیابی خطا را تأمین نمی‌کند؛ C5 مالک ندارد؛ C6 هیچ Artifact پوشش‌دهنده ندارد؛ و Script به SYN-TC99 ناموجود اشاره می‌کند. بااین‌حال چون تعداد Condition و Artifact هر دو شش است، کنترل موجودی ۱۰۰٪ نشان می‌دهد.

{
  "runtime": "v26.7.0",
  "fixture": "SYN-TEST-DESIGN-GRAPH-01",
  "naiveInventory": {
    "conditions": 6,
    "artifacts": 6,
    "nominalCoverage": "100%",
    "decision": "PASS"
  },
  "draftGraph": {
    "mappedConditions": 5,
    "totalConditions": 6,
    "mappedCoverage": "83%",
    "findings": [
      "stale-basis:SYN-C2",
      "insufficient-evidence-profile:SYN-C4",
      "missing-owner:SYN-C5",
      "uncovered-condition:SYN-C6",
      "orphan-script:SYN-AS1->SYN-TC99"
    ],
    "decision": "HOLD"
  },
  "correctedGraph": {
    "mappedConditions": 6,
    "totalConditions": 6,
    "mappedCoverage": "100%",
    "findings": [],
    "decision": "READY_FOR_DESIGN_REVIEW"
  }
}

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

Case مرزی C2 با Basis نسخهٔ RULES-v3 جایگزین شد.
برای C4 یک fault-procedure با زمان تزریق خطا و Reconciliation اضافه شد.
برای C5 مالک تخصصی a11y-owner-d تعیین شد.
C6 به reconciliation-check مستقل وصل شد.
Script به Property Check موجود SYN-P1 متصل شد، نه Case خیالی.

READY_FOR_DESIGN_REVIEW فقط یعنی قواعد ساختاری این Fixture یافته‌ای ندارند. این خروجی اثبات اجرای تست، کفایت Coverage، نبود Defect، کاهش Risk، کیفیت محصول، آمادگی انتشار یا انطباق نیست. همه IDها، Rules، داده‌ها، درصدها و تصمیم‌ها عمداً ساختگی‌اند؛ آزمایش هیچ سیستم واقعی، ابزار مدیریت تست یا محصولی را Benchmark نکرده است.

چگونه آزمایش را مستقل بازتولید کنیم؟

منطق به کتابخانه یا شبکه وابسته نیست: آرایهٔ Conditionها، Artifactها، Profileهای قابل قبول و Basisهای مورد انتظار تعریف می‌شود؛ سپس Nodeها و Edgeها پیمایش می‌شوند. برای بازتولید، Fixture را ثابت نگه دارید، نسخه Runtime و ورودی را ثبت کنید و خروجی JSON را با Expected fixture مقایسه کنید. این Demonstration جای تست Tool، Database، concurrency، دسترسی یا Workflow واقعی را نمی‌گیرد.

for each condition:
  linked = artifacts where condition.id in artifact.covers
  if linked is empty → uncovered-condition
  if no linked.type satisfies condition.profile → insufficient-evidence-profile
  if any linked.basis != expected basis → stale-basis
  if condition has no effective owner → missing-owner
for each automated-script:
  if implements target does not exist → orphan-script
decision = findings.empty ? READY_FOR_DESIGN_REVIEW : HOLD

سناریوی عملی ساختگی برای یک Checkout ایرانی

لابراتوار SYN-CHECKOUT-DESIGN-01 هیچ اتصال شبکه‌ای ندارد و از Checkout، PSP، Ledger و Notification بدل استفاده می‌کند. همه مشتری‌ها، سفارش‌ها، Eventها، مبلغ‌ها و زمان‌ها ساختگی‌اند. واحد canonical مبلغ IRR است و اگر UI تومان نشان دهد، عبارت «تومان» و تبدیل دقیق باید صریح باشد.

Basis ساختگی	Condition	Artifact انتخابی	دلیل
RULES-v3	پروفایل عادی و مرز مبلغ	High-level + parameterized Cases	Expected mapping دقیق و پرتکرار است
API-v5	Duplicate Callback	Property/invariant Check	ترکیب delivery و commit گسترده است
API-v5	Timeout-after-commit	Fault Procedure + Scenario	زمان خطا و state transition مهم است
UI-v4	رسید فارسی/RTL	Specialist Checklist + Charter	بازرسی و کاوش مکمل‌اند
LEDGER-v2	Order/Ledger reconciliation	Reconciliation Check	Population، key و unit باید مقایسه شود

Test Data و هویت در لابراتوار فارسی

Dataset باید Seed، Generator version، Reset و invariant داشته باشد. نام، موبایل، ایمیل، IP، حساب، سفارش، PAN، CVV2، OTP، Cookie، Token و Secret واقعی ممنوع است. ارقام فارسی «۱۲۳»، عربی «۱۲۳» و لاتین «۱۲۳» برای نمایش و Parsing جداگانه آزموده می‌شوند؛ Normalization نباید مقدار یا شناسه را بی‌صدا عوض کند.

DATASET: SYN-FA-PAY-v4
seed: 42017
tenant: SYN-TENANT-01
amount: 280000 IRR
display variants: "۲۸۰٬۰۰۰ ریال" | "۲۸٬۰۰۰ تومان"
event time: 2026-08-12T08:15:00Z
display zone: Asia/Tehran
Jalali: presentation-only; event identity remains ISO instant
contains_real_person_or_payment_data: false
reset: local fixture destroy/recreate

Faultها و Oracleهای نمونه در لابراتوار

Fault/variation	Oracle	Evidence مورد انتظار	ادعای ممنوع
Timeout قبل از fake commit	هیچ اثر canonical ثبت نشود یا state صریح	transition + reconciliation	رفتار PSP واقعی
Timeout بعد از fake commit	Retry اثر دوم نسازد	event/attempt/ledger IDs	Exactly-once سراسری
Duplicate/late callback	قانون API-v5 برای identity/order	delivery history + current state	نبود Race در Production
قطع cache/mirror	منبع Canonical و fallback تعریف‌شده	source selection record	تاب‌آوری زیرساخت واقعی
RTL و mixed digits	content/semantic order و exact values	matrix + specialist notes	انطباق کامل دسترس‌پذیری

Scrum و Agile چه چیزی را الزام نمی‌کنند؟

راهنمای رسمی Scrum نوامبر ۲۰۲۰ Artifactهای Product Backlog، Sprint Backlog و Increment و Commitmentهای آن‌ها را تعریف می‌کند؛ Test Scenario، Test Case یا نقش مستقل QA را تجویز نمی‌کند. پس جملهٔ «در Agile تست‌کیس نمی‌نویسیم» یا «Scrum سناریو می‌خواهد» از خود Scrum Guide نتیجه نمی‌شود. تیم می‌تواند Testware مناسب را در Definition of Done، Workflow و Engineering policy خود قرارداد کند.

چه زمانی مستند را Just-in-time بسازیم؟

وقتی UI و جزئیات جریان ناپایدارند، Condition، Oracle و Coverage intent را زود تثبیت کنید و Procedure/selector جزئی را نزدیک اجرا بسازید. Just-in-time به معنی «بدون Traceability تا لحظه آخر» نیست. Trigger آماده‌سازی را مشخص کنید: Ready for Design، interface freeze، Build candidate یا شروع Session.

Tool انتخاب کنید، نه Taxonomy ابزار را

ابزار مناسب باید ID و Version پایدار، Edgeهای نوع‌دار، bulk query، history، API/export، permission، review و لینک Run/Evidence را پشتیبانی کند. نام محصول به‌تنهایی مهم نیست. ابتدا یک نمونه Graph را در ابزار موجود پیاده کنید و ببینید آیا می‌توانید پرسش‌هایی مثل «کدام Script به Basis منسوخ وصل است؟» یا «کدام Condition پرریسک Owner ندارد؟» را بدون Spreadsheet دستی پاسخ دهید.

اگر ابزار فقط parent-child دارد، Edge type را در فیلد ساختاریافته و export نگه دارید.
اگر Versioning ضعیف است، immutable revision URL یا Git commit را مرجع کنید.
اگر Graph query ندارد، گزارش orphan/stale را با API بسازید و snapshot آن را نگه دارید.
قفل‌شدن در Vendor را با export قابل خواندن و شناسه‌های مستقل کاهش دهید.

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

اتوماسیون برای قواعد قطعی مناسب است: ID تکراری، Edge شکسته، Basis قدیمی، Owner خالی، Review-by منقضی، Evidence profile ناشناخته، Script یتیم و Cycle ممنوع. اما نمی‌تواند به‌تنهایی بگوید Scenario کافی است، Oracle درست است یا Risk پذیرفتنی است.

CI DESIGN-GRAPH POLICY
ERROR: broken edge; duplicate identity; prohibited real-data marker
HOLD: uncovered critical condition; stale basis; missing required owner
WARN: review-by expired; high fan-in/out; unexecuted active artifact
INFO: superseded artifact retained for historical evidence
Human review: adequacy, risk acceptance, oracle validity, compliance

استفاده امن از AI در طراحی Artifact

AI می‌تواند از روی Basis مجاز، Candidate Condition، Boundary، سؤال و Draft Case پیشنهاد کند یا روابط گمشده را برای Review علامت بزند. نباید Requirement، Oracle، نتیجه اجرا یا Evidence را جعل کند؛ داده حساس را به سرویس تأییدنشده بفرستد؛ یا Draft را بی‌Review فعال کند. خروجی باید provenance شامل model/tool version، prompt/template، input references، زمان و Reviewer داشته باشد.

کار	نقش AI	کنترل انسانی	ممنوع
استخراج Candidate	پیشنهاد Condition/edge	تأیید معنای Basis	ساخت منبع خیالی
تنوع داده	پیشنهاد boundary/Unicode	بررسی domain و privacy	داده شخصی واقعی
بازنویسی Case	کاهش ابهام/تکرار	حفظ Oracle و intent	تغییر خاموش معنا
Graph audit	اولویت‌بندی finding	تصمیم Gate ثبت‌شده	اعلام خودکار کفایت Coverage

نقش‌ها و حق تصمیم

تصمیم	Responsible	Approver/owner	Consulted
معنای Basis/Rule	Analyst/Product	Domain owner	QA/Engineering
Condition و Coverage model	Test analyst	Test design owner	Domain/Dev/SRE
نوع Artifact و جزئیات	Test designer	Test lead	Executor/Automation
Oracle تخصصی	Domain specialist	Claim owner	QA/Legal/Security حسب زمینه
Implementation/Script	Test/Software engineer	Code owner	Designer
Outcome Attempt	Executor/system	Run owner	Artifact owner
Risk acceptance/release	Decision owner	نام‌برده در governance	QA/Product/Engineering

Metricها و Countermetricها

Metric	کاربرد	Countermetric	بازی احتمالی
Uncovered condition count	یافتن شکاف mapping	Condition quality review	ادغام Conditionها برای کاهش عدد
Stale edge age	تأخیر Change review	Meaningful change rate	Review صوری
Orphan Script rate	پیاده‌سازی بی‌intent	Useful direct-property links	لینک‌سازی مصنوعی
Median maintenance time	هزینه مستندات	Escaped ambiguity/rework	کاهش جزئیات ضروری
Evidence rejection rate	کیفیت handoff	Reviewer latency	پذیرش آسان Evidence
Time-to-impact-assess	سرعت فهم تغییر	Missed impacted artifacts	بستن سریع بدون بررسی

تعداد Test Case، تعداد Step و درصد Automation هدف کیفیت نیستند. Metric بدون Population، Window، Status semantics و امکان بازی‌کردن، رفتار نامطلوب می‌سازد.

Pilot سی‌روزه برای Test Design Graph

روز	تمرکز	خروجی	Gate
۱–۵	یک Feature و Naming Contract	واژگان، Scope، ۱۰–۲۰ Condition	مالک معنا تأیید کرده
۶–۱۰	Artifact Decision	Scenario/Case/Charter mix و profiles	هیچ Condition حیاتی یتیم نیست
۱۱–۱۵	Implementation links	Procedure/Script/Data/Env edges	نسخه و Owner کامل
۱۶–۲۰	Run و Evidence	Attempts بدون بازنویسی Design	Trace تا Evidence قابل پرس‌وجو
۲۱–۲۵	Change drill	Basis change و impact decision	stale/orphan audit کار می‌کند
۲۶–۳۰	بازنگری هزینه/ارزش	Tailoring policy و backlog	Continue/adjust/stop با شواهد

۳۰ Anti-pattern در سناریو و تست‌کیس

Scenario را همیشه E2E دانستن.
Case را همیشه Step-by-step دانستن.
What را فقط به Scenario نسبت‌دادن.
Actual Result را در نسخه Design نوشتن.
Pass/Fail را Status دائمی Case گرفتن.
یک Scenario→چند Case را تنها رابطه مجاز دانستن.
تعداد Artifact را Coverage نامیدن.
Scenario کلی را جای Condition گذاشتن.
Checklist بی‌Oracle ساختن.
Charter بی‌Mission و Timebox نوشتن.
Script را بدون Design intent نگه‌داشتن.
برای هر Script یک Manual Case اجباری ساختن.
Steps UI را پیش از ثبات interface قفل‌کردن.
Basis version را حذف‌کردن.
ویرایش خاموش Case پس از اجرای قبلی.
Artifact منسوخ را حذف و Evidence تاریخی را یتیم‌کردن.
Owner را نام تیم عمومی گذاشتن.
Review-by نداشتن.
Oracle را «رفتار فعلی» گرفتن.
Expected مبهم «باید درست باشد» نوشتن.
Data و State را ضمنی گذاشتن.
IRR و تومان را بی‌برچسب مخلوط‌کردن.
نمایش جلالی را هویت زمان دانستن.
داده واقعی را وارد Lab کردن.
Detailed Case را الزام جهانی صنعت دانستن.
Scrum را دلیل حذف Testware معرفی‌کردن.
قالب استاندارد را مدرک انطباق دانستن.
AI Draft را بدون provenance فعال‌کردن.
Review صوری برای سبزشدن Metric.
READY_FOR_DESIGN_REVIEW را آمادگی Release دانستن.

چک‌لیست ۴۸ نقطه‌ای طراحی و ممیزی

Objective به شکل سؤال تصمیم نوشته شده است.
Scope و Exclusion روشن‌اند.
Test Basis شناسه دارد.
نسخه Basis ثبت شده است.
مالک معنای Basis مشخص است.
Risk Claim به پیامد معین وصل است.
Condition اتمی و آزمون‌پذیر است.
Coverage model نام دارد.
Coverage Itemها قابل شمارش‌اند.
اولویت دلیل دارد.
نوع Artifact آگاهانه انتخاب شده است.
Artifact ID یکتا است.
Artifact type قراردادی است.
نسخه Artifact تغییر معنا را حفظ می‌کند.
Owner فرد/نقش پاسخ‌گو است.
Reviewer مناسب زمینه است.
Review-by تعیین شده است.
Preconditionها صریح‌اند.
State و Reset تعریف شده‌اند.
Data/Generator/Seed نسخه‌دار است.
واحد و Currency صریح‌اند.
Timezone و Time semantics صریح‌اند.
Trigger از Setup جدا است.
Expected پیش از Actual تعریف شده است.
Oracle منبع و نسخه دارد.
تحمل و Unknown state تعریف شده است.
Evidence Profile متناسب ادعاست.
Scenario start/end دارد.
Charter Mission/Scope/Timebox دارد.
Checklist Item به Oracle متصل است.
Case بی‌دلیل Steps اضافی ندارد.
Procedure ترتیب لازم را مالک است.
Suite هدف Run را بیان می‌کند.
Script به Artifact موجود وصل است.
Manual Case بی‌دلیل برای Script تکرار نشده است.
هر Edge نوع و جهت دارد.
Edge به نسخه‌های دقیق وصل است.
Condition حیاتی یتیم نیست.
Artifact Active بدون upstream لازم نیست.
Orphan Script وجود ندارد.
Design Status از Outcome جدا است.
Attempt به Build/Environment وصل است.
Evidence به Attempt وصل است.
Change triggerها ثبت شده‌اند.
Superseded/Archived تاریخچه را حفظ می‌کند.
داده و محیط مجاز/ساختگی‌اند.
Metric همراه Countermetric است.
Gate نتیجه محدود و صاحب تصمیم دارد.

منابع رسمی و محدودیت استفاده از آن‌ها

ISTQB CTFL Syllabus v4.0.1: مرجع واژگان و فعالیت‌های Analysis/Design/Implementation؛ نه الگوریتم جهانی Tailoring یا مدرک کیفیت.
ISO/IEC/IEEE 29119-3:2021: صفحه عمومی استاندارد مستندسازی تست؛ نه متن کامل، مشاوره حقوقی یا گواهی انطباق.
The Scrum Guide (November 2020): تعریف رسمی Scrum؛ برای نشان‌دادن اینکه نوع Test Artifact تجویز نشده است، نه طراحی فرآیند QA.

جمع‌بندی: از نام سند به قرارداد تصمیم برسید

تفاوت Scenario و Test Case یک جدول دو ستونی ثابت نیست. ابتدا Test Basis، Risk Claim، Condition و Coverage Item را روشن کنید؛ سپس بر اساس ریسک، Oracle، تغییرپذیری، مهارت اجراکننده، فاصله handoff، تکرار و Evidence موردنیاز، Scenario، Charter، Checklist، Case، Procedure یا Script را انتخاب کنید. روابط را چندبه‌چند و نسخه‌دار نگه دارید و Actual/Outcome را فقط به Run متصل کنید.

اگر قرار است از فردا فقط یک تغییر انجام دهید، برای یک Feature یک Artifact Decision Card و یک Query یتیم‌ها بسازید. همین دو خروجی سریعاً نشان می‌دهند تیم سند تولید می‌کند یا یک زنجیرهٔ شواهد قابل تصمیم.

سؤالات متداول درباره سناریوی تست و تست‌کیس

۱. آیا سناریوی تست همیشه سطح‌بالا و تست‌کیس همیشه گام‌به‌گام است؟

خیر. Scenario معمولاً سطح‌بالاست، اما Case می‌تواند High-level، پارامتریک، Detailed یا Model-based باشد. میزان جزئیات باید از Oracle، ریسک، handoff، تکرار و هزینه تغییر بیاید. Procedure می‌تواند Steps دقیق را جداگانه مالک شود.

۲. آیا یک سناریوی تست باید به چند تست‌کیس شکسته شود؟

گاهی بله، اما قانون جهانی نیست. رابطه می‌تواند چندبه‌چند باشد: یک Scenario چند Condition را پوشش دهد، یک Condition با Case و Charter و Property Check پوشش داده شود، یا یک Case چند Coverage Item مرتبط را بیازماید. Edge و دلیل رابطه را ثبت کنید.

۳. Actual Result و Pass/Fail را در تست‌کیس بنویسیم؟

Expected Result در Design Case است؛ Actual Result و Outcome به Attempt مشخص روی Artifact، Build و Environment نسخه‌دار تعلق دارند. جداکردن آن‌ها تاریخچه را حفظ می‌کند و مانع جملهٔ مبهم «این Case پاس است» می‌شود.

۴. در Agile می‌توان فقط Scenario یا Charter داشت؟

اگر برای تصمیم و ریسک موردنظر، Condition، Oracle، Coverage، Data و Evidence کافی فراهم شود، ممکن است Artifact سبک کافی باشد. Agile یا Scrum به‌تنهایی حذف Case را توجیه نمی‌کند. Tailoring را ثبت کنید و اثر آن را با نتیجه‌های واقعی و Countermetric بازبینی کنید.

۵. حداقل فیلد یک Test Scenario و Test Case چیست؟

Scenario حداقل ID/version، Objective، محدوده، start/end و Coverage links می‌خواهد. Case حداقل ID/version، Condition/Basis links، precondition، data/parameter، trigger، Expected/Oracle و Evidence profile می‌خواهد. Owner، status و review-by برای هر دو لازم‌اند؛ Actual و Outcome در Run ثبت می‌شوند.

مدیریت تست

سناریوی تست و تست‌کیس؛ انتخاب Artifact و سطح جزئیات