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