Playwright

What is the difference between Playwright and Selenium, and why would you choose one over the other?

What they’re really testing: Whether you understand the architectural difference between browser protocols (CDP vs WebDriver) and can reason about trade-offs rather than just listing features.

Strong answer covers: Playwright uses native browser protocols with built-in auto-waiting, while Selenium uses the WebDriver standard and requires explicit waits; Playwright is the default for modern SPAs in NZ greenfield projects (CloudBooks, ListRight); Selenium remains the better choice when a team has a large existing Java-based suite and a rewrite is not in scope.

When would you use Playwright over Cypress for a new NZ project?

What they’re really testing: Whether you understand the practical trade-offs between two modern tools rather than assuming one is universally superior.

Strong answer covers: Playwright when cross-browser coverage is required (especially WebKit/Safari for NZ audiences that skew iOS); Playwright when tests need to combine API interception with UI steps in a single run; Cypress when the team is frontend-focused and values the time-travel debugger over multi-browser support; acknowledge both are valid and the decision should follow the team’s stack and delivery constraints.

You’re working at a NZ government agency and your Playwright tests pass consistently on your laptop but fail roughly 30% of the time in the GitHub Actions pipeline. How do you investigate?

What they’re really testing: Systematic debugging discipline and familiarity with CI-specific failure modes — not just whether you can write tests, but whether you can own them when they break in production.

Strong answer covers: Open the Playwright trace viewer from the CI artefact first — it replays the exact failure with network, console, and DOM snapshots; check for timing differences (slower CI runners, cold-start network latency); look for hardcoded waits or non-deterministic selectors (e.g. nth-child depending on load order); consider using --retries 2 as a short-term stabiliser while fixing the root cause, not as a permanent fix; note that government CI environments may have stricter network egress rules that affect API mocks.

How would you structure a Playwright test suite for a large React application with 10+ engineers contributing?

What they’re really testing: Whether you think about maintainability and team conventions at scale, not just how to write a single passing test.

Strong answer covers: Page Object Model (or Playwright’s fixtures pattern) to encapsulate selectors and actions so individual tests stay readable; enforce getByRole and getByTestId conventions from day one to avoid CSS selector drift; split tests into fast smoke suite (critical paths, run on every PR) and slower regression suite (run nightly or on release branches); use Playwright’s built-in sharding to parallelise across GitHub Actions workers; document selector conventions in the team’s testing standards, particularly relevant if following NZISM or agency coding standards.

How would you use Playwright to verify that an accessibility remediation sprint actually fixed the reported issues — and that regressions don’t creep back?

What they’re really testing: Whether you connect test tooling to real delivery outcomes (accessibility compliance) rather than treating Playwright purely as a functional regression tool.

Strong answer covers: Integrate @axe-core/playwright and call checkA11y() on the highest-traffic screens in every CI run to catch regressions automatically; add a dedicated WebKit run because Safari (dominant on NZ iOS devices) surfaces a distinct class of colour-contrast and focus-order bugs that Chromium misses; tie test failures to specific WCAG 2.1 criteria so developers can action them without a separate audit; relevant for NZ public sector work where the Web Accessibility Standard 1.1 (based on WCAG 2.1 AA) is a compliance requirement.