Шаблон баг-репорта, который работает (и как его автоматизировать)

QADenis Povarov25 августа 2026 г.

Поищите «шаблон баг-репорта», и найдёте сотню вариантов одной и той же формы. Заголовок, окружение, шаги воспроизведения, ожидаемый результат, фактический результат, серьёзность, скриншоты. Скопируйте её в свой трекер задач, и через месяц её почти никто не будет заполнять.

Обычно это списывают на недостаток дисциплины. Дело не в ней. Это проблема проектирования: шаблон просит человека переписывать информацию, которая у машины уже есть, а люди вполне резонно отказываются от нудной работы, от которой не видно пользы.

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

Шаблон

## Краткое описание
Одно предложение. Что сломано — с точки зрения пользователя.

## Шаги воспроизведения
1.
2.
3.

## Ожидаемый результат
Что, по-вашему, должно было произойти.

## Фактический результат
Что произошло вместо этого.

## Влияние
Кого затрагивает, как часто и есть ли обходной путь?

## Окружение
Браузер / ОС / устройство / версия приложения / URL / тип аккаунта, под которым вы вошли

## Доказательства
Скриншот, запись экрана, вывод консоли, упавший запрос, ID запроса

Вот и всё. Ничего нового здесь нет: ценность в том, зачем нужно каждое поле, и как раз тут большинство шаблонов ошибаются.

Краткое описание

Поле, которое портят чаще всего. Хорошее краткое описание говорит о том, что видно снаружи: «Кнопка оформления заказа ничего не делает на шаге оплаты сохранённой картой». Плохое пересказывает догадку о причине: «Гонка при получении токена Stripe».

Догадки в заголовке вредны: они задают рамку каждому, кто потом читает отчёт. Половина времени на разбор багов с плохими заголовками уходит на то, чтобы опровергнуть диагноз, который придумал автор отчёта и который никто не поставил под сомнение.

Просите наблюдение. Диагноз — работа того, кто будет исправлять.

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

Все знают, что это поле важно, и почти все заполняют его плохо, причём одинаково: авторы отчётов пишут шаги, которые считают важными, а не те, что сделали.

Пропускают «у меня были открыты две вкладки». Пропускают «я сидел на странице около часа». Пропускают «я пришёл по ссылке из письма, а не через меню». Обычно баг как раз в пропущенном.

Помогает такая инструкция: напишите, что вы делали, начиная с открытия страницы, включая скучные подробности.

Начальное состояние важно не меньше действий. Под какой ролью вы вошли? Какие данные уже были в аккаунте? Какой тариф? Воспроизведение с нового аккаунта часто ничего не воспроизводит.

Ожидаемый и фактический результат

Рядом с кратким описанием они кажутся лишними. Всё равно оставьте их.

Когда они разделены, отсеивается целый класс отчётов, которые не баги: программа работает ровно так, как задумано, а пользователь ждал другого. Это реальная проблема, и о ней стоит знать — это баг в документации, в UX или в обещаниях отдела продаж, — но не дефект кода, и распознать его при разборе несравнимо дешевле, чем после двух дней расследования.

Ещё эта пара заставляет быть точным. «Не работает» не переживёт разделения на ожидаемое и фактическое. Одно из двух полей будет неловко оставить расплывчатым.

Влияние

Поле, которого нет в большинстве шаблонов, хотя именно оно сильнее всего определяет, что будет дальше.

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

Кого — только меня, всю мою команду, всех клиентов в Safari?
Как часто — один раз, каждый раз, примерно один раз из десяти?
Обходной путь — можно ли сделать то же самое по-другому?

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

Окружение

Нужное поле — и самая бесполезная трата человеческого времени из всего списка. Запомните это.

Доказательства

Скриншот прикладывают по умолчанию, и это самое слабое из привычных доказательств. Скриншот доказывает, что страница выглядела неправильно. Почему — он не говорит.

По убыванию пользы для исправления бага:

Упавший запрос — метод, URL, статус, тело ответа и ID запроса или трассировки, если он есть. По ID запроса клиентский отчёт превращается в поиск по серверным логам — а это самый короткий путь от отчёта к первопричине.
Ошибка в консоли со стеком вызовов — указывает на строку кода.
Запись экрана — показывает тайминги и последовательность, чего скриншот не может.
Скриншот — показывает конечное состояние.

Большинство шаблонов просят четвёртое и не упоминают первые три, потому что для них нужен DevTools, а у авторов отчётов DevTools не открыт.

Теперь удалите большую часть

Вернитесь к шаблону и разделите поля по тому, кто может их заполнить.

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

Машина заполнит лучше: окружение, фактическое поведение и все четыре вида доказательств.

В каждом поле второй группы вы просите человека сделать работу хуже, чем сделал бы скрипт, и расплачиваетесь брошенными отчётами.

Посмотрите, о чём на деле спрашивает «Окружение». Браузер и точная версия — большинство людей не знают, где это найти. Версия ОС — то же самое. Размер вьюпорта — этого не знает никто, а именно это поле объяснило бы баг вёрстки. URL страницы — вставят адрес страницы, на которой находятся сейчас, то есть вашей формы поддержки. Версия приложения или хеш сборки — пользователю их не видно, так задумано.

Шесть значений, каждое браузер отдаёт без труда, и каждое стоит лишнего круга переписки с поддержкой, если просить его у человека.

К доказательствам тот же довод относится ещё сильнее. Вы просите нетехнического пользователя открыть DevTools, найти вкладку Network, воспроизвести баг, понять, какой из двухсот запросов нужный, и скопировать его ответ. Эту просьбу он не выполнит. А в коде это одна строка инструментации.

Какой должна быть форма

Оставьте в ней только то, что знает лишь человек:

## Что пошло не так?
[свободный текст]

## Что вы ожидали?
[свободный текст]

## Такое уже случалось?
( ) Впервые  ( ) Иногда  ( ) Каждый раз

Три поля. Тридцать секунд. А отчёт тем временем приходит с браузером, ОС, вьюпортом, URL, консолью — включая всё, что было залогировано до того, как открыли форму, — сетевым логом со статусами и таймингами, воспроизведением последних минут сессии, а также кликами и вводом пользователя по порядку.

Ради этого обмена всё и затевалось: человек пишет фразу, которую может написать только он, а машина прикладывает всё остальное.

Так и работает BugDump. Один тег script добавляет на страницу кнопку отчёта, пользователь пишет, что пошло не так, а отчёт приходит с уже приложенной телеметрией и скриншотом с пометками, на котором пользователь может размыть лишнее ещё до того, как скриншот покинет браузер. В бесплатном тарифе — 500 отчётов на проект.

Две вещи, которые по-прежнему делает человек

Автоматический сбор данных автоматизирует не всё, и границы лучше понимать чётко.

Разбирать отчёты по-прежнему должен человек. Двенадцать отчётов об одном и том же сломанном оформлении заказа должны стать одной задачей с двенадцатью доказательствами, и понять, что это один баг, может только человек. Именно при такой группировке дубликаты перестают быть шумом и становятся данными: двенадцать отчётов из пяти браузеров и двух операционных систем — это матрица, и закономерность в ней обычно указывает на причину. В BugDump так и устроено: отчёты — это доказательства, задачи — то, что вы исправляете, и к одной задаче привязывается много отчётов.

Замкнуть цикл тоже должен человек. Отчёт, отправленный в пустоту, отучает сообщать о багах. Каким бы инструментом вы ни пользовались, автор отчёта должен видеть, что дело сдвинулось с места. Дайте ему страницу статуса или напишите, когда исправление выйдет. Публичный портал, где видно, как задача переходит из Подтверждено в Готово, — самый дешёвый работающий вариант.

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