Какой стек технологий использовался для автотестов

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

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

Как отвечать

Описывайте стек как цепочку, а не как список модных слов:

• язык и раннер: Java с JUnit 5 или TestNG, Python с pytest, TypeScript с Playwright Test. Хорошо, если язык совпадает с языком разработки: тогда разработчики читают и правят тесты;
• UI: Selenium WebDriver или обёртка Selenide со встроенными ожиданиями, Playwright, Cypress. Паттерн Page Object или компонентные объекты;
• API: REST Assured, в Python requests или httpx, ответы проверяются по JSON Schema или моделям Pydantic;
• мобильные: Appium, нативные Espresso и XCUITest;
• данные и окружение: подготовка данных через API вместо UI, изолированные зависимости в Docker или Testcontainers, браузеры в Selenium Grid;
• CI и отчёты: Jenkins, GitLab CI или GitHub Actions, параллельный запуск, Allure с шагами, скриншотами и логами.

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

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

Называют инструменты, которые трогали один раз. Первый же вопрос вроде «как в Selenide поменять таймаут ожидания» это выдаст.

Лечат нестабильные тесты автоматическими перезапусками и Thread.sleep. Перезапуск прячет проблему, а интервьюер ждёт разбора причин: гонки, общие данные, нестабильное окружение.

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