Какие знаешь статусы баг репорта?

Статусы баг-репорта: полное руководство

В процессе управления дефектами статус баг-репорта — это системный индикатор, отражающий текущий этап жизненного цикла дефекта. Чёткое понимание и единообразное использование статусов критически важно для эффективной коммуникации между командами (QA, разработка, менеджмент) и для контроля над процессом исправления. Статусы могут незначительно варьироваться в разных трекерах (Jira, YouTrack, Redmine, Bugzilla), но их общая логика и назначение остаются универсальными.

Я, как опытный QA-инженер, выделяю основные (базовые) статусы, которые должны быть в любом процессе, и расширенные (дополнительные), которые добавляются для более тонкого управления в сложных workflow.

Основные (ядерные) статусы

Эти статусы образуют базовый цикл жизни почти любого дефекта.

• Open / Новый (New): Баг только что создан и зарегистрирован в системе. Обычно он ещё не был просмотрен ответственным разработчиком или лидом. Это отправная точка.
• Assigned / Назначен (In Progress): Дефект взят в работу конкретным разработчиком или командой. Статус явно указывает на ответственного и сигнализирует, что анализ или исправление началось.
• Fixed / Исправлен: Разработчик сообщает, что внес необходимые изменения в код для устранения дефекта. Баг переводится в этот статус и обязательно должен быть передан на верификацию тестировщику. Часто сопровождается комментарием о коммите или номере сборки.
• Verified / Closed / Проверен (Закрыт): QA-инженер повторно протестировал сценарий на указанной сборке и подтвердил, что дефект более не воспроизводится, а его исправление не вызвало регрессии. После этого баг может быть закрыт. В некоторых процессах "Verified" и "Closed" — это два разных статуса.
• Reopened / Переоткрыт: Если в ходе верификации (статус "Fixed") баг снова воспроизводится, либо оказалось, что фикс был неполным/ошибочным, тестировщик переводит дефект обратно в статус "Assigned" или "Reopened". Это ключевая петля обратной связи в процессе.
• Rejected / Отклонен: Разработчик или аналитик посчитали, что описанное поведение не является дефектом. Возможные причины: некорректная настройка среды тестирования, неверно понятое требование ("работает как задумано"), дубликат уже существующей задачи. Важный момент: статус "Rejected" всегда должен содержать развернутое техническое или логическое обоснование.**

Расширенные и уточняющие статусы

Они вводятся для более точного отслеживания и управления потоком работ.

• In Review / На ревью: Исправление кода готово и отправлено на code review коллеге или тимлиду. Это промежуточный этап между "Assigned" и "Fixed".
• Deferred / Отложен (Postponed): Дефект признан валидным, но его исправление решено отложить на более позднюю версию (спринт, релиз) по приоритету, сложности или стратегическим причинам. Требует согласования с продакт-менеджером.
• Duplicate / Дубликат: Обнаруженный дефект уже зарегистрирован в системе под другим идентификатором. Текущий отчет следует закрыть, указав ссылку на основной (первичный) баг-репорт.
• Cannot Reproduce (CNR) / Не воспроизводится: Разработчик не смог воспроизвести проблему в своей среде на указанных шагах. Это требует от QA максимально детализированных шагов, данных, логов и скриншотов. Часто баг возвращается тестировщику для уточнения.
• Won't Fix / Не будет исправлен: Редкий, но важный статус. Дефект технически существует, но руководство принимает осознанное решение не тратить ресурсы на его исправление (например, из-за крайне низкой критичности, огромной стоимости переделки устаревшего модуля или если баг появляется на неподдерживаемой платформе).

Практический пример workflow в Jira

// Упрощенный жизненный цикл бага с основными статусами и переходами
public class BugLifecycle {
    public static void main(String[] args) {
        BugReport bug = new BugReport("UI-101", "Кнопка 'Отправить' неактивна после валидации");

        bug.setStatus(Status.OPEN); // 1. QA создает баг -> OPEN
        // Лид разработки назначает задачу
        bug.assignTo("dev_smirnov");
        bug.setStatus(Status.ASSIGNED); // 2. Баг назначен -> ASSIGNED

        // Разработчик анализирует и исправляет
        bug.setFixVersion("build-2.5.1");
        bug.setStatus(Status.FIXED); // 3. Разработчик сообщает об исправлении -> FIXED

        // QA проводит верификацию
        if (bug.verify("build-2.5.1")) {
            bug.setStatus(Status.VERIFIED); // 4.1 Успешно -> VERIFIED
            bug.setStatus(Status.CLOSED);   // 4.2 Затем -> CLOSED
        } else {
            bug.setStatus(Status.REOPENED); // 4.3 Неудача -> REOPENED
            bug.assignTo("dev_smirnov");
            bug.setStatus(Status.ASSIGNED); // Возврат в цикл
        }
    }
}
enum Status { OPEN, ASSIGNED, FIXED, VERIFIED, CLOSED, REOPENED }

Ключевые принципы работы со статусами

1. Единый глоссарий: Вся команда (Dev, QA, PM) должна одинаково понимать значение каждого статуса. Это прописывается в Wiki или соглашении о процессе.
2. Обязательность комментариев: Ключевые переходы (особенно Rejected, Deferred, Fixed) должны сопровождаться исчерпывающими комментариями. "Fixed" — в какой сборке, "Rejected" — по какой причине.
3. Ответственность за переход: Чётко определено, кто имеет право менять статус. Например, только QA может перевести баг в Closed или Reopened, а только разработчик — в Fixed или Cannot Reproduce.
4. Адаптивность: Набор статусов должен отражать реальный процесс команды. Для простой команды достаточно 5-6 основных, для больших распределённых команд с код-ревью нужны дополнительные (In Review, Ready for Merge).

Понимание нюансов каждого статуса позволяет QA-инженеру не только корректно вести отчётность, но и эффективно управлять процессом исправления дефектов, выступая его полноценным владельцем и контролёром. Именно статусы являются тем языком, на котором команда говорит о здоровье и качестве продукта