Баг (от англ. bug) — это ошибка, дефект или сбой в программном обеспечении, который приводит к неправильной, непредсказуемой или нестабильной работе приложения или системы. Баг возникает, когда программа работает не так, как ожидается или как это было указано в техническом задании или пользовательских требованиях.

Баги могут появляться на любом этапе разработки: от проектирования и написания кода до финального релиза и использования пользователями. Они могут быть неочевидными (например, редкие ошибки в специфических условиях) или критическими (приводящими к сбоям или утечкам данных).

🔁 Жизненный цикл бага (Bug Life Cycle)

Жизненный цикл бага описывает этапы, через которые проходит ошибка — от её обнаружения до полного устранения и подтверждения. Он помогает структурировать процесс устранения дефектов, распределять ответственность и фиксировать прогресс.

1. Обнаружение (Discovery / Detection)

Ошибка фиксируется тестировщиком, разработчиком или пользователем. На этом этапе составляется баг-репорт (bug report), который должен содержать:

• Название и описание бага.

• Шаги для воспроизведения.

• Ожидаемое и фактическое поведение.

• Скриншоты или видео (если возможно).

• Окружение (версия ПО, браузер, ОС).

• Приоритет и серьёзность (severity).

2. Новый (New / Open)

Баг поступает в систему трекинга (например, Jira, Bugzilla, Redmine) и получает статус «Новый». На этом этапе он ожидает рассмотрения.

3. Подтверждение (Confirmed / Triage)

Команда (обычно тимлид, QA-лид или продукт-менеджер) рассматривает баг и решает:

• Реален ли баг?

• Нужно ли его чинить?

• Каков его приоритет (P1–P5) и серьёзность (Critical, Major, Minor)?

• В какую итерацию или спринт его поместить?

Если баг не воспроизводится, он может быть отклонён с пометкой Cannot Reproduce или Invalid.

4. Назначен (Assigned)

Баг назначается разработчику, ответственному за устранение. Назначение может происходить вручную или автоматически, в зависимости от правил в команде.

5. В процессе (In Progress / Work in Progress)

Разработчик начинает работу над багом. Он анализирует проблему, воссоздаёт её у себя локально, проверяет код, находит причину и вносит исправления.

6. Исправлен (Fixed)

Разработчик устраняет баг и коммитит правку в репозиторий. В системе багов баг переходит в статус Fixed или Ready for Testing, сопровождаясь ссылкой на коммит, pull request или номер задачи.

7. На проверке (Testing / Ready for QA)

QA-инженер или другой тестировщик проверяет исправление. Это может быть:

• Ручная проверка.

• Запуск автоматических тестов (если есть).

• Регрессионное тестирование — проверка, что не сломались другие части системы.

8. Закрыт (Closed)

Если баг больше не воспроизводится, он получает статус Closed. Иногда он может быть переведён в Verified перед закрытием.

9. Переоткрыт (Reopened)

Если после проверки или в будущем баг снова проявляется, он может быть переоткрыт. Его жизненный цикл начинается заново.

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

В зависимости от процессов и системы управления задачами, могут быть дополнительные статусы:

• Duplicate — дубликат уже заведённого бага.

• Postponed / Deferred — отложен на потом, не критичен.

• Won’t Fix — не будет исправляться (например, слишком дорого, редкий кейс).

• Invalid — ошибка не подтверждена или вызвана неправильным использованием.

🏷️ Классификация багов

По серьёзности (Severity):

• Blocker — блокирует работу приложения.

• Critical — серьёзная ошибка, может привести к потере данных.

• Major — нарушает ключевой функционал.

• Minor — ошибка UI, не критична для работы.

• Trivial — орфография, незначительные недочёты.

По приоритету (Priority):

• P1 — исправить немедленно.

• P2 — высокоприоритетный, в следующем спринте.

• P3–P5 — низкий приоритет, в будущем.

🛠 Инструменты баг-трекинга

• Jira — одна из самых популярных систем.

• Bugzilla — классика open source.

• Redmine, YouTrack, Asana, Trello — часто используются в разных масштабах проектов.

• GitHub Issues, GitLab Issues — встроены в экосистему разработки.

Жизненный цикл бага — это не просто цепочка состояний, а важная часть процесса обеспечения качества программного обеспечения. Он помогает наладить прозрачную коммуникацию между тестировщиками, разработчиками и менеджерами, обеспечивая эффективное и своевременное исправление проблем.