Баг-репорт (Bug report) – документ, котрий містить звіт про баг (дефект, будь-який недолік, тощо) у компоненті або системі. Баг-репорт містить детальний опис помилки в програмному забезпеченні, котрий допомагає розробникам зрозуміти, що саме працює неправильно та наскільки критична проблема.
Для баг-репорту важливо, щоб він був зрозумілим, а дефект можна було однозначно відтворити, за вказаними кроками у зазначеному оточенні.
Основні атрибути баг-репорту
- ID: унікальний ідентифікатор
- Опис (Summary): короткий, ємний і зрозумілий опис помилки
- Оточення (Environment): посилання на білд/коміт/версію програмного забезпечення або оточення
- Кроки відтворення (Steps to reproduce): повний перелік кроків для відтворення помилки
- Очікуваний результат (Expected result): результат котрий очікується
- Фактичний результат (Actual result): результат отриманий фактично
- Вкладення (Attachments): логи, скріншоти, відео – все що необхідно для кращого розуміння помилки
Додаткові атрибути баг-репорту
- Попередні умови (Prerequisites)
- Тестові дані (Test Data)
- Серйозність дефекту (Defect Severity)
- Пріоритет дефекту (Defect Priority)
- Проект (Project)
- Коментарі (Remarks)
- Версія релізу (Release Version)
- Модуль (Module, компонент системи)
- Автор звіту (Reported By)
- Призначено на (Assigned To)
- Статус (Status)
- Fixed Build Version
В різних проектах, атрибути баг-репорту можуть налаштовуватись індивідуально, в залежності від використовуваних інструментів (Bug tracking system) і прийнятих практик.
Слід додати, що баг-репорти можуть створюватись не тільки QA інженерами, а й будь-якими членами команди, надходити від користувачів або support команди. У другому випадку, баг-репорт може потребувати попередньої верифікації, відтворення помилки та доповнень (в разі потреби). Також можливий аналіз того, яким чином помилка потрапила у продуктове середовище, та як можна уникнути цього в майбутньому.
Деякі практики при створенні баг-репортів
- в одному баг-репорті, один баг
- бажано впевнитись, що баг дійсно відтворюється (спробуйте відтворити його повторно)
- переконайтесь, що використовуєте актуальну версію програмного забезпечення і оточення
- попередньо перевірте в bug tracking system відсутність баг-репорту на аналогічний дефект
- локалізуйте помилку, щоб краще з’ясувати її першопричину
- додайте детальні кроки і повне оточення для відтворення помилки
- напишіть добре summary дефекту, за формулою «Що? Де? За яких умов?» (What? Where? When?)
- слідкуйте за поданням інформації в процесі написання повідомлення про помилку, не слід звинувачувати когось або виражати власну точку зору з приводу події, використовуйте тільки факти
- проілюструйте проблему за допомогою відповідних скріншотів, відео та логів, для більшої наочності