Баг-репорт — это описание найденного дефекта. От его качества зависит судьба бага: понятный репорт разработчик воспроизведёт и починит за минуты, а плохой вернётся к вам с комментарием «не воспроизводится» — и время потеряют все.

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

Из чего состоит баг-репорт

Стандартный набор частей:

  • Заголовок — коротко и конкретно, в чём проблема.
  • Шаги воспроизведения — пронумерованный путь к багу.
  • Ожидаемый результат — что должно было произойти.
  • Фактический результат — что произошло на самом деле.
  • Окружение — где воспроизвелось: браузер, устройство, версия сборки, тестовый или боевой стенд.
  • Вложения — скриншот, видео, а для технических багов — ошибки из консоли или сети.
  • Важность — severity и priority.

Ядро, без которого репорт бесполезен, — это шаги + ожидаемое + фактическое. Остальное помогает, но начинается всё с этих трёх.

Заголовок: коротко и по делу

Заголовок читают первым и по нему ищут дубли. Он должен отвечать на «что, где, при чём». Сравните:

  • Плохо: «Ошибка в корзине», «Не работает!», «Баг».
  • Хорошо: «Корзина: при удалении последнего товара сумма не обнуляется».

Хороший заголовок понятен без открытия репорта. Правило: если по заголовку нельзя понять, о чём баг, — переписывайте.

Шаги воспроизведения: главное

Это сердце репорта. Пишите так, чтобы человек, который видит продукт впервые, повторил путь без догадок:

  1. Открыть страницу товара example.com/product/123.
  2. Нажать «В корзину».
  3. Перейти в корзину.
  4. Удалить единственный товар кнопкой «Удалить».

Ожидаемый результат: корзина пустая, сумма — 0 ₽. Фактический результат: товар исчез, но сумма показывает прежние 1500 ₽.

Правила шагов:

  • Начинайте с точки, понятной всем (какой URL, какой пользователь), а не с середины своего сценария.
  • Один шаг — одно действие. Не «зайти и всё оформить», а по действию.
  • Конкретика вместо общих слов. Не «ввести данные», а какие именно.
  • Минимум шагов. Уберите всё, что не влияет на баг. Чем короче путь, тем ценнее репорт.

Воспроизводимость и вложения

Перед тем как заводить баг, повторите его сами ещё раз по своим же шагам. Если баг воспроизводится стабильно — отлично. Если только иногда — так и напишите («воспроизводится примерно в одном случае из трёх») и приложите видео: плавающие баги ловить труднее, и честность тут важнее красоты.

Скриншот или короткое видео экономят кучу слов — прикладывайте их почти всегда. Для технических багов загляните в инструменты разработчика: красная ошибка в консоли или упавший запрос во вкладке Network, вложенные в репорт, помогут разработчику найти причину в разы быстрее.

Где это применяется

Баг-репорты — это то, что вы производите каждый день и по чему судят о вашей работе. Разработчики, менеджеры, другие тестировщики читают именно их. Тестировщик, который пишет понятные репорты, экономит команде часы; тот, чьи репорты приходится расшифровывать или которые возвращаются как «не воспроизводится», — наоборот. Это, без преувеличения, ваш главный навык оформления.

Где спотыкаются начинающие:

  • Пишут заголовок «не работает» без сути. По такому не найти дубль и не понять, о чём речь.
  • Пропускают шаги или начинают с середины. Разработчик не видит, как дойти до бага, и закрывает как «не воспроизводится».
  • Не разделяют ожидаемое и фактическое. «Баг в сумме» — непонятно. Нужно: должно быть 0, а показывает 1500.
  • Не проверяют воспроизводимость перед заведением и не прикладывают скриншот.

Что учить дальше. Репорт заведён — что с ним происходит дальше? Про путь бага от находки до закрытия и про то, как это выглядит в трекере, — статья жизненный цикл бага и трекеры.