Что делать с баг-репортом, который не воспроизводится

воспроизведение багаDenis Povarov30 августа 2026 г.

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

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

Понять, почему баг воспроизводится у них и не воспроизводится у вас, — отдельное ремесло: разница всегда где-то в состоянии, тайминге, окружении или данных. Этот текст — о второй половине работы, о процессе. Что делать с тикетом сегодня, когда воспроизвести не получилось.

Замените «закрыто» настоящим решением

У невоспроизводимого отчёта три честных исхода, и «закрыто» к ним не относится:

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

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

Шаг 1: выжмите всё из отчёта, который у вас есть

Прежде чем открывать браузер, достаньте из отчёта всё, что в нём есть:

Сверьте время. Сопоставьте время отчёта с серверными логами и историей деплоев. «Сломалось в 14:02» рядом с «задеплоили в 13:58» раскрыло больше загадок, чем любой отладчик.
Найдите похожие отчёты. Та же страница, тот же текст ошибки, тот же эндпоинт — в трекере и в мониторинге ошибок. Отчёт, который кажется единственным в своём роде, часто оказывается третьим таким же под тремя разными заголовками.
Читайте симптом от конца к началу. Если кнопка «ничего не сделала», перечислите, что могло проглотить клик: заблокированная кнопка, ранний return, необработанное отклонение промиса. Каждая гипотеза подразумевает условие, в котором мог оказаться пользователь. Вы ещё не воспроизводите — вы составляете список гипотез.

Шаг 2: потратьте ровно час на воспроизведение в условиях пользователя

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

Если за час ничего не вышло, остановитесь. В охоте за воспроизведением без лимита времени средний баг и съедает целый спринт. Дальнейшие шаги от исхода этого часа не зависят.

Шаг 3: задайте автору один вопрос, а не пять

Анкету бросят, а на один конкретный вопрос ответят. Выберите тот, ответ на который делит ваш список гипотез пополам, — «повторяется ли это после обновления страницы?», «происходит ли это каждый раз на одной и той же записи?» — и отправьте только его.

И ещё одно правило: просите факты, а не работу. «Какой браузер?» — это факт, который пользователь не может надёжно сообщить, а инструмент собирает автоматически. Спрашивая об этом, вы тратите терпение автора на то, что должен был сделать тег script.

Шаг 4: отложите правильно

Отложить — не значит закрыть. У правильно отложенного тикета есть три вещи:

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

Шаг 5: второй отчёт — это прорыв в расследовании

Невоспроизводимые баги повторяются — это единственное, на что в них можно положиться. И второй отчёт меняет всё: один отчёт — это случай, два — сравнение, пять — набор данных. Спросите, что общего у этих случаев (браузер? роль? одна конкретная запись? время суток?) и чем они различаются. Общие переменные — ваша причина, остальное — шум.

Поэтому повторные отчёты должны складываться в одну задачу, а не закрываться как дубликаты: на этом классе багов стопка отчётов и есть анализ. Здесь же по-настоящему помогает ИИ-ассистент: через MCP-сервер BugDump Claude Code или Cursor пролистают все отчёты задачи и найдут общее быстрее, чем человек, который перематывает пять воспроизведений сессий.

Держите автора отчёта в курсе

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

Чините процесс, а не только баг

Всё, что этот план обходит, — неизвестное окружение, неизвестная последовательность действий, неизвестные ошибки — было в браузере автора отчёта в момент сбоя. Просто это не собрали. Отсюда и решение надолго: отчёт, отправленный через BugDump, приходит с буфером консоли (ошибки отмечены), последними сетевыми запросами (сбои подсвечены), браузером, ОС, устройством, вьюпортом, URL страницы и воспроизведением сессии, которое можно перематывать, — тем, что пользователь сделал в действительности. Добавьте один вызов identify, и вы будете знать, какой аккаунт проверять, а не подбирать похожий.

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