نحوه ی شناسایی، مدیریت، و برطرف کردن Bug ها توسط تیم برنامه نویسی ASP.NET

نحوه ی شناسایی، مدیریت، و برطرف کردن Bug ها توسط تیم برنامه نویسی ASP.NET



نرم افزاری که توسط تیم برنامه نویسی ASP.NET در مایکروسافت برای مدیریت Bug ها مورد استفاده قرار می گیرد، یک نرم افزار داخلی با نام Product Studio است که توسط برنامه نویسان این شرکت بدین منظور ایجاد شده است.
برنامه نویسان این نرم افزار در سال 2003 به تیم Visual Studio پیوستند و این اقدام باعث شد که مایکروسافت این برنامه را به عنوان یک برنامه ی جامع مدیریت خطاها، در اختیار شرکت های متقاضی قرار دهد.
در این نرم افزار، تمامی جزئیات Bug ها در یک بانک اطلاعاتی نگهداری می شود و با سیستم فوق العاده قدرتمندی که در ایجاد Query ها و تحلیل آماری خطاها دارد، به عنوان سیستمی محبوب در شرکت مایکروسافت شناخته می شود.
نمونه ای از محیط برنامه را در شکل زیر ملاحظه می کنید:
http://pnu-club.com/imported/mising.jpg

در عکس فوق، اطلاعاتی پیرامون شخص کشف کننده خطا، تاریخ شناسایی، تاریخ آخرین به روز رسانی، نوع Bug (اشتباه در کدنویسی، امکان بالا بردن کارایی، خطای مبهم!)، توضیحاتی در مورد خطا و ... مشاهده می شود.
امکان مشاهده ی جزئیات کامل خطا، با دو بار کلیک کردن بر روی ردیف خطای مورد نظر میسر می شود.
در شکل زیر، نمونه ای از جزئیات یکی از Bug های موجود در ASP.NET 2.0 را ملاحظه می کنید:
http://pnu-club.com/imported/mising.jpg

توضیح برخی از گزینه ها:
1)Repro Steps :
توضیحات جامعی در مورد نحوه بروز خطا

2) Details:
اطلاعات جامعی در مورد نحوه ی رسیدگی به خطا و اطلاعاتی که بین اعضا در این مورد رد و بدل شده است.

3) Priority:
این گزینه، مشخص کننده ی اولویتی است که باید به Bug نسبت داده شود.
به عنوان مثال، عدد صفر بیانگر خطرناک بودن Bug و در اولویت بودن آن جهت برطرف شدن است و یا عدد 4 نشان دهنده ی کم اهمیت بودن Bug و امکان رفع آن در زمان دیگر است.

4) Status:
این گزینه 3 حالت را می پذیرد:
الف) Active: خطا در حال بررسی است.
ب) Resolved: خطا بر طرف شده اما هنوز صحت این امر مورد تایید واقع نشده است.
ج) Closed: خطا بر طرف شده و مورد تایید واقع شده است.

5) Path:
مشخص کننده ی مسیر بروز خطاست.

6) Build:
این گزینه، مکان و تاریخ کشف خطا را نشان می دهد.
به عنوان مثال، عبارت Lab22d.40531 را در نظر بگیرید.
Lab22d بیانگر کد واحد تشخیص خطا در شرکت است.
پنج رقم باقی مانده، تاریخ کشف خطا را مشخص می کنند. این عدد با فرمت Year/Month/Day نمایش داده می شود.
بنابراین، عدد 40531، تاریخ کشف خطا را در 31 ماه می سال 2004 تعیین می کند.

7) AssignedTo:
مشخص کننده ی فردی است که در حال بررسی کردن خطا جهت برطرف کردن آن است.
----------------------------------------------------------------------------------------------------

تقریبا تمامی تیم های نرم افزاری در مایکروسافت از این نرم افزار به منظور مدیریت خطاها در محصولات خود بهره می گیرند.
امکان برقراری ارتباط بین تیم های مختلف برنامه نویسی، از مزایای دیگر این نرم افزار است.

مدیریت خطاها از آغاز تا پایان:
در مایکروسافت، تیم های مختلف وظایف مختلفی را بر عهده می گیرند اما تمامی اعضا در یک مورد مشترک هستند.
در صورتی که فردی در محصولی باگی ها را مشاهده کرد، موظف به گزارش کردن آن با جزئیات کامل از طریق نرم افزار Product Studio به تیم مربوطه است.
این فرد می تواند یک تست کننده، یک برنامه نویس، یک مدیر برنامه یا هرکس دیگری باشد.
خطای پیدا شده باید به فردی در تیم نرم افزاری شرکت نسبت داده شود.
این شخص، برنامه نویس، تست کننده یا مدیر برنامه است.
در صورتی که فرد کشف کننده ی خطا، در مورد انتساب خطا به فردی شک داشته باشد، خطا را به نام Active، (نماد بررسی کننده ی مبهم) در نرم افزار Product Studio وارد می کنند.
زمانی که خطایی به نام Active در فیلد AssignedTo قرار گرفت، سرپرست تیم یا تیم ارزیابی محصول وظیفه بازنگری در خطا را بر عهده دارند و با اولویت دادن به آن، فرد متناسبی را جهت رفع آن، منتسب می کنند.
برنامه نویسان، تست کننده ها و مدیران برنامه وظیفه دارند تا در بازه های زمانی مشخصی وضعیت خود را در نرم افزار Product Studio چک کنند تا اگر خطایی به آنها نسبت داده شده، نسبت به انجام وظیفه ی خود در قبال آن عمل کنند.
تعامل کاملی بین برنامه نویسان، تست کننده ها و مدیر برنامه در مایکروسافت وجود دارد و گاه برای برطرف خطایی چندین پیغام رد و بدل می شود.
به عنوان مثال ممکن است تست کننده ای بپرسد: آیا پیغام صحیحی برای این خطا نمایش داده می شود؟ آیا کاری که این دستور انجام می دهد درست است؟ آیا فلان چیز را فراموش نکرده اید؟ و ...
در صورتی که چنین سوالاتی برای تست کننده ی برنامه به وجود آید، باگ به منظور بررسی بیشتر برای مدیر برنامه ارسال و سپس به برنامه نویس سپرده می شود.
در صورت اطمینان از عدم صحت باگ، باگ مجددا برای بررسی یا توضیحات بیشتر با عنوان "non-repro" برای تست کننده ارسال می شود.
توجه: تمامی اتفاقاتی که در زمان چرخه ی حیات یک باگ رخ می دهد، از طریق تب History در نرم افزار قابل مشاهده است.
پس از برطرف شدن باگ توسط برنامه نویس، حالت باگ از Active به Resolved تغییر پیدا کرده و مجددا جهت تایید به فرد کشف کننده ی خطا برگشت داده می شود.
در این حالت فرد کشف کننده جهت حصول اطمینان از برطرف شدن خطا، منتظر دریافت نسخه ای از برنامه می ماند و سپس توضیحات موجود در گزینه ی Repro Steps را که بیانگر توضیحات جامعی در مورد نحوه بروز خطا است مجددا مرور می کند.
پس از اطمینان از برطرف شدن باگ، حالت وضعیت خطا را از Resolved به Closed تغییر می دهد در غیر اینصورت، وضعیت مجددا به Active باز خواهد گشت.

موفق باشید.