Баг-репорт, який полагодять з першого разу

Хороший баг-репорт економить години: розробник відтворює проблему з першого разу, менеджер правильно ставить пріоритет, а через пів року будь-хто зрозуміє, що сталося. Поганий — ходить по колу з коментарями «не відтворюється», «уточніть», «у мене працює».

Структура

Заголовок:   [Кошик] Промокод не застосовується, якщо в кошику є товар зі знижкою

Середовище:  staging, build 2026.08.12-3, Chrome 141 / Windows 11
Акаунт:      qa.buyer+12@example.com (роль: покупець)

Кроки:
  1. Додати в кошик товар зі знижкою (напр. SKU 10442, -20%)
  2. Додати звичайний товар (SKU 20018)
  3. Ввести промокод AUTUMN10 і натиснути «Застосувати»

Фактичний результат:
  Повідомлення «Промокод недійсний». Сума не змінюється.

Очікуваний результат:
  Знижка 10% застосовується до товарів без знижки (вимога PROMO-31, п. 4).

Частота:     5 з 5 спроб
Вкладення:   відео (40 с), HAR-файл, скрін консолі
Додатково:   Без товару зі знижкою промокод працює. API /promo/apply повертає 422 {"code":"PROMO_NOT_APPLICABLE"}

Заголовок: що, де, за яких умов

Заголовок читають у списках, звітах і на мітингах. Формула: [Модуль] Що не так + за якої умови.

Кроки відтворення

• Нумеровані, по одній дії на крок.
• Конкретні дані: який товар, яка сума, який акаунт. «Додати товар» — погано, «Додати SKU 10442» — добре.
• Мінімальні: приберіть кроки, що не впливають на баг. Якщо вхід в акаунт не важливий — не пишіть його.
• Перевірені: перед відправкою пройдіть кроки ще раз за своїм же текстом.

Порада

Пошукайте межу бага: з одним товаром відтворюється? А з товаром без знижки? В іншому браузері? Фраза «без товару зі знижкою працює» часто економить розробнику пів години дебагу.

Очікуваний результат — з джерелом

«Очікувалось, що працюватиме» — не аргумент. Посилайтеся на вимогу, макет, документацію API або поведінку в попередній версії. Якщо вимоги немає — так і пишіть: «Вимоги не знайшла; логічно очікувати X, бо…». Тоді рішення ухвалить продакт, а не суперечка в коментарях.

Severity і Priority — не одне й те саме

Приклади, де вони розходяться:

• Висока серйозність, низький пріоритет: падіння застосунку в адмінці, якою користуються раз на рік.
• Низька серйозність, високий пріоритет: помилка в назві компанії на головній сторінці перед запуском рекламної кампанії.

Докази

• Відео — найкраще для складних сценаріїв (20–60 секунд, без зайвого).
• Скріншот з виділеною проблемою — для візуальних багів.
• Логи, HAR, відповідь API — для всього, що стосується бекенду.
• Ідентифікатори: ID замовлення, request ID, час з часовим поясом — щоб знайти запис у логах сервера.

# Корисно додати відповідь API прямо в репорт
curl -s -X POST https://staging.example.com/api/promo/apply \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"code":"AUTUMN10","cartId":"c_8812"}' | jq

Увага

Не вставляйте в тікети реальні паролі, токени, номери карток і персональні дані клієнтів. Маскуйте їх або використовуйте тестові акаунти.

Чекліст перед відправкою

• Заголовок зрозумілий без відкриття тікета?
• Кроки відтворюються з нуля за текстом?
• Вказані середовище, версія, браузер, акаунт?
• Є очікуваний результат з джерелом?
• Додані докази?
• Перевірено, що такого бага ще немає в трекері?