Какая должна быть структура баг-репорта и что он должен включать

Что проверяют

Умеете ли вы описать дефект так, чтобы разработчик воспроизвёл его без единого уточняющего вопроса.

Как отвечать

Обязательные части:

• заголовок: что сломано, где и при каком условии, одной строкой. «Кнопка «Оплатить» не активна при сумме заказа больше 100 000 ₽» вместо «Не работает оплата»;
• окружение: сборка и версия, стенд, платформа, браузер или устройство, тип учётной записи и права. Половина невоспроизводимых дефектов это разница в окружении;
• предусловия: какое состояние нужно до начала шагов;
• шаги воспроизведения: пронумерованные, минимальные, без лишнего. Проверьте, что шагов действительно нужно столько;
• фактический результат: что произошло, с точным текстом ошибки, а не пересказом;
• ожидаемый результат: и, если возможно, ссылка на требование или макет. Без этого спор превращается в «а я думал, так и надо»;
• вложения: скриншот или короткое видео, логи, ответ сервера, идентификатор запроса из заголовка трассировки, HAR-файл. Идентификатор запроса ценнее скриншота, по нему разработчик найдёт запрос в логах за секунды;
• важность и срочность: серьёзность это влияние на систему, приоритет это срочность починки для бизнеса. Это разные шкалы, и падение на редком экране может быть критичным по серьёзности и низким по приоритету;
• воспроизводимость: всегда, иногда, один раз. «Плавающий» дефект нельзя молча закрывать, его помечают именно так.

Что делает отчёт плохим: несколько дефектов в одном описании, отсутствие ожидаемого результата, скриншот вместо текста ошибки, шаги «зайти в систему и всё сломается», описание предполагаемой причины вместо фактов.

Полезная привычка: перед отправкой воспроизвести дефект ещё раз строго по своим же шагам с чистого состояния.

Где спотыкаются

Пишут заголовок «не работает».

Смешивают серьёзность и приоритет.

Не указывают версию сборки.

Не прикладывают логи и идентификатор запроса, из-за чего разработчик ищет вслепую.