Правила, яких необхідно дотримуватися, при складанні звіту про

помилки (bug report):

1. Одна помилка – один звіт про помилку (bug report): кожну виявлену
помилку необхідно писати в окремому звіті, так як фокусуватись на одній
проблемі ефективніше, ніж розглядати велику кількість проблем, а також,
щоб обговорення різних багів не накладалося одне на одного.
2. Вкажіть посилання на головний домен сайту.
3. Опишіть послідовність дій, які призвели до цієї помилки: програміст
при перевірці може втратити ту послідовність дій, яка привела до
виникнення тих чи інших недоліків.
4. Вкажіть, що отримали після виконання дій, які призвели до помилки і
що очікували отримати.
5. Зробіть скріншот / відео помилки з додаванням прямокутника
(виділяючи проблемне місце) і червоної стрілки, показуючи повністю всю
сторінку з адресним рядком браузера, але без панелі закладок / вкладок.

Кожен хороший опис помилки повинен містити рівно три речі:

1. Які кроки привели до помилки?
2. Що Ви насправді побачили?
3. Що Ви очікували побачити?

Поле «Тема» (Summary) в звіті про помилки повинно:

- містити максимально коротку, але достатню для розуміння суті проблеми
інформацію про баг;
- відповідати на «три вічні запитання»:
 «Що?» - що відбувається або не відбувається згідно специфікації або
розуміння тестувальника про нормальну роботу програмного продукту.
При цьому вказується наявність або відсутність об'єкта проблеми, зміст
вказується в описі (description). Якщо зміст проблеми варіюється, всі
відомі варіанти вказуються в описі.
 «Де?» - в якому місці інтерфейсу користувача або архітектури
програмного продукту знаходиться проблема.
  «Коли?» - в який момент роботи програмного продукту, по настанню
якої події або за яких умов проблема проявляється.
- бути достатньо коротким, щоб повністю поміщатися на екрані (в системах
відстеження помилок у програмних продуктах (bugtracker), де кінець
пропозиції в полі короткого опису (summary) обрізається або призводить до
появи скролінгу);
- (можливо) містити інформацію про середовище, під яким був виявлений баг
(залежить від вимог проекту);
- містити закінчене речення, якою б мовою воно не було описано,
побудованим за відповідними правилами граматики.
Таким чином, при написанні теми баг-репорта (summary) необхідно в
одному реченні вмістити сенс всього звіту про помилки (bug report), а саме:
коротко і ясно, використовуючи правильну термінологію, вказати: «що»,
«де», «при яких умов» не працює.

Наприклад:
1. Додаток зависає на екрані завантаження файлу після збереження
текстового файлу розміром більше 50 Мб.
2. Дані не зберігаються на формі «Профайл» після натискання кнопки
«Зберегти».
3. Поле «Підтвердіть пароль» не є обов'язковим на формі Реєстрації.
4. Текст списку відображається за межами виділеної області на головній
сторінці після наведення курсору на меню вкладки «COURSES».

Поле «Опис» (description) в звіті про помилки повинно:

− міститиопис в одному реченні за принципом: «Що?», «Де?», «Коли?»
відповідно до теми (тема і опис можуть бути ідентичними);
− містити кілька пропозицій за умови, що зазначена інформація вказує на
важливі нюанси, опис яких не вліз до теми через обмеження за кількістю
символів.

Не менш важливим полем для заповнення в звіті про помилки (bug

report) є поле «Кроки відтворення» (Steps to reproduce).
 Кроки відтворення (steps to reproduce) є найціннішою інформацією в
звіті, тому що саме вони скеровують дії для відтворення помилки для тих,
хто буде виправляти проблему, при цьому кроки повинні відповідати таким
вимогам:
− в першому кроці необхідно використовувати посилання на головний домен:
 Відкрити сайт http: // .... (Open the site http: // ...., Go to the site http: // ...);
− в кроках необхідно відповідати на питання: «що необхідно зробити?»:
 Натиснути кнопку «Знайти» (Click the «Знайти» button)
 Ввести валідний e-mail і пароль (Enter the valid e-mail and the password)
 Заповнити необхідні поля валідними даними (Fill the necessary fields
with valid data)
−в кроках необхідно коротко писати, що зробити, куди натискати, не
уточнюючи назви сторінки;
− описується як мінімум 2 кроки, але не більше 7-8 кроків;
−в разі, якщо кроків для відтворення буде дуже багато (більше 8), можна
вказати передумови (Preconditions), наприклад:
Користувач авторизований в системі. Товар було додано до кошика.
− в кроках необхідно уточнювати, на що саме необхідно натискати
(посилання, кнопку, логотип ...);
− кроки необхідно писати з великої літери;
− в останньому кроці необхідно описати, на яку область подивитися, на що
звернути увагу або що оглянути:
 Оглянути текст в випадаючому списку (підменю) (Look at the drop-
down list (the submenu)).
 Звернути увагу на форму «Profile» (Take a look at the «Profile» form, Pay
attention to the «Profile» form).
Фактичний результат (Actual result) і Очікуваний результат
(Expected result) повинні відповідати таким вимогам:
− результати в системі відслідковування помилок Mantis (Mantis bug tracking
system) необхідно описувати відразу після кроків в поле «Кроки відтворення»
(Steps to reproduce);
−результати необхідно описувати інформативно (відповідно до теми за
принципом: «Що?», «Де?», «Коли?», іноді можна використовувати «Що?»,
«Де?»);
− очікуваний результат слід вказувати після фактичного результату;
−результати НЕ потрібно нумерувати і НЕ варто писати кілька результатів в
одному дефекті;
− результати слід описувати повними реченнями з підметом і присудком;
− результати необхідно писати з великої літери;
− краще уникати формулювань очікуваного і фактичного результатів, які
відрізняються лише негативною формою. Очікуваний результат необхідно
детально описати, не достатньо просто додати заперечення в одне з речень.

При тестуванні веб-сайту браузер і його версію вказують в розділі

«Платформа» (Platform), якщо баг повторюється в різних браузерах, тоді
даний нюанс можна вказати в розділі «Додаткова інформація» (Additional
information).
В полі «Операційна система» (OS) пишеться назва операційної системи
(наприклад, Windows), в полі «Версія ОС» (OS Version) - версія операційної
системи (наприклад, 7 х64).