Що таке Bug і Bug Report в тестуванні?

Що ж таке баг?

Якщо коротко, то баг — це сленгове позначення програмної помилки. У свою чергу програмна помилка — це помилка у програмі або системі, через яку програма виявляє неочікувану поведінку і, як наслідок, видає результат, який не відповідає плану. Тобто, bug — це розбіжність між очікуваним і фактичним результатом.

День народження багу

Днем народження першого комп’ютерного багу вважаєть 9 вересня 1945 року, коли вчені Гарвардського університету знайшли в обчислювальній машині справжнього метелика (з англ. "bug"), що застряг в електромеханічному реле. Цю комаху вони приклеїли в технічний журнал із підписом: «Перший задокументований випадок знаходження багу».

Трохи гумору

«Склянка наполовину повна», — говорить оптиміст.

«Склянка наполовину порожня», — говорить песиміст.

«Скланка наполовину порожня й повна одночасно, оскільки у склянці отвір, який відповідає специфікації», — говорить тестувальник.

З багами стало зрозуміліше, але що ж таке bug report?

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

Цілі bug report

Надати інформацію про проблему.
Пріоритезувати її.
Сприяти усуненню проблеми.

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

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

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

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

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

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

Що зробили? (Кроки для відтворення).
Що отримали? (Фактичний результат).
Що очікували отримати? (Очікуваний результат).

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

Я увімкнув гарячу воду, але вона не тече, хоча і повинна текти.

«Що зробили?» — увімкнули гарячу воду.

«Що отримали?» — вода не тече з крану.

«Що очікували отримати?» — вода має текти.

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

Прозорість. Тобто не можна відхилитися у оповідальний стиль і написати щось зайве у звіті.
Легко перевірити дефект. Це можливо тому, що ми чітко розуміємо, що було зроблено аби одержати цей неправильний результат.
Ще до відтворення видно, чи є описаний випадок багом. Оскільки ми чітко знаємо, що прописано у вимогах, ми завжди можемо з’ясувати чи має програма вести себе наступним чином.
Позбавлення від зайвої комунікації, яка може забирати час від більш пріоритетних завдань.

Життєвий цикл bug report

Ми розглянемо найпростіший життєвий цикл, який складається з наступних кроків:

Open. Знайдений баг занесено до баг-трекінгової системи.
In progress. Над проблемою розпочато роботу.
Fixed. Баг виправлено.
Verified. Підтвердження, що баг виправлено.
Closed. Баг закрито.

Поради щодо створення гарного bug report

Створюйте зрозумілі для всіх учасників команди заголовки баг репортів.
Користуйтеся пошуком. Можливо, ваш колега вже зробив такий самий баг репорт. А навіщо проекту і замовнику кілька однакових репортів?
Користуйтеся форматуванням. Це полегшить завдання тому, хто буде фіксити 30+ багів в системі.
Після того як ви завели баг репорт, обов'язково повідомте про це всю команду і окремо – людину, на який лежить відповідальність за виправлення бага.