چرخه عمر باگ (Bug Life Cycle) مسیری است که یک باگ از لحظه کشف تا بسته شدن طی میکند. وقتی این مسیر روشن باشد، هیچ باگی گم نمیشود و همه میدانند نوبت چه کسی است. در این راهنما مراحل چرخه عمر باگ، تفاوت شدت و اولویت و ساختار یک گزارش باگ خوب را با نمونه مرور میکنیم.
این مقاله بخشی از مجموعه آموزشی ماست. برای شروع از پایه، راهنمای تست نرمافزار چیست را ببینید.
باگ چیست و چرا چرخه عمر لازم دارد
باگ یعنی تفاوت بین رفتار واقعی نرمافزار و رفتار مورد انتظار آن. رفتار مورد انتظار از نیازمندی، معیار پذیرش، طراحی یا انتظار منطقی کاربر میآید.
خطا، نقص و شکست
در ادبیات تست سه واژه نزدیک به هم وجود دارد:
- خطا (Error): اشتباه انسانی؛ مثلاً برنامهنویس شرط را برعکس نوشته است.
- نقص (Defect): نتیجه آن اشتباه در کد یا مستند؛ همان چیزی که معمولاً باگ مینامیم.
- شکست (Failure): وقتی نقص اجرا میشود و رفتار نادرست دیده میشود.
در کار روزمره این تفاوتها کمتر رعایت میشوند. اما دانستنشان کمک میکند بفهمید چرا برخی نقصها تا مدتها دیده نمیشوند. نقصی که در مسیر کماستفاده است، شاید دیر به شکست تبدیل شود.
چرا به یک چرخه مشخص نیاز داریم
در تیم کوچک شاید یک پیام کوتاه برای رفع باگ کافی باشد. با بزرگ شدن تیم، این روش جواب نمیدهد. چرخه عمر مشخص این مزیتها را دارد:
- مالک هر باگ در هر لحظه روشن است.
- هیچ باگی بدون تصمیم رها نمیشود.
- وضعیت کیفیت نسخه قابل گزارش است.
- زمان رفع و بازگشایی باگها قابل اندازهگیری است.
مراحل چرخه عمر باگ
نام وضعیتها در ابزارهای مختلف کمی فرق دارد. اما منطق کلی تقریباً ثابت است.
جدید (New)
تستر باگ را پیدا میکند و گزارش آن را ثبت میکند. در این مرحله هنوز کسی آن را بررسی نکرده است.
تخصیصیافته (Assigned)
راهبر فنی یا جلسه تریاژ باگ را بررسی میکند. اگر معتبر باشد، شدت و اولویت نهایی مشخص میشود و به یک توسعهدهنده سپرده میشود.
در حال رفع (In Progress)
توسعهدهنده باگ را بازتولید میکند، علت را پیدا میکند و اصلاح را انجام میدهد.
رفعشده (Fixed)
اصلاح انجام شده و در یک بیلد قابل تست قرار گرفته است. شماره بیلد یا نسخه باید در باگ ثبت شود.
در انتظار تست مجدد (Ready for Retest)
باگ به تستر برمیگردد. تستر روی همان بیلد، مراحل گزارش را دوباره اجرا میکند.
بسته (Closed)
اگر رفتار درست باشد، تستر باگ را میبندد. بهتر است پیش از بستن، رگرسیون کوتاهی هم روی ناحیه اطراف اجرا شود. جزئیات این کار را در تست رگرسیون توضیح دادهایم.
بازگشایی (Reopened)
اگر مشکل هنوز وجود داشته باشد، باگ دوباره باز میشود و به توسعهدهنده برمیگردد. در یادداشت بازگشایی دقیق بنویسید چه چیزی هنوز درست کار نمیکند.
وضعیتهای جانبی
همه باگها مسیر اصلی را طی نمیکنند. این وضعیتها هم رایجاند:
- ردشده (Rejected): رفتار گزارششده مطابق طراحی است یا باگ محسوب نمیشود.
- تکراری (Duplicate): همین مشکل قبلاً ثبت شده است. باید به باگ اصلی پیوند داده شود.
- به تعویق افتاده (Deferred): باگ معتبر است اما رفع آن به نسخه بعدی منتقل میشود.
- قابل بازتولید نیست (Cannot Reproduce): توسعهدهنده نتوانسته مشکل را تکرار کند.
جدول خلاصه وضعیتها
| وضعیت | مالک | معنی | وضعیت بعدی رایج |
|---|---|---|---|
| جدید | تستر | باگ ثبت شده و منتظر بررسی است | تخصیصیافته، ردشده، تکراری |
| تخصیصیافته | راهبر فنی | باگ معتبر است و مسئول دارد | در حال رفع، به تعویق افتاده |
| در حال رفع | توسعهدهنده | اصلاح در جریان است | رفعشده، قابل بازتولید نیست |
| رفعشده | توسعهدهنده | اصلاح در بیلد قابل تست است | در انتظار تست مجدد |
| در انتظار تست مجدد | تستر | باید دوباره بررسی شود | بسته، بازگشایی |
| بازگشایی | توسعهدهنده | مشکل هنوز وجود دارد | در حال رفع |
| بسته | — | رفع تأیید شده است | بازگشایی در صورت بروز دوباره |
این جریان را در ابزار ردیابی باگ پیاده کنید. هر گذار بین وضعیتها باید مالک مشخص داشته باشد.
شدت و اولویت باگ
دو فیلد مهم در هر گزارش باگ، شدت و اولویت هستند. این دو اغلب با هم اشتباه گرفته میشوند.
- شدت باگ (Severity): میزان اثر فنی باگ بر سیستم. معمولاً تستر آن را پیشنهاد میدهد.
- اولویت باگ (Priority): فوریت رفع از نگاه کسبوکار. معمولاً مدیر محصول یا جلسه تریاژ تعیین میکند.
ترکیبهای رایج با مثال
| شدت | اولویت | مثال |
|---|---|---|
| بالا | بالا | پرداخت برای همه کاربران شکست میخورد. |
| بالا | پایین | گزارش سالانهای که فقط آخر سال استفاده میشود، در حالت خاصی از کار میافتد. |
| پایین | بالا | نام شرکت در صفحه اصلی غلط املایی دارد. |
| پایین | پایین | فاصله یک آیکون در صفحه تنظیمات کمی نامرتب است. |
سطحهای شدت معمولاً اینها هستند: بحرانی (Critical)، بالا (Major)، متوسط (Minor) و جزئی (Trivial). تعریف هر سطح را با مثالهای محصول خودتان مستند کنید. بدون این تعریف، هر نفر سلیقهای انتخاب میکند.
اجزای یک گزارش باگ خوب
گزارش باگ خوب باید بدون گفتگوی اضافه قابل فهم و بازتولید باشد. این اجزا را در آن بیاورید:
- عنوان کوتاه و دقیق: محل مشکل و رفتار نادرست را بگوید. مثلاً «سبد خرید: حذف آخرین کالا، مبلغ کل را صفر نمیکند».
- محیط: نسخه یا بیلد، مرورگر یا دستگاه، سیستمعامل و محیط تست.
- پیششرطها: نوع کاربر، داده لازم و تنظیمات خاص.
- مراحل بازتولید: شمارهدار، کوتاه و بدون مرحله اضافه.
- نتیجه مورد انتظار: بر اساس نیازمندی یا معیار پذیرش.
- نتیجه واقعی: دقیقاً چه اتفاقی افتاد، همراه متن پیام خطا.
- پیوستها: تصویر، ویدئوی کوتاه، لاگ کنسول یا پاسخ API.
- شدت و اولویت پیشنهادی: با توجه به تعریفهای تیم.
- تکرارپذیری: همیشه، گاهی یا یک بار.
- ارجاع: شماره تستکیس، نیازمندی یا داستان کاربری مرتبط.
اگر تستکیسها خوب نوشته شده باشند، بخش زیادی از گزارش باگ از آنها قابل برداشت است. راهنمای نوشتن تستکیس را برای این بخش ببینید.
نمونه گزارش باگ
عنوان: سبد خرید – حذف آخرین کالا، مبلغ کل را صفر نمیکند
محیط: وب، بیلد 4.12.0، کروم نسخه پایدار، محیط Staging
پیششرط: کاربر وارد حساب شده و یک کالا در سبد دارد
مراحل:
1. به صفحه سبد خرید بروید.
2. روی «حذف» کنار تنها کالای سبد بزنید.
نتیجه مورد انتظار: سبد خالی شود و مبلغ کل صفر نمایش داده شود.
نتیجه واقعی: سبد خالی میشود اما مبلغ کل همان مبلغ قبلی است.
تکرارپذیری: همیشه
شدت پیشنهادی: متوسط
اولویت پیشنهادی: بالا
پیوست: ویدئوی ۱۵ ثانیهای، پاسخ API سبد خرید
ارجاع: تستکیس C1043
اشتباهات رایج در گزارش باگ
این اشتباهها زمان رفع را طولانی میکنند:
- عنوان مبهم: «صفحه خراب است» یا «کار نمیکند» هیچ اطلاعاتی نمیدهد.
- چند مشکل در یک گزارش: هر مشکل را جدا ثبت کنید تا وضعیت هرکدام مستقل پیگیری شود.
- حذف محیط و نسخه: بسیاری از باگها فقط در یک مرورگر یا نسخه رخ میدهند.
- نظر شخصی بهجای واقعیت: بنویسید چه دیدید، نه اینکه فکر میکنید علت چیست. البته حدس فنی مستند در بخش جداگانه مفید است.
- لحن سرزنشآمیز: گزارش باگ درباره محصول است، نه درباره افراد.
- بدون جستوجوی قبلی: پیش از ثبت، باگهای باز را جستوجو کنید تا تکراری ثبت نشود.
گزارش باگ برای مشکلات متناوب
برای باگی که گاهی رخ میدهد، هر اطلاعاتی را که دارید ثبت کنید. زمان دقیق وقوع، شناسه درخواست، لاگ سرور و تعداد دفعات تلاش کمک میکنند. بنویسید در چند بار تلاش، چند بار مشکل دیده شد.
قواعد تیمی برای مدیریت باگ
چرخه عمر باگ بدون توافق تیمی فقط یک نمودار است. این قواعد آن را عملی میکنند.
جلسه تریاژ
یک جلسه کوتاه و منظم برای بررسی باگهای جدید برگزار کنید. در این جلسه معتبر بودن، شدت، اولویت و مالک هر باگ مشخص میشود. حضور نماینده تست، توسعه و محصول کافی است.
زمان پاسخ بر اساس اولویت
برای هر سطح اولویت، زمان پاسخ و رفع مورد انتظار را تعریف کنید. مثلاً باگهای اولویت بالا در همان روز بررسی شوند. این عددها را خود تیم بر اساس ظرفیتش تعیین کند.
مدیریت باگهای به تعویق افتاده
باگهای به تعویق افتاده بهمرور زیاد میشوند. اگر مرور نشوند، فهرستی طولانی و بیاستفاده میسازند. در شروع هر نسخه، این باگها را مرور کنید. بعضی دیگر معتبر نیستند و بسته میشوند. بعضی به دلیل تغییر شرایط، اولویت بالاتری پیدا کردهاند.
تعریف روشن برای بستن باگ
مشخص کنید چه کسی اجازه بستن باگ را دارد. در بیشتر تیمها فقط تستر یا گزارشدهنده باگ را میبندد. توسعهدهنده باگ را «رفعشده» علامت میزند، نه «بسته».
معیار انتشار
در طرح تست بنویسید با چه وضعیتی از باگها انتشار مجاز است. مثلاً «هیچ باگ باز بحرانی وجود نداشته باشد».
از باگ تا بهبود فرایند
هر باگ دادهای درباره فرایند توسعه است. تحلیل دورهای باگها کمک میکند ریشهها را پیدا کنید.
تحلیل ریشهای
برای باگهای مهم، علت ریشهای را ثبت کنید. آیا نیازمندی مبهم بود، طراحی ناقص بود یا تست آن سناریو وجود نداشت. این بحث به تفاوت نگاه پیشگیرانه و کشفی برمیگردد که در تفاوت QA و QC توضیح دادهایم.
شاخصهای مرتبط با باگ
- تعداد باگهای باز بر اساس شدت
- میانگین زمان رفع
- نرخ بازگشایی باگها
- باگهایی که به محیط عملیاتی رسیدند
فرمول و تفسیر این شاخصها را در معیارهای تست و گزارش کیفیت آوردهایم.
در TestRail وقتی نتیجه یک تست را Failed ثبت میکنید، میتوانید همانجا شناسه باگ را در فیلد Defects وارد کنید. با اتصال به Jira حتی میتوانید باگ را مستقیم از صفحه نتیجه در Jira بسازید و مراحل تست و نتیجه واقعی را به آن منتقل کنید. بعد از رفع، اجرای دوباره تست با وضعیت Retest یا Passed ثبت میشود و گزارشهای باگ نشان میدهند هر باگ به کدام تستها مرتبط است. برای جزئیات اتصال به ابزارهای ردیابی باگ، صفحه یکپارچهسازیهای TestRail را ببینید.
جمعبندی
چرخه عمر باگ مسیر یک باگ را از کشف تا بستن شفاف میکند. وضعیتها و مالک هر وضعیت را روشن تعریف کنید. شدت را از اولویت جدا نگه دارید و هر دو را با مثالهای محصول خودتان مستند کنید. گزارش باگ خوب عنوان دقیق، محیط، مراحل بازتولید و نتیجه مورد انتظار و واقعی دارد. با تریاژ منظم و تحلیل ریشهای، باگها به ورودی بهبود فرایند تبدیل میشوند. برای مرور مفاهیم پایه، به راهنمای تست نرمافزار برگردید.