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