Какие автотесты использовались: UI или backend
Что проверяют
Понимаете ли вы, зачем нужен каждый уровень тестов, и умеете ли распределять усилия. Ответ «и те, и другие» не говорит ничего, важны пропорции, инструменты и то, что вы писали руками. Дальше спрашивают про долю UI-тестов, про время прогона в CI и, почти обязательно, про нестабильные тесты.
Как отвечать
Дайте расклад по уровням, с цифрами своего проекта:
- API-тесты: основа автоматизации. REST Assured в Java,
pytestсrequestsв Python,APIRequestContextу Playwright. Быстрые и стабильные, проверяют коды, схему ответа, права доступа, граничные значения; - UI-тесты: обычно 10-20% от общего числа, только сквозные сценарии, на которых держится продукт: регистрация, оформление заказа, оплата. Playwright с автоожиданиями и трейсами сегодня основной инструмент, Selenium и Selenide держат легаси, Cypress встречается во фронтовых командах;
- интеграционные: сервис с поднятой в Testcontainers базой и заглушками соседей на WireMock;
- контрактные: Pact или проверка ответов по схеме OpenAPI, чтобы рассинхрон между командами всплывал в пайплайне, а не в браузере.
Скажите про подготовку данных: состояние для UI-теста создаётся через API или напрямую в базе, а не кликами по интерфейсу. Это убирает половину нестабильности и минуты времени прогона.
По CI полезны конкретные цифры: смоук на пул-реквесте за 5-10 минут, полный прогон ночью, отчёты в Allure, нестабильный тест уходит в карантин с заведённой задачей, а не перезапускается молча.
Где спотыкаются
Проверяют бизнес-логику через интерфейс. Расчёт скидки правильнее прогнать по API десятком кейсов, чем одним кликом в браузере, который сломается от переименования кнопки.
Лечат нестабильность паузами. Thread.sleep и sleep(3) растягивают прогон и всё равно падают на нагруженном стенде, нужны явные ожидания конкретного состояния.
Не разбирают красные прогоны. Пайплайн, который перезапускают до зелёного, перестаёт быть источником информации, и настоящий баг в нём никто не заметит.