نوشتن تست‌کیس حرفه‌ای؛ راهنمای فاز ۳ STLC با قالب و مثال

«روی دکمه ورود کلیک کن و ببین کار می‌کند» تست‌کیس نیست. یک Test Case مؤثر باید هدف مشخص، پیش‌شرط قابل‌تکرار، داده معلوم و نتیجه‌ای داشته باشد که دو نفر مستقل بتوانند آن را یکسان ارزیابی کنند. در عین حال، جزئیات بیش‌ازحد نیز تست را شکننده و نگهداری را پرهزینه می‌کند.

در فاز سوم STLC، ریسک‌ها و Test Conditionهای برنامه تست به سناریو، تست‌کیس، چک‌لیست، Charter، داده و در صورت نیاز اسکریپت خودکار تبدیل می‌شوند. این راهنما از تعریف و قالب تا تکنیک طراحی، مثال کامل، Traceability، بازبینی و اشتباهات رایج را پوشش می‌دهد.

توسعه تست‌کیس در فاز سوم STLC چیست؟

Test Case Development فعالیت طراحی و مستندسازی شرایط، داده، مراحل و انتظارهایی است که ریسک و نیازمندی محصول را به پوشش قابل‌اجرا تبدیل می‌کنند. خروجی همیشه Test Case گام‌به‌گام نیست؛ بسته به زمینه ممکن است Checklist، Test Charter، مدل، داده تست یا Automation Code مناسب‌تر باشد.

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

ورودی‌های فاز

• نیازمندی و Acceptance Criteria روشن؛
• Risk Register و اولویت‌ها؛
• Test Plan و Scope؛
• طراحی UI/UX، قرارداد API و مدل داده؛
• Test Conditionهای سطح‌بالا؛
• تاریخچه عیب و Incident؛
• محدودیت Environment، Tool و Data.

خروجی‌های فاز

• Test Scenario و Test Case اولویت‌دار؛
• Checklist و Exploratory Charter؛
• Test Data و روش Setup/Cleanup؛
• Automation Test یا Backlog آن؛
• Traceability میان Requirement، Risk و Test؛
• نیاز مشخص Environment، Mock، Account و Access؛
• نتیجه Review و موارد باز.

تفاوت Test Scenario، Test Case، Checklist و Charter

مصنوع	کاربرد	نمونه
Test Condition	موضوع یا ویژگی قابل‌بررسی	قانون قفل حساب
Test Scenario	جریان سطح‌بالا و «چه چیزی»	ورود با رمز اشتباه
Test Case	شرایط، داده، اقدام و انتظار قابل‌اجرا	پنج تلاش ناموفق → قفل موقت
Checklist	یادآوری سبک برای پوشش آشنا	RTL، Focus، پیام خطا، ارقام
Exploratory Charter	ماموریت زمان‌دار برای کشف و یادگیری	کاوش بازیابی ورود در شبکه ضعیف
Automation Test	اجرای تکراری و Assertion ماشینی	API Test قفل حساب در CI

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

اجزای یک Test Case حرفه‌ای

شناسه و عنوان

شناسه یکتا و عنوان رفتاری: «قفل‌شدن حساب پس از پنجمین رمز اشتباه» بهتر از «تست لاگین ۱۲» است.

هدف و ارتباط

Requirement ID، Risk ID یا Acceptance Criterion مرتبط را ثبت کنید تا دلیل وجود تست و اثر تغییر روشن باشد.

اولویت

بر اساس اثر و احتمال شکست، نه آسانی اجرا. P0/P1/P2 یا High/Medium/Low باید تعریف مشترک داشته باشد.

پیش‌شرط

State لازم پیش از اجرا: نوع حساب، موجودی، Feature Flag، نسخه، داده Seedشده و سرویس در دسترس. پیش‌شرط باید قابل ساخت باشد، نه عبارت مبهم «سیستم آماده است».

داده تست

مقدار دقیق یا مرجع داده. «شماره معتبر» کافی نیست؛ فرمت، نقش و وضعیت داده را بنویسید. Secret و داده شخصی واقعی وارد سند نکنید.

گام‌ها

اقدام‌های ضروری و قابل‌مشاهده را بنویسید. از توضیح جزئیات بدیهی UI که با هر تغییر ظاهری می‌شکند خودداری کنید، مگر خود آن جزئیات هدف تست باشند.

نتیجه مورد انتظار

پس از گام مهم یا در پایان، خروجی قابل‌اندازه‌گیری: پیام، Status، State، رکورد، Event، Email یا عدم انجام اقدام. «به‌درستی کار کند» قابل ارزیابی نیست.

پس‌شرط و Cleanup

State نهایی و بازگرداندن داده برای اجرای مستقل بعدی؛ به‌ویژه در پرداخت، موجودی و تست‌های پرتکرار.

محیط و برچسب

سطح تست، پلتفرم، Component، نوع Regression/Smoke، Manual/Automated و نیاز Sandbox را برای انتخاب Suite ثبت کنید.

ویژگی‌های Test Case مؤثر

• شفاف: دو اجراکننده برداشت مشابه دارند.
• اتمی: هدف اصلی مشخص دارد، اما بی‌دلیل خرد نشده است.
• مستقل: به نتیجه یا ترتیب Test Case دیگر وابسته نیست.
• قابل‌تکرار: داده و Environment کنترل‌شده‌اند.
• قابل‌ردیابی: به Requirement/Risk متصل است.
• قابل‌اندازه‌گیری: Expected Result دقیق دارد.
• قابل‌نگهداری: جزئیات بی‌ارزش UI و تکرار کم دارد.
• ریسک‌محور: برای هدف واقعی نوشته شده، نه افزایش تعداد.
• بازبینی‌شده: فرض و پوشش آن پیش از اجرا بررسی شده است.

مراحل نوشتن تست‌کیس

۱. Rule و Outcome را بفهمید

پیش از نوشتن گام، Actor، هدف، Rule، State و پیامد را مشخص کنید. اگر نیازمندی مبهم است، سؤال را برگردانید؛ حدس را به Test Case تبدیل نکنید.

۲. ریسک‌ها را اولویت دهید

خرابی چه اثر مالی، امنیتی، کاربری یا عملیاتی دارد؟ کدام مسیر بیشتر استفاده می‌شود؟ تاریخچه عیب کجاست؟ عمق تست باید با این پاسخ‌ها متناسب باشد.

۳. Test Condition و Scenario بسازید

پوشش سطح‌بالا را قبل از جزئیات فهرست کنید تا تکرار و شکاف دیده شود. مثال برای پرداخت: مبلغ، مجوز، State سفارش، Callback، Timeout و Recovery.

۴. تکنیک طراحی انتخاب کنید

ورودی بازه‌ای → هم‌ارزی/مرز؛ چند Rule → جدول تصمیم؛ رفتار State-dependent → انتقال حالت؛ جریان Actor → Use Case؛ ترکیب پیکربندی → Pairwise.

۵. داده و انتظار را Concrete کنید

به‌جای «مقدار نامعتبر»، مورد مشخص بنویسید و دلیل انتخاب را ثبت کنید. انتظار را در UI، API و داده در حد لازم قابل‌مشاهده کنید.

۶. سطح مناسب را تعیین کنید

Rule را در پایین‌ترین سطح مؤثر پوشش دهید. ده‌ها ترکیب مبلغ در API/Unit؛ یک یا دو مسیر حیاتی در UI. این کار سرعت و پایداری را افزایش می‌دهد.

۷. Test Case را Peer Review کنید

Developer، Product یا تستر دیگر می‌تواند شکاف Rule، انتظار غیرممکن و داده ناسازگار را پیش از اجرا پیدا کند.

۸. Traceability و Suite را کامل کنید

تست را به Requirement/Risk وصل و در Smoke، Regression، API یا Feature Suite مناسب قرار دهید.

تکنیک‌های کلیدی طراحی تست

تقسیم‌بندی هم‌ارزی و تحلیل مقدار مرزی

از هر گروه رفتار مشابه نماینده انتخاب و لبه گروه‌های مرتب را تست می‌کند. راهنمای Equivalence Partitioning و BVA مثال و جدول دارد.

جدول تصمیم

ترکیب شرط‌ها و اقدام‌ها را بدون شکاف پوشش می‌دهد؛ مناسب تخفیف، مجوز و قوانین پیچیده. مقاله Decision Table Testing را ببینید.

انتقال حالت

State، Event، Guard و Action را مدل می‌کند؛ مناسب سفارش، حساب، تیکت و Subscription. جزئیات در تست انتقال حالت.

Use Case Testing

Main Flow، Alternate Flow و Exception Flow را از هدف Actor تا نتیجه پوشش می‌دهد.

Error Guessing

از تجربه و تاریخچه استفاده می‌کند: Double-click، Back/Refresh، درخواست تکراری، ارقام فارسی، Timezone، Null و Race Condition.

Pairwise

برای Browser × OS × نقش × تنظیمات، همه ترکیب‌ها را اجرا نمی‌کند؛ مجموعه‌ای انتخاب می‌کند که هر جفت مقدار دست‌کم یک‌بار پوشش داشته باشد. ریسک بحرانی همچنان تست صریح می‌خواهد.

مثال کامل Test Case: قفل حساب

نیازمندی فرضی: «پس از پنج رمز اشتباه متوالی، حساب برای ۱۵ دقیقه قفل می‌شود. ورود موفق شمارنده را صفر می‌کند.» اعداد مثال‌اند و باید از نیاز واقعی پروژه بیایند.

Test Case ID	AUTH-LOCK-005
عنوان	قفل موقت حساب پس از پنجمین تلاش ناموفق متوالی
Requirement	AUTH-R-12
ریسک/اولویت	سوءاستفاده از حساب / P0
سطح	API Integration + یک E2E محدود
پیش‌شرط	حساب فعال، قفل‌نشده، شمارنده ناموفق صفر، ساعت تست قابل‌کنترل
داده	نام کاربری تست مستقل؛ رمز درست و یک رمز اشتباه

گام	اقدام	نتیجه مورد انتظار
۱	چهار بار ورود با رمز اشتباه	هر بار پاسخ خطای عمومی؛ حساب هنوز قفل نیست؛ شمارنده ۴
۲	بار پنجم ورود با رمز اشتباه	ورود رد؛ State قفل فعال؛ زمان پایان قفل ثبت؛ Event امنیتی ایجاد
۳	ورود فوری با رمز صحیح	ورود رد؛ پیام بدون افشای جزئیات حساس؛ Session ساخته نشود
۴	پیش‌بردن ساعت تست تا پس از ۱۵ دقیقه	قفل منقضی یا در اولین تلاش پاک شود طبق Design
۵	ورود با رمز صحیح	ورود موفق؛ شمارنده صفر؛ Session معتبر ایجاد

Test Caseهای مکمل

• ورود موفق پس از چهار خطا، شمارنده را صفر می‌کند.
• تلاش‌های هم‌زمان بیشتر از حد باعث دورزدن قفل نمی‌شوند.
• درخواست از Device/IP دیگر همان State حساب را رعایت می‌کند.
• پیام، وجود یا نبود حساب را افشا نمی‌کند.
• تلاش پس از ۱۴:۵۹ رد و پس از ۱۵:۰۰ طبق دقت تعریف‌شده پذیرفته می‌شود.
• کاربر قفل‌شده نمی‌تواند با Refresh/Token قدیمی Session جدید بگیرد.

مثال تست‌کیس ضعیف و نسخه بهتر

ضعیف	مشکل	بهتر
ورود را تست کنید	هدف و داده ندارد	ورود موفق حساب فعال با رمز صحیح
شماره نامعتبر وارد کنید	مقدار و Rule مبهم	شماره ۱۰ رقمی ۰۹۱۲۳۴۵۶۷۸ → خطای طول
سیستم درست کار کند	قابل اندازه‌گیری نیست	HTTP ۲۰۱، سفارش یک‌بار ذخیره، Event منتشر شود
اول Test ۷ را اجرا کنید	وابستگی و ترتیب	Setup مستقل با API/Fixture
روی سومین دکمه آبی کلیک کنید	شکننده و ظاهری	اقدام «ثبت آدرس» با Label/Role مشخص

طراحی داده تست

داده مثبت، منفی و مرزی

از هر Partition نماینده و برای پارتیشن مرتب مقادیر مرزی انتخاب کنید. نوع نامعتبر، Null، Duplicate و فرمت را جدا ببینید.

داده Synthetic و Masked

تا حد امکان داده مصنوعی بسازید. اگر ساختار داده واقعی لازم است، اطلاعات شخصی را با روش تأییدشده Mask/Anonymize کنید. کد ملی، موبایل، Token و اطلاعات مالی واقعی نباید در تست‌کیس یا مخزن عمومی قرار گیرند.

Setup و Cleanup

داده باید قابل‌نسخه‌بندی، ساخت سریع و پاک‌سازی باشد. هر تست مالک داده خود باشد تا اجرای موازی و تکرار مستقل ممکن شود.

زمان و تصادف

Clock، UUID، Random و سرویس بیرونی را قابل‌کنترل کنید. وابستگی به «تاریخ امروز» یا داده تصادفی بدون Seed، Test Flaky می‌سازد.

Traceability، پوشش و اولویت

Traceability پاسخ می‌دهد کدام Requirement/Risk با کدام Test پوشش دارد و تغییر چه تست‌هایی را متاثر می‌کند.

Requirement	Risk	Test Condition	Test Case	سطح
AUTH-R-12	Brute Force	قفل حساب	AUTH-LOCK-001..006	Unit/API/E2E
PAY-R-07	پرداخت تکراری	Idempotency	PAY-IDEM-001..004	Integration

پوشش صرفاً تعداد Test Case نیست. برای هر ریسک، Rule، Partition، State، سطح و نوع شواهد را ببینید. تست‌های P0 باید در Smoke/Regression مناسب و با مالک روشن باشند.

تست‌کیس دستی و اسکریپت خودکار چه رابطه‌ای دارند؟

هر Automated Test لازم نیست کپی خط‌به‌خط Test Case دستی باشد. بهتر است هدف، داده و Expected Behavior مشترک باشد، اما کد ساختار مهندسی مناسب خود را داشته باشد.

• Requirement/Risk را به نام یا Tag تست خودکار وصل کنید.
• تست API را مجبور نکنید مراحل UI را تقلید کند.
• Assertion کسب‌وکار را روشن نگه دارید.
• Setup داده را با Fixture/Factory بسازید.
• گزارش CI شناسه سناریو و Artifact شکست داشته باشد.
• Test Case دستی تکراری را پس از اتوماسیون موفق حذف یا به Checklist سبک تبدیل کنید.

بازبینی Test Case

چک‌لیست Peer Review

• به Requirement یا Risk واقعی متصل است.
• هدف و عنوان رفتاری روشن‌اند.
• پیش‌شرط قابل ساخت و داده مشخص است.
• Expected Result قابل‌اندازه‌گیری است.
• مثبت، منفی، مرز، State و خطا متناسب با ریسک دیده شده‌اند.
• در پایین‌ترین سطح مؤثر طراحی شده است.
• با تست دیگر تکرار بی‌ارزش ندارد.
• مستقل و قابل‌اجرای موازی است.
• داده حساس یا Secret ندارد.
• جزئیات UI بیش از حد و شکننده نیست.
• Cleanup یا State نهایی روشن است.

چه زمانی Test Case را به‌روزرسانی یا حذف کنیم؟

• Requirement، UI، API یا Rule تغییر کرده است؛
• باگ جدید نشان داده پوشش ناقص است؛
• تست Flaky یا وابسته شده است؛
• همان ریسک در سطح پایین‌تر بهتر پوشش دارد؛
• قابلیت حذف یا خارج از Support شده است؛
• تست هیچ عیب معناداری نمی‌یابد و هزینه نگهداری بالاست.

Test Suite محصول زنده است. انباشتن Case قدیمی اعتماد به نتیجه و سرعت اجرا را کاهش می‌دهد.

چه زمانی تست‌کیس گام‌به‌گام لازم نیست؟

• تیم باتجربه برای Smoke آشنا Checklist کافی دارد؛
• هدف کشف و یادگیری است و Charter مناسب‌تر است؛
• Rule مستقیماً در Unit Test خوانا و نسخه‌دار پوشش دارد؛
• قابلیت کم‌ریسک و کوتاه‌عمر است؛
• جزئیات UI دائماً تغییر می‌کند و هدف رفتاری ثابت است.

در مقابل، برای سناریوی حساس، اجرای قانونی/قراردادی، انتقال دانش، برون‌سپاری یا UAT رسمی، Test Case دقیق‌تر ارزش دارد.

قالب آماده تست‌کیس

Test Case ID:
عنوان رفتاری:
Requirement / Risk:
اولویت:
سطح و نوع:
Manual / Automated:

پیش‌شرط:
- ...

داده تست:
- ...

گام‌ها و نتایج:
1. Action:
   Expected:
2. Action:
   Expected:

پس‌شرط / Cleanup:
- ...

Environment / Tags:
- ...

یادداشت و شواهد:
- ...

اشتباهات رایج

• نوشتن Case قبل از شفاف‌شدن Rule؛
• افزایش تعداد به جای پوشش ریسک؛
• تمرکز فقط بر Happy Path؛
• انتظار «درست کار کند»؛
• داده مبهم یا واقعی حساس؛
• وابستگی به ترتیب اجرا؛
• تکرار همه ترکیب‌ها در UI؛
• جزئیات ظاهری بیش از حد؛
• نبود Traceability و اولویت؛
• Reviewنکردن Case؛
• حذف‌نکردن تست قدیمی؛
• فرض اینکه AI یا ابزار بدون تحلیل انسانی پوشش درست می‌سازد.

سوالات متداول

تست‌کیس چیست؟

مجموعه‌ای از شرایط، داده، اقدام و نتیجه مورد انتظار برای ارزیابی یک رفتار یا ریسک مشخص نرم‌افزار است.

تفاوت Test Scenario و Test Case چیست؟

Scenario می‌گوید چه جریان یا رفتار سطح‌بالایی بررسی شود؛ Case شرایط و انتظار قابل‌اجرای آن را مشخص می‌کند. یک Scenario می‌تواند چند Case داشته باشد.

هر Test Case چند گام داشته باشد؟

عدد ثابت ندارد. به‌اندازه‌ای که مستقل و قابل‌فهم باشد. اگر چند هدف نامرتبط، Setup پیچیده یا شکست غیرقابل‌تشخیص دارد، آن را بازطراحی کنید.

آیا همه تست‌کیس‌ها باید خودکار شوند؟

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

آیا می‌توان با هوش مصنوعی تست‌کیس نوشت؟

AI می‌تواند ایده و پیش‌نویس بسازد، اما زمینه، Rule، ریسک، داده و انتظار را باید تیم تأیید کند. خروجی را با Requirement و تاریخچه باگ Review کنید و اطلاعات حساس وارد ابزار تأییدنشده نکنید.

جمع‌بندی

تست‌کیس مؤثر دستورالعمل طولانی نیست؛ شواهد قابل‌تکرار برای یک ریسک مشخص است. از Requirement و Risk شروع کنید، تکنیک مناسب را انتخاب کنید، داده و انتظار Concrete بسازید، سطح تست را بهینه و Case را بازبینی کنید. سپس Test Suite را مانند کد محصول نگهداری کنید: اصلاح، ساده‌سازی و حذف موارد کم‌ارزش بخشی از کار است.