وقتی کاربر در حال کار با برنامه است، در صورت مشاهده باگ برای خارج شدن از برنامه درنگ نمی کند. بسیاری از tester های بتا و کاربران نهایی نمی دانند چگونه می توان یک گزارش باگ نوشت که شامل تمامی جزئیات مورد نیاز باشد که تیم توسعه دهنده آن ها را حل و رفع کند. اگر شما توسعه دهنده هستید و در حال تلاش برای مرتب سازی گزارش های دریافتی هستید، به خوبی می دانید که باید تمامی موارد ذکر شده را در برنامه درست کنید. معمولا اکثر اوقات این گزارشات نامفهوم و پیچیده هستند و درک آنها سخت و زمان بر است. برای حل این مشکل یه سری استاندارد برای نوشتن گزارشات باگ آماده شده است. داشتن یک گزارش باگ استاندارد، برای توسعه دهنده یا برنامه نویس کاربردی تر است. همچنین نوشتن و تهیه گزارش باگ از طریق این استانداردها برای tester یا کاربر نیز راحت تر و سریع تر میشود. تحقیقات نشان می دهد که تهیه گزارشات باگ 45 درصد از وقت شخص تهیه کننده را در بر میگیرد.
از این رو در ادامه به بررسی نحوه نوشتن یک گزارش اشکال استاندارد و بدون نقص می پردازیم.
گزارش باگ یا bug report چیست؟
گزارشات باگ شامل تمامی مشکلات و باگ های موجود در برنامه تولید شده است. این گزارشات باید در اختیار برنامه نویس یا تیم توسعه دهنده قرار گیرد تا آگاه شود که کدام بخش از کد ها نیاز به بهبود دارد. معمولا رفع این باگ ها برای توسعه دهندگان یک کار دلهر آور است که اگر شخص یا تیم اطلاعات کافی نداشته باشند، نمی توانند آن باگ ها رفع کنند. اما نگران نباشید!
خوشبختانه tester ها می توانند این فرایند و پروسه را با ارسال گزارش باگ با کیفیت و استاندارد آسان و سریعتر کنند. یعنی از طریق از این گزارشات تمام سرنخ های مورد نیاز برای رفع آن اشکالات را در اختیار توسعه دهنده قرار دهند.
یک گزارش باگ، باید شامل اشکالات و باگ باشد. باگ ها باید به صورت واضح و مختصر در گزارش قرار بگیرند.
همچنین باید شامل جزئیاتی از محیط و مراحل کاربر باشد که توسعه دهنده بتواند مشکلات آنها را در کد خود پیدا و حل کند.
چگونه یک گزارش باگ استاندارد و عالی بنویسیم؟
در واقع طرز نوشتن گزارش باگ به نوع برنامه بستگی دارد. ممکن است عناصری که در ادامه بیان میکنیم، در هر برنامه نیاز به تغییرات داشته باشد.
ویژگی های گزارش باگ استاندارد
عنوان یا title
عنوانی ایده آل است که واضح و کوتاه باشد. عنوان یک گزارش باگ، باید یک خلاصه از باگ ها را به توسعه دهنده ارائه دهد. همچنین می تواند شامل دسته یا بخشی از برنامه باشد که در آن باگ مشاهده میشود. به طور کلی یک عنوان واضح، باعث شناسایی راحت تر باگ ها برای توسعه دهندگان میشود. با شناسایی گزارشات تکراری، کار تست باگ ها نیز بسیار ساده تر می شود.
به عنوان مثال:
[profile] هنگام چت، عکس پروفایل مشکی نشان داده میشود.
شدت و اولویت
شدت نشان دهنده میزان اهمیت یک موضوع است. سطوح و تعاریف شدت بین توسعه دهندگان برنامه های مختلف و حتی بیشتر بین توسعه دهندگان، tester ها و کاربران نهایی که از جزئیات بی اطلاع هستند، متفاوت است. معمولا به صورت زیر دسته بندی و طبقه بندی میشوند:
بحرانی/مسدود کننده : هنگامی که یک باگ برنامه را غیرقابل استفاده میکند و یا باعث از بین رفتن داده های آن میشود.
زیاد : وقتی که باگ بر روی یکی از ویژگی های اصلی تاثیر می گذارد و روش های حل بسیار پیچیده ای دارد و یا اصلا ندارد!
متوسط : هنگامی که باگ بر روی یک ویژگی جزئی یا اصلی تاثیر می گذارد، اما برای حل آن یک سری راه حل های آسان وجود دارد.
کم : باگ هایی که باعث ایجاد مشکلات جدی نیستند و تاثیر قابل توجهی بر تجربه کاربر ندارند. مانند باگ های ظاهری جزئی.
توضیحات یا شرح
توضیحات یک نمای کلی از نحوه و زمان وقوع باگ است که باید به صورت مختصر نوشته شود. نوشته های این بخش باید کامل تر از عنوان باشد. برای مثال می تواند شامل یک سری اطلاعات در مورد این باشد که آن باگ هر چند وقت یکبار ظاهر میشود و به نظر می رسد چه شرایطی باعث ایجاد شده اند.
محیط
برنامه ها می توانند با توجه به محیط، رفتارهای کاملا متفاوتی داشته باشند. بخش محیط باید شامل تمام جزئیات مربوط به تنظیمات محیط و پیکربندی برنامه ای باشد که برنامه در آن اجرا می شود. اگر به اطلاعات خاصی در مورد نیاز دارید، مطمئن شوید که برای کاربران یا tester ها واضح باشد.
برای مثال:
- شماره سازنده و مدل دستگاه
- سیستم عامل
- نسخه سیستم عامل
- نسخه برنامه
- ارتباط شبکه
- وضعیت باتری
- جهت صفحه
مراحل بازبینی
این بخش باید شامل حداقل مراحل مورد نیاز برای تکثیر باگ باشد. در حالت ایده آل مراحل باید کوتاه، ساده و برای هر کسی قابل پیگیری باشد. با این اوصاف، تست کنندگان و کاربران خود را جزئیات بیشتری را به شما ارائه دهند. هدف این است که به توسعه دهنده اجازه دهیم تا باگ هایی موجود در کد را دوباره تولید کند تا یک دید بهتر نسبت به مشکلاتی که ممکن است رخ دهد، بدست آورد. گزارش باگی که مراحل بازبینی ندارد باعث اتلاف وقت و تلاش میشود که بهتر است برای گزارشات تخصصی و اختصاصی تر استفاده شود. از این مطمئن شوید در مواقع درست و صحیح از این روش استفاده میکنید.
نتیجه واقعی
منظور از نتیجه واقعی، خروجی است که تست کننده یا کاربر مشاهده می کند. برای مثال در برنامه یک خطا ایجاد می شود که در آن نوشته : Invalid format
پیوست ها
پیوست ها می توانند برای توسعه دهندگان بسیار مفید باشند تا مشکل را سریعتر مشخص کنند. برای مثال در موضوع های مربوط به ظاهر، میتوان با تهیه یک اسکرین شات توضیحات مورد نیاز را به توسعه دهندگان ارائه داد. این پیوست ها تاثیر زیادی در راهنمایی توسعه دهندگان خواهد داشت.
جزئیات ارتباطات
در صورت نیاز به جزئیات بیشتر در مورد یک باگ، یک آدرس ایمیل به شما داده میشود که در آن برنامه نویس یا توسعه دهنده می تواند به شخص ارسال کننده باگ دسترسی داشته باشد و سوالات خود را از او بپرسد.
البته توجه داشته باشید که پاسخگویی کاربر به ایمیل ها توسط کاربر می تواند یک چالش باشد. بنابراین برای به حداکثر رساندن پاسخ دهی، می توان کانال های ارتباطی دیگری را نیز در نظر گرفت.
