Top 20 Playwright Interview Questions & Answers (2026)
These are the Playwright questions that actually come up in automation and SDET interviews, grouped by topic. Each answer is short enough to revise quickly, with TypeScript code where interviewers expect you to show syntax, and a link to the full tutorial. For the complete learning path, start with The Complete Playwright Tutorial.
Fundamentals (Q1–5)
1. What is Playwright?
An open-source browser automation and testing framework from Microsoft. One API drives Chromium, Firefox and WebKit, and Playwright Test adds a test runner, web-first assertions, parallel execution, API testing, network mocking and a trace viewer.
2. Why use Playwright over older tools?
Built-in auto-waiting (far less flakiness), a built-in runner with parallelism and retries, isolated browser contexts per test, UI and API testing in one framework, and excellent debugging tools (UI mode, trace viewer, codegen).
3. Which browsers and languages does Playwright support?
Browsers: Chromium (Chrome, Edge), Firefox and WebKit (the Safari engine), plus mobile device emulation. Languages: JavaScript/TypeScript, Python, Java and .NET. Playwright Test — the runner with fixtures, projects and the HTML report — is the Node.js version.
4. What's the difference between headless and headed mode?
Headless runs without a visible window — faster and standard in CI. Headed (npx playwright test --headed) shows the browser, which helps when debugging.
5. How is Playwright different from Selenium?
Playwright auto-waits, includes its own runner and assertions, isolates each test in a fresh browser context, and has built-in API testing and mocking. Selenium needs explicit waits and external libraries (TestNG, REST Assured), but supports more languages and real browser brands, and has a larger ecosystem.
Auto-Wait & Synchronisation (Q6–9) ⭐
6. What is auto-wait?
Before every action, Playwright automatically waits until the element is ready to be acted on. It's the single biggest reason Playwright tests are less flaky than hand-synchronised Selenium tests.
7. What exactly does Playwright wait for?
Its actionability checks: the element is attached to the DOM, visible, stable (not animating), enabled, and receives events (not covered by another element). Different actions check different subsets — fill(), for example, also requires the element to be editable.
8. waitForTimeout vs web-first assertions — what should you use?
page.waitForTimeout() is a hard-coded pause — avoid it. Wait for a condition instead, preferably with a web-first assertion, which retries until it passes or times out:
// ❌ Fixed pause
await page.waitForTimeout(3000);
// ✅ Condition-based
await expect(page.getByTestId('result')).toBeVisible();
await page.waitForURL('**/dashboard');
Older answers mention waitForSelector(); Playwright's docs now recommend locators and assertions instead.
9. Do you still need explicit waits?
Rarely. Auto-wait and assertions cover most cases. You still wait explicitly for things Playwright can't infer — a specific API response, a download, a new tab:
const responsePromise = page.waitForResponse(r => r.url().includes('/api/users'));
await page.getByRole('button', { name: 'Load users' }).click();
await responsePromise;
Locators & Actions (Q10–12)
10. Which locators does Playwright recommend?
User-facing locators, in roughly this order: getByRole, getByLabel, getByPlaceholder, getByText, then getByTestId, with CSS/XPath as a last resort. They mirror how users and assistive technology see the page, so they survive refactors.
await page.getByRole('button', { name: 'Log in' }).click();
await page.getByLabel('Email').fill('qa@example.com');
11. What is locator strictness?
If a locator matches more than one element, actions throw an error instead of guessing. You fix it by making the locator specific — scoping, filter(), or first()/nth() when order genuinely doesn't matter.
page.getByRole('row').filter({ hasText: 'Ravi' }).getByRole('button', { name: 'Edit' });
12. How do you handle alerts and new tabs?
Register a dialog handler before the action that triggers it, and wait for the new page event when a link opens a tab:
page.once('dialog', dialog => dialog.accept());
await page.getByRole('button', { name: 'Delete' }).click();
const [newTab] = await Promise.all([
context.waitForEvent('page'),
page.getByRole('link', { name: 'Help' }).click(),
]);
await expect(newTab).toHaveURL(/help/);
Test Runner (Q13–15)
13. What is test.describe() used for?
Grouping related tests so they share hooks (beforeEach, afterEach), configuration and a title prefix in reports.
14. How do you run tests in parallel?
Playwright runs test files in parallel across worker processes by default. Set fullyParallel: true to parallelise tests within a file too, and control the count with workers in the config or --workers on the command line. Each test gets its own browser context, so parallel tests don't share cookies or storage.
15. What's the difference between test.only(), test.skip() and test.fixme()?
only runs just that test (never commit it), skip skips it, and fixme marks it as known-broken and skips it. test.slow() triples the timeout.
Auth & API (Q16–18) ⭐
16. What is storage state, and why does it matter?
It's a saved snapshot of cookies and local storage after logging in. A setup project logs in once and saves it; other projects load it, so every test starts already logged in — often the biggest speed win in a suite.
await page.context().storageState({ path: 'playwright/.auth/user.json' });
17. What's the difference between cookies and local storage?
Cookies are sent to the server with every matching request and can expire. Local storage stays in the browser, is only read by JavaScript, and persists until cleared. Storage state saves both.
18. Can Playwright test APIs and mock network calls?
Yes. The request fixture sends HTTP calls directly, and page.route() intercepts the browser's own requests — useful for testing error handling you can't trigger on a real backend:
await page.route('**/api/products', route =>
route.fulfill({ status: 500, json: { error: 'Server error' } }));
await page.goto('/products');
await expect(page.getByText('Something went wrong')).toBeVisible();
→ API Testing & Network Mocking
Debugging & Architecture (Q19–20)
19. What is the trace viewer?
A post-run debugging tool that shows a timeline of every action with DOM snapshots before and after, network requests, console logs and screenshots. With trace: 'on-first-retry', CI failures come with a trace you can open with npx playwright show-trace or from the HTML report.
20. How does Playwright's architecture differ from Selenium's?
Selenium sends each command as an HTTP request to a separate driver (ChromeDriver, GeckoDriver), which controls the browser. Playwright keeps a persistent WebSocket connection to the browser and uses browser-level protocols — the Chrome DevTools Protocol for Chromium and Playwright's own protocol for its patched Firefox and WebKit builds. Fewer round trips and full event visibility make it fast and able to auto-wait.
→ Playwright vs Selenium vs Cypress Architecture
Bonus: 5 Questions for Experienced Candidates
What is a browser context?
An isolated, incognito-like session inside one browser instance, with its own cookies and storage. Contexts are cheap to create, which is how Playwright isolates every test — and how you test two users at once:
const adminContext = await browser.newContext({ storageState: 'playwright/.auth/admin.json' });
const userContext = await browser.newContext({ storageState: 'playwright/.auth/user.json' });
What are fixtures?
Fixtures (page, context, request, and your own via test.extend()) set up exactly what a test needs and tear it down afterwards. Teams use custom fixtures to inject page objects or test data. See the Playwright Cheat Sheet for an example.
How do you implement the Page Object Model?
A class per page holding locators and actions. Storing locators in page objects is safe because Playwright locators are lazy — they re-query the page on every use, so they never go stale like Selenium WebElements.
How do you handle flaky tests?
Find the cause with the trace viewer (usually a missing assertion before an action, shared test data, or an unmocked slow dependency), fix it, and use retries only as a safety net in CI — tracking which tests needed a retry.
How do you run Playwright in CI?
npm ci, npx playwright install --with-deps, then npx playwright test; publish the HTML report and traces as build artefacts. Shard large suites across machines with --shard=1/4.
How to Prepare
- Be able to write a login test with a page object, a mocked API response, and a storage-state setup from memory.
- Explain auto-wait and actionability checks clearly — they come up in almost every interview.
- Revise with the Playwright Cheat Sheet, see concepts in the Playwright Visualizer, and take a timed round in the Playwright Interview Simulator.
- Practise real-world problems in Playwright Scenario-Based Questions.
Next Steps
- The Complete Playwright Tutorial
- JavaScript for Playwright Automation — interview questions
- Selenium to Playwright Migration Guide
- The Complete SDET Interview Guide
From Real Projects
I've built my automation skills on Selenium with Java and TestNG, and that background maps well onto Playwright: page classes become page objects, TestNG groups and parallel runs become projects and workers, and explicit waits become auto-waiting and web-first assertions. If you're coming from Selenium too, focus on those differences first. Testing Testsigma — a platform where users write automated tests in plain English — meant thinking like its users, who are testers themselves. Interviewers often ask Selenium testers how Playwright's auto-waiting changes the way they write tests — have a clear answer ready.
📚 Official documentation: Playwright documentation
