Опишите жизненный цикл дефекта. Что происходит с багом от обнаружения до закрытия?
Короткий ответ
- New — дефект заведён и ждёт разбора
- Триаж: подтверждение, приоритет, назначение исполнителя
- In progress — разработчик чинит, Fixed — готов к проверке
- Верификация тестировщиком на новой сборке
- Closed при успехе, Reopened при повторении
- Отклонения: Rejected, Duplicate, Deferred, Cannot reproduce
Дефект проходит путь от заведения через триаж, исправление и верификацию до закрытия, с ветками отклонения и переоткрытия.
Как сказать вслух
пример ответаЯ завожу баг — он в статусе «новый». Дальше триаж: лид или команда подтверждает дефект, выставляет приоритет и назначает разработчика. Разработчик берёт в работу и переводит в «исправлено». Я проверяю фикс на новой сборке: если всё хорошо — закрываю, если воспроизводится — переоткрываю с комментарием. Есть и боковые ветки: баг могут отклонить как «не баг», пометить дубликатом или отложить на следующий релиз.
Подробный ответ
Основной ответ
Жизненный цикл дефекта — это последовательность статусов в трекере (Jira, YouTrack и аналоги). Базовый поток: New (заведён) → Open/Triaged (подтверждён на триаже, выставлены severity, priority, исполнитель) → In Progress (в работе у разработчика) → Fixed/Resolved (исправление готово и попало в сборку) → Verification (тестировщик проверяет фикс на том окружении, куда приехала сборка) → Closed (подтверждено) либо Reopened (дефект воспроизводится — возврат разработчику). Альтернативные исходы триажа: Rejected / Not a bug (поведение соответствует требованиям), Duplicate (уже заведён), Deferred / Postponed (починка отложена осознанным решением), Cannot reproduce (не удалось повторить — нужны уточнения от автора). Конкретный набор статусов отличается по командам, но логика везде одна.
Ключевые моменты
- Триаж. Регулярная встреча или процесс, где дефекты подтверждают, приоритизируют и назначают; защищает от потери багов в бэклоге.
- Верификация на правильной сборке. Фикс проверяется на сборке, содержащей изменение, и в идеале теми же шагами плюс лёгкий регресс вокруг.
- Reopen вместо нового бага. Если дефект повторился, его переоткрывают — так сохраняется история и статистика возвратов.
- Deferred — осознанное решение. Отложить баг может владелец продукта с пониманием риска, а не тестировщик молча.
Практический контекст
Стандартный вопрос скрининга: проверяют, работал ли кандидат с реальным трекером или знает процесс только по статьям. Полезно описать цикл на примере своего проекта: как назывались статусы, кто проводил триаж, что делали со спорными багами. Дополнительный вопрос почти всегда — «что сделаете, если разработчик закрыл баг как не воспроизводится», поэтому стоит заранее продумать ответ.
Частые ошибки
- Рассказывают только счастливый путь, забывая Rejected, Duplicate и Deferred
- Говорят, что закрывает баг разработчик, хотя верифицирует и закрывает обычно QA
- Не могут объяснить, чем Reopened отличается от заведения нового дефекта