Что происходит с багом после того, когда его заводят

Жизненный цикл бага в Jira-подобной системе: от создания до архивации

После того как тестировщик (или любой член команды) обнаруживает и создаёт баг в системе учёта (например, Jira, Azure DevOps, GitLab Issues), он начинает свой формализованный жизненный цикл. Этот процесс обеспечивает отслеживаемость, приоритизацию и контроль качества. Статусы и переходы могут незначительно отличаться, но общий поток выглядит следующим образом:

Основные статусы и переходы бага

1. Open / New / Created — начальный статус. Баг только что создан, заполнены обязательные поля (краткое описание, шаги воспроизведения, окружение, ожидаемый/фактический результат, приложены скриншоты/логи).
2. Assigned / In Progress — баг назначен на ответственного (чаще всего разработчика). Может включать этап Analysis, где разработчик пытается воспроизвести проблему и локализовать её причину.
3. Fixed / Resolved — разработчик внёс изменения в код, исправил дефект и отметил баг как разрешённый. Здесь часто указывается резолюция (Resolution).
4. Ready for Test / Pending Verification — исправление попадает на тестовый стенд (например, после успешного CI/CD пайплайна). Баг переводится в статус, сигнализирующий тестировщику о необходимости проверки.
5. Reopened — если при проверке выясняется, что баг воспроизводится или исправление повлекло регрессию, тестировщик переводит баг обратно в Assigned. Цикл «исправление-проверка» повторяется.
6. Verified / Closed — если исправление прошло валидацию, баг помечается как проверенный и окончательно закрывается.

Ключевые атрибуты и действия на каждом этапе

• Приоритизация и назначение: Менеджер или тимлид анализирует новый баг, выставляет приоритет (Blocker, Critical, Major, Minor) и назначает исполнителя.
• Резолюции (Resolutions): При закрытии бага проставляется причина:

    *   `Fixed` — исправлен.
    *   `Won't Fix` — не будут исправлять (например, маловероятный сценарий, стоимость исправления превышает пользу).
    *   `Duplicate` — дубликат уже существующего бага. Важно указать ссылку на основной.
    *   `Cannot Reproduce` — не удаётся воспроизвести на предоставленных данных.
    *   `Not a Bug` — поведение соответствует требованиям или является фичей.
    *   `Obsolete` — проблема утратила актуальность (например, функционал удалён).

• Связь с кодом: В современных практиках (DevOps) статус бага часто автоматически меняется при событиях в репозитории:

  # Коммит-сообщение, ссылающееся на баг, может автоматически перевести его в "In Progress"
  git commit -m "JIRA-123: Fix null pointer exception in user profile validation"
  

  # Пример конфигурации пайплайна GitLab CI для автоматического закрытия бага
  deploy_to_staging:
    stage: deploy
    script:
      - deploy-script.sh
    only:
      - main
    after_script:
      - |
        if [ "$CI_JOB_STATUS" == "success" ]; then
          curl --request POST --header "PRIVATE-TOKEN: $API_TOKEN" \
          "https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/issues/$ISSUE_ID/notes?body=Deployed+to+staging%2C+ready+for+test"
        fi
  

Что происходит после закрытия бага?

Закрытый баг не удаляется. Он становится частью исторической базы знаний и используется для:

• Аналитика и отчётность: Рассчитываются метрики (MTTR — среднее время на исправление, количество открытых/закрытых багов за спринт, тренды).
• Постмортемы и анализ корневых причин: Для критических инцидентов проводятся встречи, чтобы предотвратить повторение.
• Ведение Backlog: Закрытые баги, помеченные Won't Fix или Not a Bug, могут позже быть пересмотрены при изменении требований.
• Архивация: По истечении длительного срока (годы) баги могут быть перенесены в холодное хранилище, но их ключ (например, PROJ-456) должен оставаться уникальным и никогда не повторяться.

Таким образом, жизнь бага — это строго регламентированный workflow, который превращает хаотичное сообщение об ошибке в управляемый рабочий элемент, интегрированный в процессы разработки, тестирования и непрерывной поставки ПО.