Из чего состоит хороший баг-репорт? Какие атрибуты обязательны?
Короткий ответ
- Краткий заголовок: что, где, при каком условии
- Шаги воспроизведения — нумерованные и минимальные
- Фактический и ожидаемый результат раздельно
- Окружение: версия, браузер, ОС, стенд, аккаунт
- Severity и priority, вложения: скриншот, видео, логи
- Один дефект — один репорт
Хороший баг-репорт позволяет разработчику воспроизвести и локализовать дефект без единого уточняющего вопроса.
Как сказать вслух
пример ответаГлавный критерий — разработчик должен воспроизвести баг, не задавая мне вопросов. Поэтому обязательно: понятный заголовок в формате «что, где, когда», минимальные пошаговые шаги, фактический результат и ожидаемый со ссылкой на требование, окружение и версия, серьёзность и приоритет. Прикладываю доказательства: скриншот или видео, логи, запрос и ответ, если дело касается API. И правило — один баг на один репорт.
Подробный ответ
Основной ответ
Баг-репорт — это документ для воспроизведения и исправления дефекта, и его качество напрямую влияет на скорость фикса. Обязательные атрибуты: заголовок по схеме «что — где — при каких условиях»; предусловия (аккаунт, данные, настройки); нумерованные шаги воспроизведения, сведённые к минимуму; фактический результат; ожидаемый результат со ссылкой на требование или макет; окружение — версия сборки, браузер, ОС, устройство, тестовый стенд; частота воспроизведения; severity (влияние на систему) и priority (срочность исправления); вложения — скриншоты, видео, логи, HAR, тело запроса и ответа. Важные правила: один дефект на репорт, проверка на дубликаты перед заведением, нейтральный тон без оценок чьей-то работы.
Ключевые моменты
- Severity vs priority. Severity — техническое влияние дефекта, priority — очерёдность исправления для бизнеса; опечатка в названии компании на главной — низкая severity, высокий priority.
- Минимальные шаги. Перед заведением шаги сокращают до необходимых — это ускоряет локализацию и выявляет реальное условие бага.
- Доказательства. Видео и логи экономят цикл «не воспроизводится — переоткрыт»; для API обязательны запрос, ответ и код статуса.
- Атомарность. Несколько дефектов в одном тикете ломают жизненный цикл: один починили, другой потерялся.
Практический контекст
На собеседовании джуна часто просят устно оформить баг для показанного примера или разобрать плохой репорт. Смотрят на структурность и на понимание разницы severity/priority — это почти гарантированный дополнительный вопрос. На реальных проектах качество репортов сильно влияет на отношения с разработчиками: репорты без шагов и логов возвращаются со статусом «не воспроизводится» и съедают время обеих сторон.
Частые ошибки
- Путают severity и priority или считают их одним полем
- Пишут шаги крупными мазками («зайти в приложение, всё сломалось») без конкретики
- Описывают в одном репорте несколько дефектов сразу