Вопросы на собеседовании Selenium

Вы писали тесты, которые проходят локально и падают в pipeline, и подозреваете, что дело в wait, но не можете сформулировать это чётко. Интервьюеры это знают, поэтому wait открывает большинство собеседований по Selenium. В этом разделе разбирается, как звучит полный ответ.

• Implicit wait против explicit wait. Implicit wait представляет собой глобальную настройку, которая при каждом поиске элемента проверяет его наличие. Explicit wait нацелен на один элемент и одно условие, например кликабельность или видимость. Explicit предпочтительнее, потому что явно показывает, чего именно вы ждёте.
• Почему их не стоит смешивать? Совмещение обоих может суммировать таймауты непредсказуемым образом, поэтому большинство команд выставляют implicit wait в ноль и везде используют только explicit wait.
• Что такое fluent wait? Explicit wait с настраиваемым интервалом опроса и игнорируемыми типами исключений.
• Почему использовать Thread.sleep неправильно? Потому что он безусловный. Он замедляет тест, который и так прошёл бы, и всё равно не спасает медленный тест.
• CSS-селектор или XPath? Отдавайте предпочтение стабильному атрибуту-идентификатору, предназначенному для тестов, затем CSS ради читаемости. XPath оправдан, когда нужно подняться к родителю или искать совпадение по тексту.
• Что делает locator хрупким? Автоматически сгенерированные имена классов, абсолютный XPath и выбор по индексу. Скажите, что вы бы попросили разработчика добавить вместо этого.

Интервьюеры слушают именно причину за каждым выбором. Назвать предпочтение без указания цены звучит как заученный ответ.

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

• Что вызывает StaleElementReferenceException? Ссылка на элемент указывает на узел, который больше не прикреплён к странице, обычно потому что framework заново отрендерил эту часть страницы. Ищите элемент заново, а не переиспользуйте сохранённую ссылку.
• А что насчёт ElementNotInteractableException? Элемент существует, но с ним нельзя взаимодействовать: он скрыт, отключён, перекрыт оверлеем или находится за пределами экрана.
• Как обрабатывать NoSuchElementException? Отличайте проблему с таймингом от действительно отсутствующего элемента и не маскируйте это более долгим ожиданием.
• Почему тесты падают только в pipeline? Другой размер viewport, более медленное окружение, отсутствующие тестовые данные, анимации, завершающиеся позже, и параллельные тесты, конкурирующие за общее состояние.
• Как исправить нестабильный тест? Сначала определите категорию проблемы, затем устраните причину. Автоматический повтор маскирует сбои, и его стоит называть именно крайней мерой.
• Как обрабатывать frame, новые окна и alert? Явно переключая контекст, а затем возвращаясь обратно.

QA-инженера, проходившего собеседование на позицию automation среднего уровня, спросили, почему один набор тестов падал дважды в неделю без каких-либо изменений в коде. Ответ, который сработал, оказался не деталью API Selenium, а тем, что тесты использовали общий заранее подготовленный аккаунт и конкурировали друг с другом. Интервьюеры ценят именно такой порядок диагностики: сначала окружение и данные, затем API.

Больше подборок вопросов по ролям и инструментам смотрите в разделе вопросы на собеседовании по ролям.

Помимо API, интервьюерам важно понять, можете ли вы взять на себя ответственность за весь набор тестов. Эти вопросы весят больше всего для senior-позиций.

• Объясните Page Object Model. Классы Page раскрывают действия и скрывают locator, поэтому изменение UI затрагивает только один файл. Скажите, какую проблему это решает; описание одной только структуры папок упускает суть.
• Что может пойти не так с Page Object? Они разрастаются в классы на тысячи строк и начинают делать проверки прямо внутри методов page. Проверки должны находиться в тестах.
• Как ваш framework запускает тесты параллельно? Потокобезопасное управление драйверами, чтобы экземпляры не разделялись между потоками, плюс независимые тестовые данные для каждого теста.
• Для чего нужен Selenium Grid? Для распределения тестов между несколькими машинами и версиями браузера, с hub и node, либо облачный провайдер выполняет ту же роль.
• Что изменилось в Selenium 4? Протокол W3C WebDriver стал стандартом, а старый JSON wire protocol был удалён, появились относительные locator, и был открыт доступ к Chrome DevTools Protocol.
• Когда не стоит использовать Selenium? Проверки на уровне API, логика, тестируемая юнит-тестами, и всё, что находится вне браузера. Знание этой границы само по себе сигнал senior-уровня.
• Как вы решаете, что автоматизировать? Стабильные, ценные и часто повторяющиеся сценарии. Не всё подряд, и не экран, который всё ещё находится в разработке.

Ответы про Selenium необычно легко знать и тяжело произнести вслух. В частности, вопрос про wait требует ответа из двух частей, определения и причины, и кандидаты, которые только читали об этом, выдают первую половину и теряются.

Выберите пять вопросов отсюда, с которыми вам меньше всего хотелось бы столкнуться, и ответьте на каждый вслух за девяносто секунд без открытого редактора. Затем попросите кого-нибудь задать следующий вопрос, почти всегда это «почему». Тренировка тех же вопросов против ИИ-интервьюера, который переспрашивает, ближе к настоящему собеседованию, чем перечитывание списка, и именно для этого существует режим пробного собеседования.

Aaron Cao, основатель SubcueAI, построил тренировку вокруг именно этого разрыва между знанием и умением сказать вслух, а не вокруг предоставления ещё большего числа вопросов. На реальном собеседовании десктопное приложение и боковая панель браузерного расширения могут показывать структуру, пока говорит интервьюер, что помогает больше всего с материалом, который вы уже отрепетировали. Что именно делает продукт и какие границы он никогда не пересекает, описано на странице безопасность.