Какие бывают статусы у бага?

Статусы дефекта (бага) в процессе разработки ПО

Статусы бага — это ключевые метки, которые отражают его жизненный цикл (Bug Lifecycle) от момента обнаружения до полного устранения. Управление этими статусами является основой эффективной работы команды контроля качества и разработки. Конкретный набор статусов может незначительно варьироваться в зависимости от используемой методологии (Waterfall, Agile, Kanban) и инструмента (Jira, Trello, Bugzilla, Redmine, Azure DevOps), но общая логика остается единой.

Основные статусы дефекта (классический цикл)

1. New / Открыт (Open)

    *   **Описание:** Дефект только что создан тестировщиком (или другим участником проекта) и зарегистрирован в системе отслеживания. Это первоначальное состояние.
    *   **Действия:** Баг ожидает первичной проверки и назначения ответственного.

1. Assigned / Назначен

    *   **Описание:** Руководитель группы тестирования или менеджер проекта проверил отчет, подтвердил его валидность, воспроизводимость и соответствие стандартам оформления, после чего назначил его конкретному разработчику (или команде разработки) для исправления.
    *   **Ключевой момент:** Статус означает, что ответственность за анализ и исправление перешла к разработке.

1. In Progress / В работе

    *   **Описание:** Разработчик приступил к анализу и/или исправлению кода, чтобы устранить причину дефекта. В Agile-командах этот статус часто отображается на Kanban-доске.
    *   **Пример кода (символический комментарий):**

    ```java
    // Bugfix JIRA-123: NullPointerException in UserProfileService
    // Status changed from 'Assigned' to 'In Progress'
    public UserProfile getUserProfile(Long userId) {
        // Было: return userRepository.findById(userId).getData(); // Могло вернуть null
        // Исправлено:
        User user = userRepository.findById(userId);
        if (user == null) {
            throw new UserNotFoundException("User with id " + userId + " not found");
        }
        return user.getProfile();
    }
    ```

4. Fixed / Исправлен

    *   **Описание:** Разработчик завершил работу и заявляет, что внес необходимые изменения в код (или конфигурацию). Дефект помечается как исправленный и возвращается в очередь для **верификации** тестировщиком.
    *   **Важно:** Это не означает, что баг закрыт. Это означает, что он готов к повторной проверке.

1. Pending Retest / Ожидает повторной проверки

    *   **Описание:** Промежуточный статус, указывающий, что исправление развернуто на тестовом стенде (например, в среде **QA** или **Staging**) и готово для проверки тестировщиком, но проверка еще не началась.

1. Retest / Повторная проверка

    *   **Описание:** Тестировщик приступил к проверке исправления. Он выполняет шаги из исходного отчета, чтобы убедиться, что дефект устранен, и проводит **регрессионное тестирование** смежных областей приложения.

1. Reopened / Переоткрыт

    *   **Описание:** Самый нежелательный, но важный статус. Тестировщик в ходе верификации обнаружил, что проблема **не исправлена** полностью, проявилась снова или исправление повлекло за собой новый дефект. Баг возвращается разработчику (статус меняется обратно на `Assigned` или `In Progress`).
    *   **Причины:** Неполное исправление, регрессия, появление связанной ошибки.

1. Verified / Проверен

    *   **Описание:** Тестировщик подтвердил, что исправление работает корректно, и исходная проблема более не воспроизводится. Все связанные проверки (**регресс**, **smoke-тесты**) пройдены успешно. Баг готов к закрытию.

1. Closed / Закрыт

    *   **Описание:** Финальный статус. Дефект считается устраненным. Обычно закрытие выполняет тестировщик после верификации или менеджер после успешного выпуска версии (**Release**). Баг переходит в архив.

Дополнительные и альтернативные статусы

• Rejected / Отклонен

    *   **Описание:** Руководитель или разработчик отклоняет отчет. Это происходит, если баг признан **не воспроизводимым**, дубликатом существующего, **некорректным** (ошибка в тест-кейсе или окружении), или если описанное поведение является **фичей (feature)**, а не дефектом.

• Deferred / Отложен

    *   **Описание:** Дефект технически существует, но его исправление откладывается на более поздний срок (например, на следующую версию или спринт). Часто такое решение принимается из-за низкого приоритета, высокой сложности исправления или недостатка времени перед релизом.

• Duplicate / Дубликат

    *   **Описание:** Обнаруженный дефект уже был зарегистрирован ранее в системе. Текущий отчет связывается (**linked**) с оригинальным багом и закрывается.

• Cannot Reproduce / Не воспроизводится

    *   **Описание:** Разработчик не смог воспроизвести проблему в своем окружении с предоставленными шагами. Требуется уточнение от тестировщика (логи, скриншоты, видео, данные тестового окружения).

• Won't Fix / Не будет исправляться

    *   **Описание:** Редкий, но важный статус. Команда или продукт-менеджер осознанно принимает решение не исправлять дефект. Причины могут быть бизнес-ориентированными: крайне низкая важность, чрезмерно высокая стоимость исправления, риск внесения нестабильности в критический модуль.

Жизненный цикл на практике (упрощенная схема)

[New] → [Assigned] → [In Progress] → [Fixed] → [Pending Retest] → [Retest] → {Проверка}
       |          |               |         |                 |          |
       |          |               |         |                 |          +--> [Reopened] --(возврат к Assigned)...
       |          |               |         |                 +--> [Verified] → [Closed]
       |          |               |         +--> [Rejected]
       |          |               +--> [Deferred]
       |          +--> [Duplicate]
       +--> [Rejected]

Вывод: Понимание и четкое соблюдение жизненного цикла дефектов — это не бюрократия, а основа прозрачности и управляемости процесса. Это позволяет всем участникам команды (QA, разработчикам, менеджерам) видеть актуальное состояние работы, планировать нагрузку, избегать потерь информации и точно оценивать качество продукта на пути к релизу.