برنامه‌ریزی تست در STLC؛ راهنمای Test Plan با قالب آماده

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

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

برنامه‌ریزی تست (Test Planning) چیست؟

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

برنامه‌ریزی فاز دوم چرخه حیات تست نرم‌افزار است، اما یک‌بار انجام نمی‌شود. با تغییر Scope، ریسک، معماری، نسخه یا زمان‌بندی باید به‌روزرسانی شود.

هدف‌های Test Plan

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

تفاوت Test Plan، Test Strategy و Test Case

مصنوع	پرسش اصلی	سطح	نمونه محتوا
Test Strategy	در سازمان/محصول چگونه تست می‌کنیم؟	کلان و نسبتاً پایدار	اصول، سطح‌ها، ابزار، Automation، مدیریت ریسک
Test Plan	در این Release/پروژه چه برنامه‌ای داریم؟	عملیاتی و زمان‌مند	دامنه، منابع، زمان، محیط، معیار و گزارش
Test Scenario	چه رفتار یا جریان‌هایی را می‌سنجیم؟	سطح بالا	پرداخت موفق، لغو سفارش، بازیابی Timeout
Test Case	با چه داده و گام‌هایی چه نتیجه‌ای انتظار داریم؟	اجرایی	پیش‌شرط، داده، مراحل، Assertion

در تیم کوچک، Strategy ممکن است یک صفحه مشترک و Plan یک بخش از Release Checklist باشد. نیازی نیست نام سندها را تکثیر کنید؛ تصمیم‌ها را بدون تکرار و با مالک روشن نگه دارید. مقاله تفاوت Test Plan، Test Strategy و Test Case جزئیات بیشتری دارد.

ورودی‌ها و خروجی‌های فاز Test Planning

ورودی‌ها

• هدف محصول، Release یا Sprint؛
• نیازمندی و Acceptance Criteria؛
• فهرست ریسک و Test Conditionهای فاز تحلیل؛
• معماری، طراحی، قرارداد API و وابستگی‌ها؛
• تقویم Release و ظرفیت تیم؛
• تاریخچه عیب، Incident و درس‌آموخته؛
• محدودیت محیط، داده، امنیت و انطباق؛
• Definition of Done و سیاست انتشار.

ورودی اصلی باید از تحلیل نیازمندی‌ها در فاز اول STLC بیاید. اگر ریسک و رفتار هنوز مبهم‌اند، برنامه تست فقط حدس دقیق‌نما خواهد بود.

خروجی‌ها

• Test Plan تأییدشده یا توافق‌شده؛
• دامنه و اولویت ریسک‌ها؛
• برآورد، زمان‌بندی و ظرفیت؛
• مسئولیت و نقاط تصمیم؛
• نیاز محیط، داده، دسترسی و ابزار؛
• معیار ورود، توقف، ازسرگیری و خروج؛
• رویکرد گزارش عیب و وضعیت؛
• فهرست Deliverableها و وابستگی‌ها؛
• ورودی آماده برای توسعه تست‌کیس در فاز سوم.

اجزای اصلی یک Test Plan حرفه‌ای

۱. زمینه، هدف و شناسه نسخه

مشخص کنید این Plan برای کدام Product، Release، Sprint، Build یا Migration است و چرا نوشته می‌شود. هدف «تست نرم‌افزار» نیست؛ مثلاً «ارزیابی آمادگی پرداخت جدید برای انتشار محدود با تمرکز بر صحت مبلغ، Idempotency و بازیابی» دقیق‌تر است.

۲. دامنه داخل و خارج

قابلیت‌ها، پلتفرم‌ها، Browserها، APIها، Integrationها و داده‌های داخل دامنه را فهرست کنید. موارد خارج را همراه با دلیل و مالک ریسک بنویسید.

داخل دامنه	خارج از دامنه	دلیل/ریسک
پرداخت Sandbox و Callback	تسویه واقعی بانک	خارج از کنترل محیط؛ بررسی قراردادی/عملیاتی جدا
Chrome و Android هدف	Browserهای قدیمی	خارج از Support Matrix مصوب

۳. ریسک و اولویت

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

۴. رویکرد و سطح‌های تست

• Static Review و تحلیل استاتیک؛
• Unit/Component توسط توسعه؛
• API، Contract و Integration؛
• System، UI و End-to-End؛
• Exploratory و Usability؛
• Performance، Security، Accessibility و Compatibility؛
• Smoke، Retest و Regression؛
• Manual/Automation و زمان اجرای هر مجموعه.

به‌جای فهرست‌کردن همه نوع تست، توضیح دهید کدام ریسک با کدام سطح پوشش داده می‌شود.

۵. Test Data

• منبع ساخت داده و مسئول آن؛
• حساب‌ها و نقش‌های لازم؛
• داده معتبر، نامعتبر، مرزی و حجیم؛
• Mask/Anonymize داده حساس؛
• Reset، Cleanup و عمر داده؛
• Seed قابل‌نسخه‌بندی و جلوگیری از وابستگی تست‌ها.

۶. محیط و پیکربندی

معماری، URL، نسخه سرویس، پایگاه داده، Feature Flag، Mock/Sandbox، Browser/Device، Log/Trace و تفاوت با Production را ثبت کنید. نیازها را زود به تیم زیرساخت بدهید. راهنمای آماده‌سازی محیط تست چک‌لیست کامل دارد.

۷. ابزار و اتوماسیون

ابزار مدیریت تست و عیب، فریمورک Automation، Performance/Security Tool، CI و گزارش را مشخص کنید. تصمیم مهم‌تر از نام ابزار است: چه تستی، در چه Triggerی، با چه Timeout و چه Artifactی اجرا می‌شود؟

۸. نقش و مسئولیت

فعالیت	مسئول نمونه	همکار/تأییدکننده
تحلیل ریسک	QA Lead	Product، Dev، Ops
Unit/Component	Developer	Reviewer
API/UI Test	QA/SDET	Developer
Environment	DevOps	QA
UAT	Business/Product	QA
Release Decision	Product/Release Owner	QA، Dev، Ops

کیفیت مسئولیت مشترک است؛ Plan نباید تمام کارها را به QA نسبت دهد.

۹. زمان‌بندی و نقاط عطف

• آماده‌شدن نیازمندی و Design؛
• تحویل Build و Environment؛
• Test Case Review؛
• شروع Smoke و اجرای عمیق؛
• Code Freeze یا Release Candidate؛
• آخرین فرصت Fix/Retest؛
• Go/No-Go و انتشار؛
• Monitoring و Closure.

۱۰. مدیریت عیب

ابزار، Workflow، Severity/Priority، SLA داخلی، Triage، شواهد لازم، Retest، Deferred و Escalation را تعریف کنید. Severity اثر عیب است؛ Priority فوریت کسب‌وکار.

۱۱. گزارش و ارتباطات

مخاطب، تناوب و محتوای گزارش را مشخص کنید:

• داشبورد روزانه تیم: اجرا، شکست، Blocker و عیب جدید؛
• گزارش Release: پوشش، ریسک باقیمانده و پیشنهاد؛
• هشدار فوری: عیب بحرانی، محیط Down یا تأخیر وابستگی؛
• قالب تصمیم: چه کسی با کدام شواهد Go/No-Go می‌دهد؟

۱۲. Deliverableها

• Test Plan/Strategy؛
• Test Scenario، Case، Charter و Checklist؛
• Automation Code و Pipeline؛
• داده و Environment Guide؛
• گزارش اجرا و عیب؛
• Traceability؛
• Test Summary و Closure Report.

برنامه‌ریزی تست مبتنی بر ریسک

زمان همیشه محدود است. Risk-based Testing کمک می‌کند عمق، ترتیب و سطح تست را بر اساس احتمال × اثر انتخاب کنیم. مقاله آزمون مبتنی بر ریسک این رویکرد را کامل‌تر توضیح می‌دهد.

ریسک	احتمال	اثر	اولویت	پوشش برنامه‌ریزی‌شده
مبلغ اشتباه	متوسط	بحرانی	P0	Unit، API، مرز، جدول تصمیم، E2E
Callback تکراری	متوسط	بحرانی	P0	Integration، Concurrency، Idempotency
به‌هم‌ریختگی موبایل	متوسط	متوسط	P1	Device هدف و Visual/Manual
غلط املایی متن کم‌استفاده	کم	کم	P2	Checklist پیش از Release

ریسک پروژه نیز باید برنامه کاهش داشته باشد:

• Sandbox دیر آماده می‌شود → Mock/Contract و Deadline؛
• داده واقعی قابل‌استفاده نیست → Synthetic Data و Masking؛
• یک SDET گلوگاه است → Pairing و Code Ownership مشترک؛
• Environment ناپایدار است → Health Check، Monitoring و رزرو زمانی؛
• Scope تغییر می‌کند → بازبینی هفتگی Plan و تحلیل اثر.

برآورد زمان و منابع تست

برآورد باید شامل تحلیل، طراحی، Review، داده، محیط، اجرا، گزارش، Retest، Regression و نگهداری Automation باشد—نه فقط زمان کلیک‌کردن.

روش‌های رایج

• Expert Judgment: تجربه تیم با مستندکردن فرض‌ها؛
• Analogous: مقایسه با Release یا قابلیت مشابه؛
• Three-point: خوش‌بینانه، محتمل و بدبینانه؛
• Work Breakdown: شکستن کار به بسته‌های کوچک؛
• Risk-based Buffer: زمان اضافه برای ناشناخته‌های پرریسک؛
• Historical Data: زمان واقعی طراحی، اجرا و رفع مانع در گذشته.

راهنمای تکنیک‌های تخمین تست نرم‌افزار مثال‌های بیشتری دارد.

فرمول سه‌نقطه‌ای نمونه

برآورد PERT = (خوش‌بینانه + ۴ × محتمل + بدبینانه) ÷ ۶

مثلاً اگر آماده‌سازی و اجرای یک مجموعه در حالت خوش‌بینانه ۲، محتمل ۴ و بدبینانه ۸ روز باشد، برآورد PERT حدود ۴٫۳ روز است. این عدد تعهد قطعی نیست؛ با تغییر فرض‌ها باید به‌روز شود.

معیار ورود، خروج، تعلیق و ازسرگیری

Entry Criteria نمونه

• Acceptance Criteria و Scope توافق شده‌اند.
• Build روی Environment هدف Deploy و Smoke پاس شده است.
• داده، حساب، دسترسی و Mock آماده‌اند.
• تست‌های سطح پایین حیاتی پاس شده‌اند.
• Known Issue و Release Note در دسترس‌اند.

Exit Criteria نمونه

• همه ریسک‌های P0 پوشش اجراشده دارند.
• هیچ عیب بحرانی باز بدون تصمیم پذیرش وجود ندارد.
• رگرسیون حیاتی پاس و Flakyهای تاثیرگذار تعیین‌تکلیف شده‌اند.
• نیاز غیرکارکردی کلیدی آستانه توافق‌شده را دارد.
• ریسک باقیمانده به ذی‌نفعان گزارش و پذیرفته شده است.

«۹۵٪ تست‌ها پاس شده» بدون وزن ریسک معیار کافی نیست. شاید همان ۵٪ شامل پرداخت باشد.

Suspension Criteria

• Smoke قابلیت اصلی Fail است؛
• Environment یا داده نتیجه را غیرقابل اعتماد کرده‌اند؛
• Build اشتباه یا نسخه سرویس ناشناخته است؛
• عیب Blocker ادامه سناریوها را ناممکن می‌کند؛
• تغییر Scope معیارها را بی‌اعتبار کرده است.

Resumption Criteria

نسخه اصلاح‌شده مشخص، محیط سالم، داده Reset، مانع رفع و Smoke دوباره پاس شده است. مسئول تأیید ازسرگیری باید معلوم باشد.

Test Plan در Agile و DevOps

Agile برنامه‌ریزی را حذف نمی‌کند؛ آن را سبک، نزدیک به تغییر و تکرارشونده می‌کند.

• Product-level Strategy: سطح‌ها، ابزار، محیط و اصول مشترک؛
• Release Plan: ریسک‌های بین‌تیمی، Migration و غیرکارکردی؛
• Sprint/Story Plan: Acceptance، Test Notes، داده و Automation Task؛
• CI/CD Policy: چه تستی در PR، Nightly و Release اجرا می‌شود؛
• Definition of Done: Review، تست، عیب، Monitoring و مستند لازم؛
• Retrospective: به‌روزرسانی Plan با Flaky، Escape و Incident واقعی.

ممکن است Plan یک صفحه زنده باشد. طول سند معیار بلوغ نیست؛ کیفیت تصمیم، ردیابی و به‌روزرسانی معیار است.

مثال عملی: Test Plan قابلیت پرداخت

هدف

ارزیابی آمادگی پرداخت جدید برای Rollout محدود، با تمرکز بر صحت مبلغ، یک‌بار نهایی‌شدن سفارش و بازیابی وضعیت نامشخص.

دامنه

• داخل: محاسبه مبلغ، ایجاد تراکنش، Redirect، Callback، State سفارش، پیام کاربر؛
• خارج: تسویه واقعی و فرایند مالی بانک؛ مالک بررسی جداگانه تیم مالی/عملیات.

ریسک‌ها

• P0: مبلغ اشتباه، سفارش تکراری، دسترسی به تراکنش کاربر دیگر؛
• P1: Timeout و وضعیت نامشخص، نمایش اشتباه تومان/ریال، Callback دیرهنگام؛
• P2: متن و جزئیات ظاهری صفحه نتیجه.

رویکرد

• Unit برای تبدیل واحد و محاسبه؛
• Contract برای Schema درگاه؛
• Integration برای Callback تکراری/هم‌زمان و State؛
• API برای خطا، مجوز و داده مرزی؛
• سه E2E برای موفق، ناموفق و Timeout؛
• Exploratory برای Back/Refresh، شبکه ضعیف و چند Tab؛
• Security Review برای IDOR، Log و Secret.

محیط و داده

Sandbox درگاه، Callback قابل‌شبیه‌سازی، حساب‌های جدا، سفارش Seedشده، Log با Trace ID و Feature Flag برای Rollout.

معیار خروج

پوشش همه P0، نبود عیب بحرانی باز، Passشدن رگرسیون حیاتی، Monitoring و Rollback آماده و ثبت ریسک‌های P1/P2 پذیرفته‌شده.

قالب آماده Test Plan

1. مشخصات
- محصول / نسخه / تاریخ / مالک
- لینک Requirement و Design

2. هدف و زمینه
- هدف کسب‌وکار
- هدف تست
- فرض‌ها و محدودیت‌ها

3. دامنه
- In Scope
- Out of Scope + دلیل + مالک ریسک

4. ریسک
- Product Risk: احتمال، اثر، اولویت، پوشش
- Project Risk: احتمال، اثر، اقدام، مالک

5. رویکرد
- سطح‌ها و انواع تست
- Manual / Automation
- Regression و Exploratory
- Non-functional

6. محیط و داده
- معماری، نسخه، URL، Device/Browser
- حساب، Seed، Cleanup، Masking
- Mock / Sandbox / Feature Flag

7. ابزار و گزارش
- Test/Defect Management
- CI و Trigger
- Report و Artifact

8. نقش و زمان
- مسئولیت‌ها
- Milestone و وابستگی
- برآورد و Buffer

9. معیار
- Entry
- Suspension / Resumption
- Exit

10. Deliverable و تأیید
- خروجی‌ها
- Reviewers / Decision owners
- تاریخ بازبینی بعدی

اشتباهات رایج در برنامه‌ریزی تست

• کپی‌کردن Plan پروژه قبلی بدون تطبیق ریسک؛
• فهرست‌کردن همه انواع تست بدون ارتباط با Scope؛
• نداشتن Out of Scope و مالک ریسک؛
• برآورد فقط زمان اجرا و فراموش‌کردن محیط/داده/Retest؛
• معیار خروج صرفاً درصد Pass؛
• نادیده‌گرفتن غیرکارکردی و عملیات؛
• قرار دادن تمام مسئولیت کیفیت روی QA؛
• انتخاب ابزار پیش از نیاز؛
• به‌روزرسانی‌نکردن Plan پس از تغییر Scope؛
• گزارش وضعیت بدون ریسک باقیمانده و تصمیم موردنیاز.

چک‌لیست Review برنامه تست

• هدف و نسخه Plan مشخص است.
• دامنه داخل/خارج و فرض‌ها ثبت شده‌اند.
• ریسک‌ها اولویت و پوشش متناسب دارند.
• سطح مناسب، به‌ویژه Unit/API، استفاده شده است.
• داده و محیط مالک و موعد دارند.
• Browser/Device بر اساس Support/Analytics انتخاب شده‌اند.
• مسئولیت و Release Decision Owner روشن است.
• برآورد شامل Review، Retest و Buffer است.
• Entry/Exit/Suspension قابل‌اندازه‌گیری‌اند.
• گزارش برای مخاطب و تصمیم طراحی شده است.
• Plan تاریخ بازبینی و مسیر تغییر دارد.

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

چه کسی Test Plan را می‌نویسد؟

معمولاً QA Lead یا Test Manager هماهنگ‌کننده است، اما Product، Development، DevOps، Security و Business باید بخش‌های مرتبط را مشارکت و تصمیم‌ها را تأیید کنند.

آیا هر پروژه به سند رسمی Test Plan نیاز دارد؟

خیر. سطح رسمیت به ریسک، اندازه و الزام بستگی دارد. تیم کوچک می‌تواند یک صفحه سبک داشته باشد؛ محصول حساس ممکن است سند نسخه‌دار و تأیید رسمی بخواهد. تصمیم‌های کلیدی نباید حذف شوند.

Test Plan چند وقت یک‌بار به‌روزرسانی شود؟

پس از تغییر Scope، ریسک، معماری، زمان، محیط یا معیار انتشار. در Agile، بازبینی کوتاه در Refinement/Sprint Planning و پیش از Release عملی است.

تفاوت Entry Criteria و Exit Criteria چیست؟

Entry شرایط لازم برای شروع قابل‌اعتماد یک فعالیت است؛ Exit شواهد لازم برای پایان و تصمیم حرکت به مرحله بعد یا انتشار را تعریف می‌کند.

اگر زمان تست کم شد چه کنیم؟

Scope را پنهانی کم نکنید. ریسک‌ها را دوباره اولویت‌بندی، سطح تست را بهینه، مسیرهای P0 را حفظ و پوشش حذف‌شده و ریسک باقیمانده را برای تصمیم ذی‌نفعان شفاف کنید.

جمع‌بندی

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