11 вопросов по теме «QA: Selenium и Playwright» на собеседовании

Короткий ответ: Selenium поддерживает восемь стратегий: id, name, className, tagName, linkText, partialLinkText, cssSelector и xpath. CSS быстрее и читаемее, но XPath умеет то, чего CSS не может: подниматься вверх и назад по DOM (ancestor, parent, preceding-sibling) и искать элемент по тексту. В этом вся асимметрия.

Подробно:

1. CSS-селектор — стандарт по умолчанию: короткий синтаксис, работает быстрее (браузер оптимизирует CSS-движок), покрывает 90% случаев.
2. XPath навигация вверх — только XPath дойдёт от найденного элемента к родителю/предку: //span[text()='Итого']/ancestor::tr.
3. XPath по тексту — //button[text()='Оплатить'] или contains(text(),'...'); в CSS поиска по текстовому содержимому нет вообще.

⚠️ Частая ошибка: не знать асимметрию и отвечать «XPath мощнее». Мощнее только в навигации вверх и по тексту — во всём остальном по умолчанию берут CSS.

Короткий ответ: Implicit wait — это глобальный таймаут поиска элемента на весь драйвер (по умолчанию 0, то есть выключен): драйвер будет ждать появления любого элемента до заданного времени. Explicit wait — это WebDriverWait под конкретное условие для конкретного элемента, опрашивающий состояние примерно каждые 500 мс. Смешивать их нельзя: таймауты складываются непредсказуемо.

Подробно:

1. Implicit — задаётся один раз (driver.implicitly_wait(10)), действует на все find_element; ждёт только присутствия элемента в DOM, не проверяет видимость или кликабельность.
2. Explicit — WebDriverWait(driver, 10).until(EC.element_to_be_clickable(...)); ждёт нужное состояние, poll interval по умолчанию 500 мс.
3. Почему не смешивать — при одновременном включении обоих драйвер может суммировать ожидания непредсказуемым образом, и вместо 10 секунд тест ждёт минуты.

⚠️ Частая ошибка: включить implicitly_wait и сверху накидывать WebDriverWait. Правило — выбрать один механизм, обычно explicit, а implicit держать на 0.

Короткий ответ: Thread.sleep() — это статичная пауза на фиксированное время. На быстром окружении она зря тормозит прогон (ждём 5 секунд там, где хватило бы 200 мс), а на медленном — всё равно не хватает, и тест флакает. Замена — условные ожидания, которые опрашивают состояние и продолжают сразу, как только условие выполнено: WebDriverWait + ExpectedConditions в Selenium или встроенный auto-wait в Playwright.

Подробно:

1. Проблема — sleep не знает ничего о состоянии страницы; он всегда либо слишком длинный, либо слишком короткий.
2. Решение — ожидание по условию: until(EC.visibility_of_element_located(...)) завершается ровно тогда, когда элемент готов.

# Плохо: слепая пауза
time.sleep(5)
driver.find_element(By.ID, "submit").click()

# Хорошо: ждём именно нужное состояние
WebDriverWait(driver, 10).until(
    EC.element_to_be_clickable((By.ID, "submit"))
).click()

⚠️ Частая ошибка: «тест флакает — поставлю sleep побольше». Это лечит симптом ценой скорости и всё равно не даёт гарантии; правильный ответ — явное ожидание условия.

Короткий ответ: Флакающий тест чинят через системный поиск root-cause, а не через retry. Изолированно прогоняю тест N раз, собираю на падении логи, скриншот и снимок DOM, классифицирую причину и чиню корень. Retry — это маскировка нестабильности, а не решение; это надо проговорить вслух.

Подробно:

1. Воспроизвести — гоняю тест изолированно 20–50 раз, ловлю падение и фиксирую частоту.
2. Собрать улики — на фейле снимаю скриншот, HTML-дамп DOM, логи браузера и трейс.
3. Классифицировать причину — чаще всего одно из пяти:

4. Починить корень и проверить — снова гоняю N раз, добиваюсь зелёного стабильно.

⚠️ Частая ошибка: обернуть тест в @Retry(3) и закрыть задачу. Это прячет баг — иногда реальный дефект продукта — и копит технический долг в наборе.

Короткий ответ: Самые частые исключения — NoSuchElementException, StaleElementReferenceException, TimeoutException и ElementNotInteractableException, и каждое привязано к своей причине. StaleElementReferenceException означает, что ссылка на элемент устарела: DOM перерисовался, и старый WebElement больше не указывает на живой узел. Лечится перезапросом элемента, а не оборачиванием всего в try/except.

Подробно:

Практика для stale: перечитать элемент прямо перед действием, а не хранить старую ссылку через ре-рендер (типично для React/SPA после обновления состояния).

⚠️ Частая ошибка: глушить StaleElementReferenceException через try/except и ретрай в цикле. Это прячет реальную гонку с ре-рендером — правильно перезапросить элемент после того, как DOM устаканился.

Короткий ответ: JavaScriptExecutor выполняет произвольный JS прямо в браузере, когда обычного WebDriver API не хватает: скролл до элемента, клик по перекрытому элементу, доступ в shadow DOM, чтение JS-переменной со страницы. Но клик через JS обходит реальный пользовательский путь — если тест «работает только через JS», это тревожный знак: возможно, вы наткнулись на баг UI.

Подробно:

1. Легитимные случаи — скролл (scrollIntoView), чтение состояния (return document.title), взаимодействие с элементами, до которых WebDriver физически не дотягивается (shadow DOM, хитрые оверлеи).
2. Красный флаг — arguments[0].click() вместо обычного клика: WebDriver отказался кликать, потому что элемент невидим/перекрыт/disabled — то есть и реальный пользователь бы не кликнул.

// Скролл — ок
js.executeScript("arguments[0].scrollIntoView(true);", el);

// JS-клик в обход проверок кликабельности — красный флаг
js.executeScript("arguments[0].click();", el);

⚠️ Частая ошибка: «обычный клик не срабатывает — сделаю через JS». Так вы прячете реальный дефект (элемент перекрыт модалкой) и получаете зелёный тест на сломанном UI.

Короткий ответ: Selenium Grid — это инфраструктура для распределённого параллельного запуска тестов на разных машинах, браузерах и ОС. Классическая архитектура — hub-and-node: хаб принимает запросы и раздаёт их нодам, где реально крутятся браузеры. Ключевое: Grid — это слой исполнения, а не драйвер и не тест-фреймворк.

Подробно:

1. Hub — точка входа: получает запрос теста с нужными capabilities (браузер, версия, ОС) и маршрутизирует его на подходящую ноду.
2. Node — рабочая машина, где запускается реальный браузер и выполняются команды WebDriver.
3. Зачем — параллелить прогон (10 тестов на 10 нодах вместо очереди), покрывать кросс-браузерную и кросс-платформенную матрицу без зоопарка локальных машин.

              ┌──────────┐
   тесты ───► │   HUB    │  маршрутизация по capabilities
              └────┬─────┘
        ┌──────────┼──────────┐
     ┌──┴───┐   ┌──┴────┐  ┌──┴────┐
     │Node 1│   │Node 2 │  │Node 3 │
     │Chrome│   │Firefox│  │ Edge  │
     └──────┘   └───────┘  └───────┘

⚠️ Частая ошибка: путать Grid с самим Selenium WebDriver или с тест-раннером (TestNG/pytest). Grid только распределяет исполнение — писать и запускать тесты по-прежнему нужно фреймворком.

Короткий ответ: Playwright автоматически ждёт actionability каждого элемента (видимость, доступность, стабильность) перед действием, поэтому ручные ожидания почти не нужны. Он управляет браузером напрямую через протоколы (CDP и аналоги), а не через цепочку WebDriver, — это быстрее и стабильнее, — и приносит из коробки трейсинг, скриншоты и мокинг сети.

Подробно:

1. Auto-wait — перед кликом Playwright сам дожидается, что элемент visible, enabled и stable; explicit WebDriverWait почти не пишут.
2. Управление браузером — прямой протокол вместо JSON Wire / W3C поверх HTTP; меньше сетевых хопов, меньше флака.
3. Из коробки — trace viewer, авто-скриншоты/видео, page.route() для мокинга сети, авто-ожидания в ассёртах (expect).

⚠️ Частая ошибка: тащить в Playwright селениумовскую привычку ручных sleep/wait. Здесь это лишнее и часто вредит — надо полагаться на встроенные авто-ожидания.

Короткий ответ: Хороший автотест описывают мнемоникой FIRST: Fast, Independent, Repeatable, Self-validating, Timely. Плюс детерминизм и отсутствие хардкода данных. На собеседовании интервьюер особенно слушает независимость тестов друг от друга — это реальный вопрос, например в Ozon.

Подробно:

• Fast (быстрый) — прогон не должен занимать вечность, иначе его перестают запускать.
• Independent (независимый) — тест не зависит от других и от порядка запуска; своё состояние готовит и убирает сам.
• Repeatable (повторяемый) — даёт один результат в любом окружении, без привязки к «сегодняшней» дате или чужим данным.
• Self-validating (самопроверяемый) — чёткий pass/fail через ассёрты, без ручного разбора логов.
• Timely (своевременный) — пишется вовремя, рядом с кодом фичи, а не «когда-нибудь потом».

Дополнительно: детерминизм (никаких случайных задержек и гонок) и никакого хардкода тест-данных — генерировать или готовить через фикстуры.

⚠️ Частая ошибка: делать тесты, которые проходят только в определённом порядке из-за общего состояния. Стоит запустить их вразнобой или параллельно — и набор рассыпается.

Короткий ответ: Стабильный локатор опирается на то, что не меняется от рестайлинга вёрстки. Приоритет: data-testid → id → семантический атрибут или роль → короткий относительный CSS. Абсолютный XPath вида /html/body/div[3]/div/span[2] хрупок, потому что ломается от любой вставки или перестановки узла в дереве.

Подробно:

1. data-testid — атрибут, добавленный специально для тестов; не меняется от дизайна и рефакторинга. Лучший выбор.
2. id — стабилен, если он не автогенерируемый (не id="ember1234").
3. Семантика/роль — getByRole, aria-label, name; устойчиво и близко к тому, что видит пользователь.
4. Короткий относительный CSS — по классу-якорю рядом с элементом.

# Плохо: абсолютный путь — рвётся от любой правки вёрстки
/html/body/div[3]/div/form/div[2]/button

# Хорошо: якорь на тестовый атрибут
[data-testid="checkout-submit"]

Бонус к ответу: договориться с разработчиками проставлять data-testid — это дешевле, чем бороться с хрупкими селекторами.

⚠️ Частая ошибка: копировать «Copy full XPath» из DevTools. Такой абсолютный путь зелёный сегодня и красный после ближайшего изменения разметки.

Короткий ответ: Selenide — это обёртка над Selenium, которая закрывает его болевые места: умные ожидания по умолчанию (таймаут 4 секунды в каждом $/$$), лаконичный синтаксис вроде $("...").shouldBe(visible), автоскриншоты при падении и автоматическое управление драйвером. В российских Java-командах Selenide почти стандарт, и вопрос про него реально задают.

Подробно:

1. Умные ожидания — каждый поиск и ассёрт сам ждёт до 4 секунд, поэтому явные WebDriverWait и sleep почти не нужны — это убирает главный источник флака.
2. Лаконичный API — shouldBe, shouldHave вместо ручных проверок; код читается как описание поведения.
3. Диагностика — автоскриншот и HTML-дамп на падении из коробки.
4. Драйвер — Selenide сам поднимает и закрывает WebDriver.

// Голый Selenium: ручной wait + разбор состояния
new WebDriverWait(driver, Duration.ofSeconds(4))
    .until(ExpectedConditions.elementToBeClickable(By.id("submit")))
    .click();

// Selenide: ожидание встроено
$("#submit").shouldBe(visible).click();

⚠️ Частая ошибка: считать Selenide отдельным «конкурентом» Selenium. Это обёртка поверх Selenium WebDriver — она не заменяет его, а делает удобнее.