Как писать баг-репорт: структура и пример
Структура репорта, заголовок как визитная карточка, доказательства и типовые ошибки. Пишем настоящий репорт в тренажёре.
Найденный, но плохо описанный дефект равен ненайденному. Разработчик открывает задачу, не понимает, что делать, и откладывает её. Через неделю баг закрывают как «не воспроизводится». Поэтому репорт — не бюрократия, а инструмент влияния.
Структура
- Заголовок — что сломалось, где и при каком условии. Одна строка, 25–120 символов.
- Окружение — стенд, версия сборки, браузер и его версия, ОС, устройство, роль пользователя.
- Предусловия — что должно быть верно до начала шагов.
- Шаги воспроизведения — пронумерованные, с конкретными данными.
- Ожидаемый результат — со ссылкой на требование, макет или логику.
- Фактический результат — что произошло на самом деле.
- Доказательства — скриншот, запись экрана, логи, запрос и ответ API.
- Серьёзность и приоритет.
- Дополнительно — воспроизводится ли всегда, есть ли обходной путь, когда появилось.
Заголовок
По заголовку принимают решение, брать ли задачу в спринт. Формула: [где] что происходит [при каком условии].
| Плохо | Хорошо |
|---|---|
| Не работает оплата | Оплата: при выборе СБП кнопка «Оплатить» неактивна на мобильной вёрстке |
| Ошибка 500 | Оформление заказа: POST /api/order возвращает 500 при пустом поле «Комментарий» |
| Криво отображается | Каталог: описание товара выходит за границы карточки при длине названия > 40 символов |
Представьте, что репорт читает человек, впервые открывший ваш продукт. Он не знает, где кнопка и какие данные подойдут. Если он сможет повторить — шаги написаны хорошо. Именно поэтому в шагах пишут конкретные данные: не «добавить товар», а «добавить товар “Наушники Aero 2”».
Доказательства
- Скриншот — со всем окном, а не с вырезанным кусочком: часто важен адрес страницы и время.
- Запись экрана — для плавающих и многошаговых дефектов. 20 секунд лучше трёх абзацев.
- Запрос и ответ из вкладки Network: метод, URL, тело запроса, код и тело ответа.
- Ошибки консоли — целиком, включая stack trace.
- Идентификаторы: id заказа, e-mail пользователя, точное время с секундами. По ним разработчик найдёт запись в логах сервера.
Типовые ошибки
- Два бага в одном репорте. Один чинят, второй теряется. Правило: один дефект — одна задача.
- Диагноз вместо симптома. «Не работает валидация на бекенде» — вы этого не знаете. Опишите наблюдаемое, гипотезу вынесите в комментарий.
- Эмоции. «Опять всё сломали!!!» портит отношения и не помогает чинить.
- Отсутствие версии сборки. Дефект могли уже починить, и вы отнимаете время у команды.
- «Иногда не работает». Это не шаги. Ищите закономерность: какие данные, какой пользователь, что было перед этим, повторяется ли после очистки кэша.
- Воспроизводится ли повторно? Хотя бы дважды.
- Воспроизводится ли в другом браузере или в режиме инкогнито? Это отделяет дефект от кэша и расширений.
- Нет ли уже такого репорта? Поиск по трекеру — 30 секунд.
- Это точно расхождение с требованием, а не ваше ожидание?
- Актуальна ли ваша сборка?
Тренажёр: напишите репорт
Ниже описан наблюдаемый дефект. Оформите его так, чтобы разработчик воспроизвёл без вопросов. Тренажёр проверит репорт по семи критериям и покажет эталон.
Практическая часть урока выполняется в браузере с проверкой результата. Попробовать бесплатно: тренажёр по вёрстке или зарегистрируйтесь — откроются уроки и тренажёры курса.
Что делать, если баг не берут в работу
Не «повоевать в комментариях», а перевести разговор в плоскость влияния на бизнес: сколько пользователей затронуто, теряются ли деньги или данные, есть ли обходной путь, что будет, если не чинить до релиза. Решение о приоритете принимает продакт — но он должен принимать его, зная последствия. Ваша работа — обеспечить его этой информацией.
Это урок из курса «Ручной тестировщик»
В курсе 47 уроков и 36 тренажёров: тест-дизайн, вёрстка и UX, DevTools, API, SQL, Git и работа со стендом. Несколько уроков открыты бесплатно после регистрации.