← Назад к вопросам

Что такое этапы жизненного цикла бага?

1.0 Junior🔥 211 комментариев
#Работа с дефектами

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI23 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Жизненный цикл бага в тестировании

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

Основные этапы жизненного цикла бага

1. New (Новый)

Баг только что был создан тестировщиком:

  • Запись об ошибке добавлена в систему отслеживания (Jira, YouTrack, Azure DevOps)
  • Статус автоматически устанавливается на New
  • Баг ждет проверки и распределения
  • Еще не назначен разработчику

2. Open (Открыт) / Assigned (Назначен)

Баг принят и распределен разработчику:

  • Тест-лид или PM проверяет корректность описания бага
  • Убедились, что это действительно баг, а не неправильное использование
  • Баг передан в работу конкретному разработчику
  • Иногда разделяют на Open (общее распределение) и Assigned (назначен конкретному человеку)

3. In Progress (В работе) / Under Investigation

Разработчик начал работать над исправлением:

  • Разработчик анализирует корень проблемы
  • Пишет код для исправления
  • Проводит локальное тестирование
  • Может попросить дополнительную информацию у тестировщика

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

Разработчик завершил работу и отправил исправление:

  • Код отправлен в основную ветку (merged)
  • Изменение готово к тестированию
  • Баг передается обратно тестировщику для проверки
  • Может быть развернуто на тестовое окружение

5. Verified (Проверен) / Closed (Закрыт)

Тестировщик подтвердил, что баг исправлен:

  • Воспроизвели сценарий, на котором был баг
  • Убедились, что ошибка больше не появляется
  • Проверили, что исправление не сломало другие функции
  • Баг закрывается со статусом Verified / Closed

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

Rejected (Отклонен)

Баг не прошел проверку и был отклонен:

  • Тест-лид/PM заключил, что это не баг
  • Или ошибка не воспроизводится
  • Или это документируемое поведение (по дизайну)
  • Баг закрывается без исправления

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

Ошибка появилась снова после исправления:

  • Тестировщик обнаружил, что баг все еще существует
  • Или исправление сломало другие части
  • Баг возвращается в статус Open или In Progress
  • Может назначаться другому разработчику

On Hold (На паузе) / Deferred (Отложен)

Баг отложен на будущее:

  • Низкий приоритет, решение отложено на следующий релиз
  • Требуется архитектурное изменение
  • Ждет выпуска зависимого компонента
  • Статус может быть изменен позже

Duplicate (Дубликат)

Баг является копией уже зарегистрированного дефекта:

  • Обнаружен дублирующий баг
  • Ссылается на основной баг
  • Закрывается как дубликат

Типичный процесс в Agile

New → Open → In Progress → Fixed → Verified → Closed

В случае отклонения или проблемы:

New → Open → Rejected (Closed)
Open → In Progress → Fixed → Reopened → In Progress → Fixed → Verified → Closed

Ключевые роли в жизненном цикле

  • QA/Тестировщик — обнаруживает, описывает, проверяет исправление
  • Developer — исправляет баг
  • Tech Lead / QA Lead — проверяет и утверждает баг
  • Product Manager — определяет приоритет и может отклонить баг

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

  1. Тестировщик находит баг: «При клике на кнопку удаления пользователя происходит ошибка 500»
  2. Статус: New → Создан отчет
  3. Статус: Open → QA Lead проверил, это реальный баг
  4. Статус: Assigned → Назначен разработчику Ивану
  5. Статус: In Progress → Иван анализирует код, находит проблему в обработчике ошибок
  6. Статус: Fixed → Иван отправил исправление в branch, merged в main
  7. Статус: Verified → Тестировщик проверил, баг исправлен
  8. Статус: Closed → Баг закрыт в рамках релиза v2.5

Заключение

Этапы жизненного цикла бага — это стандартный процесс управления качеством, который обеспечивает прозрачность, ответственность и полное решение проблем в разработке программного обеспечения. Понимание этого процесса критично для QA инженера.