مبحث گزارش خطا یا به اصلاح دنیای نرم افزاری آن باگ زدن (bug report) در تمامی رشته ها و در تمامی محصولاتی که به صورت روزمره از آنها استفاده می کنیم وجود دارد. خطا یا خرابی همیشه وجود داشته و خواهد داشت. مهارت این که به صورت سازنده خطاها و خرابی های یک محصول را به دست اندکاران آن برسانیم نیز مهارت مهمی است. بهتر است نگاهی اجمالی به نکات سازنده در ثبت خطا یا همان باگ زدن داشته باشیم.

چرا خوب گزارش دادن باگ اهمیت دارد؟

مهمترین دلیل آن صرفه جویی در زمان است. فرض کنید یک برنامه نویس که شما اصلا آن را ندیده اید قرار است باگ ثبت شده توسط شما را (شاید مدت ها بعد از زمانی که شما آن را ثبت کرده اید) رفع کند. او هیج گونه آشنایی با پیش زمینه های ذهنی شما در زمان مشاهده باگ ندارد.و با نحوه نگارش شما هم آشنا نیست. پس باید پروتکل ثابتی وجود داشته باشد که او متوجه جزئیات خطایی که شما ثبت می کنید شود.

فاکتور های متفاوتی در سازمان ها وجود دارند که خصویات یک باگ یا به طور کلی (work item) را مشخص می کنند. ولی به طور کلی هر باگ می تواند شامل اطلاعات زیر باشد.

• عنوان
• مراحل ایجاد دوباره باگ و نتایج آن
• اطلاعات فنی مورد نیاز برای بررسی باگ در محیط ایزوله شده (مانند backup پایگاه داده و …)
• اولویت باگ
• شدت باگ

بخش های متفاوت دیگری حتما در بدنه هر باگ وجود دارد به طور مثال این که مربوط به چه سیستمی است و …

عنوان

عنوان باگ یکی از مهمترین بخش های باگ است. عنوان باگ باید به حدی ساده و قابل فهم باشد که با نگاهی سر سری به آن اطلاعات کلی در مورد مکان مشاهده و نحوه مشاهده باگ به برنامه نویس مربوطه بدهد.

همیشه این گونه تصور کنید که کسی آن طرف پنل مدیریت lifecycle نرم افزار قرار دارد (هر سیستمی که هست مثلا TFS) باید عنوان باگ ها به گونه ای انتخاب شود که او به راحتی و با گذر سریع چشمی بتواند باگی را به کسی (یا تیمی) به صورت اولیه assign کند. اگر عنوان به خوبی انتخاب نشود حتما آن فرد (هر کسی که هست) با مشکلات عدیده ای مواجه خواهد شد.چند نمونه از عنوان های خوب و بد را بررسی خواهیم کرد

بد: فرم ویرایش کالا کار نمی کند.

خوب: عدم ذخیره سازی تغییرات دسته بندی ها در فرم ویرایش کالا

بد: enter کار نمی کند.

خوب: دکمه enter در هنگام  inline editing در گرید کالاها فوکوس را به فیلد بعدی نمی برد

مراحل ایجاد دوباره باگ

قبل از این که اقدام به ثبت باگ جدید بکنید ابتدا تمام سعی خود را انجام دهید که الگوی ایجاد کننده باگ را پیدا کنید. اگر این مرحله درست انجام نشود به احتمال زیاد چیزی برای گفتن در متن باگ نخواهید داشت.

پس از اینکه الگوی باگ را پیدا کردید نیاز است که مراحلی که منجر به برخورد با باگ می شوند را یادداشت کنید. این مورد خیلی مهم است. مراحلی که تهیه میکنید باید خیلی دقیق و کارا باشند.

به عنوان برنامه نویس تنها اطلاعاتی که نیاز دارم تا بتوانم باگ را رفع کنم آیتم های زیر هستند

• مراحلی که نیاز است باگ را ببینم.
• نتیجه ای که کاربر انتظار داشت ببیند.
• چیزی که الان می بیند.

برای نوشتن مراحل به صورت دقیق همیشه بررسی کنید که آیا تمام مراحلی که انجام داده اید برای ایجاد باگ الزامی بوده اند؟ سپس مراحل را یک به یک و واضح یادداشت کنید. الگوی مشخصی برای نوشتن این مراحل وجود ندارد. فقط وضوح را همیشه رعایت کنید.

نکته: اگر در جایی برای توضیح دادن مراحل ایجاد باگ یا نتایج مشکلی در نگارش دارید بهترین گزینه تصویر یا حتی فیلم ای است که از نسخه مورد بررسی تان گرفته اید.

یک نمونه از مراحل ایجاد باگ که خوب نوشته شده است به صورت زیر است. البته هیچ قانون مشخصی برای نوشتن جزئیات در این مراحل وجود ندارد. و جزئیات بر اساس شرایط تیم قابل تغییر هستند

یک: انتخاب کالا از لیست کالا و درخواست ویرایش از منو

دو: ویرایش دسته بندی های کالا

سه: ذخیره تغییرات

اطلاعات فنی مورد نیاز برای بررسی باگ

این اطلاعات عموما شامل backup از پایگاه داده مربوطه یا اطلاعات محیطی مانند سیستم عامل، browser و غیره است.

نکته مهمی که اغلب فراموش می شود تنظیمات general یا تنظیمات مربوط به هر کاربر است. اگر حس می کنید (یا حتی وقتی حس نمی کنید!) که باگ ممکن است به دلیل پاره ای از تنظیمات محیطی یا داخلی نرم افزار است بهتر است، یک کپی از تمام متغیر های محیطی و تنظیمات در کنار باگ بگذارید. تا جایی که مسائل امنیتی بروز نکند.

نکته: یک سری ابزار برای گرفتن متغیر های محیطی وجود دارد. خوب است که نرم افزار شما امکانی مشابه برای dump گرفتن از تنظیمات داخلی خودش داشته باشد.

اولویت باگ

بهترین معیار (نه الزاما اخلاقی ترین معیار) برای تعیین اولویت باگ به نظر من نظر مشتری است. اگر رفع نشدن باگی منجر به نارضایتی مشتری و پس دادن نرم افزار باشد اولویت آن باگ خیلی بالاست و در بازه عددی اولویت های شما در بالاترین حد قرار می گیرد. هر چقدر ترس از از دست دادن مشتری کمتر شد اولویت باگ هم پایین خواهد آمد!

شدت باگ

شدت باگ در تعیین اولویت باگ تاثیر بسیار مهمی دارد. اسامی مختلفی در سازمان های مختلف برای شدت باگها می گذارند. ولی به صورت نسبی باگ ها را می توان از “باگ کشنده” تا باگ “پیشنهاد بهبود” دسته بندی کرد. (در میان این دو دسته، دسته های زیادی قرار خواهد گرفت). باگ کشنده باگی است که به هر صورتی مانع ادامه کار با نرم افزار می شود و پیشنهاد بهبود باگی است که معمولا در متن آن شاهد توضیحی مبنی بر این که ” بهتر است کار X انجام شود.” خواهیم بود.

نتیجه

باگ زدن یکی از مهمترین فعالیت هایی است که همه روزه برنامه نویس ها، تحلیل گرها، و مدیران پروژه را درگیر می کند. از ذات باگ امانی نیست. قطعا بهترین نرم افزار ها و محصولات دنیا هم همراه با اشکال خواهند بود. ولی فرایند درست و مدیریت شده برای انتقال این اشکالات به تیم تولید می تواند نقش مهمی در کیفیت کلی نرم افزار ایفا کند. پس خوب باگ بزنیم.