Playwright Scenario-Based Interview Questions and Answers (25 Real Scenarios)

Answer: First I open the trace for a failing run to see what the page looked like at the moment of failure. The usual cause is that the test checks the page before the app has finished loading, often because of a manual check such as isVisible() that doesn't wait. I replace it with a web-first assertion, which retries until the condition is true or the timeout ends.

// Flaky: isVisible() returns immediately, no retry
expect(await page.getByRole('alert').isVisible()).toBe(true);

// Stable: retries until visible (default 5s expect timeout)
await expect(page.getByRole('alert')).toBeVisible();

To prevent it, I enable trace: 'on-first-retry' in the config so every CI failure comes with evidence, and I add a lint rule against waitForTimeout.

Answer: A fixed wait either wastes time on fast runs or still fails on slow ones. I ask what the test is really waiting for — a network response, a spinner disappearing, or text appearing — and wait for that instead.

// Wait for the API call the button triggers
const responsePromise = page.waitForResponse(
  (res) => res.url().includes('/api/orders') && res.status() === 200
);
await page.getByRole('button', { name: 'Place order' }).click();
await responsePromise;

// Or wait for the loading state to finish
await expect(page.getByTestId('spinner')).toBeHidden();

Answer: Playwright's actionability checks already wait for the element to be visible, stable, enabled and to receive events. If the click still lands on the overlay, I wait for the overlay to go away with await expect(overlay).toBeHidden(). I avoid { force: true } because it skips those checks and can hide a real bug where users can't click the button either.

Answer: Retries keep the pipeline moving but hide problems. Playwright marks tests that pass on retry as flaky in the report, so I track that number every week, fix the top offenders, and keep retries at 1 or 2 in CI and 0 locally.

Answer: I move to user-facing locators that follow what the user sees, in this order: getByRole, getByLabel, getByText, then getByTestId for elements with no accessible name. I also agree a data-testid convention with developers for complex widgets.

// Brittle
await page.locator('.btn.btn-primary.mt-3').click();

// Resilient
await page.getByRole('button', { name: 'Save changes' }).click();
await page.getByLabel('Email').fill('qa@example.com');

More patterns are in our complete guide to Playwright locators.

Answer: Filter the rows by text, then find the button inside that row, so the test doesn't depend on row position.

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

Answer: The locator matched more than one element, and Playwright refuses to guess which one to act on. I make the locator more specific (filter by text, scope it inside a parent region) rather than using .first(), because .first() silently picks the wrong element when the page order changes.

Answer: Type the text, then wait for the exact option with an assertion before clicking it. The locator is re-evaluated each time, so it handles the list re-rendering.

await page.getByRole('combobox', { name: 'Search' }).fill('playwr');
const option = page.getByRole('option', { name: 'Playwright' });
await expect(option).toBeVisible();
await option.click();

Answer: Log in once in a setup project, save the session with storageState, and let every test start already signed in.

// auth.setup.ts
import { test as setup, expect } from '@playwright/test';

setup('authenticate', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.TEST_USER!);
  await page.getByLabel('Password').fill(process.env.TEST_PASS!);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('link', { name: 'My account' })).toBeVisible();
  await page.context().storageState({ path: 'playwright/.auth/user.json' });
});

// playwright.config.ts (projects)
// { name: 'setup', testMatch: /.*\.setup\.ts/ },
// { name: 'chromium', use: { storageState: 'playwright/.auth/user.json' }, dependencies: ['setup'] }

I keep one UI login test so the login page itself is still covered, and I add the .auth folder to .gitignore so session files never reach the repository.

Answer: Create two browser contexts. Each context is an isolated session with its own cookies, like two separate browsers.

test('buyer and seller chat', async ({ browser }) => {
  const buyer = await browser.newContext({ storageState: 'playwright/.auth/buyer.json' });
  const seller = await browser.newContext({ storageState: 'playwright/.auth/seller.json' });
  const buyerPage = await buyer.newPage();
  const sellerPage = await seller.newPage();

  await buyerPage.goto('/messages/seller-1');
  await buyerPage.getByRole('textbox', { name: 'Message' }).fill('Is this available?');
  await buyerPage.getByRole('button', { name: 'Send' }).click();

  await sellerPage.goto('/messages/buyer-1');
  await expect(sellerPage.getByText('Is this available?')).toBeVisible();

  await buyer.close();
  await seller.close();
});

Answer: I wouldn't automate the real SMS. I'd ask the team for a test-only route: a fixed OTP in the test environment, an API that returns the latest code for a test number, or an endpoint that creates a session directly. Then I save that session with storageState. I'd test the real OTP screen with a mocked response, and leave the real SMS delivery to a small manual or monitoring check.

Answer: For UI tests, I mock the call with page.route() so the test checks our checkout behaviour, not the sandbox's uptime. I keep a separate, smaller set of tests against the real sandbox that runs nightly, so integration problems are still caught.

await page.route('**/api/payments/charge', (route) =>
  route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ status: 'captured', id: 'pay_test_123' }),
  })
);

The trade-off: mocks hide real API changes, so I keep mock data in line with the real API contract.

Answer: Force the error with a route, then assert on the message.

await page.route('**/api/profile', (route) => route.fulfill({ status: 500 }));
await page.goto('/profile');
await expect(page.getByText('Something went wrong. Please try again.')).toBeVisible();

Answer: Create data through the API using Playwright's built-in request fixture, then use the UI only for the behaviour being tested.

test('edit an existing order', async ({ page, request }) => {
  const res = await request.post('/api/orders', { data: { item: 'Notebook', qty: 2 } });
  expect(res.ok()).toBeTruthy();
  const { id } = await res.json();

  await page.goto('/orders/' + id);
  await page.getByRole('button', { name: 'Edit' }).click();
  // ...
});

We cover this pattern in depth in the Playwright API testing guide.

Answer: Wait for the request and inspect its body.

const requestPromise = page.waitForRequest('**/api/settings');
await page.getByRole('button', { name: 'Save' }).click();
const req = await requestPromise;
expect(req.method()).toBe('PUT');
expect(req.postDataJSON()).toMatchObject({ newsletter: true });

Answer: A page locator doesn't look inside iframes. Use frameLocator to step into the frame first.

const card = page.frameLocator('iframe[title="Secure card payment"]');
await card.getByLabel('Card number').fill('4111 1111 1111 1111');

Answer: Start waiting for the new page before the click, then work with it.

const popupPromise = page.context().waitForEvent('page');
await page.getByRole('link', { name: 'View invoice' }).click();
const invoice = await popupPromise;
await invoice.waitForLoadState();
await expect(invoice.getByRole('heading', { name: /Invoice/ })).toBeVisible();

Answer: Use setInputFiles for uploads and the download event for downloads.

await page.getByLabel('Upload resume').setInputFiles('fixtures/resume.pdf');
await expect(page.getByText('resume.pdf')).toBeVisible();

const downloadPromise = page.waitForEvent('download');
await page.getByRole('button', { name: 'Download report' }).click();
const download = await downloadPromise;
expect(download.suggestedFilename()).toMatch(/report.*\.csv$/);

Answer: By default Playwright dismisses dialogs automatically, so the delete is cancelled and the test waits for something that never happens. Register a dialog handler before the click and accept it.

page.once('dialog', (dialog) => dialog.accept());
await page.getByRole('button', { name: 'Delete account' }).click();

Answer: Shared state — usually the same user account or data record changed by two workers at once. I give each worker its own data, for example by creating a unique user per test or per worker in a fixture, and I make sure no test depends on another test's leftovers. testInfo.workerIndex or a unique id helps create separate data.

Answer: In order: move data setup to API calls, reuse login with storageState, raise workers to match the CI machine, then split the run across machines with sharding.

npx playwright test --shard=1/4
npx playwright test --shard=2/4
# ...run each shard on a separate CI job, then merge reports
npx playwright merge-reports --reporter html ./all-blob-reports

I'd also tag a fast smoke set with @smoke and run it on every pull request, leaving the full suite for merges.

Answer: Turn on traces, screenshots and video for failures, download the artifacts and open the trace with npx playwright show-trace trace.zip. The trace shows each action, the page snapshot, console logs and network calls. Common causes I check: a different viewport or timezone, headless rendering, slower CI machines, and missing environment variables.

Answer: Create custom fixtures with test.extend, combined with page objects, so each test asks for what it needs.

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

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

See the Playwright fixtures deep dive for more patterns.

Answer: Define projects in the config. Each project runs the full suite with its own browser or device settings.

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

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'mobile', use: { ...devices['Pixel 7'] } },
  ],
});

Answer: Functional assertions don't check layout. I'd add screenshot comparisons on a few key pages with await expect(page).toHaveScreenshot(), masking changing content such as dates, and run them on one fixed browser and OS so the baseline images stay stable. Our visual regression testing guide covers the setup.