Как часто приходили баги из продакшена и насколько они были серьезными

Что проверяют

Насколько честно вы говорите о пропущенных дефектах и что делали после них. Интервьюеру важен не ноль багов, а разбор причин и изменения в процессе. Следом обычно просят рассказать о самом серьёзном случае и объяснить, почему тесты его не поймали.

Как отвечать

Постройте ответ из трёх частей: масштаб, классификация, выводы.

• масштаб: порядок цифр за период, например сколько обращений из продакшена приходило за релиз или за месяц и сколько из них оказывалось настоящими дефектами, а не вопросами пользователей;
• серьёзность: как вы делили баги по severity (blocker, critical, major, minor, trivial) и чем она отличается от priority. Опечатка в названии компании на главной странице имеет низкую серьёзность и высокий приоритет;
• метрика утечки: доля дефектов, найденных после релиза, от всех найденных за релиз (defect leakage). Она показывает, растёт качество или нет;
• разбор причин: почему баг ушёл в прод. Не было тест-кейса, окружение отличалось от прода, в тестовой базе были нереалистичные данные, изменение не попало в регресс;
• изменения: автотест на найденный сценарий, правка чек-листа регресса, фиче-флаг, мониторинг ошибок в Sentry, смоук после деплоя.

Возьмите один конкретный случай: что сломалось, скольких пользователей задело, как быстро обнаружили и откатили, что поменяли, чтобы не повторилось. Цифры приводите свои и только те, в которых уверены: «около пяти обращений в месяц, из них один или два дефекта» звучит честнее выдуманных 30 процентов. Если коммерческого опыта нет, расскажите о дефекте, пропущенном в учебном проекте, или о том, как вы выстроили бы разбор.

Где спотыкаются

Говорят «у нас багов в проде не было». В это никто не верит, и звучит так, будто вы не следили за продом или не хотите признавать ошибки.

Перекладывают вину на разработчиков. Качество это ответственность всей команды, и интервьюер ждёт, что вы сами поменяли в тестировании.

Путают severity и priority или не могут объяснить, по какому правилу баг получил статус «критический». Для QA это базовая терминология.