50 Playwright Interview Questions and Answers for 2026

Playwright has become one of the most in-demand skills in test automation in 2026. Whether you are preparing for a QA engineer role, a senior automation engineer position, or a full stack developer interview that includes testing knowledge, you will likely face Playwright questions.

This guide covers 50 of the most commonly asked Playwright interview questions — from beginner basics to advanced topics — with clear, complete answers you can use to prepare confidently.

Beginner Playwright Interview Questions

1. What is Playwright?

Playwright is an open source browser automation and end-to-end testing framework built by Microsoft. It allows developers and QA engineers to write automated tests for web applications that run across Chromium, Firefox, and WebKit from a single API. It supports JavaScript, TypeScript, Python, Java, and .NET.

2. What browsers does Playwright support?

Playwright supports three browser engines — Chromium, Firefox, and WebKit. Chromium covers Google Chrome and Microsoft Edge. WebKit covers Safari. This means a single Playwright test suite can verify behaviour across all major browsers without installing separate drivers.

3. How is Playwright different from Selenium?

The key differences are architecture, setup, and built-in features. Playwright communicates directly with browser engines using a single protocol, while Selenium uses a layered driver model. Playwright includes auto-waiting, built-in trace viewer, video recording, and parallel execution natively. Selenium requires external tools for most of these. Playwright setup takes one command while Selenium requires separate driver management.

4. What programming languages does Playwright support?

Playwright supports JavaScript, TypeScript, Python, Java, and .NET (C#). JavaScript and TypeScript are the most popular choices with the best tooling and community support.

5. What is the Playwright test runner?

The Playwright test runner is @playwright/test — a full-featured test framework built specifically for Playwright. It provides fixtures, parallel execution, retries, HTML reports, and built-in assertions. It is different from using the Playwright library with a third-party runner like Jest or Mocha.

6. How do you install Playwright?

Run npm init playwright@latest in your project folder. This interactive command installs the Playwright package, downloads browser binaries for Chromium, Firefox, and WebKit, creates a configuration file, and generates a sample test. You can also install manually with npm install @playwright/test followed by npx playwright install.

7. What is the difference between page, context, and browser in Playwright?

A browser is the top-level browser instance. A browser context is like an isolated incognito window — it has its own cookies, localStorage, and session state completely separate from other contexts. A page is a single tab within a browser context. Tests typically get a new context and page per test to ensure full isolation.

8. What is headless mode in Playwright?

Headless mode runs the browser without a visible graphical window. The browser runs in the background and tests execute at full speed without rendering a UI on screen. Playwright runs in headless mode by default — which is what you want in CI/CD environments. Set headless: false in your config to see the browser during local development.

9. How do you run Playwright tests?

Run all tests with npx playwright test. Run a specific file with npx playwright test tests/login.spec.ts. Run in headed mode with npx playwright test --headed. Run in debug mode with npx playwright test --debug. Run in UI mode with npx playwright test --ui.

10. What is playwright.config.ts?

playwright.config.ts is the central configuration file for your Playwright project. It defines which browsers to run, timeout values, retry counts, base URL, reporter settings, parallelism, and project definitions. It is the first place you look when you need to change how your entire test suite behaves.

Locators and Selectors Interview Questions

11. What is a locator in Playwright?

A locator represents a way to find one or more elements on a page. Unlike a simple element handle, a locator is lazy — it does not search the DOM when created. It searches when you interact with it. Locators also automatically retry when actions fail, making them more reliable than element handles.

12. What are the recommended locators in Playwright?

Playwright recommends locators that reflect how users interact with the page. The preferred locators are page.getByRole() for elements with ARIA roles, page.getByLabel() for form inputs, page.getByText() for elements with visible text, page.getByPlaceholder() for inputs with placeholders, and page.getByTestId() for elements with data-testid attributes. CSS selectors and XPath are available but not recommended as first choices.

13. What is getByRole and why is it preferred?

getByRole() finds elements by their ARIA role and accessible name — the same way screen readers and assistive technology interact with a page. It is preferred because it reflects the semantic meaning of elements rather than their HTML structure or CSS styling. Tests using getByRole() survive refactoring of class names, HTML restructuring, and style changes.

14. What is the difference between locator and elementHandle?

A locator is the recommended modern approach — it is lazy, retries automatically, and is composable. An elementHandle is a direct reference to a specific DOM element at a point in time — it does not retry and can become stale if the element is removed and re-added to the DOM. Prefer locators in all new tests.

15. How do you find an element inside another element in Playwright?

Use the locator() method on another locator to scope the search. For example page.getByRole('listitem').filter({ hasText: 'Product Name' }).getByRole('button', { name: 'Add to cart' }) finds the Add to cart button inside a specific list item. Chaining locators narrows the search to the relevant part of the DOM.

16. What is the filter method on locators?

filter() narrows a locator to elements that match additional criteria. You can filter by visible text with hasText, by the absence of text with hasNotText, by the presence of a child element with has, or by the absence of a child element with hasNot. Filtering is the clean way to select a specific item from a list of similar elements.

17. What is the nth method on locators?

nth() selects a specific element from a list of elements matching a locator by its zero-based index. page.getByRole('listitem').nth(0) selects the first list item. Use it sparingly — positional selection is fragile if items are reordered. Prefer filtering by content when possible.

Assertions Interview Questions

18. What is the expect function in Playwright?

expect() is Playwright's assertion function. You pass a value, locator, page, or response to expect() and chain a matcher that describes the expected state. Web-first matchers like toBeVisible() and toHaveText() retry automatically until the condition passes or the timeout expires.

19. What are web-first assertions?

Web-first assertions are assertions designed specifically for testing web pages. They retry automatically until the condition is met or the configured timeout expires. This handles asynchronous page updates without manual waiting. Examples include toBeVisible(), toHaveText(), toHaveURL(), and toBeEnabled(). They are the preferred way to assert on page state in Playwright.

20. What is the difference between toHaveText and toContainText?

toHaveText() asserts that the element's full text content matches the expected value exactly. toContainText() asserts that the element's text includes the expected string somewhere — it does not need to match the full content. Use toContainText() when you only care about part of the text.

21. What are soft assertions in Playwright?

Soft assertions record failures but allow the test to continue running rather than stopping immediately. Use expect.soft() instead of expect(). All soft assertion failures are reported together at the end of the test. This is useful when you want to check multiple properties on a page and see all failures at once rather than one at a time.

22. How do you assert on an API response in Playwright?

Use expect(response).toBeOK() to assert the response status is between 200 and 299. Use expect(response.status()).toBe(201) to assert a specific status code. Parse the body with response.json() and assert on its properties using standard expect() matchers.

23. What is visual testing in Playwright?

Visual testing compares screenshots of your application against previously saved baseline images. Use expect(page).toHaveScreenshot('name.png') to capture and compare full page screenshots, or expect(locator).toHaveScreenshot('component.png') for specific elements. On the first run Playwright saves baselines. On subsequent runs it compares against them and fails if visual differences exceed the configured threshold.

24. What is the default timeout for Playwright assertions?

The default timeout for web-first assertions is 5000 milliseconds — 5 seconds. You can override it per assertion by passing { timeout: 15000 } as an option, or globally by setting expect: { timeout: 10000 } in playwright.config.ts.

Fixtures Interview Questions

25. What are fixtures in Playwright?

Fixtures are reusable setup and teardown logic that tests declare as parameters. Playwright runs the fixture setup before the test, injects the prepared value, and runs the teardown after the test completes — even if the test fails. Fixtures are composable, lazily executed, and scoped to control how often they run.

26. What built-in fixtures does Playwright provide?

The main built-in fixtures are page which provides a fresh browser page per test, context which provides an isolated browser context, browser which provides the browser instance, browserName which provides the name of the current browser, and request which provides an API request context for HTTP testing.

27. How do you create a custom fixture in Playwright?

Extend the base test object from @playwright/test using test.extend(). Define each fixture as a function that receives other fixtures and a use callback. Run setup code before calling use(value) to pass the fixture value to the test. Run teardown code after use(). Export the extended test object and import it in your test files instead of importing from @playwright/test directly.

28. What is fixture scope in Playwright?

Fixture scope controls how often setup and teardown runs. The default test scope runs setup and teardown for every individual test that uses the fixture. worker scope runs setup once per worker process and shares the fixture across all tests in that worker. Use test scope for isolated state and worker scope for expensive shared resources like server connections.

29. What is the difference between fixtures and beforeEach in Playwright?

beforeEach runs before every test in a file and is scoped to that file. Fixtures are reusable across any number of files, only run when a test explicitly uses them, support teardown inline without a separate afterEach, and can be scoped to test or worker level. Fixtures are more powerful and more reusable than beforeEach hooks.

30. How do you override built-in fixtures in Playwright?

Redefine the built-in fixture in your test.extend() call. For example override the page fixture to automatically navigate to a base URL before every test, or override the context fixture to inject storage state for authentication. The override applies to every test that imports from your custom test object.

Page Object Model Interview Questions

31. What is the Page Object Model in Playwright?

The Page Object Model is a design pattern that encapsulates the locators and actions for a specific page in a class. Instead of writing locator code directly in tests, tests call methods on page objects. When the UI changes, you update the page object class in one place rather than every test that interacts with that page.

32. When should you use Page Object Models?

Use page objects when the same locators and interactions appear in multiple test files, when a page has complex interactions that would create long tests if written inline, and when you want to create a readable high-level API for common user actions. Do not create page objects for simple pages with one or two interactions — the abstraction adds overhead without enough benefit.

33. How do Page Objects work with Playwright fixtures?

The cleanest pattern is to create a fixture that instantiates the page object and passes it to the test. The fixture handles navigating to the correct URL, creating the page object instance, and any necessary cleanup. Tests receive the ready-to-use page object as a fixture parameter without any setup code.

Network and API Interview Questions

34. How do you intercept network requests in Playwright?

Use page.route() to intercept and modify network requests. Pass a URL pattern and a handler function. Inside the handler you can fulfil the request with a mocked response using route.fulfill(), abort the request using route.abort(), or continue with modifications using route.continue(). This is used to mock API responses, simulate errors, and test loading states.

35. What is the request fixture in Playwright?

The request fixture provides an APIRequestContext for making HTTP requests without a browser. It supports GET, POST, PUT, PATCH, and DELETE requests. Use it for API testing, seeding test data via API calls before UI tests, and verifying backend state after UI actions.

36. How do you mock an API response in Playwright?

Use page.route() with route.fulfill() to return a mocked response. Specify the URL pattern, response status, headers, and body. The page receives the mocked response as if it came from the real server. Mocking is useful for testing how your UI handles specific API responses including errors and edge cases.

37. How do you wait for a specific network request in Playwright?

Use page.waitForRequest() or page.waitForResponse() to wait for a specific network event. Pass a URL pattern or predicate function. These return a promise that resolves when the matching request or response occurs. Useful for verifying that the correct API calls are made after a user action.

Configuration and CI/CD Interview Questions

38. How do you run Playwright tests in parallel?

Playwright runs tests in parallel by default using worker processes. Configure the number of workers with the workers option in playwright.config.ts. Tests within a single file run sequentially by default — add test.describe.configure({ mode: 'parallel' }) to run tests within a file in parallel too. For large suites use sharding to distribute across multiple CI jobs.

39. What is test sharding in Playwright?

Sharding splits your test suite across multiple machines or CI jobs running simultaneously. Pass --shard=1/4 to the first job, --shard=2/4 to the second, and so on. Each job runs its assigned portion of the suite in parallel. After all shards complete, merge reports with npx playwright merge-reports. Sharding dramatically reduces total suite execution time for large test suites.

40. How do you configure retries in Playwright?

Set the retries option in playwright.config.ts. A common pattern is retries: process.env.CI ? 2 : 0 — zero retries locally so failures are immediately visible during development, and two retries in CI to absorb genuine flakiness. Configure traces and screenshots to capture on the first retry to get debugging information without the overhead of capturing on every run.

41. What reporters does Playwright support?

Playwright supports HTML, list, dot, line, JSON, JUnit, and GitHub reporters out of the box. The HTML reporter generates a detailed interactive report. The JUnit reporter generates XML that CI platforms like GitHub Actions, GitLab CI, and Jenkins can parse natively. Configure multiple reporters simultaneously by passing an array in your config.

42. How do you set a base URL in Playwright?

Set baseURL in the use section of playwright.config.ts. When a base URL is configured, calls to page.goto('/login') automatically prepend the base URL. This lets you run the same tests against different environments — development, staging, production — by changing one config value or environment variable.

43. How do you use Playwright with GitHub Actions?

Create a .github/workflows/playwright.yml workflow file. The workflow checks out your code, sets up Node.js, runs npm ci to install dependencies, runs npx playwright install --with-deps to install browsers and system dependencies, runs npx playwright test, and uploads the HTML report as an artifact using actions/upload-artifact. Use if: always() on the artifact upload step to ensure the report is saved even when tests fail.

44. What is the --with-deps flag in Playwright?

npx playwright install --with-deps installs both the Playwright browser binaries and the Linux system libraries those browsers depend on. In CI environments on Linux runners these system libraries are not installed by default. Without --with-deps browsers may fail to launch in CI even though they work locally on macOS or Windows.

Advanced Playwright Interview Questions

45. What is the Playwright Trace Viewer?

The Trace Viewer is a built-in debugging tool that shows a complete timeline of a test run — every action, DOM snapshot at each step, network requests, console logs, and screenshots. Enable traces in config with trace: 'on-first-retry'. View a trace file with npx playwright show-trace trace.zip or by uploading it to trace.playwright.dev.

46. How do you handle multiple tabs or windows in Playwright?

Use context.waitForEvent('page') to capture a new page that opens in a new tab. Trigger the action that opens the new tab, await the new page event, and then interact with the new page object. Both the original page and the new page remain accessible as separate objects in the same browser context.

47. How do you handle file uploads in Playwright?

Use locator.setInputFiles() to set files on a file input element. Pass a file path or an array of file paths. For drag-and-drop file uploads that do not use a standard file input, use page.dispatchEvent() with a DataTransfer object. Playwright also supports uploading files from a buffer when the file is generated dynamically rather than read from disk.

48. What is the difference between page.evaluate and page.locator?

page.evaluate() runs a JavaScript function directly in the browser context and returns the result to Node.js. It gives you full access to browser APIs and the DOM but bypasses Playwright's auto-waiting and retry logic. Use it only for operations that cannot be done through locators — reading computed values, triggering custom events, or interacting with browser APIs. For everything else use locators.

49. How do you test authentication that uses OAuth or SSO?

The recommended approach is to log in once programmatically, save the resulting browser storage state with context.storageState(), and restore it in tests that need authentication. For OAuth flows that redirect to external providers, mock the authentication endpoints with page.route() to avoid dependency on external services in tests. For end-to-end OAuth testing use dedicated test accounts on the real identity provider.

50. How do you debug a failing Playwright test?

Start with the HTML report — it shows exactly which step failed and what the page looked like. If traces are enabled open the trace file in the Trace Viewer for a complete step-by-step replay with DOM snapshots and network activity. Use --debug flag to run the test with the Playwright Inspector open — it steps through each action and lets you explore the page state interactively. Add await page.pause() inside a test to pause execution at a specific point and inspect the browser manually.

Playwright Interview Tips

Know the difference between locator types. Interviewers commonly ask why getByRole() is preferred over CSS selectors. Understand that role-based locators reflect semantic meaning and survive HTML refactoring.

Understand auto-waiting. A frequent question is how Playwright handles asynchronous page updates. The answer is web-first assertions and action auto-waiting — Playwright retries until the condition is met rather than checking once and failing.

Be able to explain fixtures. Many candidates struggle to explain what a fixture is and how it differs from beforeEach. Know that fixtures are lazy, composable, scoped, and handle teardown inline.

Know CI/CD basics. Senior roles expect you to know how to run Playwright in GitHub Actions, what --with-deps does, how sharding works, and how to upload artifacts.

Have examples ready. Be prepared to describe a real testing challenge you solved with Playwright — a flaky test you fixed, a complex fixture you built, or a CI/CD pipeline you set up. Concrete examples make your answers far more credible than definitions alone.