Как писать багрепорт, который примут: структура, шаги и частые ошибки
Багрепорт пишут не для отчётности. Его читает человек, которому предстоит воспроизвести дефект у себя, понять, насколько всё плохо, и решить, чинить сейчас или после релиза. Если отчёт этого не даёт, он возвращается с вопросами — и время теряют оба.
Из чего состоит отчёт
Минимальный рабочий набор одинаков почти везде: заголовок, окружение, шаги воспроизведения, ожидаемый результат, фактический результат. Дальше добавляют важность, вложения, логи — но без первых пяти пунктов отчёта нет.
Проверить себя просто: отдай отчёт человеку, который ничего не знает о задаче. Если он повторил дефект, не задав ни одного вопроса, — отчёт готов.
Заголовок: что сломалось и где
Заголовок читают в списке из сотни строк, и по нему решают, открывать ли. Поэтому в нём должно быть два факта: что именно происходит и в каком месте. «Не работает корзина» не содержит ни одного из них.
Хороший заголовок переживает сокращение до одной строки в списке и всё ещё понятен. Плохой требует открыть отчёт, чтобы понять, о чём он.
✕
Ошибка в заказе
✓
POST /orders создаёт заказ при пустой корзине и возвращает 201
Шаги воспроизведения: точные данные, а не пересказ
Шаг — это действие, которое можно повторить буквально. «Отправить некорректное значение» повторить нельзя: некорректных значений бесконечно много, и половина из них работает правильно. Нужно то самое значение, на котором сломалось.
Для API это означает: метод, полный адрес с параметрами, тело запроса и заголовки, если они влияют. Для интерфейса — что нажали и что ввели, дословно. Порядок шагов важен: дефект, который воспроизводится только после входа в аккаунт, без этого шага не повторится.
✕
1. Открыть каталог 2. Поставить странный фильтр 3. Ничего не отфильтровалось
✓
1. GET /products?min_price=-500 2. Смотрим код ответа и число позиций в data
Ожидаемый результат берётся из требований
Самая частая слабость отчёта — ожидаемый результат, придуманный на месте. «Ожидается, что так быть не должно» — это не требование, а мнение, и спорить с ним можно бесконечно.
Ожидаемый результат — это цитата: строка из требований, критерий приёмки, пункт документации, поведение соседнего метода, который сделан правильно. Если сослаться не на что, это ещё не дефект, а вопрос к аналитику — и так его и стоит завести.
Фактический результат, наоборот, пишется без интерпретаций: код ответа, тело, конкретное число. Не «сумма посчиталась неправильно», а «в ответе total = 1380 при двух позициях по 690 и промокоде −10%».
Пять ошибок, из-за которых отчёт возвращают
- Два дефекта в одном отчёте. Починят один, закроют весь — второй уедет в релиз.
- Шаги по памяти. Написано одно, отправлено другое, воспроизвести не получается.
- Оценка вместо факта: «всё сломалось», «работает ужасно». Непонятно, что именно чинить.
- Нет окружения. На каком стенде, под каким пользователем, с какими правами.
- Дубликат. Прежде чем заводить, стоит поискать — на доске такой отчёт часто уже есть.
Полный пример API-багрепорта
Ниже — не универсальная форма, а рабочий пример. Он связывает наблюдение с контрактом и оставляет разработчику точный запрос, а не пересказ из памяти.
Заголовок: POST /orders создаёт заказ при пустой корзине и возвращает 201\nОкружение: QA, build 2026.09.21-3, user qa-buyer-17\nПредусловие: корзина пользователя пуста\n\nШаги:\n1. Отправить POST /api/v1/orders с валидным Bearer token\n2. Тело запроса: {}\n3. Выполнить GET /api/v1/orders\n\nОжидаемо: 422, order не создан (AC-ORD-04)\nФактически: 201; создан order_id=8412, total=0\nПовторяемость: 3/3\nДоказательства: request/response HAR, correlation_id=7af2…
Не вставляй рабочий токен, пароль, персональные данные или полный production-дамп. Секреты заменяют маской, персональные данные — синтетическими значениями, а доступ к чувствительным логам дают по принятому security-процессу.
Чек-лист перед отправкой и ретестом
Severity описывает ущерб, priority — очерёдность исправления для бизнеса. Их шкалы и владельцы зависят от команды, поэтому важнее обоснование. После статуса Fixed QA повторяет исходные шаги на указанной сборке и проверяет близкий риск, а не закрывает задачу по комментарию разработчика.
- В заголовке есть действие, неверный результат и место дефекта.
- Указаны build, окружение, роль, предусловия и точные тестовые данные.
- Expected ссылается на критерий, контракт или согласованное решение.
- Actual содержит наблюдаемые факты: статус, значения, время, id и частоту.
- Вложения открываются, секреты скрыты, а один отчёт описывает один дефект.
- При ретесте проверены исходный сценарий, исправленная сборка и ближайшая регрессия.
Частые вопросы о багрепортах
Нужно ли заводить баг, если дефект воспроизвёлся один раз?
Да, если влияние существенно и есть доказательства. Укажи частоту, точное время, данные и логи, не обещая стабильной воспроизводимости. Один редкий дефект оплаты важнее стабильно кривого отступа.
Кто выставляет severity и priority?
Универсального правила нет. Часто QA предлагает severity, а product или triage определяет priority, но процесс команды может быть другим. Важны единые определения и записанное обоснование.
Что делать, если требования нет?
Зафиксировать наблюдаемое поведение и риск как вопрос или discovery-задачу, получить решение владельца продукта и только после этого записать ожидаемый результат. Личное предпочтение не становится дефектом автоматически.
Отчёт — рабочий документ, и научиться его писать можно только написав несколько десятков: на реальном дефекте, а не на выдуманном примере.