انتشار نزدیک است، ۹۳٪ تستها Pass شدهاند و فقط چند باگ باز مانده است. آیا محصول آماده است؟ بدون دانستن اینکه ۷٪ باقیمانده کدام سفرها را پوشش میدهد، باگهای باز چه اثری دارند و محیط تست چه محدودیتی داشته، این درصد تقریباً هیچ پاسخ تصمیمپذیری نمیدهد. بستهشدن چرخه تست (Test Cycle Closure) فازی است که دادههای پراکنده اجرا را به یک تصویر شفاف از کیفیت و ریسک تبدیل میکند.
پاسخ کوتاه: فاز ششم STLC شامل ارزیابی معیارهای خروج، تطبیق دامنه و پوشش، جمعبندی نتایج و نقصها، ثبت ریسک باقیمانده، تهیه Test Summary Report، گرفتن تصمیم/تأیید ذینفعان، آرشیو مصنوعات و تبدیل درسآموختهها به اقدامهای دارای مالک است. بستهشدن به معنی «محصول بدون باگ» یا «تأیید شخصی QA برای انتشار» نیست.
خروجی مطلوب: هر تصمیمگیر باید بتواند در چند دقیقه بفهمد چه چیزی آزموده شد، چه چیزی نشد، چه مشکلاتی باز است، چه ریسکی پذیرفته میشود و اقدام بعدی دقیقاً چیست.
بستهشدن چرخه تست چیست؟
Test Cycle Closure آخرین فاز رایج در چرخه حیات تست نرمافزار (STLC) است. تیم در این مرحله اجرای فعال یک دامنه مشخص—مانند Release، Sprint، Migration یا کمپین—را خاتمه میدهد و شواهد آن را برای تصمیم، یادگیری و استفاده بعدی تثبیت میکند.
این فاز فقط پس از انتشار انجام نمیشود. بسته به مدل تحویل، ممکن است پیش از Go/No-Go برای تصمیم انتشار آغاز شود و پس از انتشار با ثبت نتیجه نهایی و رخدادهای اولیه تکمیل گردد. در تیمهای تحویل پیوسته نیز closure حذف نمیشود؛ به چرخههای کوچکتر و خودکارتر تبدیل میشود.
تفاوت «توقف تست» و «بستهشدن تست»
تست ممکن است بهدلیل رسیدن موعد، محدودیت محیط یا تصمیم کسبوکار متوقف شود، حتی اگر همه معیارهای خروج محقق نشده باشند. Closure این انحراف را پنهان نمیکند؛ آن را همراه اثر، صاحب اختیار و اقدام کاهش ریسک ثبت میکند. بنابراین «معیارها کامل نشدند» الزاماً مانع مستندسازی پایان چرخه نیست، اما باید تصمیم آگاهانه و قابلردیابی وجود داشته باشد.
چه زمانی یک چرخه تست آماده بستهشدن است؟
معیار خروج باید از فاز برنامهریزی تعریف شده باشد، نه در آخرین روز و متناسب با نتیجه موجود. مقاله برنامهریزی تست و Test Plan روش تعریف این معیارها را توضیح میدهد. نمونه معیارهای زمینهمند:
- تمام سفرهای بحرانی کسبوکار روی بیلد نامزد انتشار اجرا و شواهدشان ثبت شده است.
- هیچ باگ بحرانی تاییدشدهای باز نیست؛ استثنا فقط با پذیرش رسمی ریسک.
- باگهای رفعشده مهم Retest و Regression متناسب دارند.
- نیازمندیها و ریسکهای داخل دامنه به تست و نتیجه قابلردیابیاند.
- Blocked و Not Runهای باقیمانده اثر مشخص و تصمیم مالک دارند.
- سطح کارایی، امنیت، سازگاری یا معیار کیفی مرتبط با این Release بررسی شده است.
- نتایج ابزارها، لاگها و نسخهها برای بازبینی قابل دسترساند.
یک عدد ثابت مانند «۹۵٪ Pass» یا «۹۰٪ پوشش کد» استاندارد جهانی آمادگی انتشار نیست. ممکن است همه تستهای کمریسک Pass و تنها سناریوی بازپرداخت مسدود باشد. معیار خوب به ریسک و دامنه وصل است.
ورودیها و خروجیهای فاز ششم STLC
| ورودی | برای چه استفاده میشود؟ | خروجی متناظر |
|---|---|---|
| Test Plan و معیار خروج | مقایسه برنامه با واقعیت | وضعیت تحقق/انحراف |
| Test Runs و شواهد اجرا | محاسبه دامنه و نتیجه معتبر | خلاصه اجرا و محدودیت |
| Traceability | کشف نیازمندی یا ریسک بدون آزمون | گزارش پوشش |
| Backlog باگ | تحلیل باگ باز، رفعشده و نشتیافته | بیانیه ریسک نقص |
| لاگ محیط و استقرار | توضیح اعتبار و محدودیت نتیجه | شرح محیط/نسخه |
| بازخورد تیم و ذینفعان | استخراج الگو و علت | درسآموخته و Action Item |
خروجیهای اصلی معمولاً Test Summary Report، فهرست ریسک پذیرفتهشده، تصمیم انتشار یا گام بعدی، صورتجلسه درسآموختهها، آرشیو مصنوعات و اقدامهای بهبود هستند.
مراحل بستهشدن چرخه تست
۱. دامنه و خط مبنای گزارش را تثبیت کنید
نسخه، Release، بازه زمانی، محیطها و Test Runهای داخل گزارش را مشخص کنید. اگر بعد از استخراج داده تست دیگری اجرا شد، نسخه گزارش یا زمان Cut-off را بهروزرسانی کنید. آمیختن نتیجه چند بیلد بدون برچسب، Pass Rate و وضعیت باگ را غیرقابلاعتماد میکند.
۲. نتایج اجرا را تطبیق و پاکسازی کنید
تستهای بدون وضعیت، تکراری، اجراشده روی بیلد قدیمی یا Blocked با علت نامشخص را بررسی کنید. تفاوت میان Planned، In Scope، Executed، Not Run و Skipped را حفظ کنید. مقاله اجرای تست در فاز پنجم STLC تعریف وضعیتها و شواهد لازم را پوشش میدهد.
۳. معیارهای خروج را بندبهبند ارزیابی کنید
برای هر معیار یکی از وضعیتهای «محقق»، «محققنشده» یا «غیرقابل ارزیابی» همراه شاهد بدهید. اگر انحراف پذیرفته شده است، نام نقش صاحب اختیار، تاریخ، دلیل، اثر و اقدام کاهش ریسک را ثبت کنید. عبارت «طبق توافق تیم» بدون مرجع تصمیم برای حسابرسی یا Release بعدی کافی نیست.
۴. باگهای باز و Resolutionها را بازبینی کنید
باگها را فقط نشمارید. برای موارد باز، Severity، اثر کاربر، احتمال، راهحل موقت، نسخه هدف و ارتباط با مسیر بحرانی را ببینید. Duplicate، Deferred، Cannot Reproduce و Accepted Risk نیز باید دلیل و مالک داشته باشند. برای تعریف این وضعیتها، راهنمای چرخه عمر باگ و Bug Workflow را بخوانید.
۵. پوشش را از چند زاویه تحلیل کنید
پوشش فقط Code Coverage نیست. بسته به هدف Release، این ابعاد مهماند:
- پوشش نیازمندی و معیار پذیرش
- پوشش ریسکهای بحرانی
- پوشش پلتفرم، مرورگر، دستگاه و نقش
- پوشش داده و حالتهای مرزی
- پوشش تستهای غیرکارکردی مرتبط
- پوشش تغییر و شعاع Regression
هر شکاف را کنار اثرش بنویسید. «Safari تست نشد» اطلاعات است؛ «Safari در تعهد پشتیبانی است، ۱۲٪ ترافیک دارد و مسیر پرداخت روی آن تست نشد» ورودی تصمیم است.
۶. گزارش خلاصه تست را بنویسید
Test Summary Report باید دو لایه داشته باشد: خلاصه مدیریتی کوتاه برای تصمیم و جزئیات قابلردیابی برای متخصصان. نمودارها و جدولها تنها وقتی ارزش دارند که یک پرسش را پاسخ دهند. از کپیکردن دهها صفحه خروجی ابزار بدون تفسیر پرهیز کنید.
۷. تصمیم و Sign-off را ثبت کنید
QA شواهد و ارزیابی ریسک را ارائه میکند، اما معمولاً بهتنهایی مالک تصمیم تجاری انتشار نیست. مرجع تصمیم میتواند Product Owner، مدیر Release، مشتری یا کمیته تغییر باشد. Sign-off باید بگوید چه تصمیمی، برای کدام نسخه، با چه استثناها و توسط چه نقشهایی گرفته شد.
۸. درسآموخته را به اقدام تبدیل کنید
«ارتباطات بهتر شود» درسآموخته قابل اجرا نیست. یک Action Item خوب این اجزا را دارد:
- مشاهده و شاهد: چه اتفاقی چند بار رخ داد؟
- علت یا فرضیه آزمونپذیر: چرا رخ داد؟
- اقدام مشخص: چه تغییر فرایندی یا فنی انجام میشود؟
- مالک و موعد: چه کسی تا چه زمانی؟
- معیار موفقیت: در چرخه بعد چگونه میفهمیم بهتر شده است؟
برای طراحی جلسهای که واقعاً به تصمیم و اقدام برسد، راهنمای برگزاری جلسه بازبینی تست مؤثر مکمل مناسبی است.
۹. مصنوعات را آرشیو و محیط را پاکسازی کنید
Test Plan، تستکیسها، اسکریپتها، دادههای مصنوعی، خروجی اجرا، گزارشها، نسخه تنظیمات و تصمیمهای ریسک را بر اساس سیاست نگهداری سازمان ذخیره کنید. سپس حسابهای موقت، دادههای حساس، منابع ابری و دسترسیهای ویژه را کنترلشده پاک یا لغو کنید. تاریخچه لازم برای حسابرسی را با پاکسازی بیرویه از بین نبرید؛ محرمانگی و Retention Policy باید مسیر را تعیین کنند.
قالب آماده Test Summary Report
1) مشخصات
- محصول / Release:
- نسخه و Build:
- بازه تست:
- محیطها:
- نویسنده و تاریخ گزارش:
2) خلاصه مدیریتی
- هدف Release:
- نتیجه کلی و سطح اطمینان:
- تصمیم پیشنهادی/گزینهها:
- سه ریسک اصلی باقیمانده:
3) دامنه
- قابلیتها و ریسکهای داخل دامنه:
- خارج از دامنه:
- تغییرهای دامنه نسبت به Test Plan:
4) رویکرد و محیط
- انواع تست اجراشده:
- دستگاهها/مرورگرها/داده:
- محدودیت محیط و وابستگیها:
5) نتایج اجرا
- Planned / Executed / Pass / Fail / Blocked / Not Run:
- نتیجه سفرهای بحرانی:
- پوشش نیازمندی و ریسک:
6) وضعیت نقصها
- باگهای باز به تفکیک Severity و اثر:
- باگهای Deferred یا Accepted Risk:
- Retest و Regression اصلاحهای مهم:
7) معیارهای خروج
- هر معیار + وضعیت + شاهد/انحراف:
8) ریسک و توصیه
- ریسک:
- احتمال و پیامد:
- راهحل موقت/کاهش ریسک:
- مالک:
- گزینه تصمیم:
9) تصمیم و تأیید
- Go / Conditional Go / No-Go / ادامه تست:
- استثناها:
- نقشهای تأییدکننده و زمان:
10) پیوستها و درسآموخته
- لینک Test Runs، باگها و داشبورد:
- Action Item + مالک + موعد + معیار موفقیت:مثال کوتاه گزارش بستهشدن تست فروشگاه ایرانی
اعداد زیر صرفاً آموزشیاند و معیار عمومی صنعت نیستند.
Release: کمپین نوروز، Build ۴۳۱
دامنه: ورود با رمز یکبارمصرف، جستوجو، سبد، تخفیف، درگاه آزمایشی و بازگشت پرداخت روی وب موبایل.
نتیجه اجرا: ۱۳۲ تست برنامهریزی شد؛ ۱۲۶ اجرا، ۱۱۸ Pass، پنج Fail و سه Blocked؛ شش تست اجرا نشد.
معیارهای بحرانی: پرداخت موفق، جلوگیری از برداشت تکراری و سقف تخفیف تایید شد. بازپرداخت پس از قطع ارتباط درگاه بهدلیل محدودیت سندباکس کامل آزموده نشد.
باگ باز مهم: یک باگ High در نمایش وضعیت سفارش روی اینترنت ناپایدار؛ تراکنش درست ثبت میشود و کاربر با Refresh وضعیت صحیح را میبیند.
ریسک باقیمانده: ابهام موقت برای کاربر و افزایش تماس پشتیبانی؛ مالک محصول راهحل موقت پیام راهنما و مانیتورینگ سفارشهای Pending را پذیرفت.
گزینه تصمیم: Conditional Go با فعالسازی داشبورد، آموزش پشتیبانی و موعد اصلاح پیش از موج دوم کمپین.
این گزارش نمیگوید «کیفیت خوب است»؛ دامنه، شکاف، اثر و شرط تصمیم را روشن میکند. اگر شش تست اجرانشده مربوط به صفحه درباره ما بودند، ریسک با زمانی که مربوط به بازپرداختاند یکسان نیست.
چه معیارهایی در گزارش نهایی مفیدند؟
| معیار | کاربرد | خطر تفسیر نادرست |
|---|---|---|
| Execution Progress | میزان اجرای دامنه برنامهریزیشده | تغییر دامنه یا اهمیت تستها را نشان نمیدهد |
| Pass Rate | روند نتیجه تستهای اجراشده | بهتنهایی معادل کیفیت یا آمادگی نیست |
| Blocked/Not Run | شکاف پوشش و موانع | بدون اثر ریسک فقط عدد است |
| Open Defects by Severity | تصویر نقصهای شناختهشده | احتمال و مسیر کاربر را پنهان میکند |
| Requirement/Risk Coverage | شاهد برای هدفهای مهم | ردیابی صوری میتواند پوشش کاذب بسازد |
| Defect Reopen/Escape | سرنخ ضعف رفع یا کشف | برای ارزیابی فردی مناسب نیست |
| Cycle Time | کشف گلوگاه فرایند | نوع کار و زمان انتظار باید تفکیک شود |
معیار باید به تصمیم یا اقدام منجر شود. برای انتخاب سنجههای غیرقابلبازیتر، مقاله معیارهای معنادار اثربخشی QA را ببینید.
چگونه ریسک باقیمانده را بنویسیم؟
یک Risk Statement مفید این ساختار را دارد:
«بهدلیل [شکاف/شرط]، ممکن است [رخداد] برای [کاربر/دارایی] اتفاق بیفتد و پیامد [اثر] ایجاد کند. احتمال/عدمقطعیت بر اساس [شاهد] است. کاهش فعلی [کنترل]، مالک [نقش] و موعد بازبینی [زمان] است.»
نمونه: «بهدلیل آزمودهنشدن کامل بازپرداخت در قطع Callback سندباکس، ممکن است وضعیت برخی سفارشها موقتاً مبهم بماند و تماس پشتیبانی افزایش یابد. مانیتور Pending و تطبیق خودکار روزانه کنترل موقت است؛ مالک تیم پرداخت و موعد بازبینی پس از تست محیط کامل است.»
عبارت «ریسک پایین است» بدون شرط، شاهد و اثر، تصمیمپذیر نیست.
Sign-off و تصمیم Go/No-Go
تصمیم میتواند یکی از این حالتها باشد:
- Go: معیارهای لازم محقق و ریسک باقیمانده پذیرفتنی است.
- Conditional Go: انتشار با کنترلها، محدودیت دامنه، Feature Flag یا برنامه اصلاح مشخص.
- No-Go: ریسک یا شکاف حیاتی برای انتشار فعلی پذیرفتنی نیست.
- Continue Testing: هنوز شاهد کافی برای تصمیم وجود ندارد و زمان/محیط بیشتری اختصاص مییابد.
Sign-off نباید به معنی انتقال مسئولیت همه عواقب به QA باشد. هر استثنا صاحب اختیار، مالک کاهش ریسک و موعد دارد. اگر تصمیم برخلاف توصیه QA است، هر دو دیدگاه و دلیل تصمیم نهایی محترمانه و دقیق ثبت میشوند.
جلسه درسآموختهها را چگونه نتیجهمحور کنیم؟
جلسه را بر داده و فرایند متمرکز کنید، نه مقصر. پرسشهای مفید:
- کدام فرضیه تست درست یا غلط بود؟
- کدام باگ دیر کشف شد و چه سیگنالی زودتر وجود داشت؟
- چه مقدار زمان بهدلیل محیط، داده یا انتظار مبهم از دست رفت؟
- کدام تست ارزش تصمیم بالایی داشت و کدام فقط هزینه بود؟
- چه اقدام کوچکی در چرخه بعد قابلآزمایش است؟
| مشاهده | اقدام | مالک | معیار موفقیت |
|---|---|---|---|
| سه روز Blocked بهدلیل حساب تست | ساخت خودکار کاربر و Health Check پیش از Run | QA Platform | Blocked محیطی در دو چرخه بعد کاهش یابد |
| دو باگ مبلغ ناشی از ابهام ریال/تومان | افزودن مثال عددی به معیار پذیرش و قرارداد API | محصول + Backend | همه Storyهای مالی واحد و مثال دارند |
| Retry تستهای Flaky خطا را پنهان کرد | قرنطینه و داشبورد Flaky با مالک | Automation | نرخ ناپایداری مجموعه اصلی زیر هدف تیم بماند |
Action Item را وارد Backlog واقعی کنید؛ فایلی که بعد از جلسه خوانده نشود یادگیری سازمانی تولید نمیکند.
چه چیزهایی را آرشیو کنیم؟
- نسخه نهایی Test Plan، دامنه و معیارهای خروج
- تستکیسها، اسکریپتها و نسخه چارچوب اتوماسیون
- Test Runها، شواهد منتخب و محدودیتها
- فهرست باگها، Resolutionها و Accepted Riskها
- پیکربندی محیط و شناسه Build؛ نه الزاماً کل محیط
- داده مصنوعی قابلبازتولید و روش ساخت آن
- Test Summary Report، Sign-off و Action Itemها
رمزها، توکنها، داده مشتری و پیوستهای دارای اطلاعات شخصی را وارد آرشیو عمومی نکنید. مدت نگهداری بر اساس الزام حقوقی/قراردادی و ارزش بازاستفاده تعیین شود. دسترسی و حذف باید قابلحسابرسی باشند.
Test Closure در Agile و تحویل پیوسته
در Agile لازم نیست تا پایان پروژه صبر کنید. یک بستهشدن سبک میتواند در پایان Sprint یا Release شامل خلاصه ریسک، تستهای انجامنشده، باگهای منتقلشده و یک Action Item باشد. در تحویل پیوسته، بخشی از گزارش خودکار میشود: نسخه، نتیجه pipeline، پوشش مسیرها و باگهای Release. اما تفسیر ریسک و پذیرش استثنا همچنان تصمیم انسانی است.
برای تغییرهای کوچک از گزارش یکصفحهای یا رکورد Release استفاده کنید؛ برای مهاجرت مالی، تغییر احراز هویت یا Release تحت حسابرسی جزئیات بیشتری لازم است. اندازه گزارش را با ریسک تنظیم کنید، نه با قالب ثابت.
اشتباهات رایج در Test Cycle Closure
- گزارش فقط درصد Pass: شکافهای بحرانی و تغییر دامنه را پنهان میکند.
- نوشتن گزارش در لحظه آخر: دادهها ناقص و تصمیمها فراموش میشوند.
- توصیه مبهم «آماده انتشار»: ریسک و شرایط تصمیم معلوم نیست.
- مخلوط کردن چند بیلد: اعتبار نتیجه از بین میرود.
- بستن باگ برای تمیز شدن داشبورد: تاریخچه و ریسک واقعی مخدوش میشود.
- جلسه درسآموخته بدون Action Item: مشکلات در چرخه بعد تکرار میشوند.
- آرشیو همهچیز برای همیشه: هزینه و ریسک حریم خصوصی میسازد.
- Sign-off اجباری QA: مسئولیت تصمیم کسبوکار را به نقش نامناسب منتقل میکند.
چکلیست بستهشدن چرخه تست
- Release، Build، محیط و Cut-off گزارش مشخص است.
- دامنه برنامهریزیشده با دامنه واقعی تطبیق داده شده است.
- وضعیت تستهای اجراشده، Blocked و Not Run پاکسازی شده است.
- هر معیار خروج شاهد یا انحراف مصوب دارد.
- باگهای باز با اثر، مالک و نسخه هدف مرور شدهاند.
- ریسک باقیمانده به زبان کسبوکار نوشته شده است.
- گزارش خلاصه، محدودیت و گزینه تصمیم را نشان میدهد.
- Sign-off نسخه، استثنا و صاحب اختیار دارد.
- درسآموختهها به اقدام، مالک و معیار موفقیت تبدیل شدهاند.
- مصنوعات طبق سیاست نگهداری آرشیو و داده حساس پاکسازی شده است.
سؤالات متداول بستهشدن چرخه تست
آیا بستهشدن تست یعنی نرمافزار بدون باگ است؟
خیر. یعنی دامنه و نتایج مشخص جمعبندی شده، شکافها و باگهای شناختهشده شفافاند و درباره گام بعدی تصمیم گرفته شده است. نرمافزار بدون ریسک تضمین نمیشود.
Test Summary Report را چه کسی مینویسد؟
معمولاً Test Lead یا مسئول QA دادهها را گردآوری و تفسیر میکند، اما ورودی توسعه، محصول، عملیات و امنیت برای اثر و تصمیم لازم است. تأیید نهایی مطابق نقشهای Release انجام میشود.
اگر معیار خروج محقق نشده باشد، چرخه را نمیتوان بست؟
میتوان وضعیت را با انحراف بست، اگر تصمیمگیر مجاز ریسک را با دلیل، کنترل، مالک و موعد پذیرفته باشد. پنهان کردن عدم تحقق یا تغییر معیار در پایان کار حرفهای نیست.
تفاوت Test Closure Report و Test Summary Report چیست؟
در بسیاری از تیمها این اصطلاحها به یک سند اشاره میکنند. اگر جدا باشند، Summary روی نتیجه و ریسک Release تمرکز دارد و Closure علاوه بر آن آرشیو، Sign-off و درسآموختهها را ثبت میکند. تعریف تیم باید روشن باشد.
در Scrum هم به فاز ششم STLC نیاز داریم؟
بله، اما سبک و تکرارشونده. در پایان Sprint یا Release، نتایج، ریسک منتقلشده و اقدام بهبود ثبت میشود. لازم نیست یک گزارش سنگین برای هر تغییر کوچک تولید شود.
جمعبندی
بستهشدن چرخه تست زمانی ارزش دارد که داده اجرا را به تصمیم، ریسک را به مسئولیت و تجربه را به اقدام تبدیل کند. درصدها را با دامنه و اثر توضیح دهید، معیارهای خروج را تغییر ندهید، استثنا را صاحبدار کنید و درسآموخته را وارد Backlog واقعی کنید. گزارش نهایی خوب نه جشن Passهاست و نه فهرست ترسها؛ تصویر صادقانهای است که تصمیم امروز و کیفیت چرخه بعد را بهتر میکند.
