Что делать с баг-репортом, который не воспроизводится
Как системно работать с багами, которые не удаётся воспроизвести: частые причины, контекст, который их раскрывает, и как не дать им повторяться.
Идеи, руководства и новости от нашей команды.
Как системно работать с багами, которые не удаётся воспроизвести: частые причины, контекст, который их раскрывает, и как не дать им повторяться.
Сторонний виджет, который отдаёт каждому посетителю 450 КБ, должен это чем-то оправдать. Мой не мог. Замер, исправление и то, в чём я ошибался насчёт defer.
После раунда UAT остаётся таблица на шестьдесят строк, и с половиной из них ничего нельзя сделать. Дело редко в тестерах. Дело в канале отчётов: он теряет доказательства ровно в тот момент, когда они есть.
MCP превращает ваш продукт в источник, который читает ИИ-агент. Это несложно. Сложно спроектировать инструменты так, чтобы агент с первой попытки пользовался ими правильно, а это совсем другая задача, чем проектирование REST API.
«Не воспроизводится» — это не свойство бага. Это утверждение о разнице между двумя машинами. Таких различий всего около восьми, и у каждого свой узнаваемый признак.
Шаблон баг-репорта пишет каждая команда. Большинство шаблонов через месяц никто не заполняет: они просят людей делать работу, которую за них мог бы сделать браузер. Ниже — шаблон, который стоит оставить, и доводы за то, чтобы удалить из него три четверти.
DevTools открыт не на той машине. Как перехватить console, ошибки, fetch и XHR, чтобы браузер пользователя сам рассказал, что произошло, и в какие ловушки попадают наивные реализации, которые ломают страницу, за которой следят.
Разделить отчёты и задачи — небольшое структурное решение, которое не даёт входящим багам превратиться в кладбище и делает дубликаты отчётов лучшим материалом для отладки.
У воспроизведения сессии плохая репутация, и по большей части заслуженная. Как оно устроено в BugDump: привязано к отчёту, лишнее пользователь скрывает сам, а выключается всё одной строкой.
Я выпустил MCP-сервер, чтобы Claude Code сам доставал баг-репорты, логи консоли и сетевые запросы. Получился цикл отладки, в котором вы ни разу не открываете веб-интерфейс BugDump.
Каждый сигнал, который собирает виджет BugDump: зачем он нужен и какие из них на деле помогают исправлять баги.
Эта переписка знакома каждому разработчику. Пользователь пишет, что всё сломалось, вы спрашиваете, какой у него браузер, и пока он ответит, час уже потерян. Мне это надоело.