طرح تست یا تست پلن سندی است که مشخص میکند چه چیزی، چطور، توسط چه کسی و تا چه زمانی تست میشود. استراتژی تست هم رویکرد کلی تیم به کیفیت را تعریف میکند. این مقاله تفاوت این دو، اجزای یک طرح تست خوب و روش نوشتن گامبهگام آن را توضیح میدهد.
طرح تست (Test Plan) چیست
طرح تست سند برنامهریزی فعالیتهای تست برای یک پروژه، محصول یا ریلیز است. این سند دامنه تست، رویکرد، منابع، زمانبندی، ریسکها و معیارهای تصمیم را در یک جا جمع میکند.
طرح تست یک توافق است. تیم تست، توسعهدهندگان، مدیر محصول و مدیر پروژه باید روی آن همنظر باشند. وقتی سؤالی مثل «آیا تست کارایی در این ریلیز انجام میشود» پیش میآید، پاسخ باید در طرح تست باشد.
چرا تست پلن مهم است
- دامنه تست را روشن میکند و از کار اضافه یا جاافتاده جلوگیری میکند.
- منابع و زمانبندی تست را قابل پیشبینی میکند.
- ریسکها را پیش از بروز مشکل آشکار میکند.
- معیار روشنی برای تصمیم ریلیز فراهم میکند.
- مرجع مشترکی برای اعضای جدید تیم میسازد.
تفاوت طرح تست و استراتژی تست
استراتژی تست (Test Strategy) رویکرد کلی تست را در سطح سازمان یا محصول تعریف میکند. این سند کمتر تغییر میکند و به پرسش «بهطور کلی چطور تست میکنیم» پاسخ میدهد. طرح تست همین رویکرد را برای یک پروژه یا ریلیز مشخص جزئی میکند.
| معیار | استراتژی تست | طرح تست |
|---|---|---|
| دامنه | سازمان یا کل محصول | یک پروژه، ریلیز یا قابلیت |
| سطح جزئیات | کلی و اصولی | دقیق و عملیاتی |
| طول عمر | بلندمدت؛ بهندرت تغییر میکند | کوتاهمدت؛ برای هر ریلیز بهروز میشود |
| پرسش اصلی | رویکرد ما به تست چیست | در این ریلیز دقیقاً چه تست میشود |
| محتوای نمونه | سطوح تست، ابزارها، رویکرد اتوماسیون، استاندارد مستندات | قابلیتهای داخل و خارج دامنه، زمانبندی، مسئولیتها، ریسکها |
| تهیهکننده | سرپرست QA یا مدیر کیفیت | سرپرست تست پروژه با مشارکت تیم |
در تیمهای کوچک، گاهی هر دو در یک سند ترکیب میشوند. این کار اشکالی ندارد، به شرط آنکه بخش ثابت و بخش مخصوص ریلیز از هم جدا باشد.
اجزای اصلی یک طرح تست
استانداردهایی مثل IEEE 829 و جانشین آن ISO/IEC/IEEE 29119-3 قالبهایی برای مستندات تست پیشنهاد میکنند. لازم نیست همه بندهای این قالبها را پر کنید. اجزای زیر هسته یک طرح تست کاربردی هستند:
۱. معرفی و اهداف
یک پاراگراف کوتاه درباره محصول، ریلیز و هدف تست. مثلاً «اطمینان از صحت فرایند پرداخت جدید پیش از انتشار عمومی».
۲. دامنه تست
- داخل دامنه: قابلیتها و ماژولهایی که تست میشوند.
- خارج از دامنه: مواردی که تست نمیشوند، همراه با دلیل.
نوشتن موارد خارج از دامنه به همان اندازه مهم است. این کار از انتظارهای نادرست جلوگیری میکند.
۳. رویکرد تست
سطوح و انواع تست در این ریلیز مشخص میشوند. مثلاً تست سیستم دستی برای قابلیتهای جدید، تست رگرسیون خودکار برای قابلیتهای قبلی و تست بار برای سرویس پرداخت. برای مرور همه گزینهها، مقاله انواع تست نرمافزار را ببینید.
۴. معیارهای ورود و خروج
معیارهای ورود و خروج مشخص میکنند تست چه زمانی شروع و چه زمانی تمام میشود.
- نمونه معیار ورود: بیلد روی محیط تست مستقر شده و تست دود قبول شده است.
- نمونه معیار خروج: همه تستکیسهای با اولویت بالا اجرا شده و هیچ باگ بحرانی بازی باقی نمانده است.
۵. معیارهای تعلیق و ازسرگیری
شرایطی که در آن تست متوقف میشود؛ مثلاً از کار افتادن محیط تست یا باگی که بیشتر تستها را مسدود میکند. شرط ازسرگیری هم باید روشن باشد.
۶. محیط تست و داده تست
مشخصات محیط تست، مرورگرها و دستگاهها، نسخه سرویسهای وابسته و روش تهیه داده تست در این بخش میآید.
۷. نقشها و مسئولیتها
چه کسی تستکیس مینویسد، چه کسی اجرا میکند، چه کسی باگها را اولویتبندی میکند و چه کسی ریلیز را تأیید میکند.
۸. زمانبندی و تحویلدادنیها
تاریخهای کلیدی، وابستگیها و خروجیهایی مثل تستکیسها، گزارش اجرا و گزارش نهایی کیفیت. این زمانبندی معمولاً به مایلستون ریلیز گره میخورد.
۹. ریسکها و راهکارها
ریسکهای محصول و ریسکهای پروژه جدا فهرست میشوند. برای هر ریسک، احتمال، اثر و راهکار کاهش آن نوشته میشود.
مراحل نوشتن طرح تست گامبهگام
- محصول و نیازمندیها را تحلیل کنید. مستندات نیازمندی، داستانهای کاربری و طراحی را بخوانید. با مدیر محصول و توسعهدهندگان صحبت کنید.
- ریسکها را شناسایی کنید. کدام بخشها تازهاند، کدام پیچیدهاند و خرابی کدام بخش بیشترین اثر را روی کاربر دارد.
- دامنه را تعیین کنید. بر اساس ریسک، مشخص کنید چه چیزی داخل و چه چیزی خارج از دامنه است.
- رویکرد را انتخاب کنید. سطوح، انواع تست و نسبت تست دستی به خودکار را مشخص کنید.
- معیارها را تعریف کنید. معیارهای ورود، خروج، تعلیق و ازسرگیری را بنویسید.
- منابع و زمان را برآورد کنید. تعداد نفرات، مهارتها، محیطها و زمان لازم را تخمین بزنید.
- بازبینی و تأیید بگیرید. سند را با ذینفعان مرور کنید و تأیید رسمی بگیرید.
- سند را زنده نگه دارید. با تغییر دامنه یا زمانبندی، طرح تست را بهروز کنید.
نمونه خلاصه یک طرح تست
فرض کنید تیم شما قرار است قابلیت «پرداخت اقساطی» را به یک فروشگاه اینترنتی اضافه کند. خلاصه طرح تست این ریلیز میتواند این شکل را داشته باشد:
| بخش | محتوا |
|---|---|
| هدف | اطمینان از صحت محاسبه اقساط و ثبت سفارش اقساطی پیش از انتشار |
| داخل دامنه | انتخاب روش اقساطی، محاسبه مبلغ هر قسط، تأیید سفارش، پیامک اطلاعرسانی |
| خارج از دامنه | فرایند وصول اقساط؛ در ریلیز بعدی تست میشود |
| رویکرد | تست سیستم دستی برای قابلیت جدید، رگرسیون خودکار سبد خرید، تست بار سرویس محاسبه |
| معیار ورود | بیلد روی محیط استیجینگ مستقر و تست دود قبول شده باشد |
| معیار خروج | همه تستهای اولویت بالا اجرا شده و باگ بحرانی باز وجود نداشته باشد |
| ریسک اصلی | وابستگی به سرویس بیرونی اعتبارسنجی؛ راهکار: شبیهساز سرویس در محیط تست |
| مسئولیتها | طراحی و اجرا: تیم QA؛ تأیید نهایی: مالک محصول |
این جدول در یک صفحه جا میشود، اما پاسخ پرسشهای اصلی ذینفعان را میدهد.
رویکردهای رایج در استراتژی تست
استراتژی تست معمولاً بر یک یا ترکیبی از این رویکردها بنا میشود:
- مبتنی بر ریسک: تلاش تست بر اساس احتمال و اثر خرابی توزیع میشود. بخشهای پرریسک عمیقتر تست میشوند.
- مبتنی بر نیازمندی: هر نیازمندی حداقل یک تست دارد. ماتریس ردیابی پوشش را نشان میدهد. جزئیات آن در مقاله ماتریس ردیابی نیازمندی آمده است.
- مبتنی بر مدل: تستها از مدلهایی مثل نمودار حالت یا جریان کار استخراج میشوند.
- واکنشی: بخشی از تست در زمان اجرا و بر اساس یافتهها طراحی میشود؛ مانند تست اکتشافی.
- مبتنی بر پیشگیری از رگرسیون: مجموعهای از تستهای تکرارشونده، معمولاً خودکار، از قابلیتهای قبلی محافظت میکند. مقاله تست رگرسیون این رویکرد را توضیح میدهد.
جایگاه اتوماسیون در استراتژی
استراتژی تست باید مشخص کند چه چیزی خودکار میشود و در کدام لایه. هرم تست راهنمای خوبی برای این تصمیم است. برای شروع، مقاله اتوماسیون تست را بخوانید.
طرح تست در تیمهای چابک
در تیمهای چابک، طرح تست سنگین و صدصفحهای جایی ندارد. اما برنامهریزی تست همچنان لازم است. تفاوت در شکل و اندازه آن است:
- استراتژی تست یک سند کوتاه و پایدار برای کل محصول است.
- طرح تست ریلیز یک یا دو صفحه است و دامنه، ریسکها و معیارهای خروج ریلیز را مشخص میکند.
- برنامه تست اسپرینت در جلسه برنامهریزی اسپرینت و در قالب وظایف تست هر داستان کاربری تعریف میشود.
- معیارهای پذیرش هر داستان کاربری، جزئیترین لایه برنامهریزی تست است.
نکته مهم این است که طرح تست یک سند زنده باشد. اگر پس از نوشتن کسی به آن مراجعه نکند، ارزشی ندارد.
اشتباهات رایج در نوشتن تست پلن
- کپی کردن قالب بدون تطبیق: بندهایی که به پروژه ربطی ندارند، سند را طولانی و بیاستفاده میکنند.
- ننوشتن موارد خارج از دامنه: ذینفعان تصور میکنند همه چیز تست میشود.
- معیارهای خروج مبهم: «کیفیت قابل قبول باشد» قابل سنجش نیست.
- نادیده گرفتن ریسکها: زمانبندی بدون در نظر گرفتن ریسک محیط تست یا تأخیر توسعه، واقعبینانه نیست.
- بازبینی نکردن با ذینفعان: طرحی که تأیید نشده، در لحظه تصمیم ریلیز مورد اختلاف قرار میگیرد.
- بهروز نکردن سند: طرحی که با واقعیت پروژه فاصله دارد، اعتماد تیم را از دست میدهد.
پیادهسازی طرح تست در TestRail
طرح تست روی کاغذ وقتی ارزش کامل دارد که در ابزار اجرا شود. در TestRail، هر ریلیز میتواند یک Milestone باشد. هر Test Plan چند Test Run را کنار هم نگه میدارد؛ مثلاً یک اجرا برای تست سیستم و یک اجرا برای رگرسیون. تستکیسها از سوئیتها و بخشها انتخاب میشوند و نتایج با وضعیتهای Passed، Failed، Blocked و Retest ثبت میشوند. گزارشها هم پیشرفت را در برابر معیارهای خروج نشان میدهند. برای انتخاب نسخه مناسب تیم خود، صفحه قیمت و پلنهای TestRail را ببینید. برای سنجش پیشرفت، مقاله معیارهای تست و گزارش کیفیت هم کمک میکند.
جمعبندی
استراتژی تست رویکرد کلی تیم به کیفیت را تعریف میکند و طرح تست آن را برای هر ریلیز عملیاتی میکند. یک تست پلن خوب دامنه، رویکرد، معیارهای ورود و خروج، مسئولیتها و ریسکها را روشن میکند. در تیمهای چابک، این سند کوتاهتر است اما همچنان لازم است. طرح تست نقشهای است که زنجیره نیازمندی ← تستکیس ← اجرای تست ← باگ ← ریلیز را هدایت میکند. برای نوشتن تستکیسهای این طرح، مقاله نوشتن تستکیس حرفهای را بخوانید.