Баг-репорт (Defect/bug report)
Звіт про дефект (defect report): Документ, що містить звіт про будь-який недолік у компоненті або системі, який може призвести компонент або систему до неможливості виконати потрібну функцію. (IEEE 829)
«Сенс написання звіту про проблему (звіт про помилку) полягає в тому, щоб виправити помилки» - Джем Канер. Якщо тестувальник неправильно повідомляє про помилку, то програміст, швидше за все, відхилитиме цю помилку, заявивши, що вона невідтворна. Або витратить купу зайвого часу на те, щоб зробити вашу роботу за вас. Чи такий тестувальник буде вигідний бізнесу, приємний колегам і довго затримається на своєму місці.
Головне при написанні звіту - він має бути одразу і однозначно зрозумілий читаючим, а дефект однозначно відтворено за вказаними кроками у вказаному оточенні.
Основні поля баг-репорту :
Унікальний ідентифікатор ( ID );
Опис ( Summary ): короткий, ємний та зрозумілий опис помилки;
Оточення ( Environment ): посилання на білд/комміт/версія ПЗ та всього оточення;
Кроки відтворення ( Steps to reproduce ): повний перелік кроків для відтворення;
Очікуваний результат ( Expected result ): який результат мав бути без помилки;
Фактичний результат ( Actual result ): який результат вийшов насправді;
Вкладення ( Attachments ): логи, скріншоти, відео - все, що необхідно для розуміння помилки.
Додаткові :
Попередні умови (Prerequisites);
Тестові дані (Test Data);
Серйозність дефекту (Defect Severity);
Коментарі (Remarks);
Проект (Project);
Продукт (Product);
Версія релізу (Release Version);
Модуль (Module);
Виявлено у версії (Detected Build Version);
ймовірність виникнення дефекту (Defect Probability);
Пріоритет дефекту (Defect Priority);
Автор звіту (Reported By);
Призначено (Assigned To);
Статус (Status);
Fixed Build Version.
У разі використання TMS поля будуть налаштовані лідом/менеджером і залежно від розмірів проекту можуть бути пункти на зразок milestone, epic, feature тощо.
Крім іншого, баг-репорти можуть створюватися не тільки тестувальниками, а й будь-якими членами команди, приходити від користувачів або техпідтримки. У другому випадку необхідно буде відтворити помилку, скласти баг-репорт за всіма правилами або доповнити надісланий, потім провести ретроспективу на тему того, як помилка потрапила в прод і як цього уникнути в майбутньому.
Декілька ключових моментів, які слід враховувати при написанні звіту про помилку:
В одному звіті один баг;
Відтворіть його 2-3 рази;
Переконайтеся, що ви використовуєте актуальну версію ПЗ та оточення;
Перевірте наявність багтрекінгової системи на наявність звіту про такий же дефект;
Локалізуйте помилку, щоб з'ясувати її причину;
Напишіть докладні кроки та повне оточення для відтворення помилки;
Напишіть гарний summary дефект за формулою “Що? Де? При яких умовах?" (3 Ws, WWW - What? Where? When?);
Слідкуйте за словами в процесі написання повідомлення про помилку, вони не повинні звинувачувати, ображати людей, містити якусь точку зору щодо того, що сталося. Загалом, лише факти у справі;
Проілюструйте проблему за допомогою правильних скріншотів, відео та логів;
Перед надсиланням перевірте ще раз звіт про помилку. А потім ще раз;
Джерела:
Дод. матеріал:
Last updated