Питання на співбесіді Selenium

Ви писали тести, що проходять локально, але падають у pipeline, і підозрюєте, що причина у wait, хоч і не можете чітко це сформулювати. Інтерв'юери це знають, тому wait відкриває більшість раундів Selenium. Цей розділ показує, як звучить повна відповідь.

• Implicit проти explicit wait. Implicit wait, це глобальна настройка, яка опитує наявність елемента при кожному пошуку. Explicit wait націлений на один елемент і одну умову, наприклад clickable чи visible. Explicit кращий, бо чітко вказує, чого саме очікують.
• Чому їх не варто змішувати? Поєднання обох може непередбачувано підсумовувати таймаути, тому більшість команд ставлять implicit wait на нуль і всюди використовують explicit wait.
• Що таке fluent wait? Explicit wait із налаштовуваним інтервалом опитування та ігнорованими типами exception.
• Чим помилковий Thread.sleep? Він безумовний. Уповільнює тест, що пройшов би, і все одно не рятує повільний тест від провалу.
• CSS selector чи XPath? Надавайте перевагу стабільному атрибуту-ідентифікатору тесту, потім CSS для читабельності. XPath має сенс, коли потрібно піднятися до parent або зіставити за текстом.
• Що робить локатор крихким? Автоматично згенеровані назви класів, абсолютний XPath і вибір за індексом. Скажіть, що б ви попросили розробника додати натомість.

Інтерв'юери слухають причину за кожним вибором. Назвати перевагу без її ціни звучить як завчена відповідь.

Flaky тести це справжня тема більшості senior співбесід з автоматизації, бо suite, якому ніхто не довіряє, гірший за відсутність suite взагалі.

• Що спричиняє StaleElementReferenceException? Посилання на елемент вказує на вузол, який більше не приєднаний, зазвичай тому, що фреймворк перерендерив цю частину сторінки. Знайдіть елемент заново, а не використовуйте збережене посилання.
• А як щодо ElementNotInteractableException? Елемент існує, але з ним не можна взаємодіяти: він прихований, disabled, перекритий overlay, або поза екраном.
• Як обробляти NoSuchElementException? Відрізняйте проблему з таймінгом від елемента, якого справді немає, і не маскуйте це довшим sleep.
• Чому тести падають лише в pipeline? Інший розмір viewport, повільніше середовище, відсутні тестові дані, анімації, що завершуються пізніше, і паралельні тести, що конфліктують на спільному стані.
• Як виправити flaky тест? Спершу діагностуйте категорію, потім усувайте причину. Auto-retry приховує збої і є останнім засобом, який варто так і називати.
• Як працювати з frame, новими вікнами та alert? Явно перемикати контекст, а потім повертатися назад.

QA-інженера, який проходив співбесіду на посаду mid-level з автоматизації, запитали, чому один suite падав двічі на тиждень без змін у коді. Правильною відповіддю була не деталь API Selenium, а те, що тести ділили один seeded акаунт і заважали одне одному. Інтерв'юери цінують саме такий порядок діагностики: спершу середовище й дані, потім API.

Більше банків питань за роллю та інструментом наведені під interview questions by role.

Окрім API, панель хоче знати, чи здатні ви вести suite. Ці питання мають найбільшу вагу для senior ролей.

• Поясніть Page Object Model. Класи page відкривають дії й ховають локатори, тож зміна UI зачіпає лише один файл. Скажіть, яку проблему це вирішує; опис самої структури папок не влучає в суть.
• Що може піти не так із Page Object? Вони розростаються в класи на тисячі рядків і починають робити assert усередині page-методів. Assertion мають бути в тестах.
• Як ваш фреймворк запускає тести паралельно? Thread-safe керування driver, щоб інстанси не ділилися між потоками, плюс незалежні тестові дані для кожного тесту.
• Для чого потрібен Selenium Grid? Розподіляти тести між машинами й версіями браузерів, із hub і node, або з хмарним провайдером, що виконує ту саму роль.
• Що змінилося в Selenium 4? Протокол W3C WebDriver став стандартом, старий JSON wire protocol прибрали, з'явилися relative локатори, і відкрився доступ до Chrome DevTools Protocol.
• Коли ви не використовували б Selenium? Для перевірок на рівні API, логіки, яку можна покрити unit-тестами, і всього поза браузером. Знання цієї межі є сигналом senior-рівня.
• Як ви вирішуєте, що автоматизувати? Стабільні, цінні, повторювані шляхи. Не все підряд, і не екран, що досі перебуває в редизайні.

Відповіді про Selenium незвично легко знати й важко вимовити. Питання про wait зокрема має відповідь із двох частин, визначення й причину, і кандидати, які лише прочитали це, видають першу половину і губляться.

Візьміть п'ять питань звідси, з якими найменше хочете зіткнутися, і відповідайте на кожне вголос за дев'яносто секунд без відкритого редактора. Потім попросіть когось поставити уточнювальне питання, яким майже завжди буде чому. Прогнати ті самі підказки на AI-інтерв'юері, що дожимає, ближче до реального раунду, ніж перечитувати список, і саме для цього існує режим mock interview.

Aaron Cao, засновник SubcueAI, побудував цю практику навколо цього розриву в мовленні, а не навколо постачання ще більшої кількості питань. Під час живої співбесіди десктопний застосунок і Side Panel розширення браузера можуть показувати структуру, поки говорить інтерв'юер, що найбільше допомагає з матеріалом, який ви вже відпрацювали. Що робить продукт і межі, які він не перетинає, описано на сторінці security.