Баг-репорт: як правильно написати (шаблон + приклади)
Знайти дефект — половина роботи тестувальника. Друга половина — описати його так, щоб розробник відтворив проблему з першого разу і не прийшов з питанням «а як ти це отримав?». Погано написаний баг-репорт коштує команді годин переписки, а іноді дефект просто закривають як «не відтворюється».
У цьому гайді розберемо, з яких полів складається баг-репорт за програмою ISTQB, як сформулювати заголовок і кроки відтворення, чим severity відрізняється від priority, і покажемо три повні приклади «погано → добре». Наприкінці — чек-лист перед відправкою.
Головне за 30 секунд
- Баг-репорт — документ про дефект: що сталося, де, за яких умов і як це повторити.
- Обов'язкові поля: заголовок, середовище, кроки відтворення, очікуваний і фактичний результат, severity, priority, вкладення.
- Формула заголовка: що зламалося + де + за якої умови.
- Severity — наскільки шкодить дефект, priority — як терміново виправляти. Це різні речі.
Баг-репорти, тест-кейси, Jira — на практиці
На курсі тестувальника в Prog Academy ви пишете баг-репорти й тест-кейси на реальних проєктах, працюєте з Jira і Postman, а викладач перевіряє кожну роботу. 4 місяці від нуля до готовності до співбесіди на Junior QA.
Програма курсу QA →Що таке баг-репорт
Баг-репорт (звіт про дефект, bug report) — це документ, який описує знайдений дефект так, щоб його можна було відтворити, оцінити й виправити. У глосарії ISTQB звіт про дефект визначено як «документація щодо виникнення, характеру та статусу дефекту».
За програмою ISTQB Foundation Level (версія 4.0.1), у звіту про дефект три цілі: дати тим, хто його виправлятиме, достатньо інформації; відстежувати якість продукту; підказати, як покращити процес розробки й тестування. Тобто баг-репорт пишуть не «для галочки» і не для звіту керівнику, а для людини, яка виправлятиме дефект.
Баг-репорти ведуть у баг-трекері: Jira, YouTrack, Azure DevOps, GitHub Issues. Поля в різних системах звуться по-різному, але суть однакова.
Структура баг-репорту: поля за ISTQB
Програма ISTQB Foundation Level перелічує, що зазвичай містить звіт про дефект, знайдений під час тестування. У таблиці — ці поля з поясненням і прикладом.
| Поле | Що писати | Приклад |
|---|---|---|
| ID | Унікальний номер. Зазвичай присвоює баг-трекер. | SHOP-1423 |
| Заголовок | Коротко: що зламалося, де і коли | Кошик: кнопка «Оформити замовлення» неактивна після видалення промокоду |
| Автор і дата | Хто знайшов і коли | О. Коваль, 12.11.2026 |
| Об'єкт і середовище | Що тестували, де: ОС, браузер чи пристрій, стенд, версія збірки | Windows 11, Chrome 131, staging, збірка 2.14.0 |
| Контекст | Тест-кейс чи активність, у межах якої знайдено дефект; тестові дані | TC-87 «Застосування промокоду», користувач test_buyer_3 |
| Кроки відтворення | Нумерований список дій | 1. Відкрити /cart. 2. Натиснути «Видалити промокод». 3. Натиснути «Оформити замовлення» |
| Очікуваний результат | Як має бути за вимогами | Відкривається сторінка оформлення з ціною без знижки |
| Фактичний результат | Що сталося насправді | Кнопка неактивна; у консолі TypeError |
| Severity | Серйозність: наскільки дефект шкодить | Critical |
| Priority | Пріоритет: як терміново виправляти | High |
| Статус | Стан дефекту в життєвому циклі | New |
| Посилання й вкладення | Скриншоти, відео, логи, пов'язані задачі й тест-кейси | checkout-bug.mp4, console.log |
Перевірки, з яких виростає баг-репорт, зазвичай описані в тест-кейсах. Якщо ви ще плутаєте ці документи, почніть із нашого гайду «Як стати QA-тестувальником з нуля» — там розібрано всю тестову документацію.
Як написати заголовок
Заголовок — те, що розробник і менеджер бачать у списку дефектів. За ним вирішують, відкривати баг-репорт зараз чи потім, тому заголовок має бути самодостатнім. Робоча формула:
Що зламалося + де + за якої умови.
| Погано | Добре |
|---|---|
| Не працює кошик | Кошик: кнопка «Оформити замовлення» неактивна після видалення промокоду |
| Баг з реєстрацією!!! | Реєстрація: лист підтвердження не надходить, якщо email містить «+» |
| Поїхала верстка | Головна, iPhone SE: кнопка «Купити» перекриває ціну в картці товару |
| API падає | POST /api/orders повертає 500, якщо quantity = 0 |
Кілька правил: без емоцій і оцінок («жахливий баг»), без «не працює» без уточнення, до 80–100 символів. Один заголовок — один дефект.
Кроки відтворення, очікуваний і фактичний результат
Кроки відтворення
Кроки — серце баг-репорту. Їх читає людина, яка не бачила, що ви робили, тому:
- Нумеруйте. Одна дія — один крок.
- Починайте з передумов. Хто увійшов у систему, які дані вже є, яка мова інтерфейсу. «Користувач авторизований, у кошику 1 товар, застосовано промокод SALE10».
- Пишіть конкретно. Не «введіть некоректні дані», а «у поле Email введіть test@example».
- Перевірте кроки ще раз перед відправкою. Якщо дефект не відтворюється за вашими кроками — вони неповні.
Очікуваний результат
Як має бути відповідно до вимог, макета чи загальноприйнятої поведінки. Якщо є посилання на вимогу — додайте його. Без очікуваного результату розробник не знає, що саме вважати виправленням.
Фактичний результат
Що сталося насправді — точно й без інтерпретацій. Текст помилки копіюйте дослівно, а не переказуйте. «Сторінка не завантажилась» гірше, ніж «через 30 секунд з'являється сторінка 504 Gateway Time-out».
Severity і Priority: у чому різниця
Найчастіше питання на співбесідах Junior QA. Визначення з глосарію ISTQB:
- Severity (серйозність) — «ступінь впливу, який дефект має на розробку або функціонування компонента чи системи».
- Priority (пріоритет) — «рівень (бізнес-) важливості, присвоєний об'єкту, наприклад, дефекту».
Серйозність зазвичай оцінює тестувальник, бо бачить технічний вплив. Пріоритет остаточно встановлює менеджер продукту чи лід команди, бо зважує бізнес-контекст: дедлайни, кількість користувачів, ризики. Конкретні шкали в компаніях відрізняються; поширений варіант — такий:
| Severity | Що означає | Приклад |
|---|---|---|
| Blocker | Неможливо продовжити роботу чи тестування, обхідного шляху немає | Застосунок падає під час запуску |
| Critical | Не працює ключова функція або втрачаються дані чи гроші | Оплата списує гроші, а замовлення не створюється |
| Major | Функція працює неправильно, але є обхідний шлях | Фільтр за ціною ігнорує верхню межу |
| Minor | Незначна функціональна чи візуальна вада | Кнопка зміщується на 5 px на мобільному |
| Trivial | Косметика, яка не впливає на роботу | Помилка в слові в підвалі сайту |
Чому це два різні поля, найкраще видно на крайніх випадках:
- Висока серйозність, низький пріоритет: застосунок падає в старій версії браузера, якою майже ніхто не користується. Дефект серйозний, але виправлення можна відкласти.
- Низька серйозність, високий пріоритет: помилка в назві компанії на головній сторінці за день до рекламної кампанії. Технічно дрібниця, але виправити треба негайно.
Три приклади: погано → добре
Приклад 1. Вебзастосунок
Погано: «Не можу оформити замовлення, кнопка не працює. Виправте терміново!»
Добре:
Заголовок: Кошик: кнопка «Оформити замовлення» неактивна після видалення промокоду
Середовище: Windows 11, Chrome 131, staging, збірка 2.14.0
Передумови: користувач авторизований; у кошику 1 товар; застосовано промокод SALE10
Кроки: 1) Відкрити /cart. 2) Натиснути «Видалити промокод». 3) Натиснути «Оформити замовлення».
Очікуваний результат: відкривається сторінка оформлення замовлення з ціною без знижки.
Фактичний результат: кнопка неактивна, клік нічого не робить; у консолі: TypeError: Cannot read properties of null (reading 'discount').
Severity / Priority: Critical / High — користувач не може купити товар.
Вкладення: відео 12 с, скриншот консолі.
Приклад 2. Мобільний застосунок
Погано: «На айфоні все з'їхало».
Добре:
Заголовок: Картка товару, iPhone SE (iOS 18): кнопка «Купити» перекриває ціну
Середовище: iPhone SE 3-го покоління, iOS 18.1, застосунок 5.2.0 (TestFlight)
Кроки: 1) Відкрити будь-який товар з назвою довше 40 символів. 2) Прокрутити до блоку ціни.
Очікуваний результат: ціна й кнопка «Купити» розташовані одна під одною, обидві видимі повністю.
Фактичний результат: кнопка накладається на ціну, видно лише першу цифру. На iPhone 15 і Pixel 8 дефект не відтворюється.
Severity / Priority: Major / Medium — ціну можна побачити в кошику, але клієнт може піти.
Вкладення: скриншоти з iPhone SE і iPhone 15 для порівняння.
Приклад 3. API
Погано: «Замовлення з нулем ламає бекенд».
Добре:
Заголовок: POST /api/orders повертає 500 замість 400, якщо quantity = 0
Середовище: staging API, збірка 2.14.0, Postman 11
Кроки: 1) Отримати токен тестового користувача. 2) Надіслати POST /api/orders з тілом {"productId": 15, "quantity": 0}.
Очікуваний результат: 400 Bad Request з повідомленням про некоректну кількість (за специфікацією API, розділ «Orders»).
Фактичний результат: 500 Internal Server Error, тіло відповіді порожнє; у таблиці orders з'являється запис зі статусом NULL.
Severity / Priority: Major / High — у базу потрапляють некоректні дані.
Вкладення: експорт запиту з Postman, SQL-запит, який показує запис.
Зверніть увагу: у третьому прикладі тестувальник перевірив не лише відповідь, а й базу даних. Саме тому SQL і тестування API — обов'язкова частина навичок junior QA.
Скриншоти, відео й логи
- Скриншот — для візуальних дефектів. Виділіть проблемне місце рамкою чи стрілкою, обріжте зайве.
- Відео — коли важлива послідовність дій або дефект «миготить». 10–30 секунд достатньо.
- Консоль браузера — текст помилки з вкладки Console в DevTools.
- Мережа — запит і відповідь з вкладки Network або HAR-файл, якщо проблема на межі фронтенду й бекенду.
- Логи застосунку — для мобільних і серверних дефектів, якщо маєте до них доступ.
Перевірте, що у вкладеннях немає паролів, токенів і персональних даних реальних користувачів.
Життєвий цикл дефекту
Після відправки баг-репорт проходить через статуси. Програма ISTQB наводить як приклади: відкритий, відкладений, дублікат, очікує виправлення, очікує повторної перевірки, повторно відкритий, закритий, відхилений. У Jira типовий шлях виглядає так:
New → Open → In Progress → Fixed → Retest → Closed (або Reopened, якщо дефект не виправлено).
Завдання тестувальника не закінчується відправкою: після виправлення треба перевірити, що дефект справді зник і що поруч нічого не зламалося. Саме для цього існує регресійне тестування.
Чек-лист перед відправкою
- Дефект відтворюється ще раз за моїми кроками.
- Я перевірив, що такого баг-репорту ще немає (дублікат).
- Заголовок відповідає на питання «що, де, коли».
- Вказано середовище і версію збірки.
- Кроки нумеровані, одна дія — один крок.
- Є очікуваний і фактичний результат.
- Severity і priority проставлені обґрунтовано, а не «все Critical».
- Додано скриншот, відео або логи.
- Один дефект — один баг-репорт.
- Текст без емоцій і звинувачень.
Типові помилки новачків
- Кілька дефектів в одному репорті. Один виправлять, другий загубиться.
- «Не працює» без деталей. Розробник витратить час на те, щоб зрозуміти, що саме.
- Пропущені передумови. Дефект відтворюється лише з промокодом, а про промокод ні слова.
- Інтерпретація замість факту. «Сервер не витримує навантаження» замість «відповідь приходить через 30 секунд з кодом 504».
- Завищена серйозність. Якщо все Critical, команда перестає довіряти оцінкам.
- Тон звинувачення. Баг-репорт описує продукт, а не людину.
Чи можна писати баг-репорти з AI
Можна, як допомогу: асистент перетворить ваші нотатки на структурований текст, перекладе англійською, запропонує кращий заголовок. Але кроки треба відтворити самостійно, а результат перевірити: AI легко «додумує» деталі, яких не було. Не вставляйте в зовнішні чат-боти конфіденційні дані проєкту без дозволу компанії.
Хочете, щоб ваші баг-репорти хтось перевірив?
На курсі QA викладач розбирає ваші баг-репорти й тест-кейси, а наприкінці ви готуєтеся до співбесіди на позицію Junior QA Engineer.
Записатися на курс QA →Часті запитання
Що таке баг-репорт простими словами?
Баг-репорт — це документ, який описує знайдений дефект так, щоб розробник міг його відтворити й виправити без додаткових питань. У глосарії ISTQB звіт про дефект визначено як «документація щодо виникнення, характеру та статусу дефекту». Мінімум, який має бути в кожному баг-репорті: заголовок, середовище, кроки відтворення, очікуваний і фактичний результат, серйозність і вкладення.
Чим severity відрізняється від priority?
Severity (серйозність) показує, наскільки сильно дефект впливає на роботу системи, і її зазвичай визначає тестувальник. Priority (пріоритет) показує, наскільки терміново дефект треба виправити з погляду бізнесу, і остаточно його встановлює менеджер продукту або лід команди. Тому бувають критичні дефекти з низьким пріоритетом і дрібні — з високим.
Скільки кроків відтворення має бути в баг-репорті?
Стільки, скільки потрібно, щоб дефект відтворив інший член команди, і не більше. Зазвичай це 3–8 кроків. Одна дія — один крок. Якщо кроків виходить понад 10–12, спробуйте знайти коротший шлях до дефекту: це часто допомагає зрозуміти його причину.
Чи обов'язково додавати скриншот або відео?
Для візуальних дефектів скриншот обов'язковий, для дефектів у послідовності дій бажане коротке відео. Для помилок на рівні API чи бекенду корисніші логи консолі, вкладка Network або HAR-файл. Вкладення не замінюють кроків відтворення, а доповнюють їх.
Як писати баг-репорти: українською чи англійською?
Мовою, прийнятою в команді. У багатьох IT-компаніях, особливо з іноземними клієнтами, баг-трекер ведуть англійською, тому junior-тестувальнику варто вміти писати короткі й однозначні баг-репорти англійською. Головне — однакова мова в межах проєкту.
Що робити, якщо розробник каже, що це не баг, а фіча?
Поверніться до вимог: якщо поведінка суперечить специфікації, макету чи прийнятим домовленостям, послайтеся на конкретне місце. Якщо вимог немає, винесіть питання на продакт-менеджера чи аналітика, а не сперечайтеся в коментарях. Дефект зі статусом «Rejected» — нормальний результат, якщо рішення ухвалено свідомо.
Джерела
Про автора
Терміни зі статті
Короткі визначення понять, які згадуються вище.