Skip to main content
Back to Blog

Top 15 Playwright Interview Questions You Need to Know (2026)

By Aston Cook8 min read
playwright interview questionsplaywright interview questions and answersplaywright testing interviewplaywright automation interview questions 2026

Playwright has become the fastest-growing test automation framework in the QA space. More companies are adopting it, and interview questions about Playwright are showing up in QA and SDET roles across the industry. Here are the questions you will actually encounter and what interviewers expect to hear.

1. How does Playwright communicate with browsers differently from Selenium?

This is the most common opening question. It tests whether you understand architecture or just know the API surface.

Playwright uses the Chrome DevTools Protocol (CDP) for Chromium browsers and similar internal protocols for Firefox and WebKit. It maintains a persistent WebSocket connection to the browser process. Selenium, by contrast, uses the W3C WebDriver protocol, sending individual HTTP requests through a driver binary.

The practical implication: Playwright commands execute faster because there is no HTTP overhead per action, and Playwright has deeper access to browser internals — network interception, permission emulation, geolocation mocking, and more.

2. Explain Playwright's auto-waiting mechanism

Auto-waiting is Playwright's answer to the flaky test problem. Before performing any action, Playwright automatically waits for the target element to meet a set of actionability checks: visible, enabled, stable (not animating), receiving events, and attached to the DOM.

For example, when you call page.click('button'), Playwright waits for that button to be visible, enabled, and not covered by another element before clicking. If the element is behind a loading overlay, Playwright waits for the overlay to disappear.

This eliminates the need for explicit waits in most scenarios. You do not need sleep() or waitForSelector() before every action — the actions themselves are self-waiting. This is the single biggest architectural advantage over Selenium.

3. What are browser contexts and why are they useful?

A browser context is an isolated browser session within a single browser instance. Each context has its own cookies, localStorage, and session state. Think of them as incognito windows that do not share any data.

Why they matter: you can test multi-user scenarios (admin and regular user simultaneously), run tests in parallel without state leakage, and skip login flows by injecting stored authentication state into a context.

Creating a context is lightweight — much faster than launching a new browser. This is how Playwright achieves fast parallel execution without the infrastructure overhead of Selenium Grid.

4. How does Playwright handle authentication across tests?

Playwright offers a storage state feature. You log in once in a setup step, save the authenticated state (cookies and localStorage) to a JSON file, and load that state into new browser contexts for subsequent tests.

In playwright.config.ts, you define a setup project that runs first and saves the state. All other test projects depend on it and reuse the saved state. This means your entire test suite authenticates once instead of logging in before every test.

This is dramatically faster than Selenium setups where each test typically handles its own login flow.

5. What are Playwright fixtures and how do you use them?

Fixtures are Playwright's dependency injection system. They provide test-scoped resources like pages, browser contexts, or custom objects that are automatically set up before a test and torn down after.

Built-in fixtures include page, context, browser, and request. Custom fixtures let you encapsulate reusable setup logic — authenticated pages, test data, API clients — and inject them into any test that needs them.

The key benefit: fixtures ensure proper cleanup. If a test fails, the fixture teardown still runs, preventing resource leaks and state corruption between tests.

6. How do you intercept and mock network requests in Playwright?

Use page.route() to intercept requests matching a URL pattern. You can fulfill requests with custom responses, modify request headers, abort requests, or continue them with modifications.

Common use cases: mock API responses to test error states, block third-party scripts to speed up tests, capture API calls to verify request payloads, and simulate slow networks.

This is a native capability in Playwright. In Selenium, network interception requires additional tools like BrowserMob Proxy or CDP integration, making it significantly more complex.

7. Compare Playwright's locator strategies with Selenium's

Playwright encourages user-facing locators: getByRole(), getByText(), getByLabel(), getByPlaceholder(), and getByTestId(). These align with how users interact with the page and are more resilient to implementation changes.

Selenium primarily uses CSS selectors, XPath, ID, name, and class name. These are implementation-detail locators that break when the HTML structure changes.

Playwright also supports CSS and XPath, but the recommended approach is role-based locators first, test IDs second, and CSS/XPath as a last resort.

8. How does Playwright handle multiple browser types?

Playwright ships with Chromium, Firefox, and WebKit (Safari's rendering engine) bundled. You configure which browsers to test in playwright.config.ts using projects.

Each project can have its own browser, viewport, and configuration. Tests run against all configured browsers during npx playwright test. This means you get true cross-browser coverage including Safari without needing a Mac or cloud service.

This is a significant advantage over Selenium, where you must download and maintain separate driver binaries and cannot test WebKit natively.

9. What is Playwright's trace viewer and how do you use it for debugging?

The trace viewer records every action, network request, DOM snapshot, and console log during a test run. You enable it in the config or per-test, and open recorded traces with npx playwright show-trace.

The trace viewer lets you step through your test action by action, see the exact DOM state at each step, inspect network requests and responses, and view console output. It is the most powerful debugging tool in any test automation framework.

For CI failures, configure traces to record only on first retry. This gives you debugging data for flaky tests without the storage overhead of recording every run.

10. How do you run Playwright tests in parallel?

Playwright runs tests in parallel by default. Each test file runs in its own worker process, and tests within a file run sequentially by default. You can configure the number of workers in playwright.config.ts.

For CI environments, start with workers: 1 and increase gradually. Each worker launches its own browser, so the optimal number depends on available CPU and memory.

Tests must be independent to run in parallel — no shared state between test files. Playwright's browser context isolation makes this natural, but you still need to ensure test data does not conflict.

11. What is the Playwright Test Generator and when is it useful?

The test generator (npx playwright codegen) opens a browser and records your interactions as Playwright test code. It generates locators, assertions, and navigation calls automatically.

It is useful for quickly scaffolding tests for new features, learning the Playwright API, and generating locators for complex elements. However, generated code typically needs refactoring — extracting page objects, adding meaningful assertions, and removing redundant actions.

Do not use generated code directly in your test suite. Treat it as a starting point.

12. How do you test API endpoints with Playwright?

Playwright includes APIRequestContext for making HTTP requests without a browser. You can create API tests alongside your UI tests, sharing the same configuration, fixtures, and reporting.

Use request.get(), request.post(), etc. to call APIs directly. This is useful for setting up test data before UI tests, verifying backend behavior, and testing APIs that your application consumes.

The advantage over dedicated API testing tools: you get one test runner, one configuration, and one reporting pipeline for both UI and API tests.

13. How do you handle file uploads and downloads in Playwright?

For uploads, use page.setInputFiles() on the file input element. You can set single files, multiple files, or clear the selection. For drag-and-drop uploads, use locator.setInputFiles() combined with the file chooser event.

For downloads, listen for the download event on the page, trigger the download action, then save or read the downloaded file. Playwright manages the download lifecycle and gives you access to the file path and suggested filename.

14. What are Playwright's reporting options?

Built-in reporters include list (default terminal output), HTML (interactive report with traces), JSON (machine-readable), and JUnit (CI integration). You can configure multiple reporters simultaneously.

The HTML reporter is the most valuable for team use. It shows test results with screenshots, traces, and error details in a browsable interface. Configure it to open automatically on failure during local development.

For CI, combine JUnit (for pipeline integration) with HTML (for human debugging) and publish the HTML report as a build artifact.

15. When would you choose Selenium over Playwright?

This tests your objectivity and real-world judgment. Good answers acknowledge trade-offs.

Choose Selenium when: your team has an existing Selenium suite with significant investment, you need to support older browsers that Playwright does not cover, your team primarily works in languages Playwright does not support well (Ruby, C# has community support but Java and Python are strongest), or your organization has standardized on Selenium Grid infrastructure.

Choose Playwright when: starting a new project, cross-browser coverage including WebKit is important, you need built-in network mocking and API testing, test speed and reliability are priorities, or your team uses TypeScript or JavaScript.

---

Practice These Questions with AI

Knowing the answers is one thing — articulating them under pressure is another. Practice Playwright interview questions on AssertHired with an AI interviewer that asks real follow-up questions and scores your responses across four dimensions.

You might also want to prepare for Selenium interview questions since many teams use both frameworks, or browse all QA interview questions by tool.

Related Interview Prep