Playwright Interview Questions: Practical QA Answers

A Playwright interview becomes interesting when auto-waiting does not solve the test. The button is visible and enabled, the click succeeds, yet the assertion reads data from a job that has not completed. Candidates who answer with a longer timeout blur two different problems: browser actionability and application readiness. Candidates who name the missing business signal show that they can design reliable automation.

Use Playwright's capabilities as evidence-producing tools. Locators, fixtures, contexts, traces, and API clients matter because of the risks they help control.

Separate actionability from business readiness

Before performing an action, Playwright checks conditions such as visibility, stability, event reception, and enabled state where relevant. Locator assertions retry until their expectation succeeds or times out. This removes many manual waits, but it cannot infer that an imported report is semantically complete.

Prefer an observable product state:

await page.getByRole("button", { name: "Start import" }).click();

await expect(page.getByTestId("import-status")).toHaveText("Completed");
await expect(page.getByRole("row", { name: /customers imported/i }))
  .toContainText("250");

A fixed wait guesses how long completion takes. Waiting for “Completed” states what the user needs. If no UI signal exists, observe a documented API, event, or data state with a bounded polling strategy and treat missing observability as a product concern.

A weak answer says Playwright waits for everything. An acceptable answer explains actionability and retrying assertions. A strong answer identifies the exact asynchronous boundary, selects a stable signal, and distinguishes slow expected work from a hung operation.

Follow-up probes may introduce animation, navigation, or a disabled control. Explain the state Playwright can detect, then the domain state it cannot know without an assertion.

Build locators around user meaning and uniqueness

Playwright locators are evaluated when used, so they work with changing DOM state. Favor roles, accessible names, labels, and meaningful text when these reflect the user's interaction. Use explicit test IDs where accessible semantics are insufficient or mutable.

For a product grid, scope the action to the intended item:

const product = page
  .getByRole("article")
  .filter({ has: page.getByRole("heading", { name: "Trail Backpack" }) });

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

This is clearer than selecting the third button. Strict locator behavior is useful because an unexpectedly non-unique match fails instead of silently choosing an element. If duplicates are legitimate, refine the scope based on product meaning. Using first() merely to suppress strictness can hide a real ambiguity.

XPath and long CSS selectors are not forbidden, but they usually encode implementation structure. An interview answer should describe selector ownership with developers and accessibility benefits, not claim one locator family always works.

For lists that update, assert the relevant row or collection condition. Avoid reading all text into a JavaScript variable too early and then expecting that frozen value to retry.

Use fixtures to express capability and lifetime

Fixtures are more than a beforeEach replacement. They define dependencies, setup, teardown, type, and scope. A test fixture can provide a page object or authenticated API client per test. A worker fixture can provide an expensive resource shared within one worker when isolation permits.

A focused custom fixture might look like:

import { test as base, expect, APIRequestContext } from "@playwright/test";

type Fixtures = {
  ordersApi: APIRequestContext;
};

export const test = base.extend<Fixtures>({
  ordersApi: async ({ playwright }, use) => {
    const client = await playwright.request.newContext({
      baseURL: process.env.API_URL,
      extraHTTPHeaders: {
        Authorization: "Bearer " + process.env.TEST_TOKEN
      }
    });

    await use(client);
    await client.dispose();
  }
});

export { expect };

In production code, validate required environment values rather than allowing undefined credentials. The example shows lifecycle: create, provide, dispose.

An interviewer may ask whether login belongs in beforeEach, storage state, or a fixture. Repeating UI login gives integrated coverage but adds time and a shared dependency. A pre-authenticated storage state is efficient for tests not concerned with login, but it must be generated securely, refreshed, and separated by role. Fixtures can make that choice explicit.

Do not put all setup in one automatic fixture. Hidden setup slows every test and makes failures opaque. Match fixture scope to ownership of mutable state.

Control browser contexts, roles, and parallel data

Browser contexts provide isolated cookies, local storage, and sessions within a browser process. They are especially useful for multi-user scenarios. A chat permission test can create an owner context and a guest context, each with separate pages, then verify the same resource from both identities.

Isolation is not complete if both tests mutate the same backend record. Parallel safety requires unique data, deterministic cleanup, or a service that allocates test resources. Use the worker index or a generated run ID to namespace users and orders, but make failures reproducible by recording those identifiers.

Playwright runs test files and projects in parallel according to configuration. Serial mode can be justified for a genuinely sequential scenario, but it should not rescue state-dependent tests. Explain the cost: serial failures can skip dependent work and reduce throughput.

For cross-browser coverage, choose by risk. Run a focused critical set across supported engines and broader checks where they add value. Multiplying every low-value test across all projects increases runtime and maintenance without automatically increasing confidence.

A senior answer considers account limits, test-data services, worker count, CI capacity, and external rate limits together. More workers can make a suite slower or less reliable when a backend dependency is the bottleneck.

Combine API and UI checks without confusing their purpose

Playwright's request context is useful for setup, direct API validation, and checking side effects. A test can create an order through an API, open it in the UI, edit it, then verify the persisted result through a read endpoint.

const create = await request.post("/orders", {
  data: { sku: "A17", quantity: 2 }
});
expect(create.status()).toBe(201);

const order = await create.json();
await page.goto("/orders/" + order.id);
await page.getByLabel("Delivery note").fill("Leave at reception");
await page.getByRole("button", { name: "Save" }).click();

await expect(page.getByRole("status")).toHaveText("Saved");

const read = await request.get("/orders/" + order.id);
expect((await read.json()).deliveryNote).toBe("Leave at reception");

This improves setup speed and uses an independent observation for persistence. It does not replace a small number of UI creation journeys. Explain which boundary each check protects.

Network routing can fulfill rare responses, abort requests, or modify traffic. Use it for frontend behavior under controlled failure, but retain contract and integrated coverage. When mocking, assert that the outgoing request is correct and keep fixture payloads aligned with the real schema.

A probing question may ask whether a response event is sufficient. It proves network activity, not necessarily that the user-visible state or downstream processing succeeded. Complete the assertion chain at the relevant outcome.

Structure abstractions around tasks, not page anatomy

Page objects can encapsulate stable locators and coherent operations, but a class for every screen often becomes a second application UI. Tests then read as generic method calls and hide business inputs.

Prefer small domain-facing components or task helpers. A checkout object might expose submitOrder(orderData) and a confirmation locator, while test data builders express customer and item variations. Keep important assertions in the scenario unless they are true invariants of the helper.

Fixtures can inject these capabilities without global singletons. Avoid sharing a Page or mutable page object across parallel tests. Also avoid a base class with unrelated utilities, database access, screenshots, and waits. Composition makes dependencies easier to see.

When asked to design folders, start with boundaries and ownership instead of reciting directories:

• Tests describe scenarios and risk.
• Fixtures own lifecycle and dependencies.
• Domain helpers own repeated business interactions.
• Data builders create explicit variations.
• Configuration defines projects, retries, artifacts, and environment.
• Reporters and CI preserve diagnostic output.

The right abstraction is the smallest one that removes meaningful duplication without concealing state.

Debug with traces and a hypothesis

A trace can show actions, DOM snapshots, network activity, console output, and timing. It is most useful when retained for failed or retried tests according to suite policy. Screenshots alone may show the final symptom but not the sequence that caused it.

For a CI-only failure:

1. Confirm the failing attempt, project, worker, and test data.
2. Open the trace and locate the first divergence, not just the final timeout.
3. Inspect requests, console errors, locator matches, navigations, and overlays.
4. Compare with a passing trace under the same build.
5. Form one hypothesis and reproduce under a controlled variation.
6. Fix the state observation, isolation, product defect, or environment cause.
7. Remove diagnostic timeout increases that are no longer justified.

Retries can preserve delivery while collecting evidence, but report first-attempt reliability. A retry that passes after a shared record appears is evidence of a race, not proof of health.

Prepare a real example such as a test that intermittently opened the wrong tab. The durable pattern is to start waiting for the popup event before triggering the click, then interact with the returned page. Explain why event ordering mattered and how the trace confirmed it.

Answer design exercises through constraints

A common final prompt is “Design a Playwright framework for our application.” Ask about product architecture, browser support, test layers, environments, deployment frequency, team language, authentication, data ownership, CI budget, and current failures. A framework without those inputs is decoration.

Calibrate your response:

For a coding exercise, narrate why each locator and assertion is stable. Include teardown only when the created state needs it, and make cleanup resilient enough to run after a failed assertion. If time is limited, finish one coherent journey rather than scaffolding a large framework.

Close your preparation by rebuilding one flaky test from first principles. Define the prerequisite state, observable action, business result, isolation boundary, and failure artifacts. That exercise demonstrates the judgment behind Playwright's convenience features, which is what deeper interviews are designed to find.