Playwright Interview Questions for Experienced QA and SDETs (25 with Answers)

Answer: Playwright talks to browsers over a persistent connection using each engine's debugging protocol (Chromium's CDP, and patched protocols for Firefox and WebKit), rather than sending a separate HTTP request per command as classic WebDriver does. Commands and browser events flow over one channel, which reduces round trips and lets Playwright listen to network and page events directly. Speed in real suites also comes from auto-waiting (fewer manual waits and retries) and cheap browser contexts for isolation. I'd avoid saying it is "always faster"; slow apps and bad tests are slow in any tool.

Answer: A browser context is an isolated session inside one browser instance — like a fresh incognito profile with its own cookies, storage and cache. Creating one takes milliseconds, so Playwright Test gives every test a new context by default. That isolation is what makes parallel tests safe, and it lets one test simulate two users at once.

test('admin approval reaches the user', async ({ browser }) => {
  const adminCtx = await browser.newContext({ storageState: 'playwright/.auth/admin.json' });
  const userCtx = await browser.newContext({ storageState: 'playwright/.auth/user.json' });
  const admin = await adminCtx.newPage();
  const user = await userCtx.newPage();

  await admin.goto('/admin/requests');
  await admin.getByRole('row', { name: /REQ-204/ }).getByRole('button', { name: 'Approve' }).click();

  await user.goto('/requests/REQ-204');
  await expect(user.getByText('Approved')).toBeVisible();

  await adminCtx.close();
  await userCtx.close();
});

Answer: The runner starts several worker processes (controlled by workers). Each worker is a separate OS process with its own browser. By default, files run in parallel and tests inside a file run in order in the same worker; fullyParallel: true lets tests within a file run in parallel too. Workers never share memory, so anything shared — a database row, a user account, a file — must be isolated by the test design, not by the tool.

Answer: Before an action such as click(), Playwright runs actionability checks — the element is attached, visible, stable, enabled and receives events — and retries until they pass or the timeout ends. Web-first assertions such as toBeVisible() or toHaveText() also retry. It does not help when the test checks the wrong thing: reading a value once with textContent() and asserting on it, or racing a background job the UI doesn't show. In those cases I wait on a real signal: an assertion, a response, or polling with expect.poll().

// Poll an API until a background job finishes
await expect.poll(async () => {
  const res = await request.get('/api/exports/77');
  return (await res.json()).status;
}, { timeout: 30_000 }).toBe('done');

Answer: I'd choose Playwright when the team needs Chromium, Firefox and WebKit coverage, multiple tabs or users in one test, built-in parallelism and traces, and is comfortable in TypeScript or another supported language. Selenium still makes sense for large existing Java suites or grids, and Cypress for teams already invested in its ecosystem. The deciding factors are team skills, existing investment and browser needs — not hype. Our Playwright vs Selenium comparison covers the details.

Answer: I use clear layers, each with one job:

• Config — environments, projects per browser or device, reporters, retries.
• Fixtures — signed-in pages, API clients, test data with cleanup.
• Page objects / components — locators and user actions, no test logic.
• Test data builders — unique, valid data created through the API.
• Tests — short, readable, tagged (@smoke, @regression).
• CI — sharded runs, merged reports, artefacts on failure.

I keep the folder structure by feature, not by file type, once the suite grows past a few hundred tests, so a team owns its folder end to end.

Answer: Fixtures. They are set up only for tests that ask for them, they bundle setup and teardown in one place (code after use() always runs), they compose (a fixture can depend on other fixtures), and they can be test-scoped or worker-scoped. Hooks run for every test in scope whether needed or not, and teardown is easy to forget.

import { test as base } from '@playwright/test';
import { CheckoutPage } from './pages/checkout-page';

type Fixtures = { checkout: CheckoutPage };

export const test = base.extend<Fixtures>({
  checkout: async ({ page }, use) => {
    const checkout = new CheckoutPage(page);
    await checkout.open();
    await use(checkout);
  },
});
export { expect } from '@playwright/test';

More patterns are in our Playwright fixtures deep dive.

Answer: It is created once per worker process and shared by all tests that worker runs. I use it for expensive, read-only setup — for example, one test account per worker, so parallel workers never fight over the same user.

export const test = base.extend<{}, { workerUser: { email: string } }>({
  workerUser: [async ({}, use, workerInfo) => {
    const email = `qa+w${workerInfo.workerIndex}@example.com`;
    // create or reset the account through the API here
    await use({ email });
  }, { scope: 'worker' }],
});

Answer: Mostly no. Page objects should describe what a user can do (addToCart(), applyCoupon()) and expose locators; the test decides what to check. Hiding assertions in page objects makes failures harder to read and tests harder to reuse. A small exception I allow: a waitUntilLoaded() method that asserts the page is ready, because that is navigation, not the behaviour under test. I also avoid deep inheritance; composition of small component objects (header, table, modal) ages better. See our Page Object Model in TypeScript guide.

Answer: Every test creates the data it needs through the API, with unique values, and removes it in fixture teardown. Shared seed data is read-only. For things that are slow to create, I use worker-scoped fixtures. I never depend on the order tests run in. This is what makes fullyParallel and sharding safe.

Answer: I measure first: the HTML report and a JSON reporter show the slowest tests and files. Then, in order of impact:

1. Replace UI login with storageState from a setup project.
2. Create data through the API instead of clicking through the UI.
3. Remove fixed waits.
4. Make tests independent, then enable fullyParallel.
5. Shard across CI machines with --shard.
6. Run a fast @smoke subset on every pull request and the full suite on merge or nightly.

I'd also check whether some UI tests should really be API or component tests.

Answer: npx playwright test --shard=1/4 runs a quarter of the tests on one machine. Each shard writes a blob report, and a final job merges them.

# GitHub Actions (simplified)
strategy:
  matrix:
    shard: [1/4, 2/4, 3/4, 4/4]
steps:
  - run: npx playwright test --shard=${{ matrix.shard }} --reporter=blob
  - uses: actions/upload-artifact@v4
    with: { name: blob-${{ strategy.job-index }}, path: blob-report }
# merge job:
#   npx playwright merge-reports --reporter=html ./all-blob-reports

With fullyParallel on, sharding splits at test level, which balances shards better than file-level splitting.

Answer: Start with the CPU count of the CI machine (or half of it for heavy apps), then measure. More workers stop helping when the machine or the test environment becomes the bottleneck — CPU, memory, or a backend that can't handle the load — and flakiness rises. Often the better move is more shards on more machines rather than more workers on one.

Answer: Read the environment from a variable and use projects for browser and device coverage. Each project can have its own use settings and test filters.

export default defineConfig({
  use: { baseURL: process.env.BASE_URL, trace: 'on-first-retry' },
  projects: [
    { name: 'setup', testMatch: /.*\.setup\.ts/ },
    { name: 'chromium', use: { ...devices['Desktop Chrome'], storageState: 'playwright/.auth/user.json' }, dependencies: ['setup'] },
    { name: 'mobile-safari', use: { ...devices['iPhone 13'], storageState: 'playwright/.auth/user.json' }, dependencies: ['setup'], grep: /@smoke/ },
  ],
});

Answer: The HTML report, traces and screenshots for failures (trace: 'on-first-retry', screenshot: 'only-on-failure'), and a JUnit or JSON report for dashboards. Over time I track total runtime, pass rate, and the list of tests marked flaky. Artefacts are what let anyone debug a CI failure without rerunning it.

Answer: I treat flakiness as a tracked number. Playwright labels tests that fail then pass on retry as flaky; I collect that from reports each week. The top offenders get an owner and a fix date. If a test can't be fixed quickly, I quarantine it with a tag so it runs separately and doesn't block merges, with a limit on how long it can stay there. Retries stay low (1–2 in CI) so they reveal problems instead of hiding them.

Answer: In my experience: checking state too early instead of using web-first assertions; shared test data between parallel tests; tests depending on run order; animations and timers; third-party services in the path; and environments that are slow or under-resourced. Naming causes in this order — test design first, environment second — shows you look at your own code before blaming the tool.

Answer: Use toHaveScreenshot() on a small set of stable, high-value pages or components, not every screen. Mask dynamic content, disable animations, generate baselines in the same OS and browser as CI (usually a Docker image), and allow a small pixel threshold.

await expect(page).toHaveScreenshot('pricing.png', {
  mask: [page.getByTestId('live-clock')],
  animations: 'disabled',
  maxDiffPixelRatio: 0.01,
});

Our visual regression testing guide goes deeper.

Answer: Role-based locators already push tests toward accessible markup. For automated rule checks, I use the @axe-core/playwright package on key pages and fail on serious or critical violations. Automated checks catch only part of accessibility issues, so I say clearly that they complement, not replace, manual review.

import AxeBuilder from '@axe-core/playwright';

test('checkout has no serious a11y violations', async ({ page }) => {
  await page.goto('/checkout');
  const results = await new AxeBuilder({ page }).withTags(['wcag2a', 'wcag2aa']).analyze();
  const serious = results.violations.filter((v) => ['serious', 'critical'].includes(v.impact ?? ''));
  expect(serious).toEqual([]);
});

Answer: UI tests are the slowest and most fragile, so I keep them for critical user journeys and things only the browser can prove — rendering, navigation, integration of front end and back end. Business rules with many combinations go to API or unit tests. I use Playwright's API testing for setup and for many backend checks; see our Playwright API testing interview questions.

Answer: Extend expect with expect.extend(). I do this for domain checks repeated across many tests, so failures read in business terms.

import { expect as base, Locator } from '@playwright/test';

export const expect = base.extend({
  async toHavePrice(locator: Locator, expected: number) {
    const text = (await locator.textContent()) ?? '';
    const actual = Number(text.replace(/[^0-9.]/g, ''));
    return {
      pass: actual === expected,
      message: () => `expected price ${expected}, got ${actual} ("${text}")`,
      name: 'toHavePrice',
    };
  },
});

Answer: For flags, I set them per test through an API or by mocking the flag service response with page.route(), so both states are covered. For time, Playwright's page.clock API can install a fake clock and set or advance time, which removes real waits for countdowns and session timeouts.

await page.clock.install({ time: new Date('2026-01-01T09:00:00') });
await page.goto('/session');
await page.clock.fastForward('30:00');
await expect(page.getByText('Your session has expired')).toBeVisible();

Answer: Not with a big-bang rewrite. I'd start new tests in Playwright, migrate the most flaky or most valuable Selenium tests first, run both suites side by side in CI, and retire Selenium tests as Playwright equivalents prove stable. I'd agree locator and fixture conventions up front, pair with team members during the first weeks, and track runtime and flaky rate before and after, so the decision rests on data from our own suite.

Answer: I check that the test is independent and creates its own data; locators are user-facing, not CSS chains; there are no fixed waits or force: true without a comment; assertions check behaviour, not implementation; and the test name says what it proves. I also run it locally with --repeat-each=10 to catch flakiness before it reaches main.

Answer: This is a judgement question, so answer from your own work. A good shape: the decision ("we put assertions inside page objects"), the problem it caused ("failures were hard to read and tests were hard to reuse"), what you changed ("moved assertions into tests, kept page objects as actions"), and the result you actually measured. If you don't have a measured result, say what you observed — interviewers value honesty over polished numbers.