Хороший баг-репорт исправляют. Плохой получает метку «не воспроизводится», просьбу дать подробности, на которую автор так и не ответит, и медленно умирает на дне бэклога. Разница редко в старании. Важно другое: знает ли автор, что нужно человеку, который будет исправлять баг.
Ниже — из чего состоит отчёт, который переживает разбор, и неважно, пишете вы его сами или учите пользователей и коллег писать отчёты лучше.
Из чего состоит полезный отчёт
Заголовок описывает сбой, а не эмоцию
«Оформление заказа сломано» ничего не говорит разработчику. «Оформление заказа: после промокода по клику на „Оплатить“ спиннер крутится бесконечно» говорит, где искать и что попробовать, и подсказывает, что вызывает сбой. В хорошем заголовке есть место, действие и наблюдаемый результат.
Шаги воспроизведения
Запишите самую короткую последовательность действий, которая вызывает баг, начиная с известного состояния:
Войти как покупатель, у которого в корзине есть товар
Применить промокод SAVE10
Нажать «Оплатить»
Нумерованные шаги нужны, потому что тот, кто исправляет баг, будет выполнять их буквально. Если шаг 2 обязателен, а вы его пропустили, баг воспроизводится у вас и не воспроизводится у него — и вы оба застряли.
Ожидаемое и фактическое поведение
Две короткие строки: что должно было произойти и что произошло вместо этого. Звучит как бюрократия, пока не попадётся баг, в котором автор и разработчик по-разному понимают, что вообще считать правильным. «Ожидалось: страница подтверждения заказа. Фактически: бесконечный спиннер, после клика ни одного сетевого запроса» — и двусмысленности не остаётся.
Окружение
Браузер и его версия, операционная система, устройство, размер экрана и точный URL страницы. Огромная доля фронтенд-багов зависит от окружения: дату неправильно разбирает только Safari, вёрстка ломается только на ширине планшета. Без данных об окружении разработчик проверяет в своём браузере, ничего не видит и закрывает отчёт.
Доказательства
Именно они отличают отчёт, по которому причину находят за пять минут, от отчёта, на который уходит день:
Вывод консоли — само сообщение об ошибке и стек вызовов, а не пересказ.
Сетевая активность — какой запрос упал и с каким кодом ответа.
Скриншот или запись экрана — особенно для визуальных багов и багов вёрстки, где тысяча слов и правда хуже одной картинки.
Время — когда это случилось, чтобы сопоставить с серверными логами и деплоями.
Почему пользователи не станут делать ничего из этого
Тут неприятный момент: требовать этот чек-лист от QA-инженера разумно, а от пользователя — абсурдно. Пользователи не знают, что такое консоль, не станут искать версию браузера и не напишут шаги воспроизведения. Честный максимум, на который они способны, — «не работает», и каждое новое поле в форме отсекает ещё часть отчётов.
Вариантов два. Можно принимать расплывчатые отчёты и платить за это на разборе. А можно собирать техническую половину отчёта автоматически, а от пользователя получать то единственное, что есть только у него: что он пытался сделать.
На этой модели построены виджеты для баг-репортов. С инструментом вроде BugDump пользователь нажимает кнопку и пишет одно предложение, а виджет сам прикладывает логи консоли, сетевые запросы, воспроизведение сессии, данные об окружении и URL страницы. Пользователь пишет «нажал оплатить, ничего не произошло», и этого хватает: необработанное исключение и упавший запрос уже лежат в отчёте.
Чек-лист
Для отчётов, которые человек пишет целиком сам (внутренний QA, отчёты коллег, issues на GitHub):
В заголовке есть место, действие и наблюдаемый результат
Пронумерованные шаги воспроизведения из известного начального состояния
Ожидаемое поведение, одной строкой
Фактическое поведение, одной строкой
Окружение: браузер и версия, ОС, устройство, размер вьюпорта, URL
Ошибки консоли, скопированные дословно
Упавший сетевой запрос и код ответа, если такой есть
Скриншот или запись экрана для всего визуального
Серьёзность и масштаб: кто на это натыкается и как часто?
Для отчётов от пользователей чек-лист меняется: большинство пунктов должен отмечать инструмент, а не человек.
Описание словами самого пользователя (единственное обязательное поле)
Всё остальное — окружение, консоль, сеть, воспроизведение сессии — собирается автоматически
Автор отчёта подставляется автоматически, если пользователь вошёл в аккаунт, чтобы с ним можно было связаться
Один отчёт — один баг
Не складывайте всё в один отчёт. «Дашборд тормозит, ещё кнопка экспорта сломана, и тёмная тема выглядит не так» — это три бага под одним номером. Сборный отчёт нельзя приоритизировать (серьёзность у багов разная), нельзя закрыть (после одного исправления он на две трети открыт) и нельзя толком назначить. Заведите три отчёта. Если ваш трекер собирает отчёты в задачи — BugDump превращает отчёты в карточки на канбан-доске, — эта дисциплина окупается сразу: каждая карточка движется по доске сама по себе.
Честная серьёзность
Оценивайте серьёзность по последствиям, а не по тому, насколько баг раздражает. Опечатка, за которую лично вам стыдно, — низкая серьёзность. Сбой оплаты в одном браузере — высокая, даже если вы не можете его воспроизвести. Если все отчёты помечать как «критичные», команда научится вообще не смотреть на это поле, а это хуже, чем не иметь его совсем.
Что это даёт
Хорошие баг-репорты дают накопительный эффект. Отчёт с настоящими доказательствами исправляют быстрее, поэтому бэклог остаётся коротким, разбор — быстрым, а на по-настоящему сложные отчёты остаётся больше времени. И эта привычка заразна: разработчики, которым приходят хорошие отчёты, начинают сами писать такие же.
Пишите такой отчёт, какой вы хотели бы получить в пятницу в пять вечера, — и автоматизируйте всё, что автор отчёта не обязан уметь собирать.
Читайте также
Шаблон баг-репорта, который работает (и как его автоматизировать) — готовые поля для отчёта и какие из них лучше заполнять инструменту, а не человеку.
Анатомия баг-репорта: что собирает BugDump и зачем — какие данные виджет BugDump прикладывает к отчёту и как каждое помогает найти причину.
Что делать с баг-репортом, который не воспроизводится — что проверить, прежде чем закрыть отчёт с пометкой «не воспроизводится».