Жизненный цикл бага
Каждый баг проходит жизненный цикл от обнаружения до решения. Понимание этого цикла помогает эффективно отслеживать баги и гарантировать, что ничего не будет упущено.
Стандартные статусы
New
Баг зарегистрирован QA. Ещё не рассмотрен и не назначен.
Open (Assigned)
Баг рассмотрен, принят как валидный и назначен на разработчика.
In Progress
Разработчик активно работает над исправлением.
Fixed (Ready for QA)
Разработчик реализовал исправление и развернул его в тестовом окружении.
Verified (QA Passed)
QA подтвердил, что исправление решает исходную проблему.
Closed
Баг решён, исправление развёрнуто в production. Цикл завершён.
Reopened
Верификация QA не прошла — исправление не решает проблему или баг вернулся.
Специальные статусы
Duplicate
Тот же баг уже был зарегистрирован. Связать с оригиналом.
Cannot Reproduce
Баг не удаётся воспроизвести по описанным шагам.
Won’t Fix
Баг валиден, но принято осознанное решение не исправлять.
Причины: Стоимость исправления превышает влияние, функция выводится из эксплуатации, исправление может сломать обратную совместимость.
Deferred
Баг валиден, но исправление отложено на будущий релиз.
Invalid (Not a Bug)
Описанное поведение на самом деле by design.
Схема жизненного цикла
Роли на каждом этапе
| Этап | Роль QA | Роль разработчика | Роль PM |
|---|---|---|---|
| New | Создать детальный репорт | — | — |
| Triage | Объяснить, уточнить | Оценить сложность | Приоритизировать |
| Open | Мониторить | Принять назначение | Отслеживать прогресс |
| In Progress | Быть доступным для вопросов | Реализовать fix | Убирать блокеры |
| Fixed | Тщательно верифицировать | Объяснить изменения | — |
| Verified | Подтвердить решение | — | Планировать деплой |
| Closed | Обновить тест-кейсы | — | Отчитаться стейкхолдерам |
| Reopened | Объяснить, почему fix не сработал | Переанализировать | Скорректировать приоритеты |
Упражнение: Проследите пути багов
Для каждого сценария опишите полный путь жизненного цикла бага.
- QA регистрирует crash. Разработчик обнаруживает, что причина та же, что у бага #234, который уже исправляется.
- QA регистрирует медленную загрузку. Разработчик выясняет, что это происходит только с конкретным расширением браузера.
- QA регистрирует проблему выравнивания UI. PO говорит, что исправление задержит релиз на 2 дня.
- QA регистрирует баг форматирования данных. Разработчик исправляет. QA верифицирует — исходная проблема решена, но fix привнёс новый баг.
Решение
Сценарий 1: New → Duplicate (связан с #234). Закрыть с примечанием.
Сценарий 2: New → Cannot Reproduce → (QA предоставляет информацию о расширении) → Reopened → Open → In Progress → Fixed → Verified → Closed. Или: New → Invalid (если расширение не поддерживается).
Сценарий 3: New → Open → Deferred (цель: релиз v3.2).
Сценарий 4: New → Open → In Progress → Fixed → Reopened (QA: «Исходная проблема решена, но fix внёс регрессию»). Разработчик получает reopened баг И создаётся новый баг #567.
Лучшие практики
- Всегда объясняйте смену статуса — никогда не меняйте статус без комментария
- Связывайте родственные баги — дубликаты, регрессии и связанные issues
- Перепроверяйте после reopening — верифицируйте и исходную проблему, и регрессию
- Отслеживайте deferred баги — пересматривайте при планировании каждого релиза
- Закрывайте вовремя — не оставляйте верифицированные баги висящими
Ключевые выводы
- Жизненный цикл: New → Open → In Progress → Fixed → Verified → Closed
- Специальные пути: Duplicate, Cannot Reproduce, Won’t Fix, Deferred, Invalid
- Reopened баги возвращаются в In Progress — всегда объясняйте, почему fix не сработал
- QA верифицирует исправления; Product Owner решает по приоритету и отсрочке
- Каждая смена статуса сопровождается комментарием