Test Case چیست؟ آموزش کامل طراحی تست کیس (Test Case) + نمونه واقعی

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

در یک نگاه	توضیح
تعریف	مجموعه‌ای از مراحل، داده‌های تست و نتایج مورد انتظار برای اعتبارسنجی یک قابلیت نرم‌افزاری
هدف	بررسی عملکرد صحیح نرم‌افزار و کشف خطاها قبل از انتشار
ورودی‌ها	Requirement، User Story، Acceptance Criteria و قوانین کسب‌وکار
خروجی	نتیجه اجرای تست مانند Pass، Fail، Blocked یا Not Executed
کاربرد	Manual Testing، Regression Testing، Test Automation و مستندسازی فرآیند تست
کاربران اصلی	QA Engineer، Test Analyst، Software Tester و در برخی تیم‌ها Developers

اگر تازه وارد دنیای تست نرم‌افزار شده باشید، احتمالاً Test Case را فقط یک فرم برای ثبت مراحل تست تصور می‌کنید. اما در تیم‌های حرفه‌ای، Test Case نتیجه تحلیل نیازمندی‌ها، شناخت قوانین کسب‌وکار، ارزیابی ریسک و انتخاب تکنیک مناسب طراحی تست است. به همین دلیل، کیفیت یک Test Case فقط به نحوه نوشتن آن وابسته نیست؛ بلکه به کیفیت تحلیل QA Engineer نیز بستگی دارد.

در پروژه‌های Agile نیز طراحی Test Case معمولاً از User Story و Acceptance Criteria آغاز می‌شود. سپس QA با تحلیل ریسک‌ها، استخراج Test Scenarioها و انتخاب Test Design Technique مناسب، Test Caseهایی طراحی می‌کند که بیشترین پوشش ممکن را برای اعتبارسنجی نرم‌افزار فراهم کنند.

در این مقاله چه چیزهایی یاد می‌گیرید؟

• Test Case چیست و چه نقشی در تست نرم‌افزار دارد.
• تفاوت Test Case، Test Scenario و Checklist.
• اجزای یک Test Case استاندارد و حرفه‌ای.
• معرفی کامل Template استاندارد Test Case.
• ارتباط Requirement، User Story و Acceptance Criteria با Test Case.
• نحوه طراحی Test Case در پروژه‌های Agile.
• انتخاب Test Design Technique مناسب برای هر سناریو.
• نمونه واقعی Test Case از یک پروژه بانکی (BlueBank).
• اشتباهات رایج هنگام طراحی Test Case.
• بهترین روش‌های نگهداری، بازبینی و به‌روزرسانی Test Caseها.

Test Case چیست؟

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

به بیان ساده، Test Case به این سؤال پاسخ می‌دهد:

برای اطمینان از عملکرد صحیح این قابلیت، دقیقاً چه مراحلی باید اجرا شوند و نتیجه صحیح چه خواهد بود؟

در پروژه‌های کوچک ممکن است تعداد Test Caseها محدود باشد، اما در سامانه‌های بانکی، بیمه، تجارت الکترونیک یا سلامت، یک قابلیت ساده مانند ورود به سیستم (Login) می‌تواند ده‌ها یا حتی صدها Test Case داشته باشد؛ زیرا علاوه بر مسیر موفق، باید شرایط خطا، محدودیت‌های امنیتی، قوانین کسب‌وکار، داده‌های مرزی و سناریوهای غیرعادی نیز بررسی شوند.

چرا Test Case اهمیت دارد؟

در پروژه‌های کوچک شاید بتوان بسیاری از تست‌ها را بدون مستندسازی انجام داد، اما با افزایش تعداد قابلیت‌ها، اعضای تیم، نسخه‌های نرم‌افزار و پیچیدگی سیستم، اتکا به حافظه افراد دیگر امکان‌پذیر نیست. Test Case به تیم کمک می‌کند فرآیند تست استاندارد، قابل تکرار و قابل مدیریت باشد.

در تیم‌های حرفه‌ای، Test Case فقط برای اجرای تست استفاده نمی‌شود؛ بلکه نقش مهمی در مستندسازی، انتقال دانش، برنامه‌ریزی Regression Testing، تحلیل پوشش تست (Test Coverage) و حتی توسعه تست‌های خودکار دارد.

• استانداردسازی فرآیند اجرای تست
• کاهش احتمال فراموش شدن سناریوهای مهم
• افزایش قابلیت تکرار تست در نسخه‌های مختلف نرم‌افزار
• مستندسازی دانش تیم QA
• تسهیل طراحی و نگهداری تست‌های خودکار
• کمک به تحلیل Test Coverage و Requirement Coverage
• ساده‌تر شدن اجرای Regression Testing
• امکان بازبینی و بهبود کیفیت تست‌ها توسط سایر اعضای تیم

QA Note: هدف از نوشتن Test Case افزایش تعداد تست‌ها نیست؛ هدف کاهش ریسک انتشار نرم‌افزار است. یک Test Case باکیفیت می‌تواند ارزش بیشتری از ده‌ها Test Case تکراری داشته باشد.

Test Case چه زمانی نوشته می‌شود؟

در بسیاری از تیم‌های Agile، طراحی Test Case پس از آماده شدن User Story و Acceptance Criteria آغاز می‌شود. با این حال، QA حرفه‌ای معمولاً منتظر پایان توسعه نمی‌ماند و از همان ابتدای Sprint در تحلیل نیازمندی‌ها مشارکت می‌کند.

فرآیند معمول طراحی Test Case در یک پروژه Agile به شکل زیر است:

1. بررسی Requirement یا User Story
2. تحلیل Acceptance Criteria
3. شناسایی ابهام‌ها و پرسیدن سؤال از Product Owner یا Business Analyst
4. شناسایی ریسک‌های سیستم
5. استخراج Test Scenario
6. انتخاب Test Design Technique مناسب
7. طراحی Test Case
8. بازبینی (Review)
9. اجرای تست و ثبت نتیجه

این فرآیند نشان می‌دهد که Test Case اولین مرحله تست نیست؛ بلکه خروجی تحلیل و طراحی تست است.

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

یکی از رایج‌ترین سؤالات افراد تازه‌کار این است که تفاوت Test Case، Test Scenario و Checklist چیست. اگرچه هر سه برای اعتبارسنجی نرم‌افزار استفاده می‌شوند، اما هدف و سطح جزئیات آن‌ها متفاوت است.

ویژگی	Test Scenario	Test Case	Checklist
هدف	مشخص کردن «چه چیزی» باید تست شود.	مشخص کردن «چگونه» تست اجرا شود.	یادآوری مواردی که باید بررسی شوند.
سطح جزئیات	کم	زیاد	بسیار کم
شامل مراحل اجرا	خیر	بله	خیر
شامل Test Data	خیر	بله	معمولاً خیر
شامل Expected Result	خیر	بله	خیر
مناسب برای	تحلیل اولیه تست	اجرای تست و اتوماسیون	Regression سریع یا Exploratory Testing
نمونه	بررسی ورود کاربر	ورود با ایمیل معتبر و مشاهده Dashboard	بررسی Login

Test Scenario چیست؟

Test Scenario نمایی کلی از چیزی است که باید تست شود. در این سطح هنوز درباره مراحل اجرا، داده‌های تست یا نتیجه مورد انتظار صحبت نمی‌شود. هدف Test Scenario مشخص کردن محدوده تست است.

برای مثال، اگر قابلیت Login را بررسی کنیم، سناریوی زیر می‌تواند تعریف شود:

بررسی ورود موفق کاربر به سیستم

همین یک Test Scenario می‌تواند به چندین Test Case مختلف تبدیل شود.

Test Case چیست؟

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

Checklist چیست؟

Checklist ساده‌ترین روش مستندسازی تست است و معمولاً فقط فهرستی از مواردی است که باید بررسی شوند. در بسیاری از پروژه‌های کوچک، Regression Testing یا Exploratory Testing از Checklist استفاده می‌شود، زیرا تهیه و نگهداری آن نسبت به Test Case زمان کمتری نیاز دارد.

Interview Tip: در بسیاری از مصاحبه‌های QA از شما تفاوت Test Case و Test Scenario پرسیده می‌شود. پاسخ حرفه‌ای این است که Test Scenario مشخص می‌کند چه چیزی باید تست شود، اما Test Case نحوه اجرای همان سناریو را با جزئیات کامل تعریف می‌کند.

یک Test Scenario چگونه به چندین Test Case تبدیل می‌شود؟

یکی از بزرگ‌ترین تفاوت‌های افراد تازه‌کار و QA Engineerهای باتجربه، نحوه نگاه آن‌ها به یک قابلیت است. افراد مبتدی معمولاً برای هر قابلیت فقط یک یا دو Test Case می‌نویسند، در حالی که یک QA حرفه‌ای ابتدا سناریوهای مختلف را شناسایی می‌کند و سپس برای هر سناریو، Test Caseهای مناسب طراحی می‌کند.

به همین دلیل، فرآیند طراحی تست معمولاً با Test Scenario آغاز می‌شود و سپس به مجموعه‌ای از Test Caseها تبدیل می‌شود.

مثال: قابلیت Login در پروژه BlueBank

فرض کنید در پروژه فرضی BlueBank، قابلیت ورود کاربران به سامانه را بررسی می‌کنیم.

در نگاه اول ممکن است فقط یک سناریو به ذهن برسد:

کاربر وارد سیستم می‌شود.

اما یک QA Engineer این قابلیت را به سناریوهای کوچک‌تر تقسیم می‌کند.

• ورود موفق با اطلاعات معتبر
• ورود با رمز عبور اشتباه
• ورود با ایمیل ثبت‌نشده
• خالی بودن ایمیل
• خالی بودن رمز عبور
• خالی بودن هر دو فیلد
• حساب کاربری غیرفعال
• حساب کاربری قفل شده
• ورود پس از چند تلاش ناموفق
• اعتبارسنجی فرمت ایمیل
• بررسی حساس بودن رمز عبور به حروف بزرگ و کوچک
• رفتار سیستم هنگام قطع ارتباط شبکه
• بررسی پیام‌های خطا
• بررسی ایجاد Session پس از ورود موفق
• بررسی هدایت کاربر به Dashboard

اکنون برای هر یک از این سناریوها می‌توان یک یا چند Test Case طراحی کرد.

نمونه تبدیل Scenario به Test Case

Test Scenario	نمونه Test Case
ورود موفق کاربر	ورود با ایمیل و رمز عبور معتبر
ورود موفق کاربر	ورود با گزینه Remember Me
ورود موفق کاربر	ورود پس از تغییر رمز عبور
ورود ناموفق	رمز عبور اشتباه
ورود ناموفق	ایمیل ثبت نشده
ورود ناموفق	حساب کاربری غیرفعال
ورود ناموفق	حساب کاربری قفل شده
اعتبارسنجی ورودی‌ها	ایمیل خالی
اعتبارسنجی ورودی‌ها	رمز عبور خالی
اعتبارسنجی ورودی‌ها	فرمت نامعتبر ایمیل

QA Note: در پروژه‌های واقعی معمولاً نسبت بین Test Scenario و Test Case برابر با یک نیست. یک سناریوی ساده ممکن است به چندین Test Case تبدیل شود تا تمام مسیرهای مثبت، منفی، مرزی و قوانین کسب‌وکار پوشش داده شوند.

یک QA Engineer چگونه به Test Case فکر می‌کند؟

بسیاری از افراد تصور می‌کنند نوشتن Test Case از صفحه Login شروع می‌شود، اما در عمل این‌طور نیست. QA Engineer ابتدا سعی می‌کند سیستم را از دید کاربران، کسب‌وکار و ریسک‌های احتمالی تحلیل کند.

قبل از نوشتن اولین Test Case معمولاً سؤالاتی مانند موارد زیر مطرح می‌شود:

• هدف اصلی این قابلیت چیست؟
• اگر این قابلیت درست کار نکند، چه ریسکی برای کاربران یا کسب‌وکار ایجاد می‌شود؟
• کاربران معمولاً چه ورودی‌هایی وارد می‌کنند؟
• کاربران ممکن است چه اشتباهاتی انجام دهند؟
• محدودیت‌های سیستم چیست؟
• قوانین کسب‌وکار چه رفتارهایی را مجاز یا غیرمجاز می‌دانند؟
• کدام سناریوها بیشترین اولویت را دارند؟
• کدام بخش‌ها برای Regression Testing حیاتی هستند؟

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

Project Insight: در بسیاری از تیم‌های Agile، QA پیش از شروع توسعه و در جلسات Three Amigos همین سؤال‌ها را مطرح می‌کند. نتیجه این گفتگوها فقط تولید Test Case نیست؛ بلکه شفاف شدن Requirement، کشف ابهام‌ها و جلوگیری از ایجاد باگ در مراحل بعدی توسعه است.

ساختار استاندارد یک Test Case حرفه‌ای

یکی از سؤالات رایج QA Engineerهای تازه‌کار این است که یک Test Case دقیقاً باید چه اطلاعاتی داشته باشد. پاسخ این سؤال به ابزار مدیریت تست، فرآیند توسعه و نیازهای تیم بستگی دارد، اما در پروژه‌های حرفه‌ای معمولاً مجموعه‌ای از فیلدهای استاندارد برای مستندسازی Test Case استفاده می‌شود.

هرچه اطلاعات ثبت‌شده در Test Case کامل‌تر و شفاف‌تر باشد، اجرای تست، نگهداری مستندات، تحلیل پوشش تست و توسعه تست‌های خودکار نیز ساده‌تر خواهد بود.

Template زیر یکی از کامل‌ترین ساختارهایی است که می‌تواند در اکثر پروژه‌های نرم‌افزاری مورد استفاده قرار گیرد.

Field	Description
ID	شناسه یکتای Test Case
Requirement / User Story	نیازمندی یا User Story مرتبط
Scenario	سناریوی تست
Title	عنوان کوتاه و گویا
Preconditions	پیش‌نیازهای اجرای تست
Steps	مراحل اجرای تست
Expected Result	نتیجه مورد انتظار
Test Data	داده‌های مورد نیاز برای اجرای تست
Priority	اولویت تست
Status	وضعیت اجرای تست
Automation Status	وضعیت اتوماسیون
Scenario Type	نوع سناریو (Positive، Negative، Boundary، Security و …)
Test Design Technique	تکنیک طراحی تست مورد استفاده
Layer	لایه اجرای تست (UI، API، Integration و …)

QA Note: بسیاری از Templateهای موجود در اینترنت فقط شامل Title، Steps و Expected Result هستند. چنین Templateهایی برای پروژه‌های کوچک مناسب‌اند، اما در پروژه‌های متوسط و بزرگ معمولاً اطلاعات کافی برای نگهداری بلندمدت Test Case را فراهم نمی‌کنند.

آشنایی با فیلدهای Test Case

ID

ID شناسه یکتای هر Test Case است و امکان ردیابی، گزارش‌دهی و ارجاع به آن را فراهم می‌کند. این شناسه باید در طول عمر پروژه ثابت باقی بماند.

نمونه‌هایی از نام‌گذاری:

• TC-001
• LOGIN-TC-005
• AUTH-024

Requirement / User Story

این ستون نشان می‌دهد Test Case برای اعتبارسنجی کدام Requirement یا User Story طراحی شده است. وجود این ارتباط، امکان ایجاد Traceability بین نیازمندی‌ها و تست‌ها را فراهم می‌کند.

نمونه:

US-15 — As a registered user, I want to log in using my email and password.

در تیم‌های Agile، این ستون یکی از مهم‌ترین بخش‌های Template محسوب می‌شود، زیرا مشخص می‌کند هر Test Case دقیقاً برای اعتبارسنجی کدام نیازمندی ایجاد شده است.

Scenario

Scenario مشخص می‌کند Test Case متعلق به کدام سناریوی تست است. معمولاً چندین Test Case می‌توانند به یک Test Scenario مشترک تعلق داشته باشند.

نمونه:

• Successful Login
• Failed Login
• Password Validation

Title

عنوان Test Case باید کوتاه، دقیق و بدون ابهام باشد تا بدون مطالعه تمام مراحل، هدف تست مشخص شود.

نمونه مناسب:

• Login with valid credentials
• Login with incorrect password
• Login with inactive account

Interview Tip: اگر عنوان Test Case بیش از حد طولانی باشد، معمولاً نشان می‌دهد اطلاعاتی که باید در Steps یا Expected Result نوشته شوند، به اشتباه داخل Title قرار گرفته‌اند.

توضیح کامل فیلدهای Test Case Template

اگرچه ابزارهای مختلف مدیریت تست مانند TestRail، Azure Test Plans، Xray و Zephyr ممکن است فیلدهای متفاوتی داشته باشند، اما مفهوم بیشتر آن‌ها یکسان است. در ادامه هر یک از فیلدهای مهم Test Case را همراه با مثال و بهترین روش استفاده بررسی می‌کنیم.

Preconditions (پیش‌نیازها)

Preconditions شرایطی هستند که قبل از اجرای Test Case باید برقرار باشند. اگر این شرایط فراهم نباشند، نتیجه اجرای تست معتبر نخواهد بود.

نمونه‌هایی از Preconditions:

• کاربر قبلاً ثبت‌نام کرده باشد.
• حساب کاربری فعال باشد.
• کاربر در صفحه Login قرار داشته باشد.
• سرور در دسترس باشد.
• دیتابیس شامل داده‌های موردنیاز باشد.

Best Practice: فقط شرایط ضروری را در Preconditions بنویسید. مراحلی که بخشی از اجرای تست هستند نباید به قسمت Preconditions منتقل شوند.

Steps (مراحل اجرای تست)

Steps مهم‌ترین بخش Test Case هستند و مشخص می‌کنند تست‌کننده باید دقیقاً چه اقداماتی انجام دهد.

هر مرحله باید:

• واضح و بدون ابهام باشد.
• قابل تکرار باشد.
• فقط یک اقدام را توصیف کند.
• ترتیب منطقی داشته باشد.

نمونه مناسب:

1. صفحه Login را باز کنید.
2. ایمیل معتبر را وارد کنید.
3. رمز عبور معتبر را وارد کنید.
4. روی دکمه Login کلیک کنید.

نمونه نامناسب:

Login successfully.

این جمله مشخص نمی‌کند چه عملی باید انجام شود و چگونه نتیجه بررسی خواهد شد.

Expected Result (نتیجه مورد انتظار)

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

نمونه مناسب:

• کاربر به Dashboard هدایت شود.
• نام کاربر در Header نمایش داده شود.
• Session معتبر ایجاد شود.
• پاسخ API دارای Status Code برابر 200 باشد.

نمونه نامناسب:

System should work correctly.

QA Note: اگر نتیجه مورد انتظار قابل اندازه‌گیری نباشد، تصمیم‌گیری درباره Pass یا Fail بودن Test Case نیز سلیقه‌ای خواهد شد.

Test Data (داده‌های تست)

Test Data شامل تمام اطلاعاتی است که برای اجرای Test Case موردنیاز هستند. ثبت دقیق داده‌های تست باعث می‌شود سایر اعضای تیم بتوانند همان تست را با همان شرایط اجرا کنند.

مثال در پروژه BlueBank:

Field	Value
Email	customer@bluebank.com
Password	Test@123
Account Status	Active

در پروژه‌های بزرگ معمولاً به‌جای ثبت داده‌ها در خود Test Case، شناسه Dataset یا فایل Test Data Repository درج می‌شود تا نگهداری اطلاعات ساده‌تر باشد.

Priority (اولویت)

Priority نشان می‌دهد اجرای Test Case تا چه اندازه برای تیم اهمیت دارد. این اولویت معمولاً بر اساس ریسک کسب‌وکار، اهمیت قابلیت و احتمال وقوع خطا تعیین می‌شود.

Priority	کاربرد
High	قابلیت‌های حیاتی مانند Login، پرداخت یا انتقال وجه
Medium	قابلیت‌های مهم اما غیرحیاتی
Low	قابلیت‌هایی با ریسک پایین یا استفاده محدود

Project Insight: در بسیاری از پروژه‌ها، هنگام کمبود زمان ابتدا فقط Test Caseهای با اولویت High اجرا می‌شوند. به همین دلیل تعیین Priority باید بر اساس ریسک و ارزش کسب‌وکار انجام شود، نه صرفاً پیچیدگی فنی.

فیلدهای پیشرفته در Test Case Template

در بسیاری از Templateهای قدیمی Test Case فقط ستون‌هایی مانند Title، Steps و Expected Result وجود دارند. اما با گسترش Agile، DevOps و Test Automation، تیم‌های مدرن اطلاعات بیشتری را در Test Case ثبت می‌کنند تا مدیریت تست، تحلیل پوشش و نگهداری مستندات ساده‌تر شود.

در ادامه با چهار فیلد مهم آشنا می‌شوید که معمولاً در پروژه‌های حرفه‌ای استفاده می‌شوند.

Status

Status وضعیت فعلی Test Case را نشان می‌دهد. این ستون با نتیجه اجرای تست تفاوت دارد و بیشتر برای مدیریت چرخه عمر Test Case استفاده می‌شود.

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

Status	توضیح
Draft	Test Case هنوز کامل نشده است.
Ready	آماده اجرا است.
In Review	در حال بازبینی توسط اعضای تیم است.
Approved	بازبینی شده و مورد تأیید قرار گرفته است.
Deprecated	دیگر استفاده نمی‌شود.

نکته: Status با نتیجه اجرای تست (Pass، Fail، Blocked و Not Executed) تفاوت دارد. نتیجه اجرا معمولاً در Test Run ثبت می‌شود، نه در خود Test Case.

Automation Status

یکی از مهم‌ترین اطلاعات در پروژه‌های امروزی، مشخص کردن وضعیت اتوماسیون هر Test Case است. این ستون به تیم کمک می‌کند بداند کدام تست‌ها به‌صورت دستی اجرا می‌شوند و کدام تست‌ها قبلاً خودکار شده‌اند.

Automation Status	توضیح
Not Planned	برنامه‌ای برای اتوماسیون وجود ندارد.
Planned	قرار است در آینده خودکار شود.
In Progress	اسکریپت اتوماسیون در حال توسعه است.
Automated	تست کاملاً خودکار شده است.
Manual Only	فقط به‌صورت دستی اجرا می‌شود.

ثبت این اطلاعات باعث می‌شود هنگام برنامه‌ریزی Regression Testing یا بررسی میزان پیشرفت اتوماسیون، تیم تصویر دقیقی از وضعیت تست‌ها داشته باشد.

Project Insight: بسیاری از تیم‌ها به‌اشتباه تصور می‌کنند همه Test Caseها باید خودکار شوند. در عمل، تست‌های اکتشافی (Exploratory Testing)، ارزیابی تجربه کاربری (UX) و برخی سناریوهای پیچیده همچنان به اجرای دستی نیاز دارند.

Scenario Type

Scenario Type مشخص می‌کند Test Case از چه نوع سناریویی برای اعتبارسنجی سیستم استفاده می‌کند. وجود این ستون باعث می‌شود تیم بتواند پوشش تست را تحلیل کند و مطمئن شود فقط مسیرهای موفق بررسی نشده‌اند.

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

Scenario Type	کاربرد
Positive	بررسی رفتار صحیح سیستم با ورودی معتبر
Negative	بررسی رفتار سیستم با ورودی نامعتبر
Boundary	بررسی مقادیر مرزی
Business Rule	اعتبارسنجی قوانین کسب‌وکار
Error Handling	بررسی مدیریت خطاها
Security	بررسی الزامات امنیتی
Performance	بررسی رفتار سیستم تحت بار یا محدودیت زمانی

ثبت Scenario Type به تیم کمک می‌کند هنگام تحلیل Test Coverage متوجه شود چه نوع سناریوهایی پوشش داده شده‌اند و کدام بخش‌ها هنوز نیاز به طراحی تست دارند.

Test Design Technique چیست و چرا در Test Case اهمیت دارد؟

یکی از مهم‌ترین فیلدهایی که در Templateهای حرفه‌ای Test Case دیده می‌شود، Test Design Technique است. این فیلد مشخص می‌کند QA Engineer با استفاده از چه روش یا تکنیکی، Test Case را طراحی کرده است.

در بسیاری از تیم‌ها، دو Test Case ممکن است نتیجه مشابهی داشته باشند، اما کیفیت طراحی آن‌ها کاملاً متفاوت باشد. تفاوت اصلی در نحوه فکر کردن طراح تست و انتخاب تکنیک مناسب برای پوشش ریسک‌ها است.

به همین دلیل، ثبت Test Design Technique فقط یک اطلاعات اضافی نیست؛ بلکه نشان می‌دهد هر Test Case بر چه اساسی طراحی شده است و آیا پوشش مناسبی برای نیازمندی‌ها و ریسک‌های سیستم فراهم می‌کند یا خیر.

چرا ثبت Test Design Technique مفید است؟

• کمک به تحلیل Test Coverage
• بررسی کیفیت طراحی Test Caseها
• جلوگیری از طراحی تست‌های تکراری
• آموزش اعضای جدید تیم
• مستندسازی فرآیند طراحی تست
• شناسایی تکنیک‌هایی که کمتر مورد استفاده قرار گرفته‌اند

QA Note: بسیاری از تیم‌ها این ستون را در Template خود ندارند. در نتیجه پس از چند ماه دیگر مشخص نیست یک Test Case بر اساس Boundary Value Analysis طراحی شده یا Decision Table Testing. ثبت این اطلاعات نگهداری Test Caseها را در بلندمدت ساده‌تر می‌کند.

رایج‌ترین Test Design Techniqueها

Technique	بهترین کاربرد
Equivalence Partitioning	تقسیم داده‌های ورودی به کلاس‌های معتبر و نامعتبر
Boundary Value Analysis	بررسی مقادیر مرزی
Decision Table Testing	بررسی قوانین پیچیده کسب‌وکار
State Transition Testing	سیستم‌هایی که دارای وضعیت‌های مختلف هستند
Pairwise Testing	کاهش تعداد ترکیب‌های تست
Error Guessing	استفاده از تجربه QA برای پیش‌بینی خطاها
Use Case Testing	اعتبارسنجی سناریوهای اصلی کاربر

مثال از پروژه BlueBank

فرض کنید در صفحه Login، طول رمز عبور باید بین ۸ تا ۲۰ کاراکتر باشد.

اگر فقط یک رمز عبور ۱۰ کاراکتری را تست کنیم، احتمال دارد بسیاری از خطاها شناسایی نشوند. اما با استفاده از Boundary Value Analysis، مقادیر مرزی نیز بررسی می‌شوند.

Password Length	Expected Result
7	نمایش پیام خطا
8	پذیرفته شود
9	پذیرفته شود
20	پذیرفته شود
21	نمایش پیام خطا

در این مثال، ستون Test Design Technique مقدار Boundary Value Analysis (BVA) خواهد داشت، زیرا Test Caseها بر اساس مقادیر مرزی طراحی شده‌اند.

Interview Tip: اگر در مصاحبه از شما پرسیده شود «چرا این Test Case را طراحی کردی؟»، فقط توضیح سناریو کافی نیست. یک QA حرفه‌ای می‌تواند توضیح دهد که این Test Case بر اساس کدام Test Design Technique طراحی شده و چرا آن تکنیک برای این مسئله مناسب بوده است.

از Requirement تا Test Case؛ فرآیند واقعی طراحی تست در Agile

یکی از تفاوت‌های اصلی تیم‌های مدرن Agile با رویکردهای سنتی این است که Test Case از ابتدا وجود ندارد. QA Engineer ابتدا نیازمندی‌ها را تحلیل می‌کند، درباره ابهام‌ها سؤال می‌پرسد، ریسک‌ها را شناسایی می‌کند و سپس Test Caseها را طراحی می‌کند.

به همین دلیل، نوشتن Test Case آخرین مرحله از فرآیند طراحی تست است، نه اولین مرحله.

مراحل طراحی Test Case در یک تیم Agile

1. دریافت Business Requirement یا User Story
2. بررسی Acceptance Criteria
3. شرکت در جلسه Three Amigos و رفع ابهام‌ها
4. تحلیل قوانین کسب‌وکار و شناسایی ریسک‌ها
5. طراحی Test Scenarioها
6. انتخاب Test Design Technique مناسب
7. طراحی Test Caseها
8. بازبینی (Peer Review)
9. اجرای تست و ثبت نتایج
10. در صورت نیاز، تبدیل Test Caseهای مناسب به تست خودکار

QA Mindset: QA Engineerهای باتجربه مستقیماً سراغ نوشتن Test Case نمی‌روند. آن‌ها ابتدا تلاش می‌کنند سیستم را درک کنند، ریسک‌ها را بشناسند و مطمئن شوند هیچ نیازمندی یا قانون کسب‌وکاری از قلم نیفتاده است.

مثال: طراحی Test Case برای قابلیت Login در BlueBank

فرض کنید Product Owner یک User Story به تیم ارائه می‌کند.

User Story

As a registered customer, I want to log in using my email and password so that I can access my banking dashboard.

Acceptance Criteria نیز به شکل زیر تعریف شده است.

• کاربر با اطلاعات معتبر وارد سیستم شود.
• در صورت اشتباه بودن رمز عبور، پیام خطا نمایش داده شود.
• پس از پنج تلاش ناموفق، حساب کاربر به مدت ۱۵ دقیقه قفل شود.
• ایمیل باید فرمت معتبر داشته باشد.
• رمز عبور باید بین ۸ تا ۲۰ کاراکتر باشد.

یک QA Engineer قبل از طراحی Test Case معمولاً سؤالاتی مانند موارد زیر را مطرح می‌کند.

• اگر حساب کاربر غیرفعال باشد چه اتفاقی می‌افتد؟
• اگر اتصال شبکه هنگام Login قطع شود چه رفتاری انتظار می‌رود؟
• آیا حروف بزرگ و کوچک در رمز عبور تفاوت دارند؟
• آیا محدودیت تعداد تلاش ناموفق برای همه کاربران یکسان است؟
• آیا پیام‌های خطا باید یکسان باشند یا برای دلایل مختلف تفاوت داشته باشند؟
• بعد از ورود موفق، Session چه مدت اعتبار دارد؟

پاسخ به این پرسش‌ها باعث می‌شود Test Caseها فقط مسیر موفق را پوشش ندهند، بلکه سناریوهای منفی، شرایط مرزی، قوانین کسب‌وکار و ریسک‌های مهم نیز بررسی شوند.

از User Story تا Test Case

مرحله	خروجی
User Story	نیاز کاربر به ورود به سیستم
Acceptance Criteria	تعریف رفتار صحیح سیستم
Risk Analysis	شناسایی ریسک‌های امنیتی، اعتبارسنجی و خطاها
Test Scenario	ورود موفق، ورود ناموفق، اعتبارسنجی ورودی‌ها، قفل شدن حساب و …
Test Design Technique	BVA، Equivalence Partitioning، Error Guessing و …
Test Case	مجموعه مراحل، داده‌های تست و نتایج مورد انتظار

Project Insight: در بسیاری از تیم‌های Agile، QA و توسعه‌دهنده قبل از شروع پیاده‌سازی درباره همین سناریوها گفتگو می‌کنند. این همکاری باعث می‌شود ابهام‌ها زودتر شناسایی شوند و تعداد باگ‌های کشف‌شده در مراحل پایانی توسعه کاهش یابد.

اشتباهات رایج در طراحی Test Case

نوشتن Test Case صرفاً پر کردن یک فرم نیست. کیفیت Test Case تأثیر مستقیمی بر کشف باگ‌ها، سرعت اجرای تست، نگهداری مستندات و حتی موفقیت پروژه‌های Test Automation دارد. در ادامه، رایج‌ترین اشتباهاتی را بررسی می‌کنیم که در بسیاری از پروژه‌ها مشاهده می‌شوند.

۱. ترکیب چند سناریو در یک Test Case

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

نامناسب:

بررسی ورود موفق، تغییر رمز عبور و خروج از سیستم در یک Test Case

مناسب:

• Test Case اول: ورود موفق
• Test Case دوم: تغییر رمز عبور
• Test Case سوم: خروج از سیستم

۲. نوشتن مراحل مبهم

مراحل اجرای تست باید به‌گونه‌ای نوشته شوند که هر عضو تیم بتواند بدون نیاز به توضیح شفاهی همان تست را اجرا کند.

نامناسب:

ورود را بررسی کنید.

مناسب:

1. صفحه Login را باز کنید.
2. ایمیل معتبر را وارد کنید.
3. رمز عبور معتبر را وارد کنید.
4. روی دکمه Login کلیک کنید.

۳. Expected Result مبهم

نتیجه مورد انتظار باید قابل مشاهده و قابل اندازه‌گیری باشد. عباراتی مانند «سیستم درست کار کند» یا «همه چیز صحیح باشد» هیچ معیار مشخصی برای ارزیابی Pass یا Fail ارائه نمی‌کنند.

نامناسب:

سیستم به‌درستی عمل کند.

مناسب:

• کاربر به Dashboard هدایت شود.
• کد وضعیت API برابر 200 باشد.
• پیام «ورود موفقیت‌آمیز بود» نمایش داده شود.
• Session معتبر ایجاد شود.

۴. نادیده گرفتن تست‌های منفی

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

برای مثال، علاوه بر ورود موفق باید موارد زیر نیز بررسی شوند:

• رمز عبور اشتباه
• ایمیل نامعتبر
• حساب غیرفعال
• حساب قفل شده
• خالی بودن فیلدها
• قطع ارتباط شبکه

۵. فراموش کردن مقادیر مرزی

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

برای مثال، اگر طول مجاز رمز عبور بین ۸ تا ۲۰ کاراکتر باشد، فقط مقدار ۱۰ کافی نیست و باید مقادیر ۷، ۸، ۹، ۲۰ و ۲۱ نیز بررسی شوند.

۶. وابستگی Test Caseها به یکدیگر

هر Test Case تا حد امکان باید مستقل باشد. اگر اجرای یک Test Case به نتیجه Test Case قبلی وابسته باشد، نگهداری و اجرای تست‌ها دشوارتر خواهد شد.

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

۷. استفاده از داده‌های تست نامناسب

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

در پروژه‌های حرفه‌ای معمولاً مجموعه‌های مختلفی از Test Data برای کاربران فعال، غیرفعال، مسدودشده، دارای نقش‌های متفاوت و شرایط مختلف کسب‌وکار نگهداری می‌شود.

Best Practice: هنگام بازبینی Test Case از خود بپرسید: «اگر این قابلیت را امروز برای اولین بار می‌دیدم، آیا فقط با خواندن این Test Case می‌توانستم تست را بدون سؤال اضافه اجرا کنم؟» اگر پاسخ منفی است، Test Case هنوز جای بهبود دارد.

نمونه واقعی Test Case (پروژه فرضی BlueBank)

در این بخش یک نمونه Test Case کامل را بررسی می‌کنیم. این مثال بر اساس پروژه فرضی BlueBank طراحی شده است و ساختاری مشابه چیزی دارد که در بسیاری از تیم‌های حرفه‌ای توسعه نرم‌افزار استفاده می‌شود.

ID	LOGIN-TC-001
Requirement / User Story	US-15 — As a registered customer, I want to log in using my email and password.
Scenario	Successful Login
Title	Login with valid email and password
Preconditions	کاربر قبلاً ثبت‌نام کرده باشد. حساب کاربری فعال باشد. کاربر در صفحه Login قرار داشته باشد.
Steps	ایمیل معتبر را وارد کنید. رمز عبور معتبر را وارد کنید. روی دکمه Login کلیک کنید.
Expected Result	ورود با موفقیت انجام شود. کاربر به Dashboard هدایت شود. Session معتبر ایجاد شود. نام کاربر در Header نمایش داده شود.
Test Data	Email: customer@bluebank.com Password: Test@123
Priority	High
Status	Approved
Automation Status	Automated
Scenario Type	Positive
Test Design Technique	Equivalence Partitioning
Layer	UI

در نگاه اول ممکن است این Test Case ساده به نظر برسد، اما تقریباً تمام اطلاعات موردنیاز برای اجرای مجدد تست، تحلیل آن و حتی تبدیل آن به تست خودکار را در اختیار تیم قرار می‌دهد.

Project Insight: در بسیاری از تیم‌ها، Test Caseهای Manual و Automation از یک Requirement مشترک استفاده می‌کنند. به همین دلیل، وجود ستون‌هایی مانند Requirement، Automation Status و Layer باعث می‌شود ارتباط بین مستندات تست و اسکریپت‌های خودکار به‌سادگی حفظ شود.

نمونه Test Case برای سناریوی منفی

یک QA حرفه‌ای هرگز به مسیر موفق اکتفا نمی‌کند. در کنار سناریوی مثبت، باید شرایط ناموفق و رفتار سیستم در مواجهه با خطاها نیز بررسی شوند.

ID	LOGIN-TC-008
Scenario	Failed Login
Title	Login with incorrect password
Test Data	Password: Wrong@123
Scenario Type	Negative
Test Design Technique	Error Guessing
Priority	High
Expected Result	ورود انجام نشود. پیام «نام کاربری یا رمز عبور اشتباه است» نمایش داده شود. Session ایجاد نشود. تعداد تلاش ناموفق یک واحد افزایش یابد.

همان‌طور که مشاهده می‌کنید، با تغییر نوع سناریو، داده‌های تست، تکنیک طراحی تست و نتیجه مورد انتظار نیز تغییر می‌کنند. به همین دلیل معمولاً برای هر Test Scenario چندین Test Case مختلف طراحی می‌شود.

QA Mindset: هدف یک QA حرفه‌ای اثبات درست کار کردن سیستم نیست؛ بلکه تلاش برای کشف شرایطی است که ممکن است باعث شکست آن شوند. به همین دلیل، تعداد Test Caseهای منفی در بسیاری از پروژه‌های واقعی از Test Caseهای مثبت بیشتر است.

آیا همه تیم‌های Agile هنوز Test Case می‌نویسند؟

پاسخ کوتاه این سؤال خیر است.

برخلاف تصور بسیاری از افراد، در پروژه‌های Agile همه تیم‌ها از Test Caseهای طولانی و سنتی استفاده نمی‌کنند. میزان مستندسازی تست به عواملی مانند نوع پروژه، ریسک کسب‌وکار، الزامات قانونی، اندازه تیم و فرهنگ سازمان بستگی دارد.

به همین دلیل ممکن است دو شرکت نرم‌افزاری هر دو از Scrum استفاده کنند، اما یکی برای هر قابلیت ده‌ها Test Case بنویسد و دیگری بیشتر از Checklist یا Test Charter استفاده کند.

رویکردهای رایج در تیم‌های Agile

رویکرد	کاربرد	رایج در
Test Case کامل	مستندسازی دقیق مراحل، داده‌ها و نتایج مورد انتظار	بانک، بیمه، سلامت، پروژه‌های سازمانی
Lightweight Test Case	مستندسازی خلاصه برای کاهش هزینه نگهداری	بیشتر تیم‌های Agile
Checklist	فهرست مواردی که باید بررسی شوند	Regression Testing و پروژه‌های کوچک
Exploratory Testing	اجرای تست بر اساس تجربه و تحلیل QA	تیم‌های بالغ QA
BDD Scenario	سناریوهای Given-When-Then	تیم‌های استفاده‌کننده از Cucumber و SpecFlow

نکته مهم: Agile به معنی حذف مستندات نیست. یکی از اصول Agile این است که فقط به اندازه‌ای مستندات تولید شوند که برای تیم ارزش ایجاد کنند.

چه زمانی Test Case کامل بنویسیم؟

هرچه ریسک پروژه بیشتر باشد، نیاز به مستندسازی دقیق‌تر نیز افزایش پیدا می‌کند.

• سیستم‌های بانکی و پرداخت
• سامانه‌های پزشکی و سلامت
• نرم‌افزارهای هوافضا و خودروسازی
• پروژه‌های دولتی
• سیستم‌های دارای الزامات قانونی و ممیزی
• پروژه‌هایی با تیم‌های بزرگ یا توزیع‌شده

در این پروژه‌ها، وجود Test Caseهای کامل باعث می‌شود فرآیند تست قابل ردیابی، قابل بازبینی و قابل ممیزی باشد.

چه زمانی Checklist کافی است؟

در بسیاری از تیم‌های Agile، برای قابلیت‌های ساده یا Regression Testing از Checklist استفاده می‌شود. این روش زمان کمتری برای نگهداری نیاز دارد و سرعت اجرای تست را افزایش می‌دهد.

• Regression Testing روزانه
• پروژه‌های Startup
• قابلیت‌های کم‌ریسک
• تیم‌های کوچک
• Exploratory Testing

چه زمانی Test Scenario به‌تنهایی کافی است؟

اگر هدف فقط مشخص کردن محدوده تست باشد، ثبت Test Scenario ممکن است کافی باشد. در این حالت، جزئیات اجرای تست در زمان اجرا توسط QA مشخص می‌شوند.

این رویکرد معمولاً در تیم‌هایی استفاده می‌شود که اعضای آن تجربه بالایی دارند و نیازی به مستندسازی کامل همه مراحل احساس نمی‌شود.

آیا Test Case در عصر Test Automation و AI هنوز ارزش دارد؟

بله؛ اما نقش آن در حال تغییر است.

امروزه بسیاری از Test Caseهای تکراری به تست‌های خودکار تبدیل می‌شوند و ابزارهای مبتنی بر هوش مصنوعی نیز می‌توانند در تولید پیش‌نویس Test Caseها کمک کنند. با این حال، تحلیل نیازمندی‌ها، انتخاب Test Design Technique، شناسایی ریسک‌ها و طراحی سناریوهای مناسب همچنان به دانش و تجربه QA Engineer وابسته است.

QA Mindset: ابزارها و هوش مصنوعی می‌توانند در نوشتن Test Case کمک کنند، اما تصمیم‌گیری درباره اینکه «چه چیزی باید تست شود» و «کدام ریسک‌ها مهم‌تر هستند» همچنان یکی از مهم‌ترین مسئولیت‌های QA Engineer است.

Traceability چیست و چه ارتباطی با Test Case دارد؟

یکی از مهم‌ترین وظایف QA Engineer این است که مطمئن شود تمام نیازمندی‌های سیستم توسط تست‌ها پوشش داده شده‌اند. این قابلیت Traceability یا «قابلیت ردیابی» نام دارد.

به زبان ساده، Traceability به این سؤال پاسخ می‌دهد:

آیا برای هر Requirement یا User Story، تست مناسبی طراحی شده است؟

اگر نتوان این ارتباط را برقرار کرد، ممکن است بخشی از سیستم بدون هیچ تستی منتشر شود یا برعکس، برای یک نیازمندی چندین Test Case تکراری نوشته شده باشد.

Requirement Traceability Matrix (RTM) چیست؟

Requirement Traceability Matrix (RTM) جدولی است که ارتباط بین Requirementها، User Storyها و Test Caseها را نشان می‌دهد.

هدف اصلی RTM این است که هیچ نیازمندی بدون تست باقی نماند و در صورت تغییر Requirement، بتوان Test Caseهای وابسته را به‌سرعت شناسایی کرد.

Requirement	Test Scenario	Test Case	Status
US-15	Successful Login	LOGIN-TC-001	Pass
US-15	Failed Login	LOGIN-TC-008	Pass
US-15	Password Validation	LOGIN-TC-015	Fail
US-15	Account Lock	LOGIN-TC-021	Blocked

با استفاده از چنین جدولی، تیم QA می‌تواند در هر لحظه بررسی کند که آیا تمام نیازمندی‌های پروژه پوشش داده شده‌اند یا خیر.

مزایای استفاده از RTM

• اطمینان از پوشش کامل Requirementها
• شناسایی Requirementهای بدون Test Case
• تحلیل سریع تأثیر تغییرات (Impact Analysis)
• تسهیل Regression Testing
• ساده‌تر شدن ممیزی و مستندسازی پروژه
• افزایش شفافیت بین تیم توسعه، QA و Product Owner

Project Insight: در ابزارهایی مانند TestRail، Azure Test Plans و Xray معمولاً ارتباط بین Requirement و Test Case به‌صورت خودکار ثبت می‌شود. در پروژه‌های کوچک نیز می‌توان همین ارتباط را با یک فایل Excel یا Google Sheets مدیریت کرد.

آیا همیشه باید RTM ایجاد کنیم؟

خیر. نیاز به RTM به اندازه پروژه، الزامات سازمان و میزان ریسک بستگی دارد.

نوع پروژه	نیاز به RTM
بانکی، بیمه، سلامت، پروژه‌های دولتی	تقریباً همیشه
پروژه‌های سازمانی متوسط	معمولاً توصیه می‌شود
استارتاپ‌های کوچک	بسته به پیچیدگی پروژه
نمونه اولیه (Prototype)	معمولاً ضرورتی ندارد

QA Mindset: هدف از RTM تولید مستندات بیشتر نیست؛ هدف این است که مطمئن شویم هیچ Requirement مهمی بدون اعتبارسنجی وارد محیط عملیاتی نمی‌شود.

جمع‌بندی

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

در پروژه‌های مدرن Agile نیز اگرچه میزان مستندسازی ممکن است کمتر از روش‌های سنتی باشد، اما اصول طراحی تست تغییر نکرده‌اند. QA Engineer همچنان باید Requirementها را تحلیل کند، Test Scenarioها را استخراج کند، Test Design Technique مناسب را انتخاب کند و در نهایت Test Caseهایی طراحی کند که بیشترین پوشش ممکن را برای ریسک‌های سیستم فراهم کنند.

به خاطر داشته باشید که هدف از نوشتن Test Case تولید مستندات بیشتر نیست؛ بلکه کاهش ریسک انتشار نرم‌افزار، افزایش کیفیت محصول و ایجاد یک فرآیند تست قابل اعتماد است.

نکته پایانی: کیفیت یک QA Engineer را نمی‌توان با تعداد Test Caseهایی که می‌نویسد سنجید؛ بلکه با توانایی او در انتخاب سناریوهای درست، شناسایی ریسک‌ها و طراحی تست‌هایی که بیشترین ارزش را برای محصول ایجاد می‌کنند، ارزیابی می‌شود.

مطالعه بیشتر

• تست نرم‌افزار (Software Testing)
• Test Scenario چیست؟
• Test Plan چیست؟
• Test Strategy چیست؟
• STLC (Software Testing Life Cycle)
• SDLC (Software Development Life Cycle)
• Requirement Traceability Matrix (RTM)
• Boundary Value Analysis (BVA)
• Equivalence Partitioning (EP)
• Decision Table Testing
• State Transition Testing
• Error Guessing
• Exploratory Testing
• Regression Testing
• Smoke Testing
• Sanity Testing
• Playwright Test Automation

سوالات متداول (FAQ)

منابع

• ISTQB® Certified Tester Foundation Level (CTFL) v4.0 Syllabus
• ISO/IEC/IEEE 29119 Software Testing Series
• IEEE 829 Standard for Software Test Documentation (Historical Reference)
• Kaner, Cem – Lessons Learned in Software Testing
• Rex Black – Foundations of Software Testing (ISTQB)
• Lisa Crispin & Janet Gregory – Agile Testing: A Practical Guide for Testers and Agile Teams
• Lisa Crispin & Janet Gregory – More Agile Testing
• Microsoft Learn – Azure Test Plans Documentation
• TestRail Documentation
• Atlassian Documentation – Jira & Xray Test Management
• BrowserStack Test Management Guides
• Playwright Documentation
• Selenium Documentation