Як написати гарний баг-репорт. Поради від Senior QA

Довго думав яку статтю написати. Ну звичайно ж стаття має бути про тестування. І мені прийшла думка написати її про проблему, з якою сам стикався на початку своєї роботи тестувальником. І це, як ви вже зрозуміли: «Як написати гарний баг репорт?».

Навіщо потрібен хороший звіт про помилку?

Все дуже просто, якщо ваш звіт про помилку буде коректний, то шанси на його виправлення стають вищими. Таким чином, виправлення помилки залежить від того, наскільки ефективно ви повідомите про неї.

«Сенс написання звіту про проблему (звіту про помилки) полягає в тому, щоб виправити помилки»
Сем Канер

Поради щодо написання правильного звіту про помилку

Відтворюваність: якщо ваша помилка не відтворюється, вона ніколи не буде виправлена.

Необхідно чітко вказати кроки для відтворення помилки. Баг необхідно описати крок за кроком.

Як ідеальний кейс можна використовувати: «Відтворіть помилку три рази, перш ніж писати звіт про помилку».

Опис помилки: писати конкретно і по суті.

Постарайтеся описати проблему мінімальною кількістю слів. Не описувати кілька проблем, навіть якщо вони схожі. До кожної проблеми свій звіт.

Протестувати появу помилки на суміжних модулях. Іноді розробник використовує той самий код для різних схожих модулів. Таким чином, ймовірність того, що помилка в одному модулі виникне і в інших подібних модулях, вища.

Баги, що повторюються: це справжня «баласт» у циклі тестування.

Ознайомтеся зі списком відомих помилок. Іноді розробники можуть знати про цю проблему та ігнорувати її для майбутніх випусків.

Відповісти на 2 питання: “Як?” та “Де”?”. У звіті має бути чітко зазначено, як саме було проведено перевірку та де стався дефект. Людина яка читатиме вашу помилку повинна легко її відтворити і повторно не з’ясовувати у вас відсутні деталі.

Прочитайте репорт, перш ніж натиснути кнопку «Надіслати/Створити».  Прочитайте всі речення, формулювання та кроки, які використовуються у звіті про помилку. Подивіться, чи не створюють деякі речення двозначність, яка може призвести до неправильного тлумачення. Слід уникати слів або речень, які можуть не вірно зрозуміти.

Візуальний доказ/скриншот: іноді картинка коштує більше тисячі слів.

Скриншот або відео можуть не розповісти всієї історії, але вони принесуть велику користь, дозволяючи розробникам швидше побачити та зрозуміти проблему.

Очікувані та фактичні результати.  Коли ви повідомляєте про помилку, знайдіть час, щоб пояснити розробнику, що ви очікували і що сталося насправді.

Кроки для відтворення: завжди припускайте, що ваш розробник не має уявлення про знайдену вами помилку — як він її відтворить?

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

Якщо проблема відтворюється не кожен раз, ви можете увімкнути коефіцієнт відтворюваності (наприклад, 5/10 відтворення помилки).

Навколишнє середовище. Веб-сайти та програми можуть поводитися по-різному залежно від середовища.

Журнали консолі.  Ці журнали показують розробникам всі помилки, що виникають на веб-сторінці. Журнали також можуть містити інформацію, яка відстежує певні дії користувача.

Початковий URL.  Одним з важливихелементів, про які легко забувають, є вихідний URL. Це допоможе розробникам швидше орієнтуватися, що заощадить усім багато часу.

Серйозність та пріоритет помилки. Визначивши серйозність або пріоритет проблеми у своєму звіті про помилку, ваш розробник розуміє, як швидко помилка має бути виправлена.

Сподіваюсь, ці поради будуть вам корисними.

Цей текст з особистого блогу автора, опублікований з його дозволу.