Какие автотесты в основном закрывали: фронтенд или бэкенд

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

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

Как отвечать

Вопрос про ваш опыт, поэтому ответ строится на своих проектах и своих цифрах. Каркас:

• пропорция: честно назовите соотношение, например «больше API, UI примерно треть», и объясните, почему так сложилось на проекте;
• бэкенд: на чём писали (Java с REST Assured и JUnit 5, Python с pytest и requests или httpx, TypeScript), что проверяли: контракты, коды ответов, валидацию, права доступа, состояние в базе после запроса. Как готовили данные: фикстуры, вызовы API, запросы в БД, Testcontainers;
• фронтенд: Playwright, Selenium или Cypress, Page Object, стабильные локаторы через data-testid, как боролись с нестабильными тестами;
• связь с CI: какой набор бежит на каждый merge request, какой ночью, сколько длится прогон.

Покажите логику пирамиды: API-тесты быстрее и стабильнее, поэтому основную массу проверок разумно держать там, а через UI гонять ключевые пользовательские сценарии. Цифры приводите реальные: сколько тестов, время прогона, сколько дефектов поймали до релиза. Круглые проценты вроде «регрессий стало на 30% меньше» легко вскрываются вопросом «а как мерили».

Если одна из сторон у вас пустая, так и скажите: «UI автоматизировал мало, основной опыт в API, Playwright разбирал на своём проекте». Затем покажите, как подошли бы к задаче: с каких сценариев начать и где держать тестовые данные.

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

Отвечают «и то и другое поровну» без деталей. Это звучит как уход от ответа, и дальше интервьюер копает до первой пустоты.

Называют Postman фреймворком автотестов. Коллекции с проверками полезны, но не заменяют кодовый фреймворк с отчётами, параметризацией и запуском в CI.

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