Почему выбрал не фронтенд для автотестирования

Что проверяют

Осознанность выбора уровня автоматизации. Интервьюер хочет услышать не вкусовщину, а понимание, какие дефекты ловит каждый уровень и во что обходится его поддержка. Заодно проверяют, знаете ли вы проверки интерфейса вообще: отказ от них по незнанию виден сразу.

Как отвечать

Скажите, что уровень выбирается под риск, а не по симпатии, и опишите пирамиду: внизу юнит-тесты разработчиков, посередине проверки API и интеграций, сверху узкий слой сквозных сценариев через браузер.

Аргументы за бэкенд:

• скорость: сотни проверок API проходят за минуты, тот же объём через браузер занимает часы и требует поднятого стенда;
• стабильность: у HTTP-ответа нет анимаций, ленивой подгрузки и переехавшей вёрстки, поэтому тест падает по делу, а не от таймингов;
• точность диагноза: упавший запрос сразу показывает код ответа и тело, упавший сценарий в браузере требует разбираться, где именно порвалось;
• раннее подключение: контракт API готов раньше экранов, проверки пишутся, пока интерфейса ещё нет.

Дальше обязательно оговорите, что фронт закрывать надо. Вёрстка, состояния формы, доступность и связка «клик, запрос, отрисовка» на уровне API не видны, поэтому сквозными сценариями покрываются критичные пути: вход, оплата, основной сценарий продукта. Такой ответ читается как расчёт, а не как отговорка.

Где спотыкаются

Сваливаются в «интерфейсные тесты не нужны». Это уже не выбор уровня, а отказ от целого класса дефектов, и следующим вопросом спросят, кто у вас проверяет, что кнопка вообще нажимается.

Не могут назвать, что ловится только через интерфейс. Фраза «на бэкенде быстрее» без второй половины звучит как оправдание удобства, а не как взвешенное решение.

Говорят, что тесты интерфейса нестабильны, не называя ни причин, ни лечения. Ожидание по состоянию элемента вместо пауз, локаторы через отдельные атрибуты для тестов, свои данные на каждый прогон, повтор только при инфраструктурном сбое: это и отличает того, кто пробовал, от того, кто сдался.