باگی که ثبت شده اما مالک ندارد، باگی که «Fixed» است ولی روی بیلد قابلآزمایش قرار نگرفته، و باگی که ماهها در وضعیت «بعداً» مانده، هر سه یک مشکل فرایندیاند. چرخه عمر باگ (Bug Life Cycle) فقط مجموعهای از برچسبها نیست؛ قرارداد کاری تیم برای تبدیل یک مشاهده به تصمیم، اصلاح، تأیید یا پذیرش آگاهانه ریسک است.
پاسخ کوتاه: چرخه عمر باگ مسیر یک نقص از ثبت و triage تا تخصیص، رفع، Retest و بستهشدن را مشخص میکند. یک جریان ساده میتواند چنین باشد: New → Triage → Ready/Assigned → In Progress → Resolved → Ready for Test → Verified/Closed. شاخههایی مانند Duplicate، Not a Bug، Cannot Reproduce، Deferred و Reopened نیز باید تعریف، مالک و معیار انتقال روشن داشته باشند.
اصل کلیدی: «Fixed» یعنی تیم توسعه اصلاحی ارائه کرده است؛ «Closed» یعنی نتیجه طبق معیار توافقشده تأیید و کار پرونده تمام شده است. این دو وضعیت را یکی نکنید.
چرخه عمر باگ چیست؟
Bug Life Cycle یا Defect Life Cycle گردش کاری است که وضعیت یک گزارش نقص، مسئول اقدام بعدی، شاهد لازم برای انتقال و پایان معتبر آن را تعریف میکند. این چرخه باید برای QA، توسعه، محصول، پشتیبانی و عملیات زبان مشترک بسازد: اکنون چه میدانیم، چه کسی باید چه کاری انجام دهد و گام بعدی چیست؟
چرخه خوب بهاندازه کافی ساده است که تیم واقعاً از آن استفاده کند و بهاندازه کافی دقیق است که باگ میان وضعیتهای مبهم گم نشود. ابزارهایی مانند برد وظایف فقط این قرارداد را اجرا میکنند؛ ابزار جای تعریف مسئولیت و معیار تصمیم را نمیگیرد.
Bug، Defect، Error و Incident چه تفاوتی دارند؟
- Error: اشتباه انسانی در تحلیل، طراحی، کدنویسی یا عملیات.
- Defect/Bug: نقص موجود در یک محصول یا دارایی که میتواند رفتار نامطلوب ایجاد کند؛ در بسیاری از تیمها این دو واژه عملاً هممعنیاند.
- Failure: بروز رفتار نادرست هنگام اجرا.
- Incident: رخداد یا اختلال مشاهدهشده در خدمت؛ ممکن است علت آن باگ، زیرساخت، پیکربندی یا عامل دیگری باشد.
برای همکاری روزمره، توافق تیم روی واژگان مهمتر از بحث لغوی است. تعریفها را در راهنمای فرایند بنویسید و در ابزار همان نامها را بهکار ببرید.
نقشه پیشنهادی Bug Workflow
| وضعیت | معنی | مالک اقدام بعدی | شرط خروج |
|---|---|---|---|
| New | گزارش تازه ثبت شده و هنوز اعتبارسنجی نشده است | QA/مسئول triage | اطلاعات کافی و تصمیم triage |
| Triaged | اعتبار، اثر، دامنه و مسیر رسیدگی روشن شده است | محصول/فنی | اولویت، نسخه هدف و مالک تعیین شود |
| Ready / Assigned | برای اقدام آماده و به تیم مسئول سپرده شده است | توسعه یا تیم مالک | کار واقعاً شروع شود |
| In Progress | بازتولید، علتیابی یا اصلاح در حال انجام است | توسعه | راهحل و شواهد فنی آماده شود |
| Resolved / Fixed | اصلاح در کد یا پیکربندی انجام شده است | توسعه/تحویل | اصلاح روی بیلد قابل تست قرار گیرد |
| Ready for Test | نسخه اصلاحشده، داده و محیط برای Retest آمادهاند | QA | Retest و Regression متناسب انجام شود |
| Verified | رفع در نسخه مشخص تأیید شده است | QA/گزارشدهنده مجاز | معیار بستهشدن کامل شود |
| Closed | کار این گزارش تمام و شواهد نگهداری شده است | مالک فرایند | وضعیت پایانی |
لازم نیست همه تیمها دقیقاً هشت وضعیت داشته باشند. تیم کوچک ممکن است Triaged و Assigned یا Verified و Closed را ادغام کند. تیم دارای الزامات حسابرسی شاید آنها را جدا نگه دارد. هر وضعیت اضافه باید یک تصمیم یا تغییر مالک واقعی را نمایش دهد؛ وگرنه فقط هزینه بهروزرسانی است.
مراحل چرخه عمر باگ، گامبهگام
۱. کشف و ثبت (New)
گزارش از اجرای تست، مانیتورینگ، پشتیبانی یا کاربر وارد میشود. در این مرحله هنوز نباید فرض کرد هر مشاهده یک نقص قطعی است. گزارش باید حداقل عنوان، نسخه/محیط، مراحل یا زمینه رخداد، Actual/Expected و شواهد داشته باشد. اگر تیم در کیفیت گزارش مشکل دارد، راهنمای نوشتن گزارش باگ حرفهای و قالب Bug Report نقطه شروع مناسبی است.
مالک ورودی باید گزارشهای امنیتی و حریم خصوصی را از مسیر محدود و دارای سطح دسترسی مناسب دریافت کند؛ افشای جزئیات آسیبپذیری روی برد عمومی خطر تازه میسازد.
۲. اعتبارسنجی و Triage
در triage، تیم گزارش را از چند زاویه بررسی میکند:
- آیا رفتار قابلمشاهده و انتظار معتبر است؟
- آیا گزارش Duplicate، سؤال محصول یا مشکل محیط است؟
- Severity و دامنه اثر چیست؟
- Priority، نسخه هدف و راهحل موقت چه باشد؟
- کدام تیم مالک بررسی و اقدام است؟
- چه ریسک یا وابستگیای باید به انتشار منتقل شود؟
همه باگها به جلسه بزرگ نیاز ندارند. گزارشهای روشن و کماختلاف میتوانند ناهمگام triage شوند؛ جلسه را برای تصمیمهای چندذینفعی، تضاد اولویت یا ریسک بالا نگه دارید. برای عیبیابی خود جلسات، مقاله ضدالگوهای جلسه تریاژ نقص را ببینید.
۳. تخصیص و بررسی (Assigned / In Progress)
باگ را به تیم مالک مؤلفه تخصیص دهید، نه لزوماً اولین فردی که نامش به ذهن میرسد. توسعهدهنده گزارش را بازتولید، دامنه را بررسی و علت ریشهای را از نشانه جدا میکند. اگر اطلاعات کافی نیست، وضعیت Needs Info با پرسش مشخص، مسئول پاسخ و مهلت بازبینی بهتر از رفتوبرگشت کامنتی بیپایان است.
شروع کار باید در وضعیت دیده شود. باگی که Assigned مانده ولی کسی روی آن کار نمیکند، ظرفیت ظاهری و گزارش مدیریتی را مخدوش میکند.
۴. حل یا تعیین Resolution
Resolved فقط به معنی Fixed نیست. نتیجه بررسی ممکن است یکی از این Resolutionها باشد:
- Fixed: تغییر لازم انجام شده و مرجع کد/پیکربندی مشخص است.
- Duplicate: همان علت یا مسئله در رکورد اصلی پیگیری میشود؛ لینک دوطرفه لازم است.
- Not a Bug / Works as Designed: رفتار مطابق تصمیم معتبر محصول است؛ منبع تصمیم باید پیوست شود.
- Cannot Reproduce: با اطلاعات و شرایط فعلی بازتولید نشد؛ این عبارت اثبات نمیکند رخداد وجود نداشته است.
- Deferred: معتبر است، اما رسیدگی به نسخه یا تاریخ دیگری منتقل شده؛ مالک و تاریخ بازبینی لازم دارد.
- Won’t Fix / Accepted Risk: تصمیم گرفته شده فعلاً اصلاح نشود؛ دلیل، صاحب اختیار، اثر و تاریخ انقضا ثبت شود.
Resolution را از Status جدا نگه داشتن مفید است: Status میگوید «کار در کدام مرحله است» و Resolution میگوید «چگونه پرونده حل شد». این تفکیک گزارشگیری را دقیقتر میکند.
۵. تحویل اصلاح و Ready for Test
تغییر کد وقتی روی شاخه توسعه است هنوز قابل Retest نیست. برای انتقال به Ready for Test، حداقل نسخه/بیلد، محیط استقرار، خلاصه تغییر، مؤلفههای متاثر و نکته لازم برای داده یا Feature Flag ثبت شود. اتصال باگ به Pull Request و Release حدسزدن نسخه اصلاح را حذف میکند.
۶. Retest، Regression و Verification
QA ابتدا سناریوی اصلی را روی بیلد اعلامشده Retest میکند. سپس با توجه به شعاع اثر، Regression لازم را اجرا میکند. Retest میپرسد «همین نقص رفع شد؟» و Regression میپرسد «تغییر جدید بخش سالم دیگری را خراب کرد؟». جزئیات اجرای این دو در مقاله فاز اجرای تست در STLC آمده است.
اگر مشکل اصلی همچنان وجود دارد، با شاهد نسخه جدید Reopen کنید. اگر رفتار اصلی رفع شده اما نقص متفاوتی پیدا شد، گزارش جدید بسازید و ارتباط آن را با اصلاح قبلی نگه دارید.
۷. بستهشدن (Closed)
بستن باید معیار داشته باشد: Resolution معتبر، نسخه مشخص، Retest لازم، شواهد نتیجه و لینک موارد مرتبط. برای Duplicate یا Accepted Risk نیز شرط بستهشدن متفاوت است. Closed به معنی حذف تاریخچه نیست؛ رکورد باید برای تحلیل، حسابرسی و جلوگیری از گزارش تکراری باقی بماند.
وضعیتهای شاخهای را چگونه مدیریت کنیم؟
Reopened
وقتی معیار اصلی هنوز نقض میشود یا اصلاح در نسخه هدف وجود ندارد، گزارش بازگشایی میشود. دلیل، بیلد و شاهد تازه را اضافه کنید. نرخ Reopen بالا را برای سرزنش فرد استفاده نکنید؛ میتواند نشانه درک ناقص دامنه، تحویل مبهم یا Retest ضعیف باشد.
Needs Info
مشخص کنید چه اطلاعاتی، از چه کسی و تا چه تاریخی لازم است. گزارش نباید برای همیشه در این وضعیت بماند. پس از مهلت، triage تصمیم میگیرد ابزار مشاهدهپذیری اضافه کند، دامنه را محدود کند یا با Resolution مستند ببندد.
Deferred
Deferred پارکینگ دائمی نیست. نسخه هدف، علت تعویق، ریسک پذیرفتهشده و تاریخ بازبینی لازم دارد. اگر محصول یا معماری تغییر کرده، اعتبار باگ پیش از بازگرداندن به برنامه دوباره بررسی شود.
Duplicate
Duplicate را به رکورد اصلی وصل کنید و شواهد تازه را منتقل کنید. تعداد رخدادها، کاربران متاثر یا محیط متفاوت ممکن است Priority رکورد اصلی را تغییر دهد. صرفاً بستن گزارش دوم بدون ادغام اطلاعات، داده ارزشمند را از بین میبرد.
Severity، Priority و Risk در مدیریت باگ
Severity شدت اثر فنی/کاربری، Priority ترتیب رسیدگی و Risk ترکیبی از احتمال و پیامد در زمینه محصول است. نمونه:
- کرش در صفحه مدیریتی بسیار کماستفاده میتواند Severity بالا اما Priority پایینتر داشته باشد.
- غلط املایی نام برند در صفحه اصلی کمپین Severity پایین ولی Priority فوری دارد.
- نمایش سفارش کاربر دیگر هم Severity و هم Priority بسیار بالا و نیازمند مسیر امنیتی است.
سطحها را با مثالهای واقعی محصول تعریف کنید. عدد یا رنگ بدون تعریف مشترک، در triage به مذاکره تکراری تبدیل میشود. جزئیات نوشتن اثر و پیشنهاد Severity در قالب گزارش باگ آمده است.
نقشها و مسئولیتها در چرخه باگ
| نقش | مسئولیت اصلی | تصمیمی که نباید پنهان بماند |
|---|---|---|
| گزارشدهنده/QA | شاهد، بازتولید، اثر و Retest | دامنهای که آزموده نشده است |
| توسعه | تحلیل علت، اصلاح، تست فنی و توضیح شعاع اثر | نسخه و محدودیت راهحل |
| محصول | رفتار مورد انتظار و Priority کسبوکار | پذیرش یا تعویق ریسک |
| عملیات/پشتیبانی | شاهد تولید، اثر خدمت و راهحل موقت | تعداد رخداد و کاربران متاثر |
| امنیت/انطباق | ارزیابی و مسیر محرمانه یافته حساس | دامنه افشا و الزام زمانی |
| مدیر انتشار | جمعکردن ریسکهای باز برای Go/No-Go | استثنا و صاحب اختیار آن |
کیفیت باگ مسئولیت یک تیم جداگانه نیست. QA صاحب همه باگها نیست و توسعه هم نباید تنها درباره Priority تجاری تصمیم بگیرد. مرز اختیار را پیش از بحران مشخص کنید.
جلسه Triage مؤثر چگونه برگزار میشود؟
پیش از جلسه، گزارشهای ناقص پالایش و موارد روشن ناهمگام تعیین تکلیف شوند. در جلسه بهترتیب ریسک جلو بروید و برای هر مورد فقط تصمیمهای لازم را ثبت کنید:
- اعتبار و Duplicate بودن
- اثر، Severity و دامنه
- Priority و نسخه هدف
- مالک اقدام بعدی
- راهحل موقت یا ریسک انتشار
- اطلاعات لازم و موعد بازبینی
خروجی جلسه باید داخل خود سیستم ثبت شود، نه فقط در پیامرسان یا حافظه افراد. جلسهای که باگها را میخواند اما تصمیم، مالک و موعد تولید نمیکند، گزارش وضعیت است نه triage.
مدیریت Backlog باگ
بکلاگ سالم لزوماً خالی نیست؛ باید تازه، اولویتدار و تصمیمپذیر باشد. برای جلوگیری از قبرستان باگ:
- باگهای بدون مالک، بدون نسخه هدف و قدیمی را دورهای مرور کنید.
- Aging را به تفکیک Severity و وضعیت ببینید؛ میانگین کلی موارد بحرانی را پنهان میکند.
- Deferred و Accepted Risk را با تاریخ انقضا دوباره ارزیابی کنید.
- باگهای مربوط به نسخه منقضی را با دلیل ببندید یا روی نسخه پشتیبانیشده بازآزمایی کنید.
- الگوهای پرتکرار را به مسئله ریشهای، کار فنی یا اقدام پیشگیرانه تبدیل کنید.
- ظرفیت اصلاح را کنار توسعه قابلیت برنامهریزی کنید؛ شعار «بعداً پاک میکنیم» برنامه نیست.
برای طراحی فرایند وسیعتر پیشگیری، تحلیل علت و حکمرانی بکلاگ، مقاله ایجاد فرایند مدیریت نقص مؤثر مکمل این راهنماست.
معیارهای معنادار چرخه باگ
| معیار | پرسش مفید | احتیاط |
|---|---|---|
| Lead Time | از ثبت تا بستهشدن چقدر طول میکشد؟ | نوع و Severity را تفکیک کنید |
| Cycle Time | از شروع اقدام تا حل چقدر زمان میبرد؟ | زمان انتظار را جدا ببینید |
| Aging | کدام باگهای باز بیش از حد ماندهاند؟ | قدیمی بودن همیشه به معنی مهم بودن نیست |
| Reopen Rate | آیا اصلاح یا معیار تأیید مشکل دارد؟ | برای ارزیابی فردی استفاده نکنید |
| Escaped Defects | چه نقصهایی بعد از انتشار کشف شدند؟ | تعریف دامنه و منبع کشف یکسان باشد |
| Duplicate Rate | آیا جستوجو یا تجمیع نشانهها ضعیف است؟ | گزارش چند کاربر میتواند سیگنال اثر باشد |
تعداد باگ بستهشده، بهرهوری یا کیفیت را بهتنهایی نشان نمیدهد و بهراحتی بازی میشود. روندها را کنار تغییر دامنه، اندازه Release، شدت و ریسک تفسیر کنید. راهنمای معیارهای معنادار اثربخشی QA نگاه وسیعتری ارائه میدهد.
چگونه Workflow مناسب تیم خود را طراحی کنیم؟
- جریان واقعی را روی کاغذ بکشید. از مشاهده تا تصمیم و تأیید، نه آنچه ابزار پیشفرض میگوید.
- هر وضعیت را تعریف کنید. معنی، مالک، شرط ورود و خروج و زمان مورد انتظار را بنویسید.
- شاخههای پایان را جدا کنید. Fixed، Duplicate، Deferred و Accepted Risk یک معنا ندارند.
- فیلد اجباری را حداقلی کنید. فیلدهای بیمصرف داده جعلی تولید میکنند.
- انتقالهای غیرمنطقی را محدود کنید. مثلاً Closed مستقیم از New فقط با Resolution و اختیار مشخص.
- اعلان را بر اساس اقدام تنظیم کنید. همه تغییرها برای همه افراد اعلان نسازند.
- پس از چند Sprint بازبینی کنید. وضعیتهای بدون استفاده، صفهای طولانی و رفتوبرگشت را اصلاح کنید.
اگر میان چند مدل مردد هستید، راهنمای مقایسه جریانهای کاری ردیابی نقص به انتخاب بر اساس اندازه و ریسک تیم کمک میکند.
ابزار ردیابی باگ چه قابلیتهایی لازم دارد؟
- Workflow و سطح دسترسی متناسب با تیم
- تاریخچه تغییرناپذیر وضعیت، مالک و تصمیم
- جستوجو، لینک Duplicate و ارتباط با تست/کد/Release
- فیلتر Aging، Severity، نسخه هدف و ریسک پذیرفتهشده
- API و یکپارچگی با CI/CD و مانیتورینگ
- مسیر محرمانه برای امنیت و اطلاعات حساس
- داشبورد قابلتوضیح، نه فقط نمودارهای زیاد
برای تیمی که از Jira استفاده میکند، مقاله راهنمای Jira برای تسترها تنظیم عملی issue و کار در Sprint را پوشش میدهد. انتخاب ابزار باید بعد از تعریف فرایند باشد؛ مهاجرت ابزار، ابهام مسئولیت را خودکار حل نمیکند.
مثال: سفر یک باگ تخفیف در چرخه عمر
- New: QA گزارش میکند تخفیف درصدی از سقف ۱۰۰ هزار تومان عبور کرده و مبلغ درگاه با سفارش متفاوت است.
- Triaged: اثر مالی تأیید، Severity بالا و Priority نسخه جاری تعیین میشود؛ تیم Checkout مالک است.
- In Progress: توسعه علت را در اعمال سقف پس از ساخت درخواست درگاه پیدا میکند.
- Resolved/Fixed: اصلاح، تست واحد و لینک Pull Request ثبت میشود.
- Ready for Test: Build ۴۳۱ روی Staging با فلگ کمپین آماده است.
- Verified: QA سناریوی اصلی را Retest و کد ثابت، درصدی، منقضی، مرجوعی و پرداخت تکراری را Regression میکند.
- Closed: شواهد بیلد و نتیجه پیوست و رکورد به Release مرتبط میشود.
اگر در Regression مشخص شود مرجوعی تخفیف را دوبار برمیگرداند، آن یک باگ تازه با ارتباط به اصلاح قبلی است؛ گزارش اصلی فقط وقتی Reopen میشود که همان معیار اصلی هنوز نقض شده باشد.
ضدالگوهای رایج مدیریت باگ
- وضعیتهای بسیار زیاد: تفاوت عملی ندارند و برد را فرسوده میکنند.
- Fixed = Closed: تأیید مستقل و نسخه قابلآزمایش حذف میشود.
- Priority = صدای بلندتر: اثر و داده جای خود را به فشار میدهند.
- Assigned بدون مالک واقعی: صف ظاهراً مرتب ولی بیحرکت است.
- Deferred بدون تاریخ: بدهی به فراموشی تبدیل میشود.
- Cannot Reproduce بهعنوان رد گزارش: فرصت بهبود مشاهدهپذیری از بین میرود.
- بستن گروهی برای زیباتر شدن داشبورد: داده تاریخی و ریسک واقعی مخدوش میشود.
- معیار فردی بر اساس تعداد باگ: ثبت تکراری، شکستن مصنوعی گزارش و رفتار دفاعی ایجاد میکند.
چکلیست چرخه عمر باگ
- هر وضعیت تعریف، مالک و شرط خروج دارد.
- Status و Resolution از هم جدا هستند.
- Newها در بازه توافقشده triage میشوند.
- Severity با اثر و Priority با تصمیم تجاری پشتیبانی میشود.
- Fixed به بیلد/کد مشخص وصل است.
- Ready for Test واقعاً روی محیط قابلآزمایش قرار دارد.
- Retest و Regression متناسب ثبت میشوند.
- Duplicate به رکورد اصلی لینک و شواهدش منتقل میشود.
- Deferred و Accepted Risk تاریخ بازبینی و صاحب اختیار دارند.
- Aging و گلوگاهها دورهای بررسی میشوند.
سؤالات متداول چرخه عمر باگ
تفاوت Resolved، Verified و Closed چیست؟
Resolved یعنی تیم مسئول یک راهحل یا Resolution اعلام کرده؛ Verified یعنی نتیجه روی نسخه مشخص تأیید شده؛ Closed یعنی همه معیارهای پایان رکورد کاملاند. تیم کوچک میتواند دو مورد آخر را ادغام کند، اما تعریف باید روشن باشد.
چه کسی باید باگ را ببندد؟
به فرایند بستگی دارد. برای Fixed معمولاً QA یا گزارشدهنده مجاز پس از Retest میبندد؛ برای Duplicate یا Accepted Risk شاید مسئول triage یا محصول اختیار داشته باشد. سطح دسترسی باید با نوع Resolution هماهنگ باشد.
آیا هر باگ باید Severity و Priority داشته باشد؟
برای تصمیمگیری منظم مفید است، اما سطوح باید ساده و تعریفشده باشند. Severity را از Priority کپی نکنید؛ اولی اثر را توضیح میدهد و دومی ترتیب اقدام را.
باگ Cannot Reproduce را چه زمانی ببندیم؟
پس از ثبت تلاشها، نسخه و داده موجود، درخواست اطلاعات مشخص و تصمیم triage. برای اثرهای شدید، پیش از بستن ممکن است افزودن logging، مانیتورینگ یا مسیر دریافت شاهد لازم باشد.
بهترین تعداد وضعیت برای Bug Workflow چندتاست؟
عدد ثابتی وجود ندارد. کمترین تعداد وضعیت را انتخاب کنید که تغییر تصمیم یا مالک واقعی را نشان دهد. برای بسیاری از تیمها ۵ تا ۸ وضعیت اصلی همراه چند Resolution کافی است، اما الزامات حسابرسی میتواند بیشتر بخواهد.
جمعبندی
چرخه عمر باگ وقتی مفید است که حرکت کار و مسئولیت را شفاف کند، نه اینکه صرفاً بردی رنگارنگ بسازد. از جریان ساده شروع کنید، Fixed را از Closed جدا نگه دارید، شاخههای Duplicate و Deferred را با دلیل مدیریت کنید و هر انتقال را به شاهد و مالک وصل کنید. سپس با Aging، Lead Time و Reopen Rate گلوگاه فرایند را پیدا کنید—بدون تبدیل معیارها به ابزار ارزیابی افراد.
