UI Automation — Playwright

Playwright errors when a locator resolves to more than one element, forcing you to disambiguate.

Asked 'What is a strict-mode violation and how do you fix it?' (flagged as a classic separator)

asked in interviews, not named in any job description

Narrowing a locator by composing/filtering it and acting on N matching elements.

Asked 'How do you act on multiple elements?' / 'How do you click the row that contains a given text?'

named in the job descriptions

The role/label/testid family that Playwright recommends over CSS/XPath because it is resilient and accessibility-aligned.

Asked 'What is a locator?' / 'How and why do you use getByRole?' / 'When would you fall back to CSS or XPath?'

named in the job descriptions

await expect(locator).toBeVisible()/toHaveText()/toHaveValue() auto-wait and retry until timeout; expect(await locator.isVisible()).toBe(true) does not.

Asked 'Why is expect(await ...).toBe(true) flaky?' / 'What are soft assertions and when do you use them?'

asked in interviews, not named in any job description

Deterministic waits keyed to a real signal (network, navigation, predicate) that replace hard sleeps.

Asked 'Why should you avoid waitForTimeout?' / 'What types of waits does Playwright support?' / 'How do you wait for an API before asserting?'

named in the job descriptions

Before each action Playwright waits for visible/enabled/stable/receives-events/not-obscured, but it does not know about data your click triggers.

Asked 'What is auto-wait?' / 'toBeVisible vs manually checking visibility?' / trap: 'if auto-wait exists why are tests still flaky?'

named in the job descriptions

A one-time login in global setup saves session state to disk that every test/worker loads, avoiding per-test login.

Asked 'How do you handle authentication across tests?' / 'How do you avoid logging in for every test?'

named in the job descriptions

A class per page/component holding its locators and user-action methods so tests read as intent and maintenance is localized.

Asked 'Walk me through a framework you built' / 'How is your POM structured?' / 'Where do assertions go — in the page object or the test?'

named in the job descriptions

Fixtures provide the STATE a test needs (logged-in user, seeded data, API client) via dependency injection; POM provides what an ACTION looks like.

Asked 'POM vs fixtures — when do you use which?' / 'How do you create a custom fixture?' / 'How do fixtures differ from beforeEach hooks?'

named in the job descriptions

Parametrized (data-driven) and abstracted-action (keyword-driven) designs layered above POM, with each test fully independent (own storage/data).

Asked 'What framework design patterns have you used?' / 'How do you make tests independent?' / 'Data-driven vs keyword-driven?'

named in the job descriptions

Human-readable Given/When/Then scenarios (Gherkin) bound to Playwright step definitions, often linked to test-management (Xray).

Asked 'Have you used BDD/Cucumber with Playwright?' / 'How do you structure feature files and step definitions?' / 'When is BDD worth it?'

named in the job descriptions

Same suite run across three engines via projects; devices dict emulates viewport/UA/touch for mobile-web.

Asked 'How do you run cross-browser?' / 'How do you test responsive/mobile-web?'

named in the job descriptions

The single config that defines what runs where and how; projects define browser/device matrices and can chain (setup -> tests).

Asked 'What is in playwright.config?' / 'What are projects?' / 'Difference between test timeout and expect timeout?'

named in the job descriptions

Files run in parallel across worker processes by default; fullyParallel parallelizes within files; serial/default modes control intra-describe behavior.

Asked 'How does parallel execution work?' / 'workers vs parallel mode?' / 'How do you run dependent tests serially?'

named in the job descriptions

Retries re-run failures to absorb infra noise, but masking real flakiness with retries is an anti-pattern.

Asked 'When do retries hide bugs vs help?' / 'What is your retry strategy?' (separator question)

named in the job descriptions

Splitting a run across independent machines (shards) — distinct from workers (parallel within one machine) — then merging blob reports into one.

Asked 'How does sharding work and when do you need it?' / 'Sharding vs workers?' / 'How do you merge reports from shards?'

asked in interviews, not named in any job description

frameLocator() scopes actions inside an iframe; event handlers/expect handle native dialogs and new-tab popups.

Asked 'How do you handle iframes?' / 'How do you handle a new tab / dialog?'

asked in interviews, not named in any job description

Intercept requests to return mock JSON (fulfill), alter them (continue), or block them (abort); routes must be set before navigation.

Asked 'How do you intercept and mock network calls with page.route?' / 'fulfill vs continue vs abort?' / 'How do you test the UI when the backend is unstable?'

named in the job descriptions

Use Playwright's request context to set up/tear down state and to test at the right layer instead of driving everything through the slow UI.

Asked 'How do you do API testing with Playwright?' / 'How do you set up test data?' / 'When do you assert via API vs UI?'

named in the job descriptions

A time-travel recording of a run — per-action DOM snapshot, network, console, source — that makes CI-only failures diagnosable.

Asked 'What is Trace Viewer and when do you use it?' / 'A test fails in CI but passes locally — how do you debug it?' (top separator question)

asked in interviews, not named in any job description

The interactive tools for authoring and stepping through tests; codegen records actions into a script starting point.

Asked 'How do you generate tests with codegen/CLI?' / 'How do you debug a failing test locally?' / 'How do you capture screenshots/video on failure?'

named in the job descriptions

Multiple reporters run at once — HTML for humans, JUnit/blob for CI — and Allure adds step-level breakdown with auto-attached trace/screenshot/video.

Asked 'How do you report results?' / 'How do you integrate Allure?' / 'How do you make CI consume results (JUnit)?'

named in the job descriptions

axe-core flags WCAG violations in-test; ARIA snapshots assert the accessibility-tree structure as YAML — a 2025-2026 Playwright addition.

Asked 'How do you test accessibility?' / 'What are ARIA snapshots?' (rising 2026 question)

named in the job descriptions

Built-in pixel-diff assertions against committed baselines, tuned by threshold and pinned to a stable OS/browser to avoid false diffs.

Asked 'How do you do visual regression?' / 'How do you keep visual baselines stable across machines?'

named in the job descriptions

A named catalogue of why tests flake and a disciplined RCA loop that fixes the cause instead of cranking retries.

Asked 'What are the most common causes of flaky tests?' / 'A test is flaky — how do you diagnose and fix it?' (top-2 separator question)

named in the job descriptions

Enough Selenium to work a legacy suite and contrast it with Playwright: client sends W3C HTTP commands to a driver (ChromeDriver) that drives the browser.

Asked 'Explain Selenium's architecture' / 'implicit vs explicit wait' / 'Why is Playwright faster/less flaky than Selenium?'

named in the job descriptions

Selenium 4/5 added WebDriver BiDi (bidirectional WebSockets so the browser pushes console/network/JS-error events, no polling) and Selenium Manager (no more manual chromedriver downloads).

Asked 'What changed in Selenium 4/5?' / 'What is WebDriver BiDi?' / 'Does BiDi make Selenium equal to Playwright?'

asked in interviews, not named in any job description

A staged migration keeping both suites running until Playwright coverage matches, translating explicit waits -> auto-wait/web-first assertions and CSS/XPath -> role locators.

Asked 'How would you migrate a Selenium suite to Playwright?' / 'How do you translate WebDriverWait to Playwright?'

named in the job descriptions

Hosted browser/device farms to run cross-browser/real-device coverage you can't hold locally; Docker gives reproducible CI containers.

Asked 'Have you used BrowserStack/Sauce Labs?' / 'How do you get real-device/OS coverage?' / 'How do you run tests in Docker/CI?'

named in the job descriptions

A pipeline that installs browsers, runs the suite (often a tag-filtered subset), and publishes the report as an artifact.

Asked 'How do you integrate Playwright into CI/CD?' / 'How do you run only smoke tests on a PR?' / 'How do you tag and select tests?'

named in the job descriptions

Self-healing = store selector + fallback and swap on failure (Momentic-style intent locators); Clock API (page.clock) fakes time to test timeouts/dates deterministically.

Asked 'What do you think of self-healing locators?' / 'How would you test time-dependent UI?' (rising)

asked in interviews, not named in any job description

Playwright's official MCP server exposes structured browser-control tools so an LLM can drive a live session; 2026 shipped AI test agents too.

Asked 'What is Playwright MCP and why does it matter?' / 'MCP vs CLI?' / 'How would you use AI in test automation?'

named in the job descriptions