Какие инструменты и фреймворки использовал для UI тестирования

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

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

Как отвечать

Назовите то, с чем работали, и коротко объясните, где что уместно:

• Selenium WebDriver: реализация стандарта W3C WebDriver, привязки для Java, Python, C#, JavaScript. Часто в паре с Selenide и Selenium Grid для параллельных запусков;
• Playwright: Chromium, Firefox и WebKit, автоожидание элементов, изоляция через browser context, trace viewer для разбора падений, codegen для черновиков тестов;
• Cypress: тесты выполняются внутри браузера, удобная отладка по снимкам шагов. Поддерживает браузеры семейства Chrome, Firefox и Edge, WebKit экспериментально. Не работает с несколькими вкладками, переход на другой домен требует cy.origin;
• WebdriverIO и TestCafe: встречаются реже, но тоже живые;
• Appium: если интерфейс мобильный.

Дальше расскажите про обвязку, она часто важнее выбора инструмента: Page Object или его аналог, локаторы по data-testid и ролям вместо длинных XPath, отчёты в Allure, запуск в CI на каждый merge request, скриншоты и видео при падении. Приведите свой пример: сколько тестов в наборе, сколько идёт прогон, какие баги поймали. Если автоматизации было мало, честно скажите, какой инструмент изучали сами и что на нём написали.

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

Называют Jest инструментом UI-тестирования. Это раннер юнит-тестов, компоненты им проверяют вместе с Testing Library, но браузерный e2e он не заменяет.

Лечат нестабильность через Thread.sleep или cy.wait(5000). Правильный путь это ожидание нужного состояния элемента, а у Playwright и Cypress такое ожидание встроено.

Повторяют устаревшие мифы: что Cypress работает только в Chrome или что для Selenium обязателен JavaScript. Интервьюер такое замечает сразу.