رسیدگی به باگ: از گزارش تا ریشه
هر تیمی که بیش از یک سال روی یک سامانه کار کرده، یک فهرست باگ دارد که هیچکس دیگر بازش نمیکند. هشتصد ردیف، بعضی از سه سال پیش، بعضی تکراری، بعضی دربارهٔ صفحهای که دیگر وجود ندارد.
آن فهرست، فهرست کار نیست. انبار احساس گناه است — و مسئلهٔ اصلیاش این نیست که بلند است؛ این است که کسی نمیتواند از آن تصمیم دربیاورد.
فرایند رسیدگی به باگ برای کوتاه کردن آن فهرست نیست. برای این است که هر ردیف تازه، در بازهٔ مشخصی یا کار شود یا بسته شود.
گزارشی که قابل کار کردن است
نصف زمانی که صرف باگ میشود، صرف فهمیدن خود گزارش است. سه بند لازم است، و هیچکدام اختیاری نیست:
چه کردید، چه دیدید، انتظار چه داشتید. «سامانه کار نمیکند» گزارش نیست. «روی ثبت سفارش زدم، پیغام خطای عمومی آمد، انتظار داشتم سفارش ثبت شود» گزارش است.
زمان دقیق و شناسهٔ کاربر. بدون این دو، پیدا کردن ردپا در لاگ ساعتها طول میکشد. با آنها دقیقهها. اگر لاگ ساختاریافته با شناسهٔ درخواست دارید، این بند تقریباً همهٔ کار عیبیابی را انجام میدهد.
محیط و نسخه. تولید یا آزمون، کدام نسخه، کدام مرورگر یا نسخهٔ اپلیکیشن.
تجربهٔ عملی: فرم گزارش را کوتاه نگه دارید ولی این سه را اجباری کنید. فرمی با پانزده فیلد، فرمی است که پشتیبانی دورش میزند و در پیامرسان گزارش میدهد.
سطحبندی: دو محور، نه یکی
«اولویت بالا» بیمعناترین برچسب در ابزارهای پیگیری است، چون همهچیز اولویت بالا میشود. دو محور جدا لازم است:
شدت — اگر رخ دهد چقدر بد است؟ این ویژگی خود باگ است.
فراوانی — چند نفر و چند وقت یکبار؟ این ویژگی استفاده است.
باگی که سامانه را میخواباند ولی فقط در حالتی رخ میدهد که سالی یک بار پیش میآید، با باگی که ظاهر یک دکمه را خراب کرده ولی همهٔ کاربران هر روز میبینند، دو تصمیم متفاوتاند. حاصلضرب این دو اولویت است، نه هیچکدام بهتنهایی.
چهار سطحی که در عمل برایمان کار کرده:
| سطح | یعنی | پاسخ |
|---|---|---|
| بحرانی | کار متوقف است، جایگزین ندارد | همین حالا، بقیه متوقف |
| بالا | کار مختل است ولی راه دور زدن هست | همین چرخه |
| متوسط | آزاردهنده، کار جلو میرود | چرخهٔ بعد |
| کم | زیباییشناختی یا حاشیهای | وقتی کد آن ناحیه باز شد |
سطح بحرانی مسیر دیگری دارد و باگ نیست — رخداد است، با نقشها و ترتیب کار خودش. تفکیک این دو مهم است: تیمی که خرابی تولید را در صف باگ میگذارد، هم دیر جواب میدهد هم صف را بیاعتبار میکند.
جلسهٔ سطحبندی، هفتگی و کوتاه
سی دقیقه، هفتهای یک بار، با سه نفر: کسی که محصول را میشناسد، کسی که کد را میشناسد، کسی که با مشتری حرف میزند.
فقط گزارشهای جدید مرور میشوند و برای هرکدام یکی از چهار جواب داده میشود:
میسازیمش — با سطح و مسئول. رفتار درست همین است — با توضیحی که به گزارشدهنده برمیگردد. تکراری است — به ردیف اصلی وصل میشود. نمیسازیم — و بسته میشود.
آن گزینهٔ چهارم چیزی است که فهرست را زنده نگه میدارد. باگی که هجده ماه در صف بوده و کسی سراغش نرفته، تصمیمش گرفته شده؛ فقط ثبت نشده. بستنش با یک جمله دلیل، صادقانهتر از نگهداشتنش است.
قاعدهٔ سی روز
قاعدهای که به فهرستهای متورم پایان میدهد: هر ردیفی که سی روز در صف بماند و کسی برایش زمانبندی نگذارد، خودکار به بازبینی برمیگردد و در آن بازبینی یا زمانبندی میشود یا بسته.
سختگیرانه به نظر میرسد. در عمل نتیجهاش این است که فهرست باگ به چیزی تبدیل میشود که آدمها واقعاً نگاهش میکنند — و یک فهرست دویستردیفی که خوانده میشود، از فهرست هشتصدردیفی که خوانده نمیشود بینهایت مفیدتر است.
بعد از رفع: دو کاری که معمولاً انجام نمیشود
اول، تست. هر باگی که در تولید پیدا شد، پیش از رفع یک تست میشود که شکستش را نشان میدهد. بعد رفع میشود و تست سبز میشود.
دلیلش کیفیت نیست، دوبارهکاری است: باگی که تست نداشته باشد، معمولاً برمیگردد — گاهی با همان علت، گاهی از مسیر دیگری. این تنها مکانیزمی است که مجموعهٔ تست شما را به سمت چیزهایی میبرد که واقعاً میشکنند. مفصلتر در تست رگرسیون.
دوم، سؤال ریشه. برای باگهای بحرانی و بالا، یک سؤال: چرا این را زودتر نگرفتیم؟
جوابهای واقعی معمولاً از این چهارتا هستند و هر کدام کار متفاوتی میسازد:
- تست نداشت → تست اضافه شود
- در بازبینی دیده نشد → شاید بازبینی خیلی بزرگ بوده
- نیازمندی مبهم بود → مسئله در مرحلهٔ کشف است، نه در کد
- محیط آزمون شبیه تولید نبود → محیطها
این سؤال بدون فضای بدونسرزنش جواب صادقانه نمیگیرد. اگر جواب دادن به آن هزینهای برای کسی داشته باشد، جوابها تبدیل به «خطای انسانی» میشوند، که یعنی هیچ.
الگویی که باید ببینید
اگر نسبت باگهای کشفشده در تولید به باگهای کشفشده پیش از انتشار بالا میرود، مسئلهٔ شما رسیدگی به باگ نیست — مسئلهٔ شما استراتژی تست است. فرایند رسیدگی خوب، باگ کمتری تولید نمیکند؛ فقط باعث میشود بدانید چند تا دارید و کدامشان مهم است.
و اگر همان چند فایل مدام در گزارشها تکرار میشوند، آن یک نقشه است: بازآرایی را از همانجا شروع کنید، نه از جایی که کد زشتتر به نظر میرسد.