Playwright Interview Questions for SDET 2026

Q1: How does Playwright's auto-waiting mechanism work — and how does it differ from Selenium's implicit and explicit waits?

What the interviewer is testing: Whether you understand auto-waiting as an architectural feature, not a convenience — and whether you can explain how it changes test design.

Model answer: Playwright's auto-waiting is not an optional configuration — it is a fundamental property of every action and assertion in the framework. Before performing any action — click(), fill(), selectOption(), press() — Playwright runs a series of actionability checks on the target element: (1) Attached — the element is connected to the DOM. (2) Visible — the element has non-zero size and is not display: none or visibility: hidden. (3) Stable — the element has not moved for at least two consecutive animation frames, preventing clicks on elements that are mid-transition. (4) Receives events — the element is not obscured by another element at the click point. (5) Enabled — the element is not disabled. These checks run repeatedly within a configurable timeout (default 30 seconds), and the action proceeds only when all checks pass.

This is fundamentally different from Selenium's wait model. In Selenium, an implicit wait tells the WebDriver to poll the DOM for a specified duration when locating an element — but once the element is found, the wait stops, regardless of whether the element is actually ready for interaction. An explicit wait (WebDriverWait with ExpectedConditions) requires you to write wait logic for every async interaction — specifying the condition, the timeout, and the polling interval. The result: Selenium tests are littered with wait statements — and missing a single wait causes flakiness that is hard to diagnose because the failure depends on timing.

Playwright's web-first assertions extend auto-waiting to the assertion layer. expect(locator).toBeVisible(), expect(locator).toHaveText('Submitted'), expect(locator).toContainText('Success') — these assertions retry automatically until the condition is met or the timeout expires. No waitForSelector, no waitForFunction, no polling configuration. The assertion is the wait. This eliminates the category of flakiness where an assertion runs before the UI has updated — because in Playwright, the assertion waits for the UI to reach the expected state before evaluating.

The design impact: in Selenium, you write tests defensively — adding waits before every interaction because you cannot be sure the previous action has completed. In Playwright, you write tests declaratively — stating what you expect the page to look like, and trusting the framework to wait until it does. This changes test readability, maintenance, and reliability simultaneously. A Selenium test with 12 explicit waits is hard to read and easy to break. A Playwright test with 12 web-first assertions is self-documenting — each assertion describes the expected state transition.

Q2: Explain Playwright locators — and when would you use getByRole vs getByTestId vs getByText?

What the interviewer is testing: Whether you have a locator strategy — not just a list of locator methods — and whether you prioritise accessibility-resilient locators over implementation-detail locators.

Model answer: Playwright's locator API is ordered by resilience — the framework recommends a specific priority, and understanding why reveals whether you think about test maintenance strategically. The recommended priority: getByRole → getByLabel → getByPlaceholder → getByText → getByAltText → getByTitle → getByTestId.

getByRole is the most resilient locator because it mirrors how assistive technologies identify elements — by their ARIA role and accessible name. page.getByRole('button', { name: 'Submit' }) targets the button that a screen reader would announce as 'Submit button.' It survives DOM restructuring because it does not depend on CSS classes, DOM hierarchy, or element IDs — it depends on the semantic role, which is stable even when the implementation changes. If a developer changes <button class="btn-primary">Submit</button> to <div><button class="btn-lg btn-brand">Submit</button></div> — the getByRole locator still works. A CSS-selector locator would break on both the class change and the DOM restructuring.

getByLabel targets form inputs by their associated label — page.getByLabel('Email address') matches the input whose <label> element (connected via for attribute or nesting) reads 'Email address.' It is resilient because labels are driven by user-facing content, not implementation details. getByPlaceholder is similar — it targets inputs by their placeholder text, which is visible to users and tends to be stable.

getByText targets elements by their visible text content — page.getByText('Your order has been placed'). It is useful for assertions on content that appears dynamically but should be used sparingly for interactions because text content changes more frequently than roles or labels — especially in internationalised applications.

getByTestId is the escape hatch — page.getByTestId('checkout-button') targets elements by their data-testid attribute. It is resilient to DOM restructuring but requires developer cooperation to add data-testid attributes. It is the right choice when: (a) the UI is highly dynamic and no semantic locator is stable, or (b) you need to target a specific instance of a repeated component. But overusing getByTestId creates a maintenance burden — every data-testid is a contract between the test and the implementation that must be maintained.

The key interview signal: a candidate who leads with locator('.css-selector') and uses getByRole as a fallback is signalling Selenium habits. A candidate who leads with getByRole and uses getByTestId only when semantic locators are insufficient is signalling Playwright-native thinking.

Q3: What are browser contexts in Playwright — and how do they enable test isolation better than Selenium?

What the interviewer is testing: Whether you understand the browser context as an architectural concept — and whether you can explain how it solves real testing problems that Selenium cannot.

Model answer: A browser context in Playwright is an isolated browsing session — analogous to an incognito window in Chrome. Each context has its own: cookies and localStorage (completely isolated — setting a cookie in context A does not affect context B), sessionStorage, cache (including service worker caches), network state (including authentication tokens), and browser permissions (geolocation, notifications, camera, microphone). Multiple contexts can coexist within a single browser instance, and they are cheap — creating a new context takes approximately 10 milliseconds and consumes minimal memory.

This architecture enables test isolation patterns that are impossible in Selenium without launching separate browser instances. (1) Authentication isolation: authenticate once per context — not once per test — and reuse the authenticated context across tests that share the same user. In Selenium, you either authenticate before every test (slow) or share browser state across tests (risk of test cross-contamination). (2) Parallel test isolation: every test gets its own context — its own cookies, localStorage, and network state — with zero risk of one test's state leaking into another. You can run 15 tests in parallel on one machine, each with isolated state. Selenium requires separate browser instances for isolation, limiting parallelism to available machine resources. (3) Device and permission emulation: a browser context can be configured with a specific viewport, geolocation, locale, timezone, colour scheme (dark/light mode), and permission grants — all at context creation, without affecting other contexts. This means one test can run as an iPhone 15 user in Tokyo with dark mode enabled, while the next test runs as a Desktop user in London with light mode — on the same machine, in the same test run, without breaking isolation.

At BT, Mitchell's team tested a multi-tenant application where each tenant had different authentication, feature flags, and UI configurations. With Selenium, testing three tenants required three browser instances — slow, resource-heavy, and prone to session-cookie leakage. With Playwright, three browser contexts handled it in one browser instance — each context had its own authentication token, its own localStorage configuration, and its own feature-flag state. Test execution time dropped by 65%. Context isolation transformed the testing of a multi-tenant system from an infrastructure problem into a configuration problem.

Q4: How do you use Playwright for API testing — and how is it different from tools like Supertest or Postman?

What the interviewer is testing: Whether you understand Playwright's dual capability — UI automation and API testing in the same framework — and the testing patterns this unlocks.

Model answer: Playwright provides API testing through the APIRequestContext — a separate HTTP client built into the framework that is independent of browser automation. You create it with request.newContext() and it provides methods for GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS requests — with full support for headers, query parameters, request bodies, form data, file uploads, and authentication.

What makes Playwright's API testing unique is not the individual API calls — Supertest, RestAssured, and Postman can all make HTTP requests. The unique capability is combining API testing with UI testing in the same test file, sharing authentication state between them. Pattern: authenticate via API (fast, reliable, no UI dependency), store the authentication token, inject it into a browser context — and now your UI test starts already authenticated. Or the reverse: perform a UI action (fill a form, submit), then verify the result via API (check the database or backend state through an API call).

Example: test a checkout flow. (1) Use APIRequestContext to create a user, add items to a cart, and apply a promo code — all via API, in under 200ms, without touching the browser. (2) Inject the session cookie into a browserContext — the browser now has the cart pre-loaded. (3) Use UI automation for the final checkout steps — the payment form, the address entry, the confirmation page — the parts that actually need a browser. (4) Verify the order via API — check the order status, the line items, the payment amount. This hybrid approach gives you the speed and reliability of API testing for data setup and verification, combined with UI testing for the user-facing interactions. No UI-only test framework can do this. No API-only test tool can do this. Playwright is the only mainstream test framework that treats API and UI testing as equal capabilities — and interviewers want to hear that you understand the testing patterns this enables.

Q5: How does Playwright's network interception work — and when would you use route.fulfill vs route.abort?

What the interviewer is testing: Whether you understand network interception as a testing strategy — not a feature — and whether you can distinguish between mocking scenarios.

Model answer: Playwright's network interception API intercepts HTTP requests at the browser level — before they leave the browser — and allows you to modify, fulfil, abort, or continue them. This is routed through the Chrome DevTools Protocol (or the equivalent Firefox/WebKit protocols), giving Playwright access to every network request the page makes — including fetch, XHR, WebSocket connections, image loads, and service worker requests.

route.fulfill() responds to a matched request without sending it to the server. Use it when: (a) the backend is unavailable, unstable, or rate-limited — your UI tests should not depend on backend availability; (b) you need a specific API response to test a UI state — an empty list, a full list, a specific error message, a slow-loading spinner; (c) you are testing error states — a 500 response, a network timeout, a malformed JSON body — that are hard or impossible to trigger through the real backend; (d) you want deterministic, repeatable UI tests that produce the same result every time, regardless of backend state. Example: await page.route('**/api/users', route => route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify([{ id: 1, name: 'Alice' }]) })) — every call to any URL ending in /api/users returns the mock response.

route.abort() simulates a network failure — the request is terminated with no response. Use it when: (a) testing offline behaviour — what does the application display when the API is unreachable; (b) testing graceful degradation — does the UI show a meaningful error message instead of a blank page; (c) testing retry logic — does the application retry the request with the correct backoff strategy. Example: await page.route('**/api/products', route => route.abort('internetdisconnected')) — simulates a network failure for the products API. The application should display 'Unable to load products. Check your connection and try again.' — and the test should assert that message appears.

route.continue() allows the request to proceed to the real server — optionally modified. Use it when: (a) you need to modify request headers — adding authentication tokens, changing User-Agent strings; (b) you need to modify the response — stripping sensitive data, injecting test attributes; (c) you need to log or measure requests while still hitting the real backend.

The strategic distinction: route.fulfill() decouples the test from the backend entirely — the test controls the response. route.abort() verifies that the application handles failure gracefully. route.continue() passes through to the real backend while giving you observation and modification points. The interviewer wants to hear that you can choose the right interception strategy based on what you are testing — frontend behaviour, error handling, or true end-to-end integration.

Q6: How does visual comparison testing work in Playwright with toHaveScreenshot — and what makes it different from pixel-diff tools?

What the interviewer is testing: Whether you understand visual testing as a quality gate — including the failure modes, configuration, and maintenance strategy.

Model answer: Playwright's toHaveScreenshot() assertion captures a screenshot of an element or page and compares it to a stored reference screenshot (a 'golden image'). If the pixel difference exceeds a configurable threshold, the test fails. The comparison is performed by a pixelmatch-based diffing algorithm that identifies exactly which pixels changed — and Playwright generates a diff image highlighting the changed regions, stored alongside the test results.

What makes Playwright's visual testing production-grade — and different from simple pixel-diff tools — is: (1) Built-in anti-flakiness: Playwright waits for the page to reach a stable state before capturing the screenshot — no animations in progress, no pending network requests, no incomplete font loads. Pixel-diff tools that capture screenshots without these guarantees produce flaky results because they capture frames mid-transition. (2) Configurable thresholds: maxDiffPixelRatio (default 0 — any difference fails) and threshold (colour difference per pixel, 0-1) let you control sensitivity. A threshold of 0.02 means a 2% colour difference is permitted — tolerating anti-aliasing differences across operating systems and rendering engines without ignoring genuine visual regressions. (3) Masking: mask: [page.locator('.timestamp')] excludes dynamic elements (timestamps, random IDs, ads, personalised content) from the comparison — so a changing timestamp does not fail your visual test. (4) Snapshot naming and storage: Screenshots are stored in a deterministic file structure — test-name-project-browser-platform.png — enabling cross-platform comparison and CI-stored baselines. (5) Update mode: --update-snapshots flag regenerates all golden images in one command — useful after an intentional UI redesign.

At Asda, Mitchell's team added toHaveScreenshot() assertions to their checkout flow — capturing the cart, the delivery slot selector, the payment form, and the confirmation page. Within the first sprint, visual testing caught a regression where a CSS change to the button component had shifted the 'Place Order' button 4 pixels to the right — invisible to functional tests (the button still worked, the text was correct), but a visual regression that would have reached production. The pixel-diff highlighted the shift immediately — and the developer fixed it in 5 minutes instead of discovering it through a customer complaint two weeks later. Visual testing catches the category of bugs that functional testing cannot — because the functionality works, but the presentation is broken.

Q7: How do Playwright fixtures and test hooks work — and how are they different from beforeEach/afterEach in Jest?

What the interviewer is testing: Whether you understand Playwright's test runner architecture — including fixture dependency injection, worker-scoped fixtures, and the test isolation model.

Model answer: Playwright's test runner is built on a fixture system that is fundamentally different from Jest's setup/teardown hooks. The key concept is dependency injection: a test declares what it needs, and the runner provides it — managing the lifecycle automatically.

In Jest, you write:

let browser: Browser;
beforeEach(async () => {
  browser = await chromium.launch();
});
afterEach(async () => {
  await browser.close();
});
test('login flow', async () => {
  const page = await browser.newPage();
  // test logic
});

The problems: (1) You manually manage the lifecycle — if you forget afterEach, browsers stay open. (2) Every test gets the same setup — you cannot configure a test to use a different browser or authenticated session without conditional logic in beforeEach. (3) The test is responsible for creating its own page object — duplicate boilerplate in every test.

In Playwright, the equivalent:

import { test, expect } from '@playwright/test';
test('login flow', async ({ page }) => {
  // page is auto-created, auto-navigated, auto-closed
  await page.goto('/login');
  // test logic
});

The { page } parameter is a fixture — Playwright's test runner creates a new page in a new browser context, injects it into the test, and tears it down when the test completes. The test never sees the browser, context, or page lifecycle. This is the built-in page fixture — one of several built-in fixtures (browser, browserName, context, page, request).

Custom fixtures extend this pattern. Example — an authenticated page fixture:

const test = base.extend<{ authenticatedPage: Page }>({
  authenticatedPage: async ({ browser }, use) => {
    const context = await browser.newContext();
    const page = await context.newPage();
    await page.goto('/login');
    await page.fill('[name="email"]', 'test@example.com');
    await page.fill('[name="password"]', 'password');
    await page.click('button[type="submit"]');
    await expect(page).toHaveURL('/dashboard');
    await use(page);
    await context.close();
  },
});

test('view profile', async ({ authenticatedPage }) => {
  await authenticatedPage.click('text=Profile');
  await expect(authenticatedPage).toHaveURL('/profile');
});

Key differences from Jest hooks: (1) Fixture scope: Playwright fixtures can be test-scoped (created per test) or worker-scoped (created once per worker and shared across tests in that worker — e.g., a database connection). Jest's beforeAll/afterAll is the closest equivalent but lacks the dependency-injection pattern. (2) Fixture composition: fixtures can depend on other fixtures — authenticatedPage depends on browser, which Playwright resolves automatically. In Jest, you would need to chain beforeAll hooks or manage dependencies manually. (3) Test declaration: the test declares its dependencies through parameters. A test that needs an authenticated page includes { authenticatedPage }; a test that does not need authentication omits it — and the authentication fixture is never created. This is compile-time dependency selection, not runtime conditional logic. (4) Automatic teardown: the use() pattern provides setup/teardown around a test — code before use(page) is setup, code after is teardown, executed regardless of test failure. In Jest, teardown in afterEach must handle the case where setup partially completed — a common source of flaky test infrastructure.

The interviewer wants to hear that you understand fixtures as a dependency-injection pattern — not a setup/teardown mechanism. The candidate who says 'fixtures are like beforeEach' has used Playwright's test runner. The candidate who says 'fixtures are a dependency-injection system with automatic lifecycle management and scope control' understands its architecture.