300 Playwright Interview Questions & Answers (1970) — Land Your SDET Role

Playwright is an open-source browser automation framework developed by Microsoft. It is used for end-to-end testing of web applications across Chromium, Firefox, and WebKit. It supports modern testing features such as auto-waiting, browser contexts, tracing, network interception, and parallel execution. Playwright is popular because it reduces flaky tests and provides strong developer experience. For a full walkthrough, read our Playwright complete guide and the official Playwright documentation.

Playwright is used to automate browser-based testing for modern web applications. It can test user flows, forms, navigation, authentication, file upload, downloads, and cross-browser behavior. Teams prefer it because it includes auto-waiting, fast execution, built-in test runner, screenshots, videos, trace viewer, and API testing support.

Playwright supports Chromium, Firefox, and WebKit browser engines. This means it can test applications on Chrome, Edge, Firefox, and Safari-like environments. Its WebKit support is especially useful for validating Safari behavior on non-macOS CI environments.

Playwright supports TypeScript, JavaScript, Python, Java, and .NET. TypeScript is the most common choice because Playwright Test is highly optimized for Node.js and provides strong typing, better autocomplete, and easier framework maintenance.

Playwright Test is the official test runner provided by Playwright. It supports fixtures, assertions, retries, parallel execution, projects, reporters, tracing, screenshots, and videos. It removes the need for separate test runners like Jest or Mocha in most Playwright projects.

Playwright is designed for modern web apps. It uses auto-waiting, isolated browser contexts, built-in parallel execution, native network interception, and trace debugging. Unlike older tools that require many manual waits and separate drivers, Playwright provides a more integrated automation experience.

A browser is the actual application users interact with, such as Chrome or Firefox. A browser engine is the underlying rendering engine, such as Chromium, Firefox, or WebKit. Playwright automates browser engines to provide cross-browser coverage.

Headless mode runs the browser without opening a visible UI. It is faster and commonly used in CI/CD pipelines. Playwright also supports headed mode, where the browser opens visibly, which is useful during debugging and test development.

Teams choose Playwright over Selenium because Playwright has built-in auto-waiting, faster parallel execution, browser contexts, network mocking, trace viewer, and simpler setup. Selenium is still widely used, but Playwright is often preferred for new modern web automation projects. Read the detailed comparison in our Playwright vs Selenium guide and our Selenium interview questions page.

Playwright supports Chromium, Firefox, and WebKit, while Cypress mainly focuses on browser testing with a different execution model. Playwright supports multiple tabs, multiple browser contexts, native downloads, API testing, and stronger cross-browser support. Cypress has strong developer tooling but different architectural limitations.

The main advantages are auto-waiting, reliable locators, cross-browser support, fast parallel execution, browser context isolation, network interception, API testing, trace viewer, screenshots, videos, and built-in reporting. These features help teams build stable automation frameworks faster.

Playwright is mainly focused on web testing, not native mobile or desktop application testing. It requires programming knowledge and may need extra setup for complex enterprise environments. Some real Safari behavior still requires testing on actual Safari devices, even though WebKit coverage is strong.

Playwright can be used for end-to-end UI testing, regression testing, smoke testing, cross-browser testing, API testing, visual testing, accessibility checks, authentication testing, and network mocking. It is commonly used by QA automation engineers and SDETs.

Auto-waiting means Playwright automatically waits for elements to be ready before performing actions. For example, before clicking a button, it checks whether the element is attached, visible, stable, enabled, and able to receive events. This reduces the need for manual waits.

A locator is Playwright’s recommended way to find and interact with elements. Locators are lazy and retry automatically until the element is available. Examples include page.getByRole(), page.getByText(), page.getByLabel(), and page.locator().

A browser context is an isolated browser session inside a browser instance. Each context has separate cookies, local storage, session storage, and permissions. It behaves like an incognito session and helps tests run independently in parallel.

TypeScript is popular because Playwright’s official runner works very well with Node.js and TypeScript. TypeScript provides type safety, better IDE support, autocomplete, fewer runtime errors, and easier maintenance for large automation frameworks.

No. Playwright does not require separate browser drivers like ChromeDriver or GeckoDriver. It downloads and manages browser binaries automatically. This simplifies setup and avoids many driver-version mismatch issues common in Selenium projects.

Test isolation means each test runs independently without sharing browser state such as cookies, sessions, or local storage. Playwright achieves this using browser contexts. Good isolation prevents one test from affecting another and improves reliability.

Yes. Playwright is highly suitable for CI/CD pipelines. It supports headless execution, retries, parallel workers, sharding, HTML reports, JUnit reports, screenshots, videos, traces, and official Docker images. It integrates well with GitHub Actions, Jenkins, GitLab CI, and Azure DevOps.

Yes. Playwright is very strong for cross-browser testing because it supports Chromium, Firefox, and WebKit with one API. Teams can define browser projects in the Playwright config and run the same test suite across multiple browsers.

Real-world use cases include testing login flows, checkout journeys, dashboards, admin portals, role-based access, file upload/download, email verification flows, API-driven setup, network error states, and regression suites for modern single-page applications.

Playwright tests are less flaky because of auto-waiting, web-first assertions, locator retrying, test isolation, browser contexts, trace viewer, and controlled network mocking. However, bad locators, unstable test data, and hard waits can still create flaky tests.

Tracing records detailed test execution information such as screenshots, DOM snapshots, network calls, console logs, and actions. The trace viewer helps debug failures step by step. It is very useful for CI failures because developers can inspect what happened without rerunning locally.

QA engineers, automation testers, SDETs, frontend developers, and test architects should learn Playwright. It is especially useful for teams working on modern web applications, CI/CD automation, and scalable test frameworks. Practice live with our AI Mock Interview or hands-on exercises in the QA Practice Hub.

The easiest way is to run: npm init playwright@latest. This installs Playwright, creates a basic test structure, adds configuration, and prompts you to install browsers. It is the recommended setup for new TypeScript or JavaScript projects. For a step-by-step setup, see our Playwright installation guide.

A typical setup generates playwright.config.ts, a tests folder, example test files, package.json updates, and sometimes a tests-examples folder. It also installs required dependencies and browser binaries if selected during setup.

playwright.config.ts is the main configuration file for Playwright Test. It defines test directory, timeout, retries, workers, reporters, projects, browser options, baseURL, screenshots, videos, traces, and global setup or teardown settings.

testDir tells Playwright where test files are located. For example, testDir: './tests' means Playwright will search inside the tests folder for test files. It helps organize test suites clearly.

Timeout defines the maximum time allowed for a test or action before it fails. Playwright supports global test timeout, expect timeout, action timeout, and navigation timeout. Proper timeout configuration helps avoid hanging tests.

Retries allow failed tests to run again automatically. This is commonly used in CI to reduce the impact of temporary environment issues. However, retries should not hide real flakiness; failures should still be analyzed using traces and reports.

Workers are parallel processes used to run tests. Increasing workers can reduce execution time, but too many workers can overload the application or test environment. Worker count should be tuned based on infrastructure capacity.

Projects allow the same test suite to run with different configurations. For example, one project can run tests on Chromium, another on Firefox, and another on WebKit. Projects can also represent mobile devices, roles, or environments.

The use option defines shared settings for tests, such as browserName, baseURL, viewport, storageState, trace, screenshot, video, permissions, locale, and timezone. It avoids repeating common configuration in every test.

baseURL defines the base address for navigation. If baseURL is set to https://example.com, then page.goto('/login') opens https://example.com/login. It makes tests cleaner and environment switching easier.

Reporters are configured in playwright.config.ts using the reporter property. Common reporters include html, list, line, json, and junit. HTML reports are useful for local debugging, while JUnit reports are useful for CI systems.

They can be configured under the use section. Common settings are screenshot: 'only-on-failure', video: 'retain-on-failure', and trace: 'on-first-retry'. This keeps artifacts useful without consuming too much storage.

globalSetup is a function that runs once before all tests. It is often used to perform login, create authentication storage state, seed test data, or prepare the environment before test execution starts.

globalTeardown runs once after all tests complete. It is used to clean up test data, close external resources, or reset environment state. It is useful for maintaining a clean test environment.

Environment variables can be read using process.env. Teams often use .env files with dotenv for local runs and CI secrets for pipelines. Sensitive values such as passwords and tokens should never be hardcoded in test code.

You can run tests in headed mode using npx playwright test --headed. This opens the browser visibly and helps debug test behavior. Headed mode is useful during test development but not usually used in CI.

You can define projects in the config and run one using npx playwright test --project=chromium. This helps validate specific browser behavior without running the entire cross-browser matrix.

You can add scripts in package.json, such as "test:e2e": "playwright test", "test:headed": "playwright test --headed", and "report": "playwright show-report". Scripts make commands easier for team members and CI pipelines.

Playwright supports TypeScript out of the box. You can write .ts test files without manual transpilation setup. TypeScript improves maintainability by catching type errors early and providing better editor support.

You can install browsers using npx playwright install. For CI environments, npx playwright install --with-deps installs browsers and required system dependencies. This is important for Linux-based build agents.

fullyParallel allows tests within files to run in parallel, not just separate files. It can speed up execution but requires tests to be fully independent. Shared state must be avoided when using full parallel mode.

Playwright supports grep and grepInvert in config or command line. Example: npx playwright test --grep @smoke. Tags help run smoke, regression, critical, or feature-specific test subsets.

Use environment variables, separate config files, or conditional baseURL values. For example, BASE_URL can point to dev, QA, staging, or production. Avoid hardcoding environment-specific URLs inside tests.

Common mistakes include hardcoding URLs, committing secrets, using too many global dependencies, not configuring traces, ignoring test isolation, using brittle selectors, and running all tests serially. A good setup should be simple, isolated, and CI-friendly.

A simple Playwright test navigates to a page and verifies content. ``ts import { test, expect } from '@playwright/test'; test('homepage title should be visible', async ({ page }) => { await page.goto('/'); await expect(page.getByRole('heading')).toBeVisible(); }); `` This uses the page fixture, a relative URL, and a web-first assertion.

A locator represents a way to find an element on the page. It is lazy, auto-retrying, and preferred for actions and assertions. Locators wait for elements to become available, making tests more stable than using raw selectors directly.

A selector is a string used to identify elements, while a locator is a Playwright object that resolves elements at action time. Locators retry automatically and work better with dynamic pages. Selectors are lower-level and more brittle if overused.

getByRole finds elements by their accessible role, such as button, link, checkbox, or heading. It is one of the best locator strategies because it matches how users and assistive technologies understand the page.

getByText finds elements by visible text. It is useful for buttons, labels, messages, and static content. However, if text changes frequently due to localization or UI updates, role-based or test-id locators may be more stable.

getByLabel finds form controls using their associated label text. It is useful for inputs, checkboxes, radio buttons, and textareas. It encourages accessible HTML because labels must be properly connected to controls.

getByPlaceholder finds input elements by placeholder text. It is helpful for simple forms but should not be the first choice when labels are available. Placeholder text can change often and is not always ideal for accessibility.

getByTestId finds elements using a dedicated test attribute such as data-testid. It is useful when user-facing locators are unstable. Teams often use test IDs for complex components, icons, dynamic grids, and repeated elements.

Yes. CSS selectors can be used with page.locator('css-selector'). They are useful for technical targeting but can become brittle if tied to layout or styling classes. Prefer role, label, text, or test ID locators when possible.

Yes, XPath can be used, but it is generally not recommended as the default locator strategy. XPath expressions are often harder to read and maintain. Use XPath only when better locator options are not available.

Locator chaining means narrowing down elements step by step. For example, page.getByRole('list').getByRole('button', { name: 'Delete' }) targets a button inside a specific list. Chaining improves readability and reduces ambiguity.

Filtering narrows a locator using conditions such as hasText or has. It is useful when multiple similar elements exist. For example, a product card can be filtered by product name before clicking its Add to Cart button.

first(), last(), and nth(index) select a specific element from a list of matching elements. They are useful for repeated elements, but overuse can make tests fragile. Prefer unique user-facing locators when possible.

Playwright locators are strict by default for actions. If a locator matches multiple elements and an action expects one, Playwright throws an error. This prevents accidental clicks on the wrong element and encourages precise locators.

Use stable locators, web-first assertions, and avoid fixed waits. Since locators retry automatically, Playwright can handle elements that appear after rendering. For dynamic lists, filter by meaningful text or test ID.

Accessibility-first locators such as getByRole and getByLabel reflect how users interact with the application. They improve test reliability and encourage accessible UI development. They are also less tied to implementation details like CSS classes.

Playwright’s CSS and text locators can pierce open shadow DOM by default. This makes it easier to test web components. Closed shadow DOM cannot be accessed directly because it is intentionally hidden by the browser.

frameLocator is used to locate elements inside iframes. It first identifies the frame and then locates elements inside it. This is more reliable than manually switching frame references in many cases.

You can use await locator.count() to get the number of matched elements. This is useful for validating tables, lists, search results, notifications, or repeated UI components.

Use getByText when verifying static visible content or messages. Use getByRole for interactive elements such as buttons and links. Role locators are generally better for actions, while text locators are useful for content assertions.

has filters a locator by another locator inside it, while hasText filters by contained text. They are useful for targeting a specific card, row, or panel based on internal content before performing an action.

A stable locator strategy prioritizes getByRole, getByLabel, getByText, and getByTestId. Avoid fragile CSS classes, long XPath paths, and index-based locators. Good locators should survive UI refactoring and minor layout changes.

Anti-patterns include using long XPath, dynamic CSS classes, nth() without context, text that changes often, and selectors based on visual layout. These make tests brittle and difficult to maintain.

Long XPath depends heavily on DOM structure. Even small layout changes can break tests. Playwright provides better locator options that are more readable, user-focused, and reliable for modern applications.

You can configure Playwright to use a custom test ID attribute. For example, testIdAttribute: 'data-qa' makes getByTestId use data-qa. This helps align Playwright with an existing frontend testing convention.

Good locator usage targets elements like a user would. ``ts await page.getByRole('button', { name: 'Login' }).click(); await page.getByLabel('Email').fill('qa@example.com'); await expect(page.getByText('Welcome')).toBeVisible(); `` These locators are readable and stable.

Use locator.click(). Playwright automatically waits for the element to be visible, stable, enabled, and able to receive events before clicking. Example: await page.getByRole('button', { name: 'Submit' }).click();

fill clears an input and sets the provided value instantly. type simulates typing character by character and can include delay. For most form automation, fill is faster and more reliable. Use type when keyboard behavior must be tested.

Use locator.press() or page.keyboard.press(). Example: await page.getByLabel('Search').press('Enter'). This is useful for search boxes, shortcuts, form submission, and keyboard accessibility testing.

Use check(), uncheck(), and setChecked(). These methods wait for actionability and verify the final state. They are better than clicking manually because they express the test intention clearly.

Use selectOption() for native select elements. You can select by value, label, or index. For custom dropdowns, interact with visible buttons and options using locators, just like a real user.

Use setInputFiles() on a file input locator. Example: await page.getByLabel('Upload').setInputFiles('tests/fixtures/resume.pdf'). For hidden file inputs, target the input[type=file] element directly.

Use locator.hover(). Hover is useful for testing menus, tooltips, dropdowns, and hover-based UI states. Avoid relying heavily on hover for critical flows unless the product requires it.

Use locator.dragTo(targetLocator). It supports common drag-and-drop scenarios. For complex custom implementations, you may need lower-level mouse actions or JavaScript-based event simulation.

Use page.keyboard for low-level keyboard input. It supports down, up, press, insertText, and typing. Keyboard actions are useful for shortcuts, accessibility checks, and rich text editors.

Use page.mouse for low-level mouse control such as move, down, up, and click at coordinates. It is useful for canvas testing or complex drag interactions, but locator-based actions are preferred for normal UI.

Before actions such as click or fill, Playwright waits until the element is actionable. This means the element must be attached, visible, stable, enabled, and ready to receive input. This reduces timing-related flakiness.

Actionability checks are conditions Playwright verifies before performing an action. These include visibility, stability, enabled state, attachment to DOM, and whether the element receives events. They ensure Playwright acts like a real user.

Assertions verify expected application behavior. Playwright provides expect assertions such as toBeVisible, toHaveText, toHaveURL, toBeEnabled, and toHaveCount. These assertions retry automatically until timeout.

Web-first assertions are Playwright assertions designed for dynamic web pages. They automatically retry until the expected condition becomes true or timeout occurs. Example: await expect(locator).toBeVisible();

Soft assertions allow a test to continue even if an assertion fails. They are useful when collecting multiple validation failures in one test. Use expect.soft() carefully because too many soft failures can make test results harder to interpret.

expect.poll repeatedly executes a function until the expected result is reached. It is useful for checking backend state, delayed UI updates, queues, or asynchronous business processes that are not tied to a single DOM element.

expect.toPass retries a block of assertions until all pass or timeout occurs. It is useful for complex conditions involving multiple checks, such as API status plus UI state validation.

waitForLoadState waits for page load states such as load, domcontentloaded, or networkidle. It should be used carefully because Playwright actions and assertions already wait in many cases. Avoid unnecessary load-state waits.

waitForResponse waits for a specific network response. It is useful when UI changes depend on an API call. You can wait for a URL pattern, status code, or response predicate.

waitForURL waits until the page URL matches a pattern or string. It is commonly used after login, redirects, or navigation flows. It is better than using arbitrary waits after clicking a navigation button.

Hard waits like waitForTimeout slow down tests and create flakiness because they guess timing instead of waiting for real conditions. Use locators, assertions, waitForResponse, or waitForURL instead.

Use stable locators, web-first assertions, isolated test data, storageState for login, avoid hard waits, control network dependencies, run tests independently, and analyze failures using traces. Flakiness is usually a design problem, not a tool problem.

Playwright waits for elements to be stable before actions. If animations still cause issues, reduce unnecessary animations in test environments or wait for a meaningful final state. Avoid fixed waits unless there is no better condition.

Auto-waiting may not help when the element is visible but data is not ready, when custom JavaScript state is incomplete, or when an API response is delayed. In such cases, wait for a specific assertion, response, or UI state.

Example: ``ts await page.goto('/login'); await page.getByLabel('Email').fill('qa@example.com'); await page.getByLabel('Password').fill('Password123'); await page.getByRole('button', { name: 'Sign in' }).click(); await expect(page).toHaveURL(/dashboard/); await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible(); `` This uses user-focused locators and web-first assertions. CTA after Q100: Ready to practice these Playwright answers in a real interview format? Try AI Mock Interview → /ai-mock-interview Start Free → /login

The browser object represents a browser instance such as Chromium, Firefox, or WebKit. It can create browser contexts and pages. In Playwright Test, the browser fixture is usually managed automatically.

A browser context is an isolated session within a browser. It has separate cookies, local storage, session storage, permissions, and cache. Contexts make test isolation fast and efficient.

A page represents a single browser tab or window. Most interactions such as goto, click, fill, and assertions happen on the page or locators created from the page.

Browser contexts allow tests to run independently without sharing login state or cookies. They are lighter than launching new browsers and enable fast parallel execution. This is one of Playwright’s biggest architectural advantages.

Cookies can be added, read, or cleared through browserContext methods such as addCookies(), cookies(), and clearCookies(). Cookie management is useful for authentication, personalization, and session validation tests.

You can access storage using page.evaluate() or save storage using storageState. For authentication reuse, storageState is preferred because it captures cookies and localStorage in a reusable file.

You can wait for a new page event from the context. Example: const newPage = await context.waitForEvent('page'). This is useful when clicking a link opens a new tab.

Use page.waitForEvent('popup') before the action that opens the popup. Then interact with the popup page like any other page. This handles OAuth windows, payment popups, and external links.

Use frameLocator to interact with elements inside iframes. Example: page.frameLocator('#payment-frame').getByLabel('Card number').fill('4111111111111111'). This is useful for embedded widgets.

frameLocator provides a clean and retry-friendly way to locate elements inside frames. It avoids manual frame switching and works naturally with Playwright locators.

Permissions can be granted in context options using permissions: ['geolocation'] or by calling context.grantPermissions(). This is useful for testing camera, microphone, clipboard, notifications, and geolocation.

Create a context with geolocation coordinates and grant geolocation permission. This allows testing location-based features such as stores near me, delivery availability, or regional content.

Viewport can be configured in playwright.config.ts or per test using page.setViewportSize(). Viewport testing helps validate responsive UI behavior across desktop, tablet, and mobile layouts.

Device emulation simulates mobile or tablet devices using predefined descriptors. It can configure viewport, user agent, device scale factor, touch support, and browser behavior. It is useful for responsive testing.

Locale and timezone can be set in context options. This helps test date formats, currency, language-specific UI, timezone calculations, and region-specific behavior.

storageState saves browser authentication state, including cookies and localStorage. It allows tests to start already logged in without repeating login steps. This improves speed and stability.

Login once in globalSetup, save storageState to a JSON file, and configure tests to use that file. This avoids repeated UI login and makes tests faster.

Usually no. Each test should use a fresh page and context to maintain isolation. Reusing pages can create hidden dependencies and flaky behavior.

Yes. Browser contexts behave like independent incognito sessions. They do not share cookies or storage unless explicitly configured. This makes them ideal for parallel testing.

Use page.waitForEvent('download') before triggering the download. Then you can check the suggested filename, save the file, or validate its contents.

Use page.on('dialog') to accept, dismiss, or inspect alert, confirm, and prompt dialogs. Register the dialog handler before performing the action that triggers the dialog.

A new window can be handled similarly to a popup or new page event. Wait for the popup or page event, then interact with the returned Page object.

Context options include viewport, storageState, permissions, geolocation, locale, timezone, colorScheme, userAgent, extraHTTPHeaders, httpCredentials, and recordVideo. These options control browser behavior for tests.

Isolation issues happen when tests share users, data, browser state, or backend records. They often appear only in parallel execution. Use independent contexts, unique data, and cleanup strategies to avoid them.

Example: ``ts const context = await browser.newContext({ viewport: { width: 1280, height: 720 }, storageState: 'auth/user.json' }); const page = await context.newPage(); await page.goto('/dashboard'); `` This creates an isolated logged-in session.

Fixtures are reusable objects or setup logic provided to tests. Built-in fixtures include page, browser, context, request, and browserName. Custom fixtures help share page objects, test data, and services.

Built-in fixtures are provided by Playwright Test. Common examples are page, context, browser, request, browserName, baseURL, and testInfo. They reduce boilerplate and improve consistency.

A custom fixture is a user-defined fixture that provides reusable setup to tests. For example, you can create a loginPage fixture, apiClient fixture, or authenticatedPage fixture.

A test-scoped fixture is created separately for each test. It is useful for page objects, test data, and any state that must not be shared between tests.

A worker-scoped fixture is created once per worker process. It is useful for expensive setup such as creating a test account or initializing a service client. It must be safe for tests running in that worker.

beforeEach runs before every test in a scope. It is commonly used for navigation, preparing test state, or resetting page conditions. Avoid placing heavy setup in beforeEach if it slows the suite.

afterEach runs after every test. It is useful for cleanup, attaching logs, resetting data, or capturing additional diagnostics. Playwright also provides testInfo to access test status and artifacts.

beforeAll runs once before all tests in a describe block. It is useful for expensive setup shared by tests. Be careful because shared state can reduce test isolation.

afterAll runs once after all tests in a describe block. It is used for final cleanup, closing external resources, or deleting shared test data created in beforeAll.

test.describe groups related tests. It improves readability and allows scoped hooks, annotations, and configuration. For example, all checkout tests can be grouped under test.describe('Checkout').

test.step divides a test into named steps. These steps appear in reports and traces, making debugging easier. It is helpful for long scenario-based tests.

Annotations add metadata to tests. Built-in annotations include skip, fixme, fail, slow, and only. Custom annotations can also be used for reporting and filtering.

Tags are usually added in test titles or annotations, such as @smoke or @regression. They allow selective execution using grep. Tags are useful for organizing large test suites.

test.skip skips a test or group of tests. It can be unconditional or conditional. Use it when a test is not applicable for a browser, environment, or feature flag.

test.fixme marks a test as known broken or incomplete. It documents technical debt while preventing the failure from breaking the pipeline. It should be tracked and resolved.

test.only runs only selected tests. It is useful during local debugging but should never be committed. CI pipelines should fail if test.only is accidentally present.

test.slow triples the default timeout for a test. It is useful for genuinely slow flows, but should not be used to hide performance issues or poor synchronization.

Retries rerun failed tests based on config or command-line settings. They are useful in CI, but repeated failures should be investigated with traces. A passing retry may still indicate flaky behavior.

Playwright runs test files in parallel by default using workers. It can also run tests within a file in parallel if fullyParallel is enabled. Tests must be independent for safe parallel execution.

Serial mode runs tests in order within a describe block. It is useful for dependent flows, but should be avoided for most test suites because it reduces parallelism and can create dependencies.

Sharding splits tests across multiple machines or CI jobs. Example: --shard=1/3 runs the first third of tests. It helps scale large suites and reduce pipeline duration.

Project dependencies allow one project to run before another. They are useful for setup projects, such as authentication setup before running browser tests.

Yes. Playwright fixtures can be extended or overridden using test.extend(). This allows teams to customize page, context, storageState, or custom services for specific test needs.

Fixtures can instantiate page objects and inject them into tests. This keeps tests clean and avoids repeatedly creating page object instances in every test file.

Example: ``ts import { test as base } from '@playwright/test'; import { LoginPage } from './pages/LoginPage'; export const test = base.extend<{ loginPage: LoginPage }>({ loginPage: async ({ page }, use) => { await use(new LoginPage(page)); } }); `` This provides LoginPage directly to tests.

APIRequestContext is Playwright’s API client for making HTTP requests in tests. It supports GET, POST, PUT, PATCH, DELETE, headers, authentication, cookies, and response assertions. It is useful for API testing and test data setup. See the official Playwright API testing docs and our API testing interview questions for more practice.

The request fixture is a built-in Playwright fixture that provides APIRequestContext. It allows tests to call APIs without creating a browser page. This is useful for fast backend validations and hybrid UI/API tests.

Use request.get(url). Example: const response = await request.get('/api/users'). Then assert response.ok(), status code, headers, or JSON body. GET requests are commonly used for validation.

Use request.post(url, { data }). POST is commonly used to create resources, login through API, or prepare test data. Always assert status code and response body after creation.

PUT usually replaces the entire resource, while PATCH updates specific fields. In tests, verify both status code and final resource state. Also validate idempotency and behavior when required fields are missing.

Send a DELETE request and verify the status code, response body, and that the resource no longer exists. Also test deleting an already deleted or unauthorized resource.

Use expect(response.status()).toBe(200), expect(response.ok()).toBeTruthy(), and validate JSON response fields. For schema validation, integrate libraries like Zod, Ajv, or custom validators.

Obtain the token through login API or CI secrets, then pass it in headers such as Authorization: Bearer token. Avoid hardcoding tokens. Refresh or regenerate tokens when they expire.

A hybrid test uses APIs for setup or validation and UI for user-critical flows. For example, create a user through API, log in through UI, and verify dashboard behavior. This makes tests faster and more reliable.

page.route intercepts network requests matching a URL or pattern. It can mock responses, block requests, or modify outgoing requests. It is useful for testing edge cases without depending on real backend behavior.

route.fulfill completes an intercepted request with a mocked response. You can return status, headers, body, or JSON. It is useful for testing empty states, error states, and predictable API responses.

route.abort cancels an intercepted request. It is useful for simulating network failures, blocked resources, timeout scenarios, or unavailable third-party services.

route.continue allows an intercepted request to continue to the server, optionally with modified headers, method, or post data. It is useful for adding test headers or modifying requests.

Use page.on('request', callback). This helps inspect outgoing network requests, verify tracking calls, debug API calls, or ensure certain resources are requested.

Use page.on('response', callback). This helps validate status codes, inspect API responses, or debug failed backend calls during UI tests.

Use page.route to intercept the API endpoint and route.fulfill with mock data. Mocking APIs makes tests deterministic and allows validation of rare states like server errors or empty results.

HAR replay allows Playwright to serve network responses from a recorded HAR file. It can make tests more deterministic by replaying known backend responses. It is useful for demos, offline testing, and stable regression flows.

Yes. Playwright can simulate network behavior by routing requests, delaying responses, or using browser context options and CDP for Chromium-specific throttling. Testing slow networks helps validate loaders, retries, and timeout handling.

Mock the API response using route.fulfill with status codes like 400, 401, 403, or 500. Then verify that the UI shows correct error messages, retry options, or fallback behavior.

GraphQL requests usually go to one endpoint. Validate operationName, variables, response data, and errors. You can intercept GraphQL requests and return mocked responses for specific operations.

Contract-style validation checks whether API responses follow expected structure, types, and required fields. It does not replace full contract testing tools, but it helps catch breaking API changes during UI or API automation.

Verify page size, total count, next/previous tokens, sorting consistency, empty pages, invalid page numbers, and combined filters. For cursor pagination, verify that records do not duplicate or disappear across pages.

APIs can create users, orders, products, permissions, or test records faster than UI steps. This keeps UI tests focused on user behavior instead of long setup flows.

APIs can delete test-created records after execution. Cleanup prevents test data pollution and reduces environment instability. Always design cleanup to be safe and idempotent.

Yes. APIRequestContext can share cookie storage with browser context depending on how it is created. This allows login through API and later validation through UI, or vice versa.

Use expect.poll or a custom retry loop when backend state is eventually consistent. Avoid blind waits. Retry meaningful conditions such as order status becoming completed.

Timeouts can be passed in request options or configured globally. Proper API timeouts prevent tests from hanging and make failures easier to diagnose.

Read headers using response.headers() and assert expected values such as content-type, cache-control, location, or security headers. Header validation is important for API correctness and security.

Validate authentication, authorization, secure headers, HTTPS usage, token handling, and blocked unauthorized requests. Playwright can inspect UI requests and API responses to detect security regressions.

Example: ``ts test('create user through API', async ({ request }) => { const response = await request.post('/api/users', { data: { name: 'QA User', email: 'qa@example.com' } }); expect(response.status()).toBe(201); const body = await response.json(); expect(body.email).toBe('qa@example.com'); }); `` This validates API creation directly.

You can automate login through UI steps or API calls. For most large suites, login once using global setup and save storageState. This avoids repeated login and reduces execution time.

Use storageState. Login once, save authentication state to a JSON file, and configure tests to reuse it. This keeps tests faster and avoids failures caused by repeated login flow dependencies.

storageState authentication means saving cookies and localStorage after login and reusing them in future tests. It is useful when tests need an already authenticated user session.

globalSetup runs before tests, logs in a user, saves storageState, and then tests use that saved state. This creates a clean and reusable authentication flow for CI and local execution.

Create separate storageState files for each role, such as admin, manager, and viewer. Configure projects or fixtures to use the correct role. This supports role-based access testing.

A good strategy creates only the data needed for each test, uses unique identifiers, avoids shared mutable data, and cleans up after execution. API-based setup is often faster than UI-based setup.

Cleanup prevents polluted environments, false failures, duplicate records, and unpredictable test results. Cleanup should be reliable, idempotent, and safe even if a test fails halfway.

API setup is faster and more stable than UI setup. It lets UI tests focus on the actual user journey being validated. For example, create an order through API and verify it in the UI.

Use controlled seed data, test-specific records, transactions, or cleanup jobs. Direct database manipulation should be used carefully because it can bypass business rules. API setup is often safer.

Use timestamps, UUIDs, worker indexes, or random suffixes. Unique test data prevents conflicts during parallel execution and avoids failures caused by duplicate emails, usernames, or order IDs.

Data-driven testing runs the same test logic with different input values. In Playwright, data can come from arrays, JSON files, CSV files, or external sources. It improves coverage without duplicating test code.

Store data in JSON files and import it into tests. JSON is useful for structured test data such as users, products, roles, and expected messages. Keep sensitive data out of committed JSON files.

CSV can be parsed using Node.js libraries when tabular test data is needed. It is useful for large input combinations, but JSON is usually easier for nested data structures.

Use environment variables and configuration files to separate dev, QA, staging, and production data. Avoid using production-sensitive data in automated tests unless tests are read-only and approved.

Use CI secret stores, environment variables, or secret management tools. Do not commit passwords, tokens, or API keys. Locally, use .env files excluded from version control.

Prefer test-only OTP bypasses, API access to retrieve OTP, static OTP in lower environments, or mocked authentication providers. Avoid relying on real SMS or email delivery in automated regression tests.

CAPTCHA should not be automated directly. Use test environment bypasses, feature flags, or mock verification services. CAPTCHA is designed to stop automation, so testing should focus on integration and fallback behavior.

Anti-patterns include shared users for all tests, hardcoded data, no cleanup, dependency on production data, manual preconditions, and tests that must run in a specific order. These cause flaky and unreliable suites.

Seed data is predefined data loaded into an environment before tests. It is useful for reference values such as roles, categories, plans, and permissions. Seed data should be stable and version-controlled.

Use unique data per worker or test, avoid shared mutable records, and clean up created data. Playwright provides workerInfo, which can help generate worker-specific users or data identifiers. CTA after Q200: Ready to practice these Playwright answers in a real interview format? Try AI Mock Interview → /ai-mock-interview Start Free → /login

If storageState expires, regenerate it in global setup. Tests should not rely on old authentication files forever. In CI, create fresh storage state for each run to avoid token expiry failures.

Define expected permissions for each role and validate allowed and blocked actions. Use separate users or storageState files for each role. Test both UI visibility and backend authorization where possible.

Test invalid password, locked account, expired token, missing token, wrong role, and direct URL access without login. Negative authentication tests should verify both error messages and blocked access.

Cleanup should be retried or handled by scheduled cleanup jobs using unique test identifiers. Tests should log created data to make manual cleanup easier. Cleanup failure should be visible, not silently ignored.

Example: ``ts const browser = await chromium.launch(); const page = await browser.newPage(); await page.goto('/login'); await page.getByLabel('Email').fill(process.env.USER_EMAIL!); await page.getByLabel('Password').fill(process.env.USER_PASSWORD!); await page.getByRole('button', { name: 'Login' }).click(); await page.context().storageState({ path: 'auth/user.json' }); await browser.close(); `` Tests can reuse auth/user.json.

Playwright Inspector is a debugging tool that lets you step through tests, inspect locators, view actions, and pause execution. It is useful for developing and fixing tests locally.

PWDEBUG is an environment variable used to run Playwright in debug mode. Example: PWDEBUG=1 npx playwright test. It opens the inspector and runs tests in headed mode with slower execution.

Codegen records user actions and generates Playwright test code. It is useful for learning selectors and quickly creating draft tests. However, generated code should be reviewed and refactored before production use.

Trace Viewer is a Playwright tool for analyzing test execution. It shows actions, screenshots, DOM snapshots, console logs, network calls, and errors. It is one of the best tools for debugging CI failures.

Traces can be enabled in config using trace: 'on', 'retain-on-failure', or 'on-first-retry'. A common CI setting is trace: 'on-first-retry' because it captures useful data without storing traces for every passed test.

Use page.screenshot() manually or configure screenshot: 'only-on-failure'. Screenshots help understand UI state at failure time and are useful in reports.

Videos can be enabled using video: 'on', 'retain-on-failure', or 'off'. Video recording is useful for debugging complex UI flows but can increase storage usage in CI.

Use page.on('console', msg => console.log(msg.text())). Console logs help debug frontend errors, warnings, and application logs during test execution.

Use page.on('pageerror', error => ...). Page errors indicate uncaught JavaScript exceptions. Capturing them helps detect frontend issues even if the UI appears normal.

Artifacts are files generated during tests, such as screenshots, videos, traces, logs, and reports. They help investigate failures, especially in CI environments where the browser is not visible.

The HTML reporter generates an interactive report showing passed, failed, skipped, and flaky tests. It includes test steps, errors, screenshots, videos, and traces when configured.

The JSON reporter outputs test results in machine-readable format. It is useful for dashboards, custom reporting, analytics, and integration with internal tools.

The JUnit reporter creates XML output compatible with CI tools such as Jenkins, GitLab CI, Azure DevOps, and test reporting plugins. It is commonly used in enterprise pipelines.

Yes. Playwright can integrate with Allure using third-party reporters. Allure provides rich reports, history, categories, attachments, and trend analysis for larger QA teams.

Configure CI to upload playwright-report, test-results, screenshots, videos, and traces as build artifacts. This allows developers to debug failures after the pipeline finishes.

Analyze traces, screenshots, videos, retries, network logs, and test data. Look for weak locators, race conditions, shared state, slow APIs, or environment instability. Fix the root cause instead of increasing timeouts blindly.

Time-travel debugging means inspecting each step of a test using Trace Viewer. You can see what the page looked like before and after actions, which network calls happened, and why an assertion failed.

Use reports and traces to identify slow steps, repeated login, unnecessary waits, heavy setup, or slow backend responses. Optimize by using API setup, storageState, parallel execution, and focused assertions.

Good failure analysis identifies whether the issue is test code, application bug, data problem, environment issue, or network dependency. Attach traces and logs so developers can reproduce and fix failures quickly.

Check how many elements the locator matches using count() or inspect it in the trace viewer. Improve the locator by adding role name, filtering by text, or narrowing scope with parent locators.

Use page.on('requestfailed'), response logs, trace viewer network tab, and waitForResponse. Validate status codes, payloads, authentication headers, and environment availability.

Yes. Playwright supports visual comparisons using expect(page).toHaveScreenshot(). This is useful for visual regression testing, but baselines must be managed carefully across browsers and operating systems.

Trace on first retry captures diagnostic information only when a test fails and retries. It keeps CI storage lower than tracing every test while still providing useful debugging data for flaky failures.

Compare browser version, OS, viewport, environment variables, baseURL, test data, timezone, locale, and resource speed. CI often exposes race conditions because it runs slower or more parallel than local machines.

Example: ``ts use: { screenshot: 'only-on-failure', video: 'retain-on-failure', trace: 'on-first-retry' }, reporter: [['html'], ['junit', { outputFile: 'results.xml' }]] `` This configuration captures useful failure artifacts.

A good structure separates tests, pages, fixtures, test data, utilities, API clients, configuration, and reports. This improves maintainability and helps teams scale automation without duplicating code.

Page Object Model is a design pattern where page-specific locators and actions are stored in separate classes. Tests call meaningful methods like login() or addProductToCart() instead of directly handling every selector.

POM improves readability, reusability, maintainability, and abstraction. If a locator changes, it is updated in one page class instead of many tests. It also makes test scenarios easier to understand.

Locators should be stored inside the page object class as readonly locator properties or methods. This keeps UI implementation details away from tests and makes maintenance easier.

Fixtures can create and inject page objects into tests automatically. This avoids repetitive initialization and gives every test a clean, consistent object setup.

Component objects represent reusable UI components such as navigation bars, modals, tables, date pickers, or product cards. They reduce duplication when the same component appears on multiple pages.

A service layer contains reusable API methods for setup, cleanup, and backend validation. It keeps API logic separate from UI tests and supports hybrid automation strategies.

A base page contains shared page behavior such as navigation helpers, common waits, screenshot helpers, or shared components. Avoid putting too much logic in the base page because it can become a dumping ground.

Useful utilities include data generators, date helpers, file helpers, API clients, environment readers, custom assertions, test data builders, and logging helpers. Utilities should be small and focused.

Reusable assertions are helper methods for common validations, such as verifying toast messages, table rows, or page headers. They reduce duplication and improve consistency across tests.

Playwright does not use custom commands in the same way as Cypress. Instead, use fixtures, helper functions, page objects, and custom expect matchers when needed.

Test data builders create test objects with sensible defaults and allow overriding specific fields. They make tests cleaner and reduce repeated data setup code.

A reporting layer should include HTML reports, CI reports, screenshots, traces, videos, logs, and test metadata. For large teams, Allure or dashboard integrations may be useful.

Configuration should separate common settings from environment-specific values. Use baseURL, projects, environment variables, and CI overrides. Avoid hardcoding URLs, credentials, or browser settings inside tests.

Use environment variables such as BASE_URL, USER_EMAIL, and API_URL. Optionally use config files for dev, QA, staging, and production. The same tests should run across environments with minimal changes.

Design independent tests, reusable fixtures, stable locators, API setup, parallel execution, clear folders, tagging, reporting, and CI integration. Scalability depends on both technical design and team discipline.

Use readable test names, stable locators, POM or screen objects, reusable helpers, limited duplication, good code reviews, and meaningful assertions. Avoid hiding too much logic inside large helper methods.

Review locator quality, test independence, assertion strength, data setup, cleanup, hard waits, readability, unnecessary retries, and whether the test validates real business value.

Overengineering means adding unnecessary abstraction, complex inheritance, generic wrappers, or framework code that makes tests harder to read. A good framework should simplify testing, not become harder than the product.

Consistent names for tests, page objects, fixtures, and data files help teams understand and maintain the framework. Good naming reduces onboarding time and prevents confusion.

Basic UI state checks can be inside page objects, but business assertions are often clearer in tests. Avoid hiding all expectations inside page methods because tests should clearly show what is being verified.

Not usually. Selectors should be close to the page or component they belong to. A giant global selector file becomes hard to maintain and does not scale well.

Let Playwright assertions fail naturally with clear messages. Add custom error messages only where they improve debugging. Avoid catching errors and hiding failures unless cleanup or logging is required.

Provide setup instructions, folder structure, coding standards, locator strategy, test data rules, sample tests, and CI instructions. A strong README and example test help new members become productive quickly.

Example: ``ts export class LoginPage { constructor(private page: Page) {} email = this.page.getByLabel('Email'); password = this.page.getByLabel('Password'); loginButton = this.page.getByRole('button', { name: 'Login' }); async login(email: string, password: string) { await this.email.fill(email); await this.password.fill(password); await this.loginButton.click(); } } `` This keeps login logic reusable.

Install dependencies, install browsers, run npx playwright test, and upload reports as artifacts. Playwright provides good CI documentation and works well with GitHub-hosted runners.

Create a pipeline that checks out code, installs Node dependencies, installs Playwright browsers, runs tests, and publishes HTML or JUnit reports. Store credentials in Jenkins credentials, not code.

Use a YAML pipeline with Node setup, npm ci, npx playwright install --with-deps, and npx playwright test. Publish test results and artifacts using Azure DevOps publishing tasks.

Use a GitLab CI YAML file with a Playwright Docker image or Node image. Install dependencies, run tests, and save reports, traces, and screenshots as artifacts.

Docker provides a consistent runtime environment with browsers, dependencies, and OS libraries. It reduces “works on my machine” problems and makes CI execution more predictable.

Playwright provides official Docker images containing browsers and required system dependencies. They simplify CI setup and avoid dependency issues on Linux agents.

Playwright browsers must be installed before tests run. In Linux CI, system dependencies may also be required. Using npx playwright install --with-deps or official Docker images solves this.

Cache npm dependencies where appropriate, but be careful with browser cache compatibility. Many teams use npm ci for clean reproducible installs. Browser caching can speed pipelines but must be managed carefully.

Yes, limited retries such as 1 or 2 are common in CI. However, retries should not hide flaky tests. Use traces and dashboards to track tests that pass only after retry.

Workers control parallelism. More workers can reduce runtime, but too many can overload the application under test or CI machine. Tune workers based on CPU, memory, and environment capacity.

Sharding splits tests across multiple CI jobs. For example, four jobs can each run one-fourth of the suite. This is useful for large regression suites where one machine would take too long.

Test splitting divides tests by files, tags, historical duration, or shards. It helps balance workload across CI jobs and reduce total pipeline time.

Quarantine means separating unstable tests from blocking pipelines while they are investigated. It prevents unreliable tests from stopping releases but should be temporary and tracked.

Yes. Playwright can run on BrowserStack for cloud browser testing. This helps validate real browser and platform combinations beyond local or CI-provided browsers.

Yes. Cloud testing providers such as Sauce Labs and LambdaTest support Playwright execution. They are useful for cross-platform coverage, browser versions, and enterprise reporting needs.

Upload HTML reports, JUnit XML, traces, screenshots, videos, and logs. These artifacts help debug failures without rerunning tests locally.

Use API setup, storageState authentication, parallel workers, sharding, selective tags, test impact analysis, efficient locators, and reduced unnecessary waits. Keep smoke tests fast and regression tests scalable.

Use CI secret storage such as GitHub Secrets, Jenkins Credentials, GitLab Variables, or Azure Key Vault. Never print secrets in logs or commit them to repositories.

Fail-fast stops execution early when critical failures occur. It is useful for smoke pipelines but less useful for full regression where teams want complete failure visibility.

Example: ``yaml name: Playwright Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test - uses: actions/upload-artifact@v4 if: always() with: name: playwright-report path: playwright-report/ `` This runs tests and uploads reports.

Start with clear folder structure, Playwright config, TypeScript, fixtures, page objects, API clients, data builders, reporting, and CI integration. Prioritize test isolation, stable locators, storageState authentication, and parallel execution from the beginning. For a complete implementation, follow our Playwright framework setup with TypeScript guide.

Do not blindly convert every Selenium test. First identify high-value stable flows, design a Playwright framework, migrate smoke tests, compare execution time and flakiness, then gradually migrate regression coverage. Keep Selenium running during transition if needed.

Risks include rewriting too many tests at once, copying bad locator strategies, ignoring framework design, underestimating training needs, and losing historical coverage. A phased migration with clear priorities works best.

Test critical user journeys across micro-frontends, validate integration points, mock unstable services when needed, and use contract tests for boundaries. Avoid tying tests to internal implementation of each micro-frontend.

Use stable user-facing locators, wait for meaningful business states, validate API responses when needed, and avoid hard waits. Dynamic apps require strong test data control and clear synchronization points.

Create users for each role, verify visible and hidden UI actions, test direct URL access, and validate backend authorization through APIs. Do not rely only on UI visibility because security must be enforced server-side.

Mock third-party services for most automated tests and keep a small number of integration tests against sandbox environments. This balances reliability, cost, and confidence.

Use stable locators, avoid layout-based selectors, keep tests independent, use API setup, write clear assertions, avoid excessive abstraction, and review tests like production code.

Collect failure data, identify top flaky tests, inspect traces, fix locator and data issues, remove hard waits, isolate shared state, improve environment stability, and track retry-based passes. Fixing flakiness should be systematic.

Prefer getByRole, getByLabel, and getByText for user-facing elements. Use getByTestId for complex or unstable UI. Avoid long XPath and CSS tied to styling. A good locator is readable and resilient.

Compare environment data, feature flags, browser versions, permissions, network responses, third-party services, and user roles. Use traces, logs, and safe read-only tests. Avoid destructive automation in production.

The test pyramid recommends many unit tests, fewer API/integration tests, and fewer UI end-to-end tests. Playwright is powerful for UI and API tests, but not every scenario should be automated through the UI.

Use API tests for business rules, data validation, and fast coverage. Use UI tests for critical user journeys and visual workflow validation. Combine both for efficient and reliable automation.

Use CI history, retry data, failure categories, dashboards, and test annotations. Track whether failures are due to product bugs, environment issues, test data, or automation code. Prioritize the most frequent blockers.

Keep shared utilities in common packages, define project-specific configs, use tags or paths for selective execution, and avoid cross-team coupling. CI should run only impacted tests where possible.

Use screenshot comparisons for stable UI components and critical pages. Control fonts, viewport, browser, animations, and data. Visual testing is valuable but requires careful baseline management to avoid noisy failures.

Yes. Playwright can validate keyboard navigation, ARIA roles, labels, focus behavior, and integrate with tools like axe-core. Accessibility-first locators also encourage better accessible UI design.

Use worker-specific users, unique identifiers, API setup, isolated records, and cleanup strategies. Avoid shared mutable data. Parallel-safe test data is essential for fast and reliable enterprise automation.

Playwright can validate API response shapes, but dedicated contract testing tools are better for formal consumer-provider contracts. Use Playwright for UI/API confidence and contract tests for service compatibility.

Use device emulation for viewport, user agent, touch, and mobile layout validation. For real mobile browser behavior, complement emulation with device cloud testing when required.

Avoid unnecessary UI setup, hard waits, repeated login, and oversized scenarios. Use API setup, parallel execution, storageState, and focused assertions. Tests should be fast enough to provide feedback in CI.

Create standards for locator strategy, folder structure, naming, test data, assertions, tagging, code review, CI artifacts, and flaky test handling. Document them and enforce through reviews and examples.

Measure reduced manual regression time, faster release feedback, defect detection, pipeline stability, test maintenance effort, and confidence in critical flows. ROI is not just number of tests; it is useful feedback.

A senior SDET should discuss framework design, test strategy, CI/CD, parallel execution, flakiness management, API/UI balance, maintainability, team standards, and business risk coverage. Senior answers should explain trade-offs, not just syntax.

Start with training and proof of concept, automate critical smoke flows, design framework standards, integrate CI, add API setup, migrate high-value tests, monitor flakiness, and expand regression coverage gradually. Adoption should be practical, measurable, and team-friendly. For a production-ready blueprint, see our Playwright framework setup with TypeScript guide.