فاز اجرای تست جایی نیست که تستر فقط مقابل یک فهرست، علامت Pass یا Fail بزند. اینجا باید از هر اجرا شاهد قابلاعتماد بسازیم: چه نسخهای، در کدام محیط، با چه دادهای، توسط چه کسی یا چه پایپلاینی اجرا شد و نتیجه دقیقاً چه بود. اگر این زمینه ثبت نشود، حتی صدها تست اجراشده هم برای تصمیم انتشار ارزش کمی دارند.
پاسخ کوتاه: اجرای تست (Test Execution) فاز پنجم STLC است؛ تیم، تستکیسهای اولویتبندیشده را روی بیلد آماده اجرا میکند، نتیجه واقعی را با انتظار مقایسه میکند، شواهد را ثبت میکند، مغایرتها را triage و در صورت تأیید بهعنوان باگ گزارش میکند، اصلاحها را دوباره میآزماید و ریسک باقیمانده را برای تصمیم انتشار گزارش میدهد.
خروجی کلیدی این فاز: لاگ اجرای قابلردیابی، وضعیت تستها، گزارش باگهای قابلبازتولید، نتیجه Retest و Regression، شاخصهای روند و تصویری شفاف از ریسکهای حلشده و باز.
فاز اجرای تست در STLC چیست؟
در چرخه حیات تست نرمافزار (STLC)، تحلیل نیازمندی، برنامهریزی، طراحی تستکیس و آمادهسازی محیط پیش از اجرا قرار میگیرند. در فاز پنجم، فرضیهها و طراحیهای قبلی با رفتار واقعی نرمافزار روبهرو میشوند. هدف فقط پیدا کردن باگ نیست؛ تیم باید شواهدی فراهم کند که نشان دهد چه چیزی آزموده شده، چه چیزی هنوز آزموده نشده و انتشار چه ریسکهایی دارد.
اجرای تست میتواند دستی، خودکار یا ترکیبی باشد. تستر انسانی برای مشاهده، قضاوت، اکتشاف و بررسی تجربه کاربر ارزش دارد؛ خودکارسازی برای بازخورد سریع و تکرار پایدار مناسب است. هیچکدام ذاتاً جای دیگری را نمیگیرد.
مرز فاز اجرا با بستهشدن چرخه تست
در اجرا، نتیجهها جمعآوری و ریسکها پیگیری میشوند. تحلیل نهایی تحقق اهداف، گزارش جمعبندی، بایگانی داراییها و درسآموختهها متعلق به فاز بستهشدن چرخه تست است. این تفکیک کمک میکند گزارش روزانه اجرا با گزارش مدیریتی پایان چرخه اشتباه نشود.
معیارهای ورود به فاز اجرای تست
شروع زودهنگام روی بیلد ناپایدار، محیط ناقص یا تستکیس مبهم معمولاً زمان تیم را صرف تشخیص مشکل آزمایشگاه میکند. پیش از شروع، معیارهای ورود مصوب در Test Plan را کنترل کنید:
- بیلد قابلشناسایی: شماره نسخه، commit یا بسته انتشار ثبت و نصب شده است.
- Smoke Test اولیه: مسیرهای پایه آنقدر سالماند که اجرای عمیقتر معنا داشته باشد.
- محیط آماده: سرویسها، نسخهها، تنظیمات، دسترسیها و مانیتورینگ بررسی شدهاند. از چکلیست راهاندازی محیط تست میتوان برای کنترل این بخش استفاده کرد.
- داده تست معتبر: پیششرط داده، حسابها، نقشها و سیاست پاکسازی مشخص است؛ اطلاعات واقعی حساس بدون مجوز استفاده نمیشود.
- تستکیس بازبینیشده: انتظار، پیششرط و داده قابلفهماند. راهنمای نوشتن تستکیس حرفهای قالب و معیارهای آن را توضیح میدهد.
- دامنه و اولویت روشن: معلوم است کدام سناریوها برای این بیلد، مرورگر، دستگاه یا نقش کاربری داخل محدودهاند.
- مسیر گزارش و triage آماده: ابزار، وضعیتها، مسئول بررسی و زمان جلسه رفع ابهام مشخصاند.
معیار ورود به معنی انتظار برای «بیلد بینقص» نیست. تیم میتواند با پذیرش آگاهانه یک محدودیت شروع کند، به شرط آنکه اثر آن بر پوشش و اعتبار نتیجه ثبت شود.
تستها را با چه ترتیبی اجرا کنیم؟
وقتی زمان محدود است، ترتیب اجرا باید بیشترین اطلاعات را درباره بزرگترین ریسک بدهد. یک توالی عملی میتواند چنین باشد:
- Build Verification یا Smoke: نصب، ورود، دسترسی به سرویسهای پایه و مسیر اصلی را سریع بررسی کنید.
- سناریوهای بحرانی کسبوکار: پرداخت، ثبت سفارش، بازیابی حساب یا هر مسیری که شکست آن خسارت بیشتری دارد.
- تغییرهای همین بیلد: تستهای مستقیم قابلیت جدید و نواحی اثرپذیر از کد.
- رفع باگها: Retest اصلاحهای اعلامشده و سپس Regression متناسب با شعاع اثر.
- پوشش گستردهتر: حالتهای منفی، مرزی، سازگاری، اکتشافی و مجموعههای کمریسکتر.
اولویت فقط Severity احتمالی نیست. احتمال شکست، تعداد کاربر متاثر، قابلیت کشف در تولید، امکان بازگشت نسخه، تعهد قراردادی و هزینه جبران هم باید وارد تصمیم شوند.
فرآیند گامبهگام اجرای تست
۱. بیلد و خط مبنا را ثبت کنید
در ابتدای Test Run، نسخه برنامه، نسخه API و پایگاه داده، محیط، مرورگر یا دستگاه، فلگهای قابلیت، منبع داده و زمان شروع را ثبت کنید. اگر در میانه اجرا بیلد عوض شد، نتیجههای دو نسخه را در یک Run مخلوط نکنید یا دستکم مرز تغییر را کاملاً مشخص کنید.
۲. پیششرط را بدون آلوده کردن نتیجه آماده کنید
حساب کاربری، نقش، سبد، سفارش یا وضعیت داده باید دقیقاً مطابق تستکیس باشد. دادهای که از اجرای قبلی باقی مانده میتواند هم False Pass بسازد و هم False Fail. در تست خودکار، setup و teardown قابلاعتماد بخشی از خود تستاند.
۳. تست را اجرا و فراتر از نتیجه نهایی مشاهده کنید
گامها را انجام دهید، اما فقط آخرین صفحه را نبینید. پیامها، تغییر وضعیت، درخواست شبکه، لاگ، اعلان، ایمیل یا پیامک و اثر روی داده را هم مطابق هدف تست بررسی کنید. در تست اکتشافی، مسیر و مشاهدات مهم را یادداشت کنید تا یافته قابلبازتولید بماند.
۴. نتیجه واقعی را با اوراکل تست مقایسه کنید
اوراکل میتواند نیازمندی، قانون کسبوکار، معیار پذیرش، نمونه محاسبهشده، قرارداد API یا رفتار نسخه مرجع باشد. اگر انتظار مبهم یا متناقض است، تست را بهزور Pass/Fail نکنید؛ ابهام را ثبت و از مالک تصمیم روشنسازی بگیرید.
۵. وضعیت و شواهد اجرا را ثبت کنید
هر نتیجه باید حداقل به تستکیس، Run، نسخه و محیط وصل باشد. وضعیتهای رایج عبارتاند از:
| وضعیت | معنی عملی | چه چیزی ثبت شود؟ |
|---|---|---|
| Pass | نتیجه مشاهدهشده با انتظار این اجرا تطابق دارد | نسخه، محیط و در صورت نیاز شاهد کلیدی |
| Fail | مغایرت دیده شده و نیازمند بررسی است | گام شکست، نتیجه واقعی، شواهد و لینک triage/باگ |
| Blocked | پیششرط، محیط یا وابستگی مانع اجراست | مانع، مالک رفع و اثر بر پوشش |
| Not Run | هنوز اجرا نشده است | علت باقیماندن در دامنه یا برنامه اجرا |
| Skipped / N/A | با تصمیم مستند اجرا نمیشود یا مصداق ندارد | دلیل و تأییدکننده تصمیم |
نام وضعیتها ممکن است در ابزار شما فرق کند؛ تعریف مشترک مهمتر از نام است. همچنین Pass فقط درباره همان نسخه، شرایط و داده ادعا میکند و اثبات نمیکند نرمافزار در همه حالتها بینقص است.
۶. پیش از ثبت باگ، Fail را triage کنید
هر Fail لزوماً باگ محصول نیست. علت میتواند تستکیس قدیمی، داده نامعتبر، محیط خراب، انتظار اشتباه، اسکریپت ناپایدار یا نقص واقعی باشد. یک triage کوتاه این پرسشها را پاسخ میدهد:
- آیا روی بیلد و داده تمیز قابلبازتولید است؟
- آیا انتظار با آخرین نیازمندی و تصمیم محصول سازگار است؟
- آیا مشکل از سرویس وابسته، شبکه یا تنظیمات محیط است؟
- آیا همین نشانه قبلاً گزارش شده و Duplicate است؟
- اثر روی کاربر، داده و مسیرهای دیگر چیست؟
اگر نقص محصول تأیید شد، گزارش باگ باید برای نفر دیگری قابلبازتولید و تصمیمپذیر باشد. مقاله فرآیند ثبت و ردیابی باگ جزئیات چرخه، وضعیتها و فیلدهای گزارش را پوشش میدهد.
۷. Retest و Regression را جدا انجام دهید
Retest همان سناریوی شکستخورده را پس از اصلاح تکرار میکند تا رفع مشخص تایید شود. Regression Testing بررسی میکند تغییر، رفتارهای سالم دیگر را خراب نکرده باشد. مثلاً پس از اصلاح گرد کردن تخفیف، ابتدا همان محاسبه Retest میشود؛ سپس سناریوهای مالیات، مرجوعی، چند کالا و درگاههای مختلف بر اساس شعاع اثر Regression میشوند.
اگر اصلاح قابل تایید نبود، با شواهد تازه Reopen کنید؛ اگر باگ برطرف شده اما یک مشکل متفاوت دیده شد، بهتر است گزارش جداگانه بسازید تا تاریخچه و مسئولیتها مخلوط نشوند.
۸. وضعیت و ریسک را در طول اجرا بهروز کنید
گزارش روزانه باید کوتاه و تصمیمپذیر باشد: چه دامنهای اجرا شد، چه چیزی مانده، کدام مانع پوشش را کم کرده، چه باگهای مهمی بازند، روند نسبت به روز قبل چیست و چه تصمیمی لازم است. فهرست خام همه تستها را میتوان در ابزار نگه داشت؛ گزارش وضعیت باید معنای آن فهرست را توضیح دهد.
نمونه عملی اجرای تست و ثبت نقص
سناریوی یک فروشگاه ایرانی را در نظر بگیرید: «کاربر یک کالای ۸۰۰ هزار تومانی و یک کد تخفیف معتبر دارد؛ سقف تخفیف طبق قانون ۱۰۰ هزار تومان است.»
- تستر بیلد، محیط، شناسه کالا و کد تخفیف را ثبت میکند.
- کالا را به سبد میافزاید و کد را اعمال میکند.
- نتیجه مورد انتظار: تخفیف از سقف مجاز عبور نکند و مبلغ نهایی در سبد، سفارش و درگاه یکسان باشد.
- نتیجه واقعی: سبد ۱۲۰ هزار تومان تخفیف میدهد، اما درگاه مبلغ دیگری نشان میدهد.
- تستر روی داده تازه و نقش کاربر دیگر بازتولید، درخواست شبکه و شناسه سفارش را ذخیره و Fail را triage میکند.
- گزارش تاییدشده با عنوان «عبور تخفیف درصدی از سقف و مغایرت مبلغ سبد با درگاه» ثبت میشود؛ اثر مالی و دامنه نسخه مشخص میشود.
- پس از اصلاح، همان سفارش Retest و سپس کدهای ثابت، درصدی، منقضی و مرجوعی Regression میشوند.
این گزارش بسیار مفیدتر از «کد تخفیف کار نمیکند» است، زیرا شرایط، قانون نقضشده، اثر و مسیر بررسی را روشن میکند.
اجرای دستی یا خودکار؟
| رویکرد | مناسبتر برای | ریسک اصلی |
|---|---|---|
| دستی | اکتشافی، کاربردپذیری، قابلیت تازه و قضاوت بصری/زمینهای | تکرار کند، تفاوت اجرا و ثبت ناقص شاهد |
| خودکار | رگرسیون پرتکرار، کنترل قرارداد، دادههای متعدد و بازخورد CI | Flaky Test، انتظار ضعیف و هزینه نگهداری |
| ترکیبی | اکثر محصولات در حال توسعه | نبود مرز روشن و اجرای تکراری بدون ارزش |
یک مسیر منطقی این است که انسان قابلیت تازه را بیاموزد و ریسکها را کشف کند؛ سپس سناریوهای پایدار، پرتکرار و ارزشمند برای بازخورد سریع خودکار شوند. مقاله نقشه راه شروع تست خودکار معیار انتخاب و مراحل ساخت این توانمندی را توضیح میدهد.
با تست خودکار ناپایدار چه کنیم؟
تست Flaky بدون تغییر واقعی محصول گاهی Pass و گاهی Fail میشود. تکرار خودکار تا سبز شدن، خطا را پنهان و اعتماد تیم را تخریب میکند. نتیجه را قرنطینه کنید، نرخ ناپایداری را بسنجید، علتهایی مانند زمانبندی، داده مشترک، وابستگی بیرونی و selector شکننده را اصلاح کنید و مالک و موعد بازگشت به مجموعه اصلی داشته باشید.
معیارهای مفید برای پایش اجرای تست
- پیشرفت اجرا: تعداد تستهای اجراشده نسبت به دامنه برنامهریزیشده؛ تغییر دامنه را جدا نشان دهید.
- Pass Rate: تستهای موفق نسبت به اجراشدهها؛ بهتنهایی شاخص کیفیت محصول نیست.
- Blocked Rate: سهم تستهایی که محیط، داده یا وابستگی مانعشان شده است.
- پوشش ریسک: چه درصدی از ریسکهای بحرانی شواهد کافی دارند؟
- روند باگهای باز: تعداد و سن باگها به تفکیک شدت، مؤلفه و وضعیت.
- نرخ Reopen: میتواند ضعف اصلاح، ابهام معیار یا Retest ناکافی را نشان دهد و باید علتیابی شود.
- پایداری اتوماسیون: نرخ Flaky، مدت اجرا و زمان بازخورد مجموعههای خودکار.
تعداد باگ پیداشده معیار بهرهوری تستر نیست. یک عدد بالا ممکن است محصول ناپایدار یا گزارشهای تکراری را نشان دهد؛ عدد پایین هم میتواند حاصل کیفیت خوب، پوشش کم یا تست ضعیف باشد. معیار را همیشه کنار دامنه، روند و ریسک تفسیر کنید.
معیارهای خروج از فاز اجرا
«همه تستها Pass شدند» معمولاً نه عملی است و نه معیار کافی. معیار خروج باید پیشتر توافق شده و ریسکمحور باشد. نمونهها:
- تمام سناریوهای بحرانی اجرا شده و شاهد معتبر دارند.
- هیچ نقص بحرانی حلنشدهای باقی نمانده، یا استثنا با مالک و برنامه کاهش ریسک پذیرفته شده است.
- درصد اجرای دامنه و پوشش نیازمندی/ریسک به آستانه مصوب رسیده است.
- باگهای مهم Retest و Regression متناسب انجام شدهاند.
- Blockedهای باقیمانده و اثر آنها بر تصمیم انتشار شفاف است.
- نتایج، شواهد، نسخه و محدودیتها برای گزارش پایان چرخه آمادهاند.
اگر موعد انتشار رسیده ولی معیار خروج محقق نشده است، QA نباید «کیفیت را تایید» یا انتشار را یکنفره متوقف کند. نقش حرفهای تیم، ارائه شواهد، شدت ریسک، گزینههای کاهش و پیامد هر تصمیم به صاحبان اختیار است.
چالشهای رایج و راهحل سریع
| چالش | نشانه | اقدام عملی |
|---|---|---|
| محیط ناپایدار | Failهای غیرقابلبازتولید و Blocked زیاد | Health Check، مالک محیط و ثبت تغییرات |
| داده مشترک | نتیجه وابسته به ترتیب اجرا | داده مستقل، seed کنترلشده و پاکسازی |
| نیازمندی مبهم | بحث طولانی درباره انتظار | ثبت سؤال و تصمیم با مالک محصول |
| فشار زمانی | حذف تصادفی تستها | اولویتبندی ریسک و اعلام پوشش ازدسترفته |
| باگهای تکراری | چند گزارش برای یک علت | جستوجو، لینککردن نشانهها و triage منظم |
| اتوماسیون Flaky | Retry تا سبز شدن | قرنطینه، علتیابی و SLA اصلاح |
چکلیست فاز اجرای تست
- بیلد، محیط، داده و محدوده Run ثبت شدهاند.
- Smoke Test پیش از اجرای گسترده انجام شده است.
- تستها بر اساس ریسک و تغییر اولویت دارند.
- برای هر نتیجه، وضعیت و شاهد متناسب ثبت میشود.
- Fail پیش از گزارش باگ triage میشود.
- Blockedها مالک، علت و اثر پوشش دارند.
- Retest با Regression اشتباه نمیشود.
- تستهای Flaky پنهان یا بینهایت Retry نمیشوند.
- گزارش روزانه روند، ریسک و تصمیم لازم را نشان میدهد.
- معیارهای خروج پیش از پایان زمان ارزیابی میشوند.
سؤالات متداول اجرای تست
آیا هر تست Fail شده یک باگ است؟
خیر. Fail یعنی نتیجه مشاهدهشده با انتظار اجرا همخوان نیست. پیش از ثبت باگ باید احتمال مشکل محیط، داده، تستکیس، انتظار یا اسکریپت بررسی شود. پس از triage ممکن است نقص محصول، نقص تست یا مانع محیطی ثبت شود.
تفاوت Retest و Regression چیست؟
Retest رفع همان نقص مشخص را تایید میکند؛ Regression بررسی میکند تغییر انجامشده رفتارهای سالم مرتبط را خراب نکرده باشد. معمولاً ابتدا Retest و سپس رگرسیون متناسب با شعاع اثر اجرا میشود.
برای یک تست Pass هم باید اسکرینشات بگیریم؟
نه برای همه تستها. سطح شاهد باید با ریسک، الزام حسابرسی و هزینه نگهداری متناسب باشد. اتصال نتیجه به نسخه و محیط ضروری است؛ اسکرینشات یا لاگ کامل را برای سناریوهای بحرانی، قراردادها یا مواردی که بازسازی آن دشوار است نگه دارید.
اگر زمان برای اجرای همه تستها نباشد چه کنیم؟
دامنه را بر اساس ریسک، تغییر و مسیرهای پرتکرار اولویتبندی کنید. مهمتر از افزایش مصنوعی Pass Rate، ثبت شفاف تستهای اجرانشده و اثر آنها بر ریسک انتشار است.
چه کسی نتیجه نهایی انتشار را میگیرد؟
ساختار سازمان متفاوت است، اما QA باید شواهد و ریسک را ارائه کند؛ مالک محصول یا مرجع تعیینشده در فرایند انتشار، با مشارکت فنی و کسبوکار تصمیم میگیرد. استثناها باید مستند، زماندار و دارای مالک باشند.
جمعبندی
اجرای تست زمانی ارزشمند است که از «انجام گامها» به «تولید شواهد برای تصمیم» تبدیل شود. بیلد و محیط را ثبت کنید، تستهای پرریسک را جلو بیندازید، Fail را triage کنید، Retest و Regression را جدا نگه دارید و بهجای اعداد تزئینی، ریسک و محدودیت پوشش را گزارش دهید. نتیجه خوب فاز پنجم، محصول بیادعا و بدون باگ نیست؛ تصویری صادقانه و قابلردیابی از آمادگی انتشار است.
