Какой жизненный цикл у бага в системе отслеживания?

После создания (заведения) в системе управления задачами (Jira, YouTrack, Bugzilla) баг проходит через последовательность статусов — жизненный цикл дефекта (Bug Lifecycle).

Типичный workflow:

1. New / Открыт: Дефект зарегистрирован и ожидает первоначальной проверки.
2. Assigned / Назначен: Баг назначен конкретному разработчику или команде для исправления.
3. In Progress / В работе: Разработчик приступил к анализу и исправлению.
4. Fixed / Исправлен: Разработчик завершил работу и помечает баг как исправленный, указывая версию сборки.
5. Ready for Test / На проверке: Баг передан в очередь для тестирования.
6. Testing / Проверка: Тестировщик проверяет исправление в указанной сборке.
7. Verified / Проверено: Исправление подтверждено, баг может быть закрыт.
8. Closed / Закрыт: Дефект окончательно закрыт.

Альтернативные пути:

• Reopened / Переоткрыт: Если при проверке баг воспроизводится снова, он возвращается в статус In Progress или Assigned.
• Won't Fix / Не будет исправлен: Решение об отказе от исправления (например, низкий приоритет, нецелесообразность).
• Duplicate / Дубликат: Баг уже заведен ранее.
• Cannot Reproduce / Не воспроизводится: Тестировщик или разработчик не смогли воспроизвести проблему по описанию.

Пример диаграммы состояний в Mermaid:

stateDiagram-v2
    [*] --> New
    New --> Assigned : Триаж
    Assigned --> InProgress : Взят в работу
    InProgress --> Fixed : Исправлен
    Fixed --> Testing : Сборка готова
    Testing --> Closed : PASS
    Testing --> InProgress : FAIL → Reopened
    New --> Rejected : (Duplicate, Won't Fix, Not a Bug)
    Rejected --> [*]
    Closed --> [*]