Зачем это спрашивают
Жизненный цикл бага — это то, как дефект движется по команде от момента находки до закрытия. Вопрос проверяет, понимаете ли вы процесс, в котором будете работать каждый день: кто за что отвечает на каждом этапе и что делает тестировщик, когда баг к нему возвращается.
Слабый ответ заканчивается словом «исправлен». Интервьюеру важно услышать, что после исправления есть перепроверка, что баг может вернуться и что не каждый баг заканчивается исправлением. Это отличает человека, который работал с трекером, от того, кто выучил схему по картинке.
Как построить сильный ответ
Основной путь
Назовите статусы по порядку и скажите, кто переводит баг в каждый из них:
| Статус | Что происходит | Кто действует |
|---|---|---|
| Новый (New) | баг заведён и ждёт разбора | тестировщик |
| Назначен / Открыт (Assigned, Open) | баг принят, определён исполнитель | тимлид или менеджер |
| В работе (In Progress) | разработчик исправляет | разработчик |
| Исправлен (Fixed, Resolved) | исправление сделано и выложено на тестовый стенд | разработчик |
| На перепроверке (Ready for Test, In Testing) | тестировщик проверяет исправление | тестировщик |
| Закрыт (Closed, Verified) | исправление подтверждено | тестировщик |
| Переоткрыт (Reopened) | исправление не помогло, баг вернулся в работу | тестировщик |
Подчеркните важную деталь: «исправлен» не значит «готов». Код может быть исправлен в ветке, но ещё не доехать до стенда, где вы тестируете. Перед перепроверкой убедитесь, что на стенде нужная сборка.
Альтернативные резолюции
Не каждый баг исправляют. На разборе его могут закрыть с другой резолюцией:
- Дубликат (Duplicate) — такой баг уже заведён; закрывают со ссылкой на оригинал.
- Не баг (Not a Bug, Works as Designed) — система работает по требованиям, ожидание было неверным.
- Не воспроизводится (Cannot Reproduce) — разработчик не смог повторить проблему. Что делать в этом случае, разобрано в отдельной статье про невоспроизводимые баги.
- Не будем исправлять (Won't Fix) — исправление дороже, чем вред от дефекта, или функция скоро уйдёт.
- Отложен (Deferred) — исправят в одном из следующих релизов.
Что делает тестировщик на перепроверке
Это часть, которая показывает практический опыт:
- Проверяет, что исправление на стенде.
- Повторяет шаги из баг-репорта — проблема ушла.
- Проверяет соседние сценарии: исправление не должно было сломать связанную функциональность.
- Если всё хорошо — закрывает. Если исходная проблема осталась — переоткрывает с комментарием, что именно проверено и на какой сборке.
Переоткрыть или завести новый
Правило простое: переоткрывают, если не исправлена та же самая проблема. Если исходная проблема ушла, но после исправления появилась другая, старый баг закрывают, а новый заводят со ссылкой на старый. Иначе в одной задаче смешиваются разные дефекты, и история становится нечитаемой.
Пример ответа
Тестировщик заводит баг в статусе «новый». Тимлид разбирает его и назначает исполнителя, разработчик берёт в работу, исправляет и переводит в «исправлен», когда исправление выложено на тестовый стенд. Дальше я делаю перепроверку: убеждаюсь, что на стенде нужная сборка, повторяю шаги и проверяю соседние сценарии. Если проблема ушла — закрываю, если нет — переоткрываю с комментарием. Если исходный баг исправлен, но появилась другая проблема, я закрываю старый и завожу новый со ссылкой. И не каждый баг доходит до исправления: его могут закрыть как дубликат, как не баг, как невоспроизводимый или решить не исправлять.
Частые ошибки
- Цикл заканчивается на «исправлен». Пропущены перепроверка и закрытие — самая важная часть для тестировщика.
- Нет альтернативных резолюций. Получается, что каждый баг обязательно чинят, а это не так.
- Переоткрывать баг из-за новой проблемы. Новая проблема — новый баг со ссылкой.
- Перепроверять на старой сборке. Тестировщик закрывает или переоткрывает баг, не убедившись, что исправление вообще доехало до стенда.
- Выдавать одну схему за единственно верную. Набор статусов настраивается в каждом трекере по-своему. Стоит сказать, что вы опишете типовой цикл, а в конкретной команде он может отличаться.
Пример на MarketCove
Представим гипотетическую ситуацию в учебном магазине https://shop.tomiddle.com. Сотрудник в админке переводит заказ из статуса PENDING в следующий, но покупатель в истории заказов профиля продолжает видеть PENDING.
- Вы заводите баг: шаги, ожидаемый и фактический результат, ответ
/api/shop/ordersиз вкладки Network в DevTools. Статус — «новый». - Тимлид назначает разработчика, тот исправляет отображение статуса и переводит баг в «исправлен», указав номер сборки.
- Вы проверяете, что сборка на стенде, повторяете сценарий — новый статус виден в профиле. Затем проверяете соседние сценарии: несколько смен статуса подряд, ответ
GET /api/orders/{id}, заказ из нескольких товаров. Это и есть перепроверка плюс точечный регресс. - Допустим, статус теперь обновляется, но в истории заказов в профиле стала отображаться неверная дата. Это другая проблема: исходный баг закрываете, новый заводите со ссылкой на первый.
Серьёзность каждого бага оценивается отдельно — как это делать, разобрано в статье про severity и priority.
Задание для практики
Нарисуйте на листе жизненный цикл бага так, как вы его понимаете: статусы, стрелки переходов и подписи, кто выполняет каждый переход. Добавьте ветки альтернативных резолюций. Затем пройдите по схеме три сценария: баг исправлен с первого раза; исправление не помогло; после исправления появилась новая проблема. Проговорите каждый вслух. Потренируйтесь оформлять баги в тренажёре баг-репортов.
