Расскажите про последнюю доработку, которую тестировали
Что проверяют
Как вы подходите к незнакомой задаче: что читаете до начала, как выбираете проверки, как решаете объём регресса и что осознанно не проверяете. Рассказ должен быть про вашу работу, а не про то, какая полезная получилась функциональность.
Как отвечать
Одно предложение про саму доработку, дальше про тестирование:
- требования: что было непонятно, какие вопросы задали аналитику и разработчику до начала, чем закончились;
- риски: что ломается, если доработка задела смежное, отсюда и объём регресса;
- тест-дизайн: классы эквивалентности и границы, таблица решений для набора правил, негативные сценарии, проверки на уровне сервиса и в базе, а не только через интерфейс;
- что автоматизировали, что оставили ручным и по какой причине;
- результат: какие дефекты нашли, что починили до релиза, что отпустили сознательно и под каким риском;
- после выкладки: смотрели ли логи и метрики, приходили ли обращения в поддержку.
Хорошо звучит момент, когда вы нашли не ошибку кода, а дырку в требованиях: не описано поведение при пустом значении или при повторной отправке. Это показывает, что вы включались до готовой сборки.
Где спотыкаются
Пересказывают функциональность вместо своей работы. Интервьюер слушает две минуты про двухфакторную аутентификацию и так и не узнаёт, что и как проверял кандидат.
Говорят «протестировал всё». Полный перебор невозможен, и сильный ответ звучит наоборот: вот что проверили в первую очередь, вот что не трогали и почему этот риск был приемлем.
Не называют ни одного приёма тест-дизайна. Без границ, классов и таблицы решений набор проверок выглядит случайным, и следующий вопрос будет про то, как вы поняли, что проверок достаточно.