Баг-репорт, который не закроют с пометкой «не воспроизводится»

Вы передали ошибку разработчику, а через два дня задача вернулась со статусом «не воспроизводится». Чаще всего дело не в разработчике — ему просто не хватило того, что вы видели, а он нет.

Почему задачи возвращаются

Когда вы разбирали заявку, у вас перед глазами было многое: переписка с пользователем, его учётная запись, вкладка с логами, время обращения. Часть этого вы держали в голове и не записали, потому что для вас это было очевидно.

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

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

Время: поле, на котором чаще всего экономят

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

Правильно писать так: «первые ошибки зафиксированы в 09:32 МСК, последняя — в 10:15 МСК». Даже если точность приблизительная, интервал в сорок минут отличается от интервала в двенадцать часов принципиально.

Три момента, которые стоит держать в голове.

Часовой пояс указывайте всегда. Пользователь во Владивостоке, вы в Москве, сервер пишет логи в UTC — при разборе инцидента три разных времени в одной задаче гарантированно приведут к путанице.

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

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

Окружение

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

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

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

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

• откуда начинать — конкретный адрес страницы или экран приложения;
• под какой учётной записью, с какой ролью;
• какие данные вводить — с реальными значениями, а не «вводим корректный номер»;
• что происходит на каждом шаге;
• на каком шаге ломается.

Обязательно разделите «что ожидалось» и «что получилось». Это звучит как формальность из учебника, но именно здесь чаще всего выясняется, что пользователь и разработчик по-разному понимают, как система вообще должна работать, — и никакого бага нет.

Логи и запрос

Раздел, который отличает баг-репорт от L2 от простой пересылки жалобы.

Приложите ссылку на выборку в системе логов — уже с наложенными фильтрами по времени и сервису, а не просто ссылку на Kibana. Если ошибок много, укажите их количество и динамику: «за час 340 ошибок, пик в 09:40». Разработчик по этой строке сразу поймёт масштаб.

Если ошибка в API, вложите готовый curl, который можно скопировать и выполнить. Не описание запроса словами, а именно исполняемую команду — с методом, адресом, заголовками и телом. Токены, разумеется, замените на заглушки. Такой curl снимает с разработчика полчаса работы по восстановлению запроса и резко повышает шанс, что задачу возьмут сегодня, а не в следующем спринте.

Сюда же: идентификаторы. user_id, номер заказа, trace_id или request_id, если в системе сквозная трассировка. Один идентификатор запроса нередко заменяет половину описания.

Код ответа тоже пишите явно — по нему часто сразу видно, где остановился запрос. Что означают самые частые из них, разобрано в статье про ошибки 401, 403 и 404.

Пример

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

Время: первая ошибка 09:32 МСК 21.09.2026, последняя 10:15 МСК. На момент заведения задачи ошибка не повторяется.

Окружение: прод, Chrome 141 / Windows 11, десктоп, домашняя сеть. Воспроизводится также в Safari на iOS.

Пользователи: user_id 884213, 884477, 885901 (всего 12 обращений).

Шаги:

Войти под user_id 884213 Открыть /cart/, нажать «Оформить» Выбрать оплату картой, ввести данные тестовой карты 4111... Нажать «Оплатить»

Ожидалось: переход на страницу успешной оплаты. Получилось: страница ошибки «Платёж отклонён», в этот момент приходит СМС о списании.

Запрос: <curl, если ошибку можно воспроизвести отправкой запроса> Логи: <ссылка на выборку с фильтром по сервису и интервалу> За период 340 ошибок.

Такой репорт читается за минуту, и все вопросы, которые разработчик мог бы задать, уже закрыты.

Если воспроизвести не удалось

Это нормальная ситуация, и она не повод не заводить задачу — повод оформить её иначе.

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

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

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

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