Playwright Interview Questions and Answers PDF: 30 Questions to Revise

1. Open this article on a laptop or desktop.
2. Press Ctrl+P (Windows/Linux) or Cmd+P (Mac).
3. Choose Save as PDF as the destination and click Save.

On a phone, use the browser's Share menu and choose Print, then save. You get all 30 questions below in one file you can read on the train or mark up before your interview.

If you prefer a laid-out document with more questions and deeper explanations, these PDFs exist in our library. Each page shows a free preview of the opening pages before you decide:

• Playwright Interview Questions — 21 pages.
• Playwright Interview Questions — Advanced Edition — 20 pages, 18 advanced questions with TypeScript examples.
• Playwright: 30 Interview Questions and Answers — 13 pages.

These are part of the paid QA Notes Vault, not free downloads; the current price is shown on each page. Start with Option A. If you find yourself wanting more depth after working through it, the Vault PDFs are the next step.

A PDF is a revision tool, not a replacement for practice. Read one section, close the file, and explain each answer out loud in your own words. Then write the code example in a real project and run it. Interviewers can usually tell within a minute whether a candidate has memorised a list or has actually used the tool.

Answer: Playwright is an open-source framework from Microsoft for end-to-end testing of web applications. One API drives Chromium, Firefox and WebKit, and it supports TypeScript/JavaScript, Python, Java and .NET. Playwright Test is its built-in test runner, with parallel execution, fixtures, retries, reports and tracing included.

Answer: The main reasons are built-in auto-waiting, which removes most manual waits; fast, isolated browser contexts; a full test runner in the box; and strong debugging tools such as the trace viewer and UI mode. Selenium is still a good choice when a team has a large existing Java suite or needs a browser Playwright doesn't support. A balanced answer mentions both sides. Our Cypress vs Playwright comparison covers the trade-offs in more detail.

Answer: A browser is one running browser process. A browser context is an isolated session inside it, like a fresh incognito profile with its own cookies and storage. A page is a single tab inside a context. Playwright Test gives every test a new context, so tests don't share login state or cookies.

Answer: Run npm init playwright@latest, which creates the config, an example test and installs browsers. Then run npx playwright test. Use npx playwright test --ui for UI mode or --headed to watch the browser.

Answer: It holds shared settings: the test directory, timeouts, retries, number of workers, reporters, the base URL, and projects (for example one per browser or device). Keeping these settings in config rather than in tests makes the suite consistent and easy to change.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  retries: process.env.CI ? 2 : 0,
  use: { baseURL: 'https://staging.example.com', trace: 'on-first-retry' },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
  ],
});

Answer: Headless means the browser runs without a visible window. It is the default for Playwright Test and is faster, so it suits CI. You run headed (--headed) when you want to watch a test locally.

Answer: User-facing locators first: getByRole, getByLabel, getByPlaceholder, getByText, then getByTestId as a stable fallback. CSS and XPath still work but break more easily when the page structure changes. The locators guide lists this order.

await page.getByRole('button', { name: 'Sign in' }).click();
await page.getByLabel('Email').fill('qa@example.com');
await page.getByTestId('cart-count');

Answer: A Locator is a description of how to find an element; Playwright finds it again every time you act on it, so it survives re-renders. An ElementHandle points to one specific DOM node and can go stale. Use locators; element handles are discouraged for normal tests.

Answer: Before an action like click(), Playwright checks that the element is attached, visible, stable (not animating), enabled and able to receive events. It retries these checks until they pass or the timeout ends. This removes most need for manual waits.

Answer: A fixed sleep either waits too long, slowing the suite, or not long enough, causing random failures. It waits for time, not for a condition. Replace it with an action that auto-waits or a web-first assertion such as await expect(locator).toBeVisible().

Answer: Narrow down with filtering instead of index-based XPath:

const row = page.getByRole('row').filter({ hasText: 'Order #1042' });
await row.getByRole('button', { name: 'Cancel' }).click();

Use .first(), .last() or .nth() only when position really is the thing being tested.

Answer: If a locator matches more than one element when you perform an action, Playwright throws an error instead of guessing. This protects you from clicking the wrong element. The fix is a more specific locator, not turning the check off. For hands-on practice, our Playwright locators guide goes deeper.

Answer: Assertions like toBeVisible, toHaveText and toHaveURL that retry automatically until the condition is true or the timeout ends. Because the page may still be updating, retrying assertions are far more reliable than reading a value once and comparing it.

await expect(page.getByRole('alert')).toHaveText('Saved');
await expect(page).toHaveURL(/\/dashboard/);

Answer: expect.soft() records a failure but lets the test continue, so you see several problems in one run. The test is still marked as failed at the end. It is useful for checking many fields on one page.

Answer: The first reads visibility once with no retry, so it fails if the element appears a moment later. The second keeps retrying until the timeout. This is one of the most common interview "spot the bug" questions.

Answer: Use expect.poll, which calls a function repeatedly until its value matches:

await expect.poll(async () => {
  const res = await request.get('/api/reports/55');
  return (await res.json()).status;
}, { timeout: 30_000 }).toBe('ready');

Answer: A fixture is a piece of setup a test asks for by name, like page, context or request. Fixtures set up only what a test needs and clean up after it automatically. You can create your own with test.extend.

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

export const test = base.extend<{ loginPage: LoginPage }>({
  loginPage: async ({ page }, use) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await use(loginPage);
  },
});

Answer: Hooks are fine for simple setup inside one file. Fixtures are better for shared setup because they are reusable, run only when a test needs them, and keep setup and teardown together. Many teams use both. The fixtures deep dive shows worked examples.

Answer: A pattern where each page or component gets a class holding its locators and actions, such as login(email, password). Tests then read like user steps, and when the page changes you update one class instead of many tests.

Answer: Mostly no. Keeping assertions in the test makes it clear what each test checks. A small helper such as expectLoaded() is acceptable when the same check is used everywhere.

Answer: Log in once in a setup project, save the session with storageState, and load that file in other tests. This saves time and keeps the login flow tested in one place.

// auth.setup.ts
await page.getByLabel('Email').fill(process.env.QA_USER!);
await page.getByLabel('Password').fill(process.env.QA_PASS!);
await page.getByRole('button', { name: 'Sign in' }).click();
await page.context().storageState({ path: 'playwright/.auth/user.json' });

Answer: Yes. The request fixture sends HTTP requests without a browser. It is useful for pure API tests and for creating test data quickly before a UI test.

test('creates a user', async ({ request }) => {
  const res = await request.post('/api/users', { data: { name: 'Asha' } });
  expect(res.status()).toBe(201);
  expect((await res.json()).name).toBe('Asha');
});

Answer: Use page.route() to intercept a request and return your own data. This helps test error states or empty lists that are hard to create on a real server.

await page.route('**/api/orders', route =>
  route.fulfill({ status: 500, json: { error: 'Server error' } })
);
await page.goto('/orders');
await expect(page.getByText('Something went wrong')).toBeVisible();

Answer: Start waiting before the action, then await the result, so you never miss a fast response:

const responsePromise = page.waitForResponse('**/api/search*');
await page.getByRole('button', { name: 'Search' }).click();
const response = await responsePromise;
expect(response.ok()).toBeTruthy();

To practise API questions against a real endpoint, try the free API Playground.

Answer: The runner starts several worker processes. By default, test files run in parallel and tests inside a file run in order. Setting fullyParallel: true runs individual tests in parallel too. Parallel runs only work well when tests don't share data or accounts.

Answer: Splitting the suite across machines with --shard=1/4, --shard=2/4 and so on. Each machine runs a part, and the blob reports can be merged into one HTML report with npx playwright merge-reports.

Answer: Turn on tracing for retries (trace: 'on-first-retry'), download the trace from the CI artifacts and open it with npx playwright show-trace. The trace shows each action, DOM snapshots, network calls and console logs, which usually reveals timing or data problems. Locally, --debug and UI mode let you step through.

Answer: Find the cause instead of hiding it. Common causes are fixed sleeps, shared test data, weak locators and assertions that don't retry. Retries can keep CI moving while you fix things, but a test that passes only on retry should be tracked and fixed, not ignored.

Answer: For upload, use setInputFiles on the file input. For download, start waiting for the download event before clicking, then check the file name:

await page.getByLabel('Upload invoice').setInputFiles('fixtures/invoice.pdf');

const downloadPromise = page.waitForEvent('download');
await page.getByRole('button', { name: 'Export CSV' }).click();
const download = await downloadPromise;
expect(download.suggestedFilename()).toContain('.csv');

Answer: Wait for the new page event on the context before the click that opens it, then work with the new page like any other:

const pagePromise = page.context().waitForEvent('page');
await page.getByRole('link', { name: 'Open help' }).click();
const helpPage = await pagePromise;
await expect(helpPage).toHaveTitle(/Help/);

Scenario questions test whether you can turn a requirement into steps and pick the right API. Talk through your thinking before writing code.