База знань

Bug report

Дефект (він же баг) – це невідповідність фактичного результату виконання програми очікуваному результату.

Дефекти виявляються на етапі тестування програмного забезпечення (ПЗ), коли тестувальник проводить порівняння отриманих результатів роботи програми (компонента або дизайну) з очікуваним результатом, описаним в специфікації вимог.

Отже, як тільки ми виявляємо баг, нам необхідно його задокументувати для продовження життєвого циклу дефекту. Документ, який описує баг, називається – баг репорт.

Баг репорт (bug report) – це технічний документ, який містить в собі повний опис бага, що включає інформацію, як про сам баг (короткий опис, серйозність, пріоритет і т.д.), так і про умови виникнення даного бага. Баг репорт повинен містити правильну, єдину термінологію, що описує елементи призначеного для користувача інтерфейсу і події даних елементів, що приводять до виникнення бага.

У загальному випадку, баг репорт складається з:

Шапка:

  • номер репорту;
  • короткий опис (короткий опис проблеми, Summary);
  • проект (назва поточного проекту);
  • компонент додатка (в якому виник дефект);
  • версія (версія білда, в якому знайдено баг);
  • серйозність (градація ступеня впливу на додаток бага);
  • пріоритет (черговість виправлення бага);
  • статус (відображає статус бага в своєму життєвому циклі);
  • автор (автор баг репорту);
  • призначення (хто повинен виправити дефект).     

Середовище:

  • операційна система, розрядність, Сервіс Пак, браузер, його версія і т.д.

Опис:

  • кроки відтворення (опис шляху, який призводить до виникнення дефекту);
  • фактичний результат (результат, до якого ми приходимо виконавши всі кроки відтворення);
  • очікуваний результат (результат, який повинен бути відповідно до вимог).

Додатки:

  • прикріплений файл (логи, скріншоти, інші документи, які можуть допомогти відтворити проблему або розв’язати цю проблему).

Незважаючи на таку велику кількість пунктів баг репорту, можна виділити кілька основних полів, присутність яких необхідна:

  1. Короткий опис. Поле, де ви хочете розмістити весь сенс усього баг репорту. Найчастіше, в короткому описі лаконічно відповідають на 3 питання: «Де?», «Що?», «Коли?» (Саме в такій послідовності, як би не хотілося змінити її за прикладом всім відомої гри).
  2. Серйозність. Дефект або повністю зупиняє працездатність програми, або тільки частину функціональності, або інше.
  3. Кроки до відтворення. Точний і зрозумілий опис всіх кроків, які призводять до появи дефекту, з урахуванням всіх необхідних вхідних даних і т.д.
  4. Фактичний результат. Результат, отриманий після проходження кроків до відтворення.
  5. Очікуваний результат. Очікуваний правильний результат, як правило, отриманий з вимог щодо розроблюваного ПЗ.
  6. Знімки екрану. Зробити знімок екрана з проблемною областю. Зберегти краще в форматі JPEG. На знімку виділити фрагменти, які явно вказують на дефект.

Хороший баг репорт повинен відповідати таким вимогам:

  1. Простота: не потрібно використовувати складні граматичні конструкції або неоднозначні висловлювання для опису дефекту. Потрібно застосовувати короткі ясні фрази, щоб уникнути неоднозначних кроків або визначень. Найкраще підходить оформлення у вигляді списку.
  2. Повнота.
  3. Об’єктивність: не можна вказувати на винуватця. Робота тестувальника полягає в тому, щоб представити об’єктивні дані для прийняття вірних рішень;
  4. Нейтральність:не можна вкладати емоції в опис дефекту. Не можна користуватися формулюваннями гумористичного або саркастичного характеру. Потрібно викладати суть дефекту зрозумілою і діловою мовою.

Баг репорт повинен:

  • викликати потребу виправити помилку;
  • спонукати програміста виправити помилку;
  • спонукати до прийняття бізнес рішень;
  • долати заперечення.

 

Набагато більше інформації на курсі базовий модуль тестування