Ответ
На последнем проекте мы следовали строгому шаблону для баг-репортов в Jira. Каждый отчет о дефекте должен был содержать:
- Заголовок (Summary): Краткое и информативное описание проблемы. Использовался шаблон
[Область] Краткое описание дефекта. Например:[Checkout] Применение промокода "SUMMER20" приводит к ошибке 404. - Шаги воспроизведения (Steps to Reproduce): Нумерованный, детальный список действий. Важно, чтобы по этим шагам любой член команды мог воспроизвести проблему.
- Фактический результат (Actual Result): Что система делает на самом деле после выполнения шагов.
- Ожидаемый результат (Expected Result): Как система должна вести себя согласно требованиям или здравому смыслу.
- Окружение (Environment): Обязательно указывались: версия приложения, ОС, браузер и его версия (для веба), модель устройства (для мобильных тестов). Мы использовали заранее заготовленные значения из списка.
- Серьезность/Приоритет (Severity/Priority):
- Severity (Blocker, Critical, Major, Minor, Trivial) — объективная оценка влияния дефекта на функциональность.
- Priority (P0 - P3) — субъективная оценка срочности исправления, выставляемая продакт-менеджером.
- Вложения (Attachments): Скриншот с аннотациями, логи консоли браузера, видео запись экрана или HAR-файл для сетевых проблем.
Ключевые правила: дефект должен быть воспроизводим, изолирован (описывает одну проблему) и четко сформулирован. Перед заведением я всегда проверял, не был ли подобный баг уже создан.