Как выглядит идеальный багрепорт

Что проверяют

Умеете ли вы писать так, чтобы разработчик воспроизвёл дефект с первого раза и не пришёл с вопросами. Отдельно смотрят, различаете ли вы серьёзность и приоритет. Следом часто показывают реальный баг и просят сформулировать заголовок вслух.

Как отвечать

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

• заголовок: по формуле «что, где, при каком условии». Например, «Корзина: 500 при добавлении товара со скидкой из карточки». Без слов «не работает» и «ошибка»;
• окружение: стенд, версия сборки, ОС, браузер или модель устройства. Без версии сборки баг не привязать к релизу;
• предусловия: тестовый аккаунт, роль, состояние данных, включённые фича-флаги;
• шаги: пронумерованные, одно действие на шаг, с конкретными входными данными;
• ожидаемый результат: со ссылкой на требование, макет или спецификацию API, а не «как мне кажется»;
• фактический результат: что именно произошло, текст ошибки, код ответа;
• вложения: скриншот с выделенной областью, короткое видео, логи, HAR-файл или request id из ответа, по которому бэкенд найдёт запрос в своих логах;
• серьёзность и приоритет: серьёзность оценивает влияние на систему, приоритет задаёт очередь исправления, и его обычно ставит менеджер или лид;
• частота: воспроизводится всегда или один раз из десяти.

Добавьте, что перед заведением бага вы ищете дубли в трекере (Jira, YouTrack) и локализуете проблему: фронт или бэк, одна платформа или все.

Где спотыкаются

Складывают в один репорт несколько дефектов. Один чинят, второй теряется вместе с закрытой задачей.

Путают серьёзность и приоритет. Опечатка в названии продукта на главной странице имеет низкую серьёзность, но высокий приоритет, и этот пример стоит держать наготове.

Пишут шаги с пропусками вроде «авторизоваться и открыть заказ», не указывают тестовые данные и версию сборки. Разработчик не воспроизводит баг, и тот уходит в статус «не воспроизводится».