Жизненный цикл дефекта и критерии входа и выхода

Здесь проверяют не термины, а то, работали ли вы внутри процесса: кто передаёт баг дальше, когда тестирование считается законченным и кто это решает.

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

Вопрос 1: «Опишите жизненный цикл дефекта»

Что на самом деле проверяет интервьюер

Понимаете ли вы, кто делает переход между статусами. Назвать цепочку недостаточно — важно, что закрывает баг тестировщик, а не разработчик.

Развёрнутый ответ

Базовый маршрут: New → Assigned → In Progress → Fixed / Resolved → Verified → Closed.

Тупиковые ветки, о которых обязательно нужно упомянуть:

• Rejected — это не дефект (ошибка тестировщика или неверно понятое требование);
• Duplicate — уже заведён такой же дефект;
• Deferred / Postponed — дефект признан, но отложен на будущий релиз;
• Cannot reproduce — не воспроизводится, нужны дополнительные данные;
• Won't fix — чинить не будем осознанно (например, функция скоро удаляется).

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

Вопрос 2: «Что такое критерии входа и выхода? Когда тестирование можно закончить?»

Что на самом деле проверяет интервьюер

Понимаете ли вы, что «мы всё протестировали» — не критерий, а ощущение. Заодно проверяют, умеете ли вы отказаться принимать сборку в работу.

Развёрнутый ответ

Критерии входа (entry criteria) — условия, без которых нет смысла начинать: развёрнута сборка нужной версии, стенд стабилен, требования зафиксированы, тестовые данные и доступы готовы, smoke пройден. Если сборка не проходит smoke, тестировщик вправе вернуть её — это не конфликт, а экономия дня работы команды.

Критерии выхода (exit criteria) — условия, при которых тестирование считается завершённым:

• выполнены все запланированные тесты или согласованная их доля;
• нет открытых дефектов severity blocker и critical;
• количество открытых major не превышает согласованный порог;
• регрессия пройдена, автотесты зелёные;
• все оставшиеся дефекты явно приняты продуктом с решением «релизим как есть».

Важная поправка, которая отличает зрелого кандидата: тестирование не заканчивается «когда багов не осталось» — их не может не остаться. Оно заканчивается, когда достигнуты заранее согласованные критерии либо когда закончилось время и бизнес осознанно принял остаточный риск. Формулировка «мы даём картину рисков, решение о релизе принимает продукт» — то, что интервьюер хочет услышать.

Вопрос 3: «Как вы взаимодействуете с разработчиком?»

Развёрнутый ответ

Три практических принципа, которые стоит назвать: обсуждать дефект, а не человека; приносить данные (лог, request-id, видео) вместо оценок; при спорной трактовке требования звать аналитика, а не побеждать в переписке. Полезно упомянуть участие в груминге и ревью требований — там дефекты ловятся до написания кода и вообще не превращаются в баг-репорты.

Типичные ошибки кандидатов

• Говорят, что баг закрывает разработчик. Разработчик ставит Fixed, закрывает тестировщик после проверки.
• Не различают Rejected («это не баг») и Deferred («баг есть, чиним позже»).
• Считают критерием выхода «нет багов» — исчерпывающее тестирование невозможно.
• Не знают, что можно вернуть сборку по критериям входа, и героически тестируют заведомо сломанный билд.
• Описывают конфликт с разработчиком как борьбу, а не как совместный поиск фактов.

Как ответить кратко

Дефект проходит путь New → Assigned → In Progress → Fixed → Verified → Closed, а при повторном воспроизведении уходит в Reopened. Есть боковые ветки: Rejected — не дефект, Duplicate — уже заведён, Deferred — признан, но отложен, Cannot reproduce и Won't fix. Fixed ставит разработчик, а Verified и Closed — только тестировщик после re-testing. Критерии входа — условия начала работ: собранный билд нужной версии, стабильный стенд, готовые данные и пройденный smoke. Критерии выхода — согласованные условия завершения: выполнены запланированные тесты, нет открытых blocker и critical, регрессия зелёная, остаточные дефекты приняты продуктом. Тестирование заканчивается не тогда, когда багов нет, а когда достигнуты критерии и бизнес осознанно принял риск.