Bug report, або звіт про помилку, є одним із ключових документів у роботі тестувальників. На практиці ж QA-початківці не завжди можуть підготувати такий звіт грамотно й зрозуміло. Одні — не дотримуються структури баг-репорту, інші — не адаптують звіт відповідно до різновиду тестування програмного забезпечення. А хтось просто не знає, як правильно повідомити про помилку та зазначити це в документі.
Розібратися із цими питаннями допоможе Акім Тонконоженко, QA Lead в ІТ-команді NIX. У статті експерт зібрав базові, практичні поради з написання дієвого bug report.
Що таке баг-репорт
Баг-репорт — це структурований звіт про помилку, баг, у цифровому продукті: мобільному застосунку, онлайн-сервісі, на сайті тощо. Зазвичай цей артефакт готують тестувальники. Для цього вони використовують різні інструменти для звітування про помилки. Та в реальності до процесу може долучитися майже будь-хто: від розробників і проєктних менеджерів до власників продукту та навіть користувачів (наприклад, через форму зворотного зв’язку). Але якісний bug report — це не просто повідомлення про помилку, що щось не працює. Звіт повинен описати місце, де стався збій застосунку, перерахувати умови, показати вплив на роботу продукту та юзерів.
Що вважати багом
Запитання із підзаголовка може здатися дивним. Але насправді це важливий момент в обговоренні, як написати баг-репорт. В різних командах можуть по-різному трактувати, що писати в документі та як вести наявні бази даних помилок. Десь говорять лише про критичні збої. Десь про будь-які відхилення у поведінці продукту від очікуваного результату. А десь — про усі знайдені проблеми. Тому як домовились на проєкті, так і буде відбуватись процес тестування, звітування й відстеження помилок.
Але все одно треба знати теорію й не плутати терміни, які деякі QA-фахівці часто використовують у bug report як синоніми. Ви маєте чітко розрізняти:
- Баг. Це виникнення помилки в коді, через яку щось працює не так, як треба. Відхилення можуть стосуватися функціональності (не реагує кнопка Зберегти), продуктивності (сторінка входу повільно завантажується), інтерфейсу (з’їхала фото на сторінці), безпеки (порушення в авторизації) тощо. Багом можуть бути навіть невірні повідомлення для користувачів і неточності у перекладі меню.
- Дефект. Це більш широке поняття у процесі звітування про помилки. Дефект вказує на будь-які відхилення від вимог чи специфікацій продукту. Тобто з одного боку, цим терміном можна назвати технічну помилку, баг. Але дефект може стосуватися й проблеми реалізації (дизайнери переплутали макет для кнопки) або помилки в описі бізнес-логіки (всі взагалі забули про ту кнопку).
- Іш’ю. Слово issue перекладається як «проблема». Але в контексті bug report воно скоріше означає будь-яку задачу у системах звітності про помилки. Тобто за issue можна вважати запис у Jira або GitLab про якийсь баг. Але також це про майже все інше: нову фічу, поліпшення (імпрувмент), технічний борг тощо. Тобто кожен баг — це іш’ю, але не кожен іш’ю — це баг.
- Прод-баг. У деяких випадках його називають інцидент. Це серйозне порушення роботи у продакшн-середовищі та у юзерів. Тобто це результат виникнення помилки, яку не виявлено на ранніх стадіях у тестовому чи дев-середовищі. Проблема вимагає швидкої реакції та навіть окремої обробки в програмному забезпеченні для звітності про помилки та власного процесу налагодження.
Чому bug report важливий
Звіт про помилку в програмному забезпеченні — це один із ключових способів комунікації тестувальників і розробників. Його часто порівнюють з діагнозом хвороби: якщо він точний і зрозумілий, то швидким і якісним буде лікування. Тобто виправлення помилок. Але це не єдина причина відповідально розібратися, як написати bug report. У нього є інші цілі:
- Фіксація проблеми. Коли все документується у системі відстеження, нічого в процесі тестування не загубиться (на відміну від повідомлень про помилку у тому ж Slack). А тому пошук в наявних базах даних помилок буде простим.
- Визначення серйозності багу. За допомогою звіту про помилку можна показувати й сортувати технічний рівень дефектів. Деякі з проблем можна виправити буквально в кілька кліків, а інші потребують серйозних змін у коді.
- Пріоритизація. Проблем у продукті може бути багато, а ресурсів — обмаль. Якщо не систематизувати відстеження помилок, складно вирішити, з чого починати. Дієві баг-репорти допомагають визначати більш важливі проблеми.
- Економія часу розробників. Добре складений bug report, де є якнайбільше деталей, дозволяє девелоперам одразу зрозуміти проблему. Інакше ці фахівці будуть вимушені звертатись до тестувальників з уточненнями, що призводить до зайвих витрати часу.
- Висока якість програмного забезпечення. Детальний опис знайдених проблем дає змогу з першої спроби виправити баг. Якщо ж буде поганий звіт про помилку, команди розробників можуть опрацювати дефект лише частково.
Структура баг-репорту
Єдиного універсального шаблону ефективного звіту про помилки не існує. Елементи у bug report можуть змінюватися відповідно до проєкту, типу тестів, формату у системі звітності про помилки на кшталт Bugzilla чи GitHub Issues та навіть традицій конкретної QA-команди. Але в будь-якому випадку документ повинен бути структурованим і мати тему, опис помилки, кроки для відтворення, очікуваний і фактичний результат та деяку додаткову інформацію. Про кожен із цих пунктів варто розповісти окремо.
Тема / Summary
Це перше, що бачить розробник. Тож саммері має повідомити про помилку. Але не слід писати у темі баг-репорту лише «Критичний збій застосунку!» чи «Поламка реєстрації». Потрібно коротко, але описово вказати на баг. Для цього можна використати підхід що-де-коли: «Не працює кнопка «Купити» (що сталося) у десктопній версії застосунку (де виникло) після вибори товару (коли проявляється)». Є й альтернатива: де-що-коли.
Опис / Description
В дескрипшені bur report необхідно в кількох реченнях розповісти про суть знайденої проблеми. Наприклад, «Коли користувач на iPhone 15 Pro зберігає в застосунку зміни у своєму профілі, система зависає на понад 20 секунд. Ніяких повідомлень на кшталт «Почекайте, йде синхронізація» немає. Журнали пристрою порожні». Такий опис помилки дозволить розробникам одразу прикинути варіанти виправлення дефекту.
Кроки для відтворення / Steps to Reproduce
В цьому розділі звіту про помилку слід перерахувати всі кроки, які ведуть до проблем. Це можна оформити як список дій, навіть на перший погляд саме собою зрозумілих. Наприклад, «1. Відкриваємо сайт у Chrome на Samsung Galaxy S24. 2. Обираємо будь-який товар. 3. Додаємо до кошика. 4. Не бачимо змін у кошику». Це повідомлення про помилку економить час розробника і гарантує: він повторить ваш шлях.
Очікуваний результат / Expected Result
Початківці доволі часто не приділяють уваги цьому пункту. Адже все ніби є очевидним: кнопка має працювати, реєстрація відбуватись, товар додаватись до кошика, сторінка завантажуватись швидко. Але тестувальники все одно мають прописати у bug report, що відбувається при нормальній роботі. З одного боку, це знімає ризик непорозуміння з розробниками. З іншого, інколи бізнес-логіка може бути дійсно складною, неочевидною.
Фактичний результат / Actual Result
Комусь із новачків може здатися цей розділ таким, що повторює те, що було вказано в інших пунктах. Але фактичний результат важливий в обговоренні правил, як написати дієвий звіт про помилку. Окремий пункт з чіткою фразою на кшталт «Сайт після реєстрації видає сторінку 404, після її оновлення вхід за вказаними кредами не відбувається» дозволяє розробникам звернути увагу на ключовий момент.
Технічні атрибути / Technical Attributes
Це інформація, необхідна для дотримання процесів розробки та QA на проєкті. Передусім серед таких атрибутів є дані про спринт, версію або реліз і середовище: білд, версія, операційна система, пристрій, браузер тощо. Також можуть бути журнали консолі чи серверу, розширення в браузері та навіть вказівки на тип зв’язку (WiFi або стільниковий). Все це значно прискорює процес обробки баг-репорту.
Додаткова інформація / Additional Information
Звіт можна доповнювати ще й іншими корисними даними. Насамперед це візуальні докази: скриншот або відео з відтворенням помилки. Вони дуже сильно спрощують розуміння проблеми для команди розробників. Окрім цього, ви можете додати в bug report майже будь-яку інформацію. Наприклад, чи відтворюється проблема на інших пристроях або чи спостерігались якісь дійсно незвичайні обставини.
Зверніть увагу на це при написанні баг-репорту
- У звіті про помилку має бути один баг. Не об’єднуйте проблеми — це може заплутати розробника. Виключення: кілька однотипних багів або вони пов’язані. Тоді один репорт спростить роботу девелопера та не буде спамити команду.
- Показувати серйозність. В системах звітності про помилки варто давати оцінку Severity, технічної серйозності: Blocker (блок застосунку або головної функції), Critical (серйозний дефект), Major (помилка, яку можна обійти), Minor (малі баги).
- Чіткий опис помилки. Інформація в якісному баг-репорті має бути конкретною і точною. Уявіть, що людина, яка буде знайомитись із цим документом, взагалі не знає продукту. А тому їй має бути зрозумілим все про баг лише з вашого тексту.
- Треба уникати емоційності. Гучні фрази про «все пропало», драматичні порівняння, потрійні знаки оклику — це зайве для bug reports. Ви маєте повідомити про помилку через сухі факти, без стилістичних прикрас.
- Детальна інформація. Ефективний баг-репорт має містити всі дані, які потрібні для розуміння та, що головніше, відтворення помилки. Не можна упускати якісь важливі нюанси. Інакше це заважатиме оперативному виправленню помилок.
- Лаконічність. Ця порада багато в чому пов’язана з попередньою. Початківці, намагаючись надати повну інформацію, інколи йдуть в інший бік — і починають в повідомленні про помилку «лити воду». Це заважає зрозуміти суть проблеми.
- Дотримуватись об’єктивності. У звіті про помилку не місце для припущень — потрібні факти. Тестувальники не можуть використовувати в документах для відстеження помилок слова на кшталт «мабуть» або «мені здається».
- Все перевірити. Деякі проблеми з’являються за умови 100500 факторів. Тому перед збереженням репорту у програмному забезпеченні для звітності про помилки слід переконатися, що баг дійсно відтворюється за вашим сценарієм.
Приклад якісного баг-репорту
Summary:
Не змінюється пароль користувача на Android.
Description:
Коли користувач Android-застосунку змінює свій пароль, система зависає після спроби збереження нових даних. Перезавантаження застосунку не допомагає. Одна й та сама помилка з’являється на різних смартфонах з цією ОС.
Steps to Reproduce:
- Увійти в застосунок зі старим паролем.
- Відкрити розділ Профіль.
- Перейти в пункт меню Редагувати пароль.
- Ввести старий пароль та двічі новий пароль.
- Натиснути кнопку Зберегти.
Expected Result:
Пароль оновлюється. Користувачу демонструється повідомлення «Збережено новий пароль». Після 5 секунд юзера автоматично повертає до розділу Профіль.
Actual Result:
Продукт перестає реагувати, в циклі крутиться колесо. Після перезавантаження застосунку бачимо: нові дані не збереглися, доступ відбувається за старим паролем.
Additional Information:
- Пристрій: Xiaomi 14T, Pixel 7 Pro, Samsung Galaxy A55.
- Операційна система: від Android 13 і вище.
- Візуальний доказ: Додано запис відео.
- Журнали пристрою: помилки відсутні.
- Коментар: перевірено також на версії для iPhone 15 з iOS 17 — все працює коректно.
Поганий приклад
Summary:
Не працює кошик!!!
Description:
Це якийсь треш. Я додаю товари в кошик, але все зависає, нічого не оновлюється. Швидко виправте цей збій застосунку, бо ми втрачаємо тисячі клієнтів!
Steps to Reproduce:
- Обрати товар.
- Перейти в кошик.
- Нічого не працює.
Expected Result:
Юзер купує товар.
Actual Result:
Продукт не працює!
Additional Information:
(відсутня).
Цей зразок — приклад того, як писати баг-репорт не треба. В ньому немає нічого, що дійсно має значення для процесу налагодження. Адже що таке звіт про помилку в програмному забезпеченні? Це корисна інформація в усіх деталях. А тут тема без конкретики. Опис сповнений емоційних висловів, але не об’єктивних фактів, як деталі середовища й багу. Відтворити дефект за вказаними у bug report кроками може бути дуже складно або неможливо. Очікуваний результат не про бізнес-логіку. А фактичний результат, візуальні докази та додаткова інформація відсутні. Тому треба справді відповідально заповнювати шаблон звіту про помилку — навіть якщо в центрі уваги буде лише якась незначна проблема інтерфейсу.
Поширені помилки при написанні баг-репорту
- Загальні теми. Початківці нерідко не вказують у саммері, що, де та за яких умов не працює. Це ускладнює сортування звітів у системі відстеження помилок.
- Спрощені кроки для відтворення. Часто новачкам здається: у використанні продукту все зрозуміло. Та розробники можуть не знати конкретного юзер-флоу.
- Емоції замість конкретики. Красиві слова — не для дієвого звіту про помилку. В описі та інших розділах все має бути сухо, з фактами та роз’ясненнями.
- Неочевидні умови. Інколи виникнення помилки спостерігається за особливих обставин — наприклад, коли користувач залогінений. На це треба акцентувати.
- Проблеми з фактичним і очікуваним результатами. Хтось вважає: це повтори. Тому не заповнює ці графи у bug report або виконує це формально.
- Без середовища. Часом помилки є лише на окремих пристроях чи операційних системах і браузерах. Без цих даних девелопер може й не побачити проблеми.
- Відсутність візуальних доказів. Додавання скриншотів, запису екрана, логів та інших артефактів дуже спрощує для розробників розуміння проблеми.
- Без додаткової перевірки. До надсилання баг-репорту слід переконатися, що ви нічого не забули (тут може допомогти чекліст), і перевірити саму помилку.
Знайте міру в деталізації
Бажання надати максимум інформації інколи грає поганий жарт із новачками — і вони витрачають час на другорядні деталі чи довгий збір візуальних доказів. Наприклад, перераховують і додають у bug report скриншоти про кожен крок для відтворення: відкрив браузер, прописав адресу, клацнув Enter для збереження у формі зворотного зв’язку. Або вказують зайві параметри середовища — типу Chrome 136.0.7103.114. Або додають великі файли журналів, де важко відшукати потрібну дрібницю.
Деталізація має бути виправданою. Не слід перетворювати якісний баг-репорт на покрокову хроніку дій. Не треба згадувати базові для будь-якого технічного фахівця моменти. Не варто занурюватися в параметри, які лише відволікають. Пам’ятайте: ви маєте надати ефективний звіт про помилку, аби допомогти командам розробників локалізувати та виправити дефект. Тож у вас має бути баланс між повнотою та стислістю. Тоді й відгук «користувачів» вашого документа буде виключно позитивний.
Як тип тестування впливає на написання баг-репорту?
Загальні структура та формат звіту про помилки є незмінними майже в будь-якому випадку. Тобто елементи та основні підходи до викладення інформації зберігаються, що б ви не перевіряли в цифровому продукті. Але залежно від виду тестів змінюються фокус та дані, які треба додавати в bug reports.
Функціональне тестування
Базові перевірки, чи працює система відповідно до очікуваного результату. В цьому випадку уся увага на юзер-флоу і реакції продукту. Тому в баг-репортах зростає роль послідовності кроків для відтворення помилки. Важливим є посилання на вимоги або цитата з них. Наприклад, що має відбуватись після натискання кнопки. Плюсом буде указівка ролі юзера (незареєстрований, адмін тощо) та окремі залежності в процесах.
Нефункціональне тестування
Ці тести перевіряють не те, що система робить, а як саме робить. Це може стосуватись продуктивності, безпеки, зручності. На перше місце виходять діагностична інформація та метрики: час відгуку і завантаження, ресурси, логи. Розробникам допоможуть і дані про інструменти. Наприклад, який у вас сканер безпеки чи які ваші дії у запуску JMeter. Ще варто у звіт про помилку додати тригер поламки — припустимо, кількість запитів.
Регресійне тестування
Перевірка працездатності після оновлень продукту — тобто чи не поламалось те, що раніше працювало. Треба не просто повідомити про помилку, а ще вказати зв’язки зі старими тестами й номери тест-кейсів. Слід навести і реліз, де така ж перевірка була успішна. Гарний тон у bug report — опис того, що змінилось у новій версії програмного забезпечення. Це допоможе розробникам у пошуках, з чим пов’язана нова помилка.
Тестування бекенду
Таке тестування найбільше відрізняється від традиційного з інтерфейсом. Перевірки йдуть через запити до API. Тому замість «Натиснув таку-то кнопку» і «Не оновлюється сторінка входу» у bug report будуть фрази на кшталт «Використав такий-то метод», «Передав ці параметри» чи «Отримав HTTP-респонс». Також слід вказувати структуру запитів і відповідей (JSON або XML), статуси, надавати журнал помилок.
Автоматизоване тестування
Баг-репорти для тестів, які запускаються автоматично, в чомусь схожі на попередні — тут важлива технічна інформація. Головне — це логи автотесту, фрагмент коду чи скрипт, які впали, та стек трейс самого багу. Ще варто дати посилання на джобу CI/CD (Jenkins, GitLab Pipelines тощо). Але не можна плутати фейл в автотесті з помилкою в продукті! Якщо проблема в самому тесті, для цього заводиться окремий документ.
А як впливає проєкт?
Інколи новачки, які вже вивчили, як написати ефективний баг-репорт, починають на проєкті випадати з робочих процесів. А все тому, що в цій команді існує свій шаблон звіту про помилку. В ньому можуть бути інший порядок елементів, деякі з них об’єднані, а деякі відсутні чи замінені. Це — цілком нормальна ситуація. Адже у вас може бути той самий процес, але — з певними відмінностями.
Особливості продукту
Залежно від галузі та бізнес-процесів конкретного сервісу чи застосунку акценти в роботі QA-команди можуть змінюватися. Це позначається й на підготовці bug report. Наприклад, на сайті для замовлення доставки їжі основна увага йде на відстеження помилок в UI. А в медичному застосунку — на стандартах безпеки. При цьому у звіті можуть з’являтися поля, припустимо, для специфічних ідентифікаторів контрактів.
Інструменти для звітування про помилки
Всі популярні тулзи для написання дієвих баг-репортів мають власні формати, шаблони та навіть назви для розділів — наприклад, Title замість Summary. Також трекер помилок може мати інші поля. Припустимо, в Jira це Pre-Conditions чи RCA, Root Cause Analysis. В GitHub Issues звіт може виглядати взагалі як текст із чеклістом. А в деяких випадках тестувальники все це ще й прив’язують до User Stories та тест-кейсів.
Формальні вимоги
Замовники можуть мати свої побажання щодо формату звітів про помилки. Наприклад, інколи вимагають вказувати у баг-репорті посилання на конкретний розділ специфікації. Або, припустимо, додати у цикл зворотного зв’язку HAR-файл з мережевими логами і відповідною фоновою інформацією. Вимоги можуть стосуватися й іншого — на кшталт визначення і Severity, і Priority тестувальниками (пріоритети традиційно є задачею PM).
Традиції в команді
Зазвичай на проєкті стандарт того, як писати bug report, задає хтось із менеджменту QA-команди — досвідчені техлід або тімлід. Це дозволяє добитися уніфікації, коли всі тестувальники дотримуються єдиного процесу звітування про помилки. Такий підхід економить час і нерви всієї команди. Адже спільні принципи дозволяють не гаяти зусилля на розуміння, що ж саме мав на увазі якийсь окремий QA-фахівець.
Як діяти новачку, якщо bug report має інший формат
Адаптуватися. З одного боку, початківці повинні знати універсальні принципи якісного звіту про помилки. Це основа роботи. З іншого, вивчення нових підходів до того, що таке bug report, може бути дуже корисним. Так новачок побачить, як можна працювати з іншими форматом звітів, полями, стилем подачі детальної інформації, інструментом відстеження помилок. Такі знання розширять професійний кругозір та допоможуть стати інженером з якості, а не простим тестувальником.
Якщо стикаєтесь з незвичним стандартом баг-репорту, не треба пручатися й говорити, що вас навчали іншого. Краще вивчіть локальні вимоги та дотримуйтесь їх деякий час. Лише згодом, якщо вам все одно здається, що можна писати звіт про помилки кращим чином — обговоріть конкретні пропозиції із досвідченими тестувальниками. Можливо, ваші ідеї впровадять у життя. А можливо — вам обґрунтують, чому це не спрацює.
Як переконатися, що ваш баг-репорт дієвий
Формати, шаблони, поля, особливості проєкту, види тестування, системи звітності про помилки чи звички команди — насправді це все деталі. Головне, пам’ятати: ваш bug report має бути зрозумілим. Тому після написання документа спитайте себе:
- Чи може розробник зрозуміти проблему з опису, не звертаючись до тестувальника?
- Чи може будь-хто за цим описом помилки повторити шлях до багу?
- Чи наявні в баг-репорті всі необхідні дані для локалізації знайденого дефекту?
Якщо відповідь ствердна на всі питання, можете сміливо передавати звіт далі — значить, ваш документ дійсно вийшов змістовний та корисний.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
