استراتژی تست میگوید سازمان چگونه درباره کیفیت تصمیم میگیرد؛ تست پلن میگوید در این پروژه یا انتشار دقیقاً چه خواهیم کرد؛ تستکیس میگوید یک رفتار مشخص را با چه شرایط و انتظاری میسنجیم. وقتی این سه سطح با هم مخلوط شوند، یا سندهای تکراری میسازیم یا اجرای تست از هدف و ریسک جدا میشود.
در این راهنما و در چارچوب چرخه حیات تست نرمافزار، تفاوت Test Strategy، Test Plan و Test Case را با جدول مقایسه، مثال پرداخت فروشگاه اینترنتی، قالب کوتاه و کاربرد هرکدام در Agile و پروژههای رسمی توضیح میدهیم.
فهرست مطالب
تفاوت Test Strategy، Test Plan و Test Case در یک نگاه
| مصنوع | پرسش اصلی | سطح | مثال کوتاه |
|---|---|---|---|
| Test Strategy | بهطور کلی چگونه و بر چه اصولی تست میکنیم؟ | سازمان، محصول یا برنامه | اولویت API، Risk-based Testing، سیاست CI |
| Test Plan | برای این Release یا پروژه چه برنامهای داریم؟ | پروژه، Release یا Sprint | دامنه پرداخت، زمان، محیط و Exit Criteria |
| Test Case | این رفتار را با چه داده و انتظاری بررسی میکنیم؟ | سناریو و اجرا | Callback تکراری فقط یک سفارش نهایی کند |
خلاصه:
- Strategy جهت و قواعد نسبتاً پایدار را تعیین میکند.
- Plan همان قواعد را برای یک دامنه و بازه زمانی مشخص عملیاتی میکند.
- Case پوشش را به اجرای قابلتکرار و نتیجه قابلاندازهگیری تبدیل میکند.
Test Strategy چیست؟
استراتژی تست چارچوب سطحبالایی است که اهداف کیفیت، اصول تصمیمگیری و رویکرد مشترک تست را تعریف میکند. بسته به ساختار سازمان، ممکن است در سطح کل شرکت، یک محصول یا برنامه بزرگ نوشته شود.
محتوای رایج Test Strategy
- هدفهای کیفیت و Risk Appetite؛
- اصول Shift-left و Shift-right؛
- سطوح تست و Testing Pyramid؛
- رویکرد Manual، Exploratory و Automation؛
- سیاست Static Analysis، Security و Non-functional Test؛
- استاندارد محیط و Test Data؛
- ابزارهای مرجع و شیوه ادغام CI/CD؛
- Defect Management و Quality Gate؛
- Metricها، گزارش و Governance؛
- مسئولیت مشترک تیمها.
نمونه تصمیم استراتژیک
قواعد کسبوکار در Unit/API، قرارداد سرویسها در Contract Test و فقط مسیرهای حیاتی کاربر در UI خودکار پوشش داده میشوند. تست اکتشافی برای هر قابلیت پرریسک الزامی است.
این تصمیم برای چند Release قابل استفاده است و مانع ساختن Suite بزرگ و شکننده UI میشود.
مالک و زمان تغییر
معمولاً QA/Test Leadership با مشارکت Engineering، Product، Security و Operations آن را نگهداری میکند. Strategy نباید «کاملاً ثابت» فرض شود؛ تغییر معماری، ریسک، مقررات، مدل انتشار یا تجربه Incident میتواند آن را اصلاح کند.
Test Plan چیست؟
تست پلن، Strategy را برای یک Scope مشخص به برنامه اجرایی تبدیل میکند. توضیح میدهد چه چیزی داخل یا خارج دامنه است، چه ریسکهایی اولویت دارند، چه سطح و نوع تستی انجام میشود، چه منابع و محیطی لازم است و با چه شواهدی تست را تمام میدانیم.
محتوای رایج Test Plan
- محصول، نسخه، هدف و زمینه؛
- In Scope و Out of Scope؛
- Product Risk و Project Risk؛
- Test Approach و پوشش هر ریسک؛
- نقشها و ظرفیت؛
- Environment، Device، Browser و Test Data؛
- ابزار، Automation و Triggerهای CI؛
- زمانبندی، برآورد تست و وابستگی؛
- Entry، Suspension، Resumption و Exit Criteria؛
- Defect Workflow و گزارش وضعیت؛
- Deliverableها و Release Decision.
برای نوشتن سند اجرایی، از راهنمای برنامهریزی تست در STLC همراه با قالب Test Plan استفاده کنید.
نمونه تصمیم در Plan
در Release پرداخت، تبدیل ریال/تومان، Idempotency Callback و دسترسی تراکنش P0 هستند؛ Sandbox باید تا سه روز پیش از اجرای E2E آماده باشد و خروج تنها با تعیینتکلیف همه عیبهای بحرانی مجاز است.
Test Case چیست؟
تستکیس مجموعه شرایط، داده، اقدام و نتیجه مورد انتظار برای بررسی یک رفتار یا ریسک مشخص است. Test Case باید به Requirement یا Risk متصل، مستقل، قابلتکرار و دارای نتیجه قابلاندازهگیری باشد.
اجزای رایج Test Case
- شناسه و عنوان رفتاری؛
- Requirement/Risk و اولویت؛
- سطح و نوع تست؛
- پیششرط و داده؛
- گام یا اقدام؛
- Expected Result؛
- پسشرط و Cleanup؛
- Environment و Tag؛
- نتیجه و شواهد اجرا.
برای نمونه کامل و قالب قابل کپی، مقاله نوشتن تستکیس حرفهای را بخوانید.
نمونه Test Case کوتاه
| ID | PAY-IDEM-02 |
|---|---|
| هدف | Callback موفق تکراری نباید سفارش را دوباره نهایی کند |
| پیششرط | سفارش Pending و تراکنش معتبر Sandbox |
| اقدام | یک Callback موفق را دوبار با شناسه یکسان ارسال کنید |
| انتظار | هر دو درخواست پاسخ کنترلشده؛ فقط یک پرداخت و یک تغییر State؛ بدون Event تکراری |
مقایسه جامع Test Strategy، Test Plan و Test Case
| معیار | Test Strategy | Test Plan | Test Case |
|---|---|---|---|
| هدف | تعریف جهت و اصول | عملیاتیکردن تست Scope مشخص | ارزیابی رفتار مشخص |
| دامنه | سازمان/محصول/برنامه | پروژه/Release/Sprint | Requirement/Risk/Scenario |
| سطح جزئیات | کلان | میانی و اجرایی | جزئی و قابل اجرا |
| افق زمانی | نسبتاً بلندمدت | محدود به چرخه مشخص | تا زمانی که رفتار معتبر است |
| تغییر | با تغییر اساسی رویکرد | با Scope، Risk و Schedule | با Requirement، Design و Bug |
| مالک نمونه | QA/Engineering Leadership | QA Lead/Test Manager | Tester/SDET/Developer |
| مخاطب | Leadership و تیمهای مهندسی | تیم پروژه و ذینفعان Release | اجراکننده و Reviewer |
| ورودی | هدف سازمان، معماری، ریسک | Strategy، Requirement، Risk، Schedule | Plan، Rule، Acceptance Criteria |
| خروجی | اصول و استاندارد مشترک | دامنه، منابع، معیار و برنامه | شواهد Pass/Fail/Blocked |
| نمونه معیار | Quality Gate عمومی | Exit Criteria Release | Expected Result |
| ابزار نگهداری | Wiki/Document Repository | Wiki/Test Management/Project Tool | Test Management/Code Repository |
رابطه این سه مفهوم با یکدیگر
جریان منطقی چنین است:
- هدف و ریسک کسبوکار مشخص میشود.
- Test Strategy اصول مشترک کنترل ریسک را تعیین میکند.
- Requirement Analysis رفتار قابل تست و ریسک Scope را استخراج میکند.
- Test Plan دامنه، منابع، رویکرد و معیار Release را تعیین میکند.
- Test Scenario/Condition رفتارهای سطحبالا را فهرست میکند.
- Test Case/Charter/Automation پوشش اجرایی میسازد.
- نتیجه، عیب و Metric بازخورد لازم برای Plan و Strategy بعدی را فراهم میکند.
این یک سلسلهمراتب یکطرفه نیست. اگر Test Case نشان دهد داده یا Environment قابلکنترل نیست، Plan باید اصلاح شود. اگر چند Release از UI Flaky آسیب ببینند، Strategy سطح اتوماسیون را بازنگری میکند.
Test Policy و Test Scenario کجا قرار میگیرند؟
- Test Policy: بیانیه بسیار کلان سازمان درباره ارزش، هدف و تعهد کیفیت؛ ممکن است بالاتر از Strategy باشد.
- Test Scenario: جریان یا موضوع سطحبالای تست که به چند Test Case، Charter یا Automated Test تبدیل میشود.
همه تیمها به سند جداگانه برای هر نام نیاز ندارند. از تکرار محتوا جلوگیری و فقط سطح تصمیمها را روشن کنید.
مثال کامل: پرداخت فروشگاه اینترنتی
در Test Strategy
- قواعد مالی در Unit/API پوشش گسترده دارند.
- Contract Test برای سرویس پرداخت اجباری است.
- فقط سه مسیر حیاتی UI خودکار میشوند.
- داده واقعی حساس در محیط تست ممنوع است.
- عیب امنیتی بحرانی مانع Release است.
در Test Plan این Release
- Scope: ایجاد تراکنش، Redirect، Callback و State سفارش؛
- ریسک P0: مبلغ اشتباه، سفارش تکراری، دسترسی تراکنش کاربر دیگر؛
- Environment: Sandbox درگاه، Callback Simulator و Trace ID؛
- Schedule: Contract پیش از Integration؛ E2E پس از Smoke؛
- Exit: پوشش همه P0، نبود Critical Open و Monitoring آماده.
در Test Scenario
- پرداخت موفق؛
- پرداخت ناموفق؛
- Timeout و وضعیت نامشخص؛
- Callback تکراری؛
- تلاش کاربر دیگر برای مشاهده تراکنش.
در Test Case
برای «Callback تکراری»، شناسه تراکنش، State اولیه، دو درخواست، انتظار پایگاه داده/Event و Cleanup مشخص میشود.
این مثال نشان میدهد یک اطلاعات نباید سه بار کپی شود: Strategy اصل «Contract Test» را میگوید؛ Plan میگوید در این Release کدام Contract و چه موعدی؛ Case رفتار مشخص را Assert میکند.
آیا در Agile به این اسناد نیاز داریم؟
Agile مستندسازی مفید را حذف نمیکند؛ حجم و زمان آن را با ریسک تطبیق میدهد.
مدل سبک پیشنهادی
- یک صفحه Product Test Strategy؛
- بخش Release/Sprint Test Plan در Wiki یا Board؛
- Acceptance Criteria و Test Notes در Story؛
- Automation Testها در Repository؛
- Exploratory Charter برای ریسکهای ناشناخته؛
- Dashboard زنده برای اجرا و عیب؛
- Retrospective برای اصلاح Strategy و Checklist.
برای قابلیت کمریسک، Checklist کافی است؛ برای پرداخت، Migration یا محصول تحت مقررات، Traceability و تأیید رسمی بیشتری لازم است. «Working software over comprehensive documentation» به معنی نبود تصمیم ثبتشده نیست.
چه زمانی Strategy و Plan را ادغام کنیم؟
ادغام زمانی منطقی است که:
- تیم و محصول کوچکاند؛
- تنها یک Release یا دامنه محدود وجود دارد؛
- محتوا تکراری میشود؛
- مخاطب و مالک تقریباً یکساناند.
جدا نگهداشتن زمانی ارزش دارد که:
- چند تیم و Release از اصول مشترک استفاده میکنند؛
- Strategy نسبتاً پایدار ولی Planها پرتغییرند؛
- محصول مقرراتی یا پرریسک است؛
- ابزار، Environment و Governance در سطح سازمان تعریف میشوند.
قالب کوتاه Test Strategy
1. هدف و دامنه محصول/سازمان
2. اصول کیفیت و Risk Appetite
3. سطحها و انواع تست
4. Manual / Exploratory / Automation
5. Environment و Test Data
6. CI/CD و Quality Gate
7. Defect Management
8. Metric و Reporting
9. نقشها و Governance
10. بازبینی و بهبودقالب کوتاه Test Plan
1. نسخه، هدف و لینک Requirement
2. In Scope / Out of Scope
3. Product Risk / Project Risk
4. Test Approach و Coverage
5. Environment / Data / Tool
6. نقش، ظرفیت و Schedule
7. Entry / Suspension / Exit
8. Defect و Reporting
9. Deliverable و Decision Ownerقالب کوتاه Test Case
ID و عنوان:
Requirement / Risk:
اولویت و سطح:
پیششرط:
داده:
Action:
Expected Result:
Cleanup:
Environment / Tags:مدیریت در ابزارها
- Strategy را در منبعی قابلکشف و نسخهدار نگه دارید.
- Plan را به Release، Epic و Risk Register وصل کنید.
- Case را به Requirement و Execution مرتبط کنید.
- Automation را با Tag/ID به Risk یا Scenario متصل کنید.
- تصمیمها را در Decision Log نگه دارید، نه فقط جلسه.
- محتوای مشترک را لینک کنید و کپی نکنید.
ابزار ساختار را آسان میکند، اما نبود تصمیم یا Expected Result را جبران نمیکند.
اشتباهات رایج
- استفاده از سه اصطلاح بهجای یکدیگر؛
- کپیکردن Strategy در هر Plan؛
- نوشتن Plan بدون Risk و Exit Criteria؛
- نوشتن Case بدون ارتباط با Requirement؛
- فرض اینکه Strategy هرگز تغییر نمیکند؛
- نگهداری سندهای طولانی و بدون مالک؛
- اندازهگیری کیفیت با تعداد Test Case؛
- ثبت ابزار بهجای رویکرد و هدف؛
- نداشتن Out of Scope و مالک ریسک؛
- فراموشکردن Charter و Checklist بهعنوان جایگزین مناسب Case.
چکلیست انتخاب مصنوع مناسب
- آیا تصمیم برای چند تیم/Release تکرار میشود؟ → Strategy.
- آیا تصمیم به Scope و زمان مشخص وابسته است؟ → Plan.
- آیا رفتار نیاز به داده و انتظار اجرایی دارد؟ → Case.
- آیا هدف یادگیری و کشف است؟ → Charter.
- آیا رفتار آشنا و کمریسک است؟ → Checklist.
- آیا اجرای پرتکرار و قابلاندازهگیری است؟ → Automation Test.
- آیا محتوا قبلاً در سطح بالاتر ثبت شده؟ → لینک، نه کپی.
سوالات متداول
آیا Test Strategy و Test Plan یکساناند؟
خیر. Strategy اصول و رویکرد کلان و نسبتاً پایدار را تعریف میکند؛ Plan آن را برای Scope، زمان و ریسک یک پروژه یا Release عملیاتی میکند. در تیم کوچک میتوانند در یک صفحه ادغام شوند.
کدامیک اول نوشته میشود؟
معمولاً Strategy زمینه Plan را میدهد و Plan زمینه طراحی Test Case را. اما همه آنها با بازخورد اجرا بهروزرسانی میشوند؛ روند کاملاً خطی نیست.
آیا بدون Test Plan میتوان تست کرد؟
میتوان اجرا کرد، اما تصمیمهای دامنه، ریسک، محیط و پایان همچنان باید وجود داشته باشند. برای کار کوچک ممکن است Plan سبک باشد؛ حذف برنامهریزی با سبکبودن فرق دارد.
آیا هر Test Scenario فقط یک Test Case دارد؟
خیر. یک Scenario مانند «پرداخت» میتواند Caseهای موفق، ناموفق، مرزی، Timeout، مجوز و Recovery داشته باشد. بعضی Scenarioها نیز با Charter یا Automation پوشش داده میشوند.
چه کسی این اسناد را تأیید میکند؟
بسته به ریسک: Strategy با مشارکت رهبری مهندسی/محصول، Plan توسط تیم Release و Decision Owner، و Case با Peer Review فنی یا کسبوکاری. در محیط مقرراتی ممکن است تأیید رسمی لازم باشد.
جمعبندی
Test Strategy جهت و اصول، Test Plan برنامه اجرایی Scope مشخص و Test Case شواهد یک رفتار را تعریف میکند. ارزش این سه در تعداد سند نیست؛ در اتصال هدف و ریسک به تصمیم و اجراست. سطح مناسب را انتخاب، محتوای مشترک را لینک و نتیجه واقعی پروژه را برای اصلاح هر سه استفاده کنید.
