Подробное объяснение, что происходит с багом от момента его нахождения до полного закрытия.

🧩 1. Что такое баг?

Баг — это отклонение фактического результата от требований

Простыми словами:
💬 «Я нажимаю на кнопку — должно происходить А, но происходит Б».

🤓 Причина появления:
Разработчик допустил ошибку в коде или логике → тестировщик нашёл проблему во время тестирования → завёл баг-репорт.

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

🔄 2. Что такое жизненный цикл бага

Жизненный цикл бага (Bug Life Cycle) — это все стадии, через которые проходит баг с момента обнаружения тестировщиком до момента, когда он окончательно исправлен и закрыт.

Этот цикл помогает команде:

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

🧬 3. Общая схема для жизненного цикла бага

Ниже — полный перечень статусов, через которые может пройти дефект.
Мы разберём каждый подробно и простым языком.

🟦 4. Основные состояния бага

1️⃣ New — Новый

🔍 Баг только что найден тестировщиком.
Он оформляет баг-репорт и отправляет в систему (например, заводит новую карточку с баг-репортом на канбан-доску).
Никто ещё не проверял, не анализировал, не подтверждал.

2️⃣ Assigned — Назначен

👨‍💻 Менеджер или тестировщик назначает баг конкретному разработчику.
Теперь у бага есть «владелец» — человек, который должен разобраться.

3️⃣ Open — Открыт

Разработчик перетаскивает карточку с багом в колонку "В работе" и начинает разбор:

• воспроизводит баг
• изучает причину
• анализирует код
• принимает решение, что с ним делать

🧠 На этом этапе разработчик может сказать:

• баг реальный → надо чинить
• баг не воспроизводится
• это не баг, а фича (так и должно работать)
• это дубликат (такой баг-репорт уже есть в системе)
• это низкий приоритет → можно отложить

Поэтому отсюда статус часто меняется на другие варианты (см. ниже).

4️⃣ Fixed — Исправлен

🛠 Разработчик внёс изменения в код и считает, что проблема устранена.
Он перетаскивает карточку с багом в колонку «Тестирование», чтобы тестировщик перепроверил исправление

5️⃣ Retest — Повторное тестирование

Тестировщик вручную проверяет:

• действительно ли баг исправлен
• нет ли побочных эффектов
• полностью ли соответствует требованиям

6️⃣ Reopen — Открыт заново

Если баг всё ещё воспроизводится, или исправлен частично, или появилась новая ошибка — тестировщик переоткрывает его.

♻️ Баг уходит обратно разработчику. Либо в колонку "В работе", либо в отдельную колонку "На исправлении", как показано на скрине:

7️⃣ Verified — Проверен

Если после ретеста баг полностью исправлен → тестировщик помечает «Verified».
Это означает, что дефект исправлен корректно, и можно закрывать.

Если на канбане есть колонка "Готово к релизу", то карточка перемещается туда.

8️⃣ Closed — Закрыт

Финальное состояние.
Версия нашего кода с исправленным багом развёртывается на прод и доступна для всех пользователей нашего сервиса.
Баг больше не существует → задача завершена и перемещается в "Готово".

🟨 5. Дополнительные состояния багов

Эти статусы часто дают разработчики, написав соответствующий комментарий внутри карточки:

❌ Rejected — Отклонён

Баг признан некорректным. Причины:

• тестировщик неправильно понял функционал
• это не баг, а фича
• ошибка тестовой среды (лагает серверное железо, не ошибка в коде)

В таком случае карточка перемещается в "Готово"

🔁 Duplicate — Дубликат

Такой баг уже есть в системе. Карточка удаляется.

⏳ Deferred — Отложен

Баг реальный, но:

• у него низкий приоритет
• он не критичен
• его исправят в следующем релизе

Карточка возвращается в Бэклог

ℹ️ Not a Bug — Не баг

Разработчик считает, что текущая реализация программы не противоречит требованиям (он не всегда прав!).
Но если прав, то карточка перемещается в "Готово".

📝 Важный нюанс:

Не нужно запоминать наизусть все состояния багов. Эти состояния не нужно будет нигде указывать в работе с баг-репортами.
Цикл был описан для понимания процессов внутри команды, чтобы иметь представления, как ездят по канбану карточки с баг-репортами.

🎯 Почему разработчик может отказаться исправлять баг?

Очень частый вопрос.

Причины:

1. ❌ Баг не воспроизводится
2. ❌Это не баг, а ожидаемое поведение (фича)
3. ❌ Баг — дубликат
4. ❌ Непонятно оформлен баг-репорт
5. ❌ Низкий приоритет, дорого исправлять → отложен
6. ❌ Баг относится к старой функциональности, которая и так будет удалена в следующем релизе
7. ❌ Исправление создаст больше рисков, чем сам баг
8. ❌ Баг относится к внешнему сервису, который команда не контролирует

Достаточно запомнить первые 5.