Когда заводишь новый баг - репорт, что с ним происходит дальше?

Жизненный цикл баг-репорта (Bug Workflow)

С момента создания баг-репорта начинается его структурированный жизненный цикл, который является краеугольным камнем процесса контроля качества. Вот типичный и подробный путь, основанный на классическом workflow в системах типа Jira, Yandex Tracker или Redmine.

1. Создание и логирование (Creation & Logging)

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

• Заголовок (Summary): Лаконичное и информативное описание проблемы.
• Шаги воспроизведения (Steps to Reproduce): Последовательные, четкие шаги. Ключевой элемент для воспроизводимости.
• Фактический и Ожидаемый результат (Actual/Expected Result).
• Серьезность (Severity): Влияние бага на систему (S1-Critical, S2-Major и т.д.).
• Приоритет (Priority): Срочность исправления (P1-High, P2-Medium и т.д.).
• Окружение (Environment): ОС, браузер, версия приложения.
• Вложения (Attachments): Скриншоты, логи, видео.

2. Валидация и назначение (Triage & Assignment)

Созданный репорт попадает на "триаж" (triage) — этап сортировки и оценки.

• Валидация (Validation): Лид QA или менеджер проекта проверяет корректность описания, воспроизводимость, отсутствие дубликатов. Иногда баг может быть отклонен сразу (например, "Not a Bug", "Duplicate").
• Назначение (Assignment): После валидации баг назначается:

    *   **Тимлиду/Менеджеру** для дальнейшего планирования, или напрямую
    *   **Разработчику (Dev Lead/Backend/Frontend)**, ответственному за проблемный модуль.

// Пример статуса бага в Jira-подобной системе после этой стадии
{
  "key": "PROJ-123",
  "status": "OPEN", // или "ASSIGNED"
  "assignee": "dev_smirnov",
  "priority": "P2",
  "severity": "S2"
}

3. Анализ и исправление (Analysis & Fix)

Разработчик входит в цикл работы:

• Анализ корневой причины (Root Cause Analysis): Изучает код, логи, находит источник проблемы.
• Разработка исправления (Coding the Fix): Пишет код, устраняющий дефект, стараясь не создать регрессию.
• Модульное тестирование (Unit Testing): Проверяет свое исправление на уровне модуля.
• Фиксация изменений (Commit): Пуш изменений в ветку системы контроля версий (Git). В комментарии к коммиту указывает ID бага (Fixes PROJ-123).
• Смена статуса: Меняет статус бага на "Resolved" или "Fixed", часто заполняя поле "Resolution".

4. Верификация (Verification & QA Check)

Баг возвращается в зону ответственности QA.

• Построение билда: QA проверяет, что исправление попало в тестовую сборку (например, в ветку develop).
• Повторное тестирование (Re-test): Инженер точно повторяет шаги из репорта на актуальной сборке, чтобы убедиться, что проблема устранена.
• Регрессионное тестирование (Regression Testing): Проверяет область вокруг исправления и связанную функциональность на предмет появления новых дефектов.
• Исход: По результатам:

    *   **PASS ->** Статус меняется на **"Verified"** или **"Closed"**. Баг закрыт.
    *   **FAIL ->** Статус меняется обратно на **"Reopened"** с комментарием. Цикл повторяется с п.3.

5. Закрытие и мониторинг (Closure & Monitoring)

• Закрытие (Closing): После успешной верификации баг закрывается. В идеале это делает автор репорта.
• Отслеживание метрик (Metrics Tracking): Данные по закрытому багу (время жизни, приоритет, компонент) попадают в QA-метрики (например, Cycle Time, Reopen Rate). Это помогает анализировать качество процесса и продукта.
• Пост-релизная проверка (Post-Release Check): Особо критичные баги, исправленные в релизе, дополнительно проверяются на production-окружении после деплоя.

Ключевые статусы в жизненном цикле:

1. OPEN/NEW -> ASSIGNED -> IN PROGRESS (Dev) -> RESOLVED/FIXED -> VERIFIED (QA) -> CLOSED.
2. При неудовлетворительном исправлении: RESOLVED -> REOPENED -> ASSIGNED (снова).

Важно понимать, что этот процесс гибкий и зависит от методологии (Agile, Waterfall), политики компании и возможностей трекер-системы. В некоторых случаях этапы "триажа" или "верификации" могут быть формализованы меньше, но их суть всегда присутствует. Основная цель — обеспечить прозрачность, отслеживаемость и гарантировать, что каждый дефект будет должным образом обработан и устранен.