تاریخ انتشار نسخه اصلی 9 آوریل, 2017
یکی از کارهای روزانه تیمهای نرم افزاری تصحیح باگهای گزارش شده است. گزارش هایی که یا از سمت مشتری و بخش پشتیبانی ایجاد میشود یا تست کنندگاه سیستم و یا خود برنامه نویسان. در واقع فرقی نمیکند که نرم افزار تولید شده در دوره رشد یا دوره بلوغ و نگهداری خود باشد. باگها همیشه هستند و همیشه هم باید آنها را با توجه به الویتشان درست کرد. برای گزارش و پیگیری باگها هم سیستمهای یکپارچه رایجی مانند Jira، YouTrack یا Zandesk وجود دارد که کار را برای بخش فنی و پشتیبانی ساده کرده اند. اما متاسفانه در موارد بسیاری این باگها پس از تصحیح، تایید و patch شدن به دست فراموشی سپرده میشوند ?
یکی از فرایندهایی که در بخشهای فنی کارا و با سابقه وجود دارد، تحلیل باگها یا اصطلاحاً Defect Analysis است. در این فرایند تیمهای نرم افزاری بجای فراموش کردن باگها در طول زمان، هر یک ماه در جلسهای دور هم مینشینند و باگهای گزارش شده در ماه گذشته را بازنگری، دسته بندی و تجزیه و تحلیل میکنند تا هم شناخت بهتری از وضعیت سیستم داشته باشند و هم علل اصلی ایجاد باگها یا اصطلاحاً Root Cause را با برنامه ریزی رفع کنند. روشهایی برای هم دو کار یعنی تحلیل باگ و تحلیل علل اصلی ایجاد باگ مانند Fishbone Diagram وجود دارد اما در چند خط پیش رو میخواهم تجربه شخصی خود در این مورد بنویسم.
برای تحلیل باگها اولین کار ایجاد معیارهایی برای دسته بندی آنهاست. تعدادی از این دسته بندیها مانند نسخه نرم افزار و اولویت آن به طور پیشفرض در سیستمهای مدیریت باگ وجود دارد. اما میتوان موارد زیر را که برای تحلیل مهمتر است را به آن افزود:
یکی از وظیفه های تست کننده در تیم نرم افزار میتواند تحلیل و دسته بندی باگها بر اساس معیارهای بالا و آوردن نتایج برای بررسی در جلسه ادواری تحلیل باگها باشد. حاصل این جلسات موارد زیر است:
انجام این فرایند در ماههای متمادی میتواند راهی باشد برای کاهش میزان مشکلات نرم افزار و شناخت بیشتر از وضعیت آن.
