Как оформить баг-репорт, чтобы его починили с первого раза

Вячеслав Степанов — проджект-менеджер, ментор · 23 октября 2026

Задача «Не работает экран долгов» через два дня непонятна даже её автору. Разработчик не может повторить проблему и возвращает задачу со статусом «не воспроизводится»: время потеряли оба, ошибка осталась в продукте. Хороший баг-репорт написан так, чтобы другой человек повторил проблему у себя, ничего не спрашивая. Как этого добиться, показываю на полях, примере и типичных ошибках.

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Что такое баг-репорт

Баг (bug, дефект) — расхождение между тем, как продукт должен работать по требованиям, и тем, как он работает фактически. Баг-репорт — описание этого расхождения в трекере задач, например в Jira.

У слова есть известная история. 9 сентября 1947 года команда Грейс Хоппер нашла в реле компьютера Harvard Mark II мотылька и вклеила его в журнал с подписью «первый настоящий случай обнаружения бага». Само слово «баг» инженеры использовали для неисправностей и раньше, но этот журнал сохранился и стал легендой.

Хороший баг-репорт отвечает на три вопроса: как повторить, что должно было произойти и что произошло вместо этого. Если по нему разработчик без единого вопроса видит ошибку у себя, репорт хороший.

Когда заводят баг

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

Поля баг-репорта

Перед тем как нажать «Создать», пройди свои шаги заново с чистого листа. Если у тебя самого ошибка не повторилась, у разработчика не повторится тем более.

Пример баг-репорта

Заголовок: Кнопка «Напомнить» остаётся активной после отправки напоминания

Шаги воспроизведения:
  1. Войти в сервис под аккаунтом репетитора
  2. Открыть «Оплаты» → «Долги учеников»
  3. Нажать «Напомнить» в строке должника и отправить напоминание
  4. Нажать «Напомнить» в той же строке ещё раз

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

Окружение: тестовый стенд, Chrome, аккаунт демо-репетитора
Серьёзность: средняя — данные целы, репетитор теряет время
Приоритет: высокий — фича идёт на демо в четверг
Вложения: скриншот окна с текстом ошибки
Связи: тест-кейс на повторную отправку напоминания

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

Серьёзность и приоритет

Эти поля постоянно смешивают, хотя решения по ним принимают разные люди. Серьёзность (severity) оценивает тот, кто нашёл ошибку: у потери данных она высокая, у кривой надписи низкая. Приоритет (priority) определяет проджект вместе с продакт-оунером, глядя на планы и пользователей.

Шкалы в командах разные, но похожи друг на друга. Серьёзность часто делят на уровни от блокирующей (продуктом невозможно пользоваться) до незначительной, вроде опечатки. Приоритет в Jira по умолчанию задают уровнями от Highest до Lowest. Команде нужно договориться, что значит каждый уровень, и записать это в правилах работы.

Что происходит после исправления

Ретест — повторный прогон той самой проверки, которая нашла ошибку. Только так видно, что починили то, что сломалось. После ретеста в истории тест-кейса остаётся след: в одном прогоне красный, в следующем зелёный. Через полгода по нему видно, что проверка когда-то падала и почему.

Рядом с ретестом проводят регресс: проверяют, что исправление не сломало соседние функции. Ошибки часто возвращаются после исправления или появляются рядом, поэтому кейсы хранят и прогоняют повторно.

Роль проджект-менеджера

• Расставляет приоритеты. Вместе с продакт-оунером решает, какие баги чинить в этом спринте, а какие отправить в бэклог.
• Следит за потоком. По тому, сколько багов открыто, сколько висит в ретесте и сколько переоткрыто, видно, готов ли релиз.
• Разводит Fail и Blocked. Заблокированные проверки — это задачи для команды: поднять стенд, подготовить данные. Их тоже нужно снимать, иначе тестирование встанет.
• Сам пишет баги. Проджект часто первым узнаёт о проблеме: от поддержки, продакта или на демо. В его работу входит оформить её по формату, сообщение из чата разработчику не пересылают.

Типичные ошибки

• Заголовок «Ничего не работает». Непонятно, что и где сломано. Пиши заголовок по схеме «что сломано + где»: «Кнопка „Напомнить“ активна после отправки».
• Нет шагов воспроизведения. Разработчик гадает, как получить ошибку. Помогают пронумерованные шаги от входа в систему.
• Нет ожидаемого результата. Непонятно, почему это ошибка, а не задуманное поведение. Решается ссылкой на требование и чётким «как должно быть».
• Несколько проблем в одном баге. Одну починили, другую забыли, а баг уже закрыт. Поэтому на каждую ошибку заводят отдельный репорт.
• Серьёзность и приоритет — одно и то же. Опечатку чинят месяц, а критичный баг висит. Чтобы этого не было, оценивай ошибку по двум шкалам отдельно.

Частые вопросы