Какие атрибуты должны быть в багрепорте
Что проверяют
Умеете ли вы писать баг так, чтобы разработчик воспроизвёл его без переписки с вами. Следом обычно просят объяснить разницу между severity и priority или разобрать плохой заголовок.
Как отвечать
Перечислите поля и коротко скажите, зачем каждое:
- ID: присваивает трекер (Jira, YouTrack), по нему баг связывают с задачей и коммитом;
- заголовок: суть по схеме «что, где, при каком условии», например «Корзина: итог не пересчитывается после удаления промокода». Без слов «не работает» и «ошибка»;
- предусловия: роль пользователя, тестовые данные, включённые фича-флаги;
- шаги воспроизведения: пронумерованные, минимальные, по одному действию на шаг;
- фактический и ожидаемый результат: ожидаемый со ссылкой на требование или макет, иначе это ваше мнение;
- окружение: стенд, версия сборки, ОС, браузер или устройство;
- severity: влияние на систему, обычно blocker, critical, major, minor, trivial;
- priority: срочность исправления, её часто выставляет PM или тимлид;
- вложения: скриншот с пометкой, видео, логи, HAR-файл или запрос из DevTools, ответ API;
- служебные поля: автор, исполнитель, компонент, статус, частота воспроизведения.
Дату, время и автора трекер ставит сам, отдельно их расписывать не нужно. Хорошо добавить, что перед заведением бага вы ищете дубликат и проверяете воспроизведение на свежей сборке.
Где спотыкаются
Путают severity и priority. Опечатка в названии бренда на главной имеет тривиальную severity и высокий приоритет, а падение в редком админском отчёте наоборот.
Не указывают версию сборки и стенд. Разработчик проверяет на другой ветке, не воспроизводит и закрывает баг.
Смешивают в одном репорте несколько проблем или пишут шаги сплошным абзацем с «ну и там дальше». Такой баг невозможно ни проверить после исправления, ни закрыть частично.