Какой опыт работы с Selenium

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

Работали ли вы с Selenium руками или только слышали о нём, и умеете ли писать тесты, которые не падают через раз. Следом почти всегда спрашивают про ожидания и про то, как вы боролись с нестабильными тестами.

Как отвечать

Начните с контекста: что за приложение, сколько сценариев покрыли, кто запускал тесты и где. Дальше пройдитесь по технике:

• Selenium 4 и WebDriver: поиск через driver.find_element(By.CSS_SELECTOR, ...), старые методы find_element_by_* из актуальных версий удалены. Драйверы браузеров подтягивает встроенный Selenium Manager, ручная возня с chromedriver больше не нужна;
• явные ожидания: WebDriverWait(driver, 10).until(EC.element_to_be_clickable(...)) вместо time.sleep. Неявные ожидания лучше не смешивать с явными, иначе таймауты складываются непредсказуемо;
• Page Object: локаторы и действия страницы живут в классе, тест читается как сценарий. Поменялась вёрстка, правите одно место;
• pytest: фикстура с yield поднимает и закрывает драйвер, conftest.py держит общие настройки, pytest-xdist гоняет тесты параллельно;
• инфраструктура: headless-режим в CI, Selenium Grid или контейнеры с браузерами для параллельного запуска, скриншот и лог браузера при падении.

Хорошо, если скажете, почему часть команд уходит на Playwright: автоожидание из коробки и более быстрый прогон. Это показывает, что вы видите инструмент в контексте, а не только знаете его API.

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

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

Ставят time.sleep(5) «для надёжности». Тест становится медленным и всё равно падает, когда стенд тормозит сильнее обычного.

Опираются на хрупкие локаторы вроде абсолютного XPath от корня документа. Лучше договориться с разработчиками о data-testid и искать по нему.

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