7️⃣Bug report

Bug report — це документ, який описує та пріоритезує знайдений баг, а також сприяє його усуненню.

Цілі bug report

• Надати інформацію про проблему.

• Пріоритезувати її.

• Сприяти усуненню проблеми.

У тестувальника немає завдання засипати команду незліченними баг репортами. Перед ним стоїть задача написати саме ті, які важливі для бізнесу і допоможуть вдосконалити ПЗ, яке випускається.

Дуже важливий момент: тестувальнику НЕпотрібно писати 1000 беззмістовних bug reports — він має оформити звіт таким чином, щоб робота з усунення помилок була ефективною.

Чому це важливо?

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

Логіка побудови bug report

Ця логіка дуже проста:

• Що зробили? (Кроки для відтворення).

• Що отримали? (Фактичний результат).

• Що очікували отримати? (Очікуваний результат).

Пояснимо на прикладі

Я запустив гру, але вона не працює, хоча повинна.

«Що зробили?» — запустили гру.

«Що отримали?» — гра не запускається.

«Що очікували отримати?» — що гра запускається.

Переваги такої логіки — це:

• Прозорість. Тобто не можна відхилитися у оповідальний стиль і написати щось зайве у звіті.

• Легко перевірити дефект. Це можливо тому, що ми чітко розуміємо, що було зроблено аби одержати цей неправильний результат.

• Ще до відтворення видно, чи є описаний випадок багом. Оскільки ми чітко знаємо, що прописано у вимогах, ми завжди можемо з’ясувати чи має програма вести себе наступним чином.

• Позбавлення від зайвої комунікації, яка може забирати час від більш пріоритетних завдань.