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