Ответ
Типичный workflow баг-репорта включает следующие статусы (названия могут незначительно отличаться в разных системах, например, Jira, Bugzilla):
- New / Open — дефект только что создан и ожидает первоначальной проверки.
- Assigned / In Progress — баг назначен разработчику и находится в работе.
- Fixed / Resolved — разработчик завершил исправление и отправил код на проверку. Часто требует указания Resolution (см. ниже).
- Ready for Test / Pending Verification — исправление выложено на тестовое окружение и готово для проверки тестировщиком.
- Verified / Closed — тестировщик подтвердил, что исправление работает корректно, и баг закрыт.
- Reopened — баг был воспроизведён снова после фикса. Возвращается в статус New/Open или Assigned.
Дополнительные Resolution (причины закрытия) или отдельные статусы:
- Duplicate — дефект является дубликатом уже существующего.
- Won't Fix — баг признан валидным, но его исправление не планируется (низкий приоритет, затраты > пользы).
- Cannot Reproduce — команда не смогла воспроизвести проблему на предоставленных данных.
- Not a Bug / Works as Intended — описанное поведение является корректным согласно требованиям.
- Deferred / Postponed — исправление отложено на будущие релизы.
Пример типичного цикла в Jira:
[OPEN] → [IN PROGRESS] → [RESOLVED (Fixed)] → [VERIFIED] → [CLOSED]
↳ [REOPENED] ─────┘Почему это важно: Чёткое следование workflow и правильное использование статусов обеспечивает прозрачность процесса, позволяет отслеживать прогресс и избегать потери дефектов.