Как решали проблему с багами
Что проверяют
Умеете ли вы работать с потоком дефектов системно: не только находить баги, но и понимать, откуда они берутся и как сделать, чтобы их стало меньше. Следом обычно спрашивают, какими метриками вы подтвердили улучшение и что сделали с багами, которые дошли до прода.
Как отвечать
Вопрос о личном опыте, поэтому нужен ваш случай с вашими цифрами. Каркас:
- проблема: что именно было не так. Много багов в релизе, рост багов с прода, частые переоткрытия, баги, которые разработчики не могут воспроизвести;
- анализ: разбор причин, а не перечисление найденного. Выгрузка из Jira или YouTrack за квартал, группировка по модулю, типу и этапу, где баг внесён и где найден. Дефекты обычно кучкуются в нескольких модулях, туда и идут основные усилия. Для поиска причины помогает метод «пять почему»;
- меры: зависят от причины. Не покрыты граничные случаи: техники тест-дизайна (классы эквивалентности, граничные значения, попарное тестирование). Возвращаются старые баги: регрессионный автотест на каждый исправленный дефект. Баги не воспроизводятся: шаблон баг-репорта с окружением, логами и шагами. Требования противоречат друг другу: участие QA в разборе задач до разработки;
- триаж: регулярный разбор новых дефектов с разработчиками и продактом, severity отдельно от priority;
- результат: метрики, которые вы реально считали. Утечка дефектов в прод, доля переоткрытых, время от репорта до исправления. Если цифр нет, опишите результат качественно, но честно.
Если опыта системной работы с качеством ещё нет, расскажите про один сложный баг: как локализовали, какими инструментами (DevTools, логи, Charles или Proxyman, запросы в базу), что добавили в тесты после исправления.
Где спотыкаются
Называют круглые проценты без источника: «багов стало на 30% меньше». Следующий вопрос будет «как считали», и без ответа цифра работает против вас.
Путают severity и priority. Опечатка в логотипе на главной имеет низкую severity и высокий priority, и это нужно уметь объяснить.
Сводят историю к «разработчики писали плохой код, а я их ловил». Интервьюер ищет инженера, который работает на качество вместе с командой, а не против неё.