21 Playwright Interview Questions & Answers (2026)

Playwright has become one of the most requested automation skills in new QA job descriptions, and interviewers now test it in depth. These Playwright interview questions cover fundamentals, locators, auto-waiting, fixtures, configuration, network mocking, API testing, debugging and real scenarios — with short answers and TypeScript examples you can explain confidently in 2026.

If you are deciding between tools, first read our Playwright vs Selenium vs Cypress comparison. For classic WebDriver rounds, revise the Selenium interview questions as well — many interviews ask both.

Key takeaways

• Expect questions on why Playwright tests are less flaky: auto-waiting, actionability checks, web-first assertions and isolated browser contexts.
• Know user-facing locators (getByRole, getByLabel, getByText, getByTestId) and when to use each.
• Be ready to explain playwright.config, fixtures, projects, retries, traces and CI setup from your own project.

Basic Playwright interview questions

1. What is Playwright?

Playwright is an open-source end-to-end testing framework from Microsoft. It automates Chromium, Firefox and WebKit with a single API, supports JavaScript/TypeScript, Python, Java and .NET, and ships a built-in test runner (Playwright Test) for JS/TS with parallel execution, reporters, retries and tracing.

2. What are Browser, BrowserContext and Page?

A Browser is a launched browser instance. A BrowserContext is an isolated, incognito-like session inside it with its own cookies and storage — Playwright Test creates a fresh context for every test, which keeps tests independent. A Page is a single tab within a context. Multiple contexts let you simulate two users (for example, a buyer and a seller) in one test.

3. What is auto-waiting?

Before performing an action such as click() or fill(), Playwright automatically waits until the element is attached, visible, stable (not animating), enabled and able to receive events. This removes most explicit waits and sleeps that cause flakiness in other tools.

4. What are web-first assertions?

Assertions such as expect(locator).toBeVisible(), toHaveText() and toHaveURL() automatically retry until the condition passes or the timeout expires. Avoid patterns like expect(await locator.isVisible()).toBe(true), which check once and do not retry.

await page.getByRole('button', { name: 'Add to cart' }).click();
await expect(page.getByTestId('cart-count')).toHaveText('1');

Locator questions

5. Which locators does Playwright recommend?

Playwright recommends user-facing locators in this rough order: getByRole (with an accessible name), getByLabel, getByPlaceholder, getByText, getByAltText, getByTitle and getByTestId. CSS and XPath are supported through page.locator() but are more fragile because they depend on DOM structure.

6. What is the difference between a Locator and an ElementHandle?

A Locator is lazy: it describes how to find an element and re-queries the DOM every time you use it, so it handles re-renders. An ElementHandle points to one specific DOM node and can become stale. Playwright discourages ElementHandles in favour of Locators.

7. How do you handle multiple matching elements?

Locators are strict: an action on a locator that matches more than one element throws an error. Narrow it with filter({ hasText }), chain from a parent locator, or use first(), last() or nth(index) when position is genuinely what you want.

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

8. How do you work with iframes and new tabs?

Use page.frameLocator(‘#payment-frame’) and then locate elements inside it. For a new tab, wait for the context’s page event while clicking the link:

const [newPage] = await Promise.all([
  context.waitForEvent('page'),
  page.getByRole('link', { name: 'Open invoice' }).click(),
]);
await expect(newPage).toHaveURL(/invoice/);

Playwright Test runner, fixtures and configuration

9. What is playwright.config.ts used for?

It holds global settings: testDir, timeout, retries, number of workers, reporters (list, html, junit, allure), the use block (baseURL, headless, viewport, trace, screenshot, video) and projects to run the same tests across Chromium, Firefox, WebKit or mobile device profiles.

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

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

10. What are fixtures?

Fixtures provide each test with what it needs — built-in ones include page, context, browser and request. You can create custom fixtures with test.extend() to supply logged-in pages, Page Objects or test data, with setup and teardown handled automatically. Fixtures replace much of the beforeEach/afterEach code you would write elsewhere.

11. How do you avoid logging in before every test?

Log in once in a setup project, save the session with page.context().storageState({ path: ‘auth.json’ }), and configure other projects with use: { storageState: ‘auth.json’ } and a dependency on the setup project. Every test then starts already authenticated.

12. How does parallel execution work?

Playwright Test runs test files in parallel across worker processes by default. Inside a file, tests run in order unless you enable test.describe.configure({ mode: ‘parallel’ }) or fullyParallel: true. In CI you can also split the suite across machines with the –shard option, for example –shard=1/4.

13. How do you implement the Page Object Model?

Create a class per page that receives the Page in its constructor, defines locators as readonly properties and exposes actions such as login(email, password). Inject Page Objects through custom fixtures so tests stay short and readable.

Network, API and debugging questions

14. How do you mock or intercept network requests?

await page.route('**/api/products', route =>
  route.fulfill({ status: 200, json: [{ id: 1, name: 'Test Phone' }] })
);
await page.goto('/products');
await expect(page.getByText('Test Phone')).toBeVisible();

page.route() can fulfil, modify, abort or continue requests — useful to test error states (500 responses), empty lists or slow APIs without changing the backend. page.waitForResponse() lets you assert on real responses.

15. Can Playwright do API testing?

Yes. The request fixture (APIRequestContext) sends HTTP calls directly — great for API tests, creating test data before a UI test, or cleaning up afterwards. Responses can be checked with expect(response).toBeOK() and by parsing response.json(). For dedicated API suites, also see our API testing interview questions.

16. How do you debug a failing test?

• UI mode (npx playwright test –ui) to watch, step through and re-run tests.
• –debug flag or await page.pause() to open the Playwright Inspector.
• Trace Viewer (npx playwright show-trace trace.zip) to inspect every action, DOM snapshot, console log and network call — especially for CI failures.
• Codegen (npx playwright codegen URL) to record actions and suggest locators.

Scenario-based Playwright interview questions

1. Tests pass locally but fail in CI. Enable traces on retry, check baseURL and environment variables, viewport and headless differences, shared test data between parallel workers, and missing browser dependencies (install with npx playwright install –with-deps).
2. A test is flaky. Replace manual waits with web-first assertions, use stricter role-based locators, isolate test data per worker and investigate the trace instead of simply raising timeouts or retries.
3. Test a file download. Wait for the download event while clicking, then use download.suggestedFilename() and download.saveAs() to verify the file.
4. Visual regression. Use expect(page).toHaveScreenshot() to compare against baseline images, masking dynamic areas such as dates.
5. Run tests in Jenkins or GitHub Actions. Install dependencies with npm ci, install browsers, run npx playwright test, publish the HTML report and traces as build artefacts.

The official Playwright documentation is excellent and worth reading section by section before your interview.

FAQs

Which language is best for Playwright interviews?

TypeScript is the most common in job descriptions because the Playwright Test runner is built for JS/TS. Java and Python versions are used too, mostly in teams migrating from Selenium.

Do I need JavaScript knowledge for Playwright?

For the TypeScript flavour, yes: async/await, promises, arrow functions, modules and basic types. These topics are often asked alongside Playwright interview questions.

Is Playwright good for freshers to learn?

Yes. Its built-in tooling makes it beginner-friendly, and Playwright skills are increasingly listed in fresher and junior automation openings.

Can Playwright test mobile apps?

Playwright emulates mobile browsers (viewport, user agent, touch) but does not automate native Android or iOS apps. Use Appium for native mobile apps.

Conclusion

Use these Playwright interview questions to revise concepts, then prove them with a small GitHub project that includes Page Objects, fixtures, API calls, network mocking and a CI workflow. When you are ready, check today’s QA jobs and apply to roles that list Playwright.