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