Баг-репорт — это описание найденного дефекта. От его качества зависит судьба бага: понятный репорт разработчик воспроизведёт и починит за минуты, а плохой вернётся к вам с комментарием «не воспроизводится» — и время потеряют все.
Хороший баг-репорт — это не творчество, а строгая структура. Разработчик, читая его, должен без вас повторить проблему шаг в шаг. Разберём, из чего состоит репорт и как сделать его таким, чтобы к нему не было вопросов.
Из чего состоит баг-репорт
Стандартный набор частей:
- Заголовок — коротко и конкретно, в чём проблема.
- Шаги воспроизведения — пронумерованный путь к багу.
- Ожидаемый результат — что должно было произойти.
- Фактический результат — что произошло на самом деле.
- Окружение — где воспроизвелось: браузер, устройство, версия сборки, тестовый или боевой стенд.
- Вложения — скриншот, видео, а для технических багов — ошибки из консоли или сети.
- Важность — severity и priority.
Ядро, без которого репорт бесполезен, — это шаги + ожидаемое + фактическое. Остальное помогает, но начинается всё с этих трёх.
Заголовок: коротко и по делу
Заголовок читают первым и по нему ищут дубли. Он должен отвечать на «что, где, при чём». Сравните:
- Плохо: «Ошибка в корзине», «Не работает!», «Баг».
- Хорошо: «Корзина: при удалении последнего товара сумма не обнуляется».
Хороший заголовок понятен без открытия репорта. Правило: если по заголовку нельзя понять, о чём баг, — переписывайте.
Шаги воспроизведения: главное
Это сердце репорта. Пишите так, чтобы человек, который видит продукт впервые, повторил путь без догадок:
- Открыть страницу товара
example.com/product/123. - Нажать «В корзину».
- Перейти в корзину.
- Удалить единственный товар кнопкой «Удалить».
Ожидаемый результат: корзина пустая, сумма — 0 ₽. Фактический результат: товар исчез, но сумма показывает прежние 1500 ₽.
Правила шагов:
- Начинайте с точки, понятной всем (какой URL, какой пользователь), а не с середины своего сценария.
- Один шаг — одно действие. Не «зайти и всё оформить», а по действию.
- Конкретика вместо общих слов. Не «ввести данные», а какие именно.
- Минимум шагов. Уберите всё, что не влияет на баг. Чем короче путь, тем ценнее репорт.
Воспроизводимость и вложения
Перед тем как заводить баг, повторите его сами ещё раз по своим же шагам. Если баг воспроизводится стабильно — отлично. Если только иногда — так и напишите («воспроизводится примерно в одном случае из трёх») и приложите видео: плавающие баги ловить труднее, и честность тут важнее красоты.
Скриншот или короткое видео экономят кучу слов — прикладывайте их почти всегда. Для технических багов загляните в инструменты разработчика: красная ошибка в консоли или упавший запрос во вкладке Network, вложенные в репорт, помогут разработчику найти причину в разы быстрее.
Где это применяется
Баг-репорты — это то, что вы производите каждый день и по чему судят о вашей работе. Разработчики, менеджеры, другие тестировщики читают именно их. Тестировщик, который пишет понятные репорты, экономит команде часы; тот, чьи репорты приходится расшифровывать или которые возвращаются как «не воспроизводится», — наоборот. Это, без преувеличения, ваш главный навык оформления.
Где спотыкаются начинающие:
- Пишут заголовок «не работает» без сути. По такому не найти дубль и не понять, о чём речь.
- Пропускают шаги или начинают с середины. Разработчик не видит, как дойти до бага, и закрывает как «не воспроизводится».
- Не разделяют ожидаемое и фактическое. «Баг в сумме» — непонятно. Нужно: должно быть 0, а показывает 1500.
- Не проверяют воспроизводимость перед заведением и не прикладывают скриншот.
Что учить дальше. Репорт заведён — что с ним происходит дальше? Про путь бага от находки до закрытия и про то, как это выглядит в трекере, — статья жизненный цикл бага и трекеры.