اولویت و شدت باگ


حدود سه سال پیش مطلبی تحت عنوان “خوب باگ بزنیم” در وبلاگم منتشر کردم. موضوع گزارش خطای کارآمد یکی از موضوعاتی هست که به طور روزمره تیم های تولید و تحلیل را درگیر خود خواهد کرد.
در آن مطلب به خصوصیات مختلف یک گزارش خطای خوب پرداختم. اما در تیمی که مشغول کار هستم یکی از چالش های پیش روی ما وارد کردن صحیح و دقیق دو فاکتور Priority و Severity برای باگ ها است. یکی از بهترین توضیحاتی که در رابطه با این دو فاکتور مشاهده کرده ام، توضیحات خود مایکروسافت برای این دو مورد است.

اولویت (Priority)

معیار درجه بندی به باگ ها از زاویه کسب و کار و نیازهای مشتری. اولویت یک باگ ترتیب رفع باگ ها را نشان می دهد. مقادیری مناسبی که برای اولویت وجود دارد را می توان به صورت زیر توضیح داد.
اولویت ۱: باگ هایی با این اولویت نشان دهنده این هستند که محصول بدون رفع آنها قابل ارائه نیست و باید در اسرع وقت حل شوند.
اولویت ۲: باگ هایی با این اولویت نشان دهنده این هستند که محصول بدون رفع آنها قابل ارائه نیست ولی نیاز به رفع فوری آنها نیست.
اولویت ۳: رفع باگ اختیاری است و بر اساس منابع و زمان و ریسک می توان برای رفع آن برنامه ریزی کرد.

شدت (Severity)

معیار درجه بندی یک باگ بر اساس تاثیری که روی پروژه یا محصول نرم افزاری دارد. مقادیری که این برای این فاکتور می توان در نظر گرفت به صورت زیر هستند:
Critical: باید رفع شود. اشکالی که باعث از کار افتاد یک بخش یا تمام سیستم نرم افزاری شود و یا منجر به خرابی داده های نرم افزار شود. همچنین راهکار جایگزین قابل قبولی برای گرفتن نتیاج مورد انتظار در محصول وجود ندارد.
High: برای رفع در نظر گرفته شود. بخش اول تعریف این نوع باگ مانند مورد Critical است ولی راهکار جایگزین قابل قبولی برای گرفتن نتایج مورد انتظار در محصول وجود دارد.
Medium: باگی که باعث می شود سیستم نتایج نادرست یا ناقصی ارائه دهد.
Low: اشکال کوچک و تزیینی که راه حل های قابل قبولی در محصول نرم افزاری برای آن وجود دارد به طوری که نتایج مطلوب حاصل شود.

موارد بالا از اینجا نقل قول شده است. برای مطالعه بیشتر در مورد مدیریت باگ ها می توانید به لینک مذکور مراجعه نمایید.

 

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *