Могут ли быть автоматизированные UI тесты на верхнем уровне

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

Знаете ли вы пирамиду тестирования и понимаете ли, почему UI-тестов в ней мало, но они есть. Интервьюеру важно, чтобы вы не отвечали ни «всё автоматизируем через интерфейс», ни «UI-тесты не нужны». Следом обычно спрашивают, как вы боретесь с нестабильными тестами.

Как отвечать

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

Что стоит отдать UI-автотестам:

• критичные пользовательские пути: регистрация, вход, поиск, оформление заказа, оплата в тестовом режиме. Это смоук, который гоняется на каждый деплой;
• то, что нельзя проверить ниже: связку фронтенда и бэкенда целиком, редиректы, поведение в разных браузерах.

Проверки валидации и граничных значений лучше спускать на уровень API или компонентных тестов.

Инструменты стоит называть с пониманием различий. Playwright работает с Chromium, Firefox и WebKit, сам ждёт готовности элементов и пишет трассу для разбора падений. Cypress выполняет тесты внутри браузера и удобен фронтенд-команде. Selenium WebDriver остаётся стандартом для многих языков, в Java-стеке поверх него часто берут Selenide. Для мобильных приложений есть Appium.

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

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

Строят перевёрнутую пирамиду: сотни UI-тестов и почти нет тестов API. Прогон идёт часами, падает по случайным причинам, и команда перестаёт смотреть на результат.

Пишут sleep(5) вместо ожидания условия. На быстром стенде тест тратит время впустую, на медленном всё равно падает.

Готовят данные через интерфейс. Тест проверяет оплату, а падает на регистрации пользователя, и по отчёту уже не понять, что сломалось.