معرفی و تعریف
تحلیل و مدیریت باگ، توانایی شناسایی، بازتولید، بررسی و پیگیری خطاهای نرمافزار در طول چرخه توسعه است. فرد دارای این مهارت میتواند تفاوت میان رفتار مورد انتظار و رفتار واقعی سیستم را تشخیص دهد، شرایط بروز خطا را مشخص و محدود کند و شواهد لازم را برای بررسی و رفع مشکل در اختیار توسعهدهنده قرار دهد.
گزارش باگ استاندارد فقط اعلام «کار نمیکند» نیست. این گزارش باید شامل گامهای بازتولید، محیط اجرا، دادههای ورودی، نتیجه مورد انتظار، نتیجه واقعی، شواهدی مانند تصویر یا فایل لاگ و تعیین شدت و اولویت خطا باشد. سپس باگ در ابزار پیگیری ثبت، به فرد یا تیم مسئول ارجاع، پس از رفع مشکل دوباره آزمایش و در نهایت بسته میشود.
مهندسان تست نرمافزار، توسعهدهندگان، مدیران محصول و تیمهای پشتیبانی در فرایند مدیریت باگ نقش دارند. تقسیم مسئولیت به ساختار تیم وابسته است؛ QA میتواند کیفیت گزارش و آزمون مجدد را هدایت کند، توسعهدهنده علت فنی را تحلیل و اصلاح لازم را انجام دهد، پشتیبانی شواهد مربوط به رخداد مشکل برای کاربر را جمعآوری کند و تیم محصول درباره اولویت رسیدگی تصمیمگیری کند. فرایند مشخص، مسئول هر مرحله و معیار بستهشدن باگ باید در تیم تعریف شده باشد.
این مهارت را با نامهای دیگری نیز میشناسند:
- مدیریت نقص نرمافزار
- گزارش و پیگیری باگ
- مدیریت خطاهای نرمافزار
- Bug Reporting
- Bug Tracking
- Defect Tracking
- Defect Management
اهمیت و کاربردها
چرا این مهارت مهم است؟
در تیمهای نرمافزاری، باگی که قابل بازتولید و قابل فهم نباشد، معمولا زمان بیشتری از توسعهدهنده، مهندس تست و مدیر محصول میگیرد. گزارش دقیق کمک میکند تیم بهجای حدسزدن، مسئله را با اطلاعات و شرایط مشخص بررسی کند و تصمیم بگیرد رفع آن با چه اولویتی و در چه زمانی ضروری است.
برای کسی که میخواهد در نقشهای تست نرمافزار یا تضمین کیفیت فعالیت کند، این مهارت بخشی از کار روزمره است؛ باید بتواند رخداد را بازتولید کند، گزارش قابل بررسی و پیگیری بنویسد، پس از اصلاح، تست مجدد انجام دهد و با تیم توسعه و محصول درباره وضعیت باگ ارتباط شفاف داشته باشد. نام ابزار و گردش کار میان سازمانها متفاوت است، اما کیفیت شواهد، شفافیت گزارش و پیگیری نتیجه در هر فرایند تست اهمیت دارد.
تفکیک شدت از اولویت اهمیت ویژهای دارد. شدت نشان میدهد نقص چه میزان بر عملکرد سیستم یا تجربه کاربر تأثیر میگذارد، اما اولویت تعیین میکند تیم آن را با چه سرعتی رفع کند. ممکن است یک خطای ظاهری شدت بالایی نداشته باشد، اما بهدلیل نمایش در صفحه اصلی یا نزدیکبودن زمان انتشار، اولویت بالایی دریافت کند.
کاربردها
-
ثبت نقص در تست دستی وب
ثبت خطایی مانند ناتوانی کاربر در تکمیل پرداخت، همراه با گامهای دقیق بازتولید، مرورگر، نسخه سیستمعامل، دادههای آزمایشی و نتیجه واقعی.
-
محدودکردن دامنه خطای API
با تفکیک اینکه مشکل از رابط کاربری، درخواست HTTP، اعتبارسنجی ورودی یا پاسخ سرویس ناشی شده است، انجام میشود. میتوان درخواست و پاسخ را با ابزارهایی مانند Postman بررسی و شواهد لازم را برای تیم بکاند ثبت کرد.
-
بررسی خطاهای مرورگر
استفاده از Chrome DevTools برای بررسی خطاهای کنسول، درخواستهای شبکه و جزئیات پاسخ، تا مشخص شود رفتار مشاهدهشده در مرورگر از کدام بخش رابط کاربری، درخواست یا پاسخ سرویس ناشی شده است.
-
پیگیری باگ در اسپرینت
بهروزرسانی وضعیت باگ، ارائه اطلاعات تکمیلی به توسعهدهنده، ثبت تصمیمهای مرتبط با محصول و اطمینان از انجام آزمون مجدد پیش از بستهشدن تیکت.
-
آزمون مجدد پس از رفع
اجرای دوباره گامهای بازتولید روی نسخه اصلاحشده برای اطمینان از رفع باگ و بررسی اینکه تغییر جدید، بخشهای مرتبط را تحت تأثیر منفی قرار نداده است.
-
تحلیل الگوی نقصها
مرور باگهای تکراری یا پرتعداد برای یافتن بخشهای پرریسک محصول، ابهامهای نیازمندی یا نقاط ضعف در پوشش تست.
ابزارهای مرتبط
پیشنیازها
شروع این مهارت با دانستن پیشنیازهای زیر هموارتر میشود.
- دسترسی به یک نرمافزار یا محیط آزمایشی برای تمرین
- آشنایی پایه با رفتار مورد انتظار محصول یا نیازمندیهای آن
مسیر یادگیری تحلیل و مدیریت باگ
-
۸ ساعت
تشخیص نقص و تمایز آن از رفتار مورد انتظار
مفهوم نقص، خطا، خرابی و رفتار مورد انتظار را یاد بگیرید. چند سناریوی محصول را بررسی کنید و برای هرکدام مشخص کنید کدام مورد واقعا یک باگ محسوب میشود، کدام مورد ناشی از ابهام در نیازمندی است و کدام صرفا یک درخواست تغییر محسوب میشود.
نتیجه این گام، دستهبندی دستکم ۱۰ سناریو همراه با دلیل است. زمانی از این گام عبور کنید که بتوانید برای هر مورد به رفتار مورد انتظار یا قوانین محصول استناد کنید، نه صرفا برداشت شخصی.
-
۱۰ ساعت
بازتولید پایدار خطا
یک خطا را چند بار با داده و محیط یکسان تکرار کنید. متغیرهایی مانند نقش کاربر، مرورگر، دستگاه، نسخه برنامه، اتصال شبکه و داده ورودی را تغییر دهید تا شرایط ضروری رخداد خطا را از عوامل غیرمؤثر جدا کنید.
برای پایان گام، یک جدول شرایط رخداد بسازید و حداقل شرایط لازم برای بازتولید را مشخص کنید. فرد دیگری باید بتواند با استفاده از گامها، دادهها و محیط ثبتشده همان خطا را مشاهده کند یا دلیل تفاوت در نتیجه را تشخیص دهد.
-
۱۲ ساعت
نوشتن گزارش باگ قابل اقدام
برای هر باگ عنوان مشخص، پیششرط، گامهای بازتولید، نتیجه مورد انتظار، نتیجه واقعی و اطلاعات محیط را ثبت کنید. تصویر، ویدئو، متن خطا یا درخواست و پاسخ HTTP را فقط زمانی اضافه کنید که به فهم یا بازتولید مسئله کمک کند.
سه گزارش بنویسید و از فرد دیگری بخواهید با استفاده از آنها مسئله را بازتولید کند. گزارش زمانی قابل قبول است که ابهام مهمی درباره گامها، محیط یا تفاوت بین رفتار مورد انتظار و واقعی باقی نماند.
-
۱۲ ساعت
ارزیابی مستقل شدت و اولویت نقص
شدت را بر اساس اثر نقص بر کارکرد، داده، امنیت یا تجربه کاربر تعیین کنید. اولویت را با توجه به ارزش مسیر کاربر، زمان انتشار، تعداد کاربران درگیر و راهکار موقت ارزیابی کنید. برای چند باگ فرضی، دلیل تعیین شدت و اولویت هرکدام را بنویسید.
خروجی این گام، ارزیابی حداقل ۵ باگ با دو ستون مجزا برای شدت و اولویت است. ارزیابی زمانی مناسب است که دلیل هر تصمیم به معیارهای اعلامشده تیم یا سناریوی محصول متصل باشد و شدت با فوریت اشتباه گرفته نشود.
-
۱۰ ساعت
مدیریت چرخه باگ در ابزار پیگیری
پیش از کار با Jira، مفهوم ابزار پیگیری نقص را یاد بگیرید: تیکت، وضعیت، تخصیص، تاریخچه تغییرات، برچسب و پیوند با نسخه یا داستان کاربر، مفاهیمی مستقل از یک ابزار مشخص هستند. Jira یکی از ابزارهای رایج برای تمرین این فرایند است و میتوان همین فرایند را در ابزارهای مشابه یا حتی یک جدول ساختیافته نیز شبیهسازی کرد.
ایجاد تیکت، برچسبگذاری، تخصیص، تغییر وضعیت، ثبت نظر و پیوند دادن باگ به نسخه یا داستان کاربر را در Jira تمرین کنید. وضعیتهای مختلف را با فرایند تیم هماهنگ کنید؛ نام و تعداد وضعیتها میان تیمها یکسان نیست.
برای پایان گام، مسیر کامل دستکم ۳ تیکت را از ثبت تا بستن ثبت کنید. تاریخچه باید نشان دهد چه کسی، چه زمانی و با چه دلیلی وضعیت هر تیکت را تغییر داده و چه اطلاعاتی برای تصمیمگیری ثبت شده است.
-
۸ ساعت
آزمون مجدد رفع باگ و مستند کردن نتیجه
پس از اعلام رفع، ابتدا همان گامهای بازتولید را اجرا کنید. سپس بخشهای مرتبط با تغییر را بررسی کنید تا نشانهای از خطای جانبی پیدا شود. در صورت رفعنشدن مشکل، با شواهد جدید تیکت را بازگشایی کنید و در صورت تأیید رفع، دلیل بستن آن را بهصورت روشن ثبت کنید.
برای پایان گام، نتیجه آزمون مجدد را برای دستکم ۳ تیکت ثبت کنید. هر نتیجه باید نسخه یا محیط آزمون، نتیجه اجرای مراحل، شواهد تازه و تصمیم نهایی درباره بستن یا بازگشایی تیکت را شامل شود.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیشزمینه شما میتواند کمتر یا بیشتر باشد.
پروژههای تمرینی
در ادامه، مهمترین موارد این بخش به تفکیک معرفی شدهاند.
-
ثبت ۱۰ باگ برای یک فروشگاه اینترنتی آزمایشی
توضیح پروژه: یک وبسایت آزمایشی را در سناریوهای ثبتنام، جستوجو، سبد خرید و پرداخت بررسی کنید. هر مورد باید بر اساس رفتار مشاهدهشده در محیط آزمایشی یا یک سناریوی خطای ازپیشتعریفشده باشد؛ گزارش بدون امکان بررسی و بازتولید پذیرفته نیست. برای هر مورد، شواهد، شرایط بازتولید و ارزیابی شدت و اولویت را ثبت کنید.
-
بازتولید و محدودسازی یک خطای وابسته به محیط
توضیح پروژه: یک خطا را در دو مرورگر یا دو اندازه نمایشگر بررسی کنید. جدول کوتاهی از شرایطی ثبت کنید که خطا در آنها رخ میدهد یا رخ نمیدهد و در گزارش باگ، حداقل شرایط لازم برای بازتولید را بنویسید.
-
مدیریت چرخه یک مجموعه باگ در Jira
توضیح پروژه: برای ۵ باگ نمونه، تیکت ایجاد کنید و چرخه عمر آنها را از ثبت و تخصیص تا رفع، آزمون مجدد، بازگشایی یا بستن شبیهسازی کنید. برای هر تغییر وضعیت، دلیل کوتاه و قابل پیگیری ثبت کنید.
-
بازبینی کیفیت گزارشهای باگ
توضیح پروژه: ۵ گزارش باگ ناقص تهیه کنید، سپس آنها را بازنویسی و تکمیل کنید. در نسخه نهایی باید گامهای بازتولید، نتیجه مورد انتظار، نتیجه واقعی، اطلاعات محیط و شواهد لازم ثبت شده باشد.
پرسشهای رایج درباره تحلیل و مدیریت باگ
در این بخش، به تعدادی از پرسشهای رایج درباره این مهارت پاسخ داده شده است.
تفاوت شدت و اولویت باگ چیست؟
شدت، میزان آسیب نقص به عملکرد، داده، امنیت یا تجربه کاربر را نشان میدهد. اولویت، میزان فوریت و ترتیب رسیدگی تیم به نقص را مشخص میکند. یک باگ با شدت پایین ممکن است بهدلیل نمایش گسترده یا نزدیکبودن زمان انتشار، اولویت بالایی داشته باشد.
برای گزارش باگ چه اطلاعاتی باید ثبت کنم؟
عنوان مشخص، پیششرط، گامهای بازتولید، نتیجه مورد انتظار، نتیجه واقعی، محیط اجرا و شواهد مرتبط را ثبت کنید. اگر مسئله به داده یا حساب مشخصی وابسته است، داده موردنیاز را با نمونه امن یا توضیح کافی، بدون افشای اطلاعات حساس ثبت کنید.
اگر نتوانم باگ را دوباره ببینم، باید آن را ثبت کنم؟
بله، اما اگر خطا قابل بازتولید نیست، در گزارش صریح بنویسید که رخداد در تلاشهای مجدد تکرار نشده است. زمان رخداد، محیط اجرا، داده ورودی، لاگها و شواهد موجود را ثبت کنید. پیش از ثبت نهایی، متغیرهایی مانند مرورگر، نقش کاربر و اتصال شبکه را بررسی کنید تا شرایط احتمالی رخداد مشخص شود.
آیا هر خطایی که کاربر گزارش میکند باگ است؟
خیر. ممکن است مشکل از ابهام نیازمندی، استفاده خارج از سناریوی پشتیبانیشده، محدودیت طراحی، داده نامعتبر یا درخواست تغییر و قابلیت جدید باشد. ابتدا رفتار مشاهدهشده را با نیازمندیها و قواعد محصول مقایسه کنید.
برای شروع مدیریت باگ باید Jira یاد بگیرم؟
آشنایی با Jira برای بسیاری از تیمهای نرمافزاری مفید است، اما بخش اصلی مهارت به کیفیت تحلیل، گزارش و پیگیری باگ وابسته است. اگر به Jira دسترسی ندارید، میتوانید ابتدا چرخه عمر باگ و ساختار گزارش را با یک جدول یا ابزار مشابه تمرین کنید.
بعد از اعلام رفع باگ، چه کاری انجام دهم؟
همان گامهای بازتولید را روی نسخه اصلاحشده اجرا کنید. سپس بخشهای مرتبط با تغییر را بررسی کنید. اگر نقص باقی مانده یا خطای جانبی ایجاد شده است، تیکت را با شواهد تازه بازگشایی کنید؛ در غیر این صورت، رفع باگ را تأیید و تیکت را ببندید.
