Playwright Scenario Based Interview Questions: Real-World Problems and Answers

Leave a Comment / Uncategorized / By

Introduction: Why Playwright Scenario Based Interview Questions Matter

Modern Playwright interviews are moving beyond basic questions such as “What is Playwright?” and “Which browsers does Playwright support?”

Companies want engineers who can solve automation problems.

An interviewer may give you a situation such as:

“Your Playwright test passes 20 times locally but fails randomly in CI. What would you investigate?”

There is no single API call that answers this question.

You need to demonstrate knowledge of:

That is why Playwright scenario based interview questions are particularly important for QA Automation Engineers, SDETs, Senior SDETs, and QA Leads.

A strong candidate doesn’t immediately change the code.

Instead, they explain:

Problem → Investigation → Root Cause → Solution → Prevention

This guide covers practical Playwright real-time interview questions, troubleshooting scenarios, framework decisions, CI/CD problems, and TypeScript coding situations.

How to Answer Playwright Scenario Based Interview Questions

Before looking at individual scenarios, use this five-step structure.

1. Understand the failure

Ask:

  • What exactly failed?
  • Is it reproducible?
  • Is it browser-specific?
  • Is it environment-specific?
  • Is it data-specific?

2. Investigate before changing code

Use:

3. Identify the root cause

Common categories are:

Locator

Synchronization

Test Data

Authentication

Application

Browser

Environment

Infrastructure

4. Apply the smallest correct solution

Don’t add arbitrary waits or increase timeouts without understanding the problem.

5. Prevent recurrence

For example, if parallel execution exposed shared test data, redesign the data strategy rather than reducing workers.

Strong interview formula:

“First I would reproduce and classify the failure. Then I would inspect the trace and relevant logs, identify the root cause, apply a targeted fix, and add isolation or monitoring so the problem does not return.”

Locator and Element-Related Playwright Scenario Based Interview Questions

Scenario 1: Locator Matches Multiple Elements

Scenario

You write:

await page.getByRole(‘button’, {

  name: ‘Delete’

}).click();

The test fails with a strict-mode violation because several Delete buttons exist.

What Would You Do?

I would make the locator specific using the surrounding business context.

Root Cause

The locator describes multiple elements instead of one unique element.

Solution

const customerRow = page.getByRole(‘row’, {

  name: ‘John Smith’

});

await customerRow.getByRole(‘button’, {

  name: ‘Delete’

}).click();

Interview-Ready Answer

“I would not immediately use .nth(0). I would first understand why multiple elements match and make the locator unique using semantic context such as a row, card, label, or test ID.”

Interview Tip

This demonstrates that you understand locator quality, not just Playwright syntax.

Follow-up: When would you use getByTestId()?

A good answer:

“I would use a stable test ID when semantic locators are unavailable or when the application team has intentionally provided stable automation attributes.”

Scenario 2: Element Is Visible but Click Fails

Scenario

The button is visible in the trace, but:

await page.getByRole(‘button’, {

  name: ‘Submit’

}).click();

fails.

What Would You Do?

Check whether the element is:

  • Covered by another element
  • Disabled
  • Moving due to animation
  • Outside the expected frame
  • Affected by an overlay

Root Cause

Visibility alone does not guarantee that an element is actionable.

Solution

Inspect the trace and page state.

const button = page.getByRole(‘button’, {

  name: ‘Submit’

});

await expect(button).toBeVisible();

await expect(button).toBeEnabled();

await button.click();

Avoid immediately doing:

await button.click({ force: true });

Interview-Ready Answer

“I would determine why the normal actionability checks fail. I would use force clicking only when I understand and intentionally accept the application’s behavior.”

Interview Tip

Interviewers often use this scenario to test whether you understand Playwright’s actionability checks.

Scenario 3: Element Is Detached From the DOM

Scenario

A test finds an element, but during the action the application rerenders and the element is replaced.

Root Cause

Modern reactive applications frequently recreate DOM nodes.

Solution

Use a Locator instead of storing an outdated element reference.

const saveButton = page.getByRole(‘button’, {

  name: ‘Save’

});

await saveButton.click();

Locators resolve the element when the action occurs.

Interview-Ready Answer

“I would use Playwright Locators because they are designed for dynamic pages and resolve the current element when an operation is performed.”

Interview Tip

Mention React, Angular, or other dynamically rendered applications when explaining DOM replacement.

Wait, Timeout, and Synchronization Scenarios

Scenario 4: Test Randomly Times Out

Scenario

A checkout test sometimes fails with a timeout:

Timeout 30000ms exceeded

What Would You Do?

First determine which operation timed out.

Root Causes

Possible causes include:

  • Incorrect locator
  • Slow API
  • Application race condition
  • Authentication issue
  • Test-data problem
  • CI resource contention

Solution

Use the trace to determine exactly where the test stopped.

Prefer:

await expect(

  page.getByText(‘Order Confirmed’)

).toBeVisible();

instead of:

await page.waitForTimeout(5000);

Interview-Ready Answer

“I would not immediately increase the timeout. I would identify what the test was waiting for and determine whether the problem was synchronization, application performance, data, or infrastructure.”

Interview Tip

This is one of the most common Playwright troubleshooting interview questions.

Scenario 5: Element Takes Several Seconds to Appear

What Would You Do?

Use Playwright’s automatic waiting and web-first assertions.

await expect(

  page.getByRole(‘heading’, {

    name: ‘Payment Successful’

  })

).toBeVisible();

Interview-Ready Answer

“I would wait for the meaningful application state rather than adding a fixed delay.”

Login and Authentication Scenarios

Scenario 6: Login Session Expires During Execution

Scenario

A long regression suite begins failing after several hours because authentication tokens expire.

Root Cause

The suite assumes authentication state remains valid for the entire execution.

Solution

Possible approaches include:

Example:

await page.context().storageState({

  path: ‘playwright/.auth/user.json’

});

Interview-Ready Answer

“I would treat authentication state as an execution dependency. I would generate or refresh it according to token lifetime rather than assuming one static state file is valid indefinitely.”

Interview Tip

Do not expose real credentials or authentication tokens in source control.

Scenario 7: Authentication Works Locally but Fails in CI

Possible Causes

  • Missing CI secrets
  • Incorrect base URL
  • Different environment
  • Expired state
  • Redirect differences
  • Network restrictions
  • Authentication service unavailable

Debugging

Check:

BASE_URL

Username/secret configuration

Redirect URL

Authentication API

Storage state

CI network access

Interview-Ready Answer

“I would compare the authentication flow and environment configuration between local and CI, then inspect the trace rather than assuming the login locator is wrong.”

Page Object Model and Framework Scenarios

Scenario 8: Page Object Has Become Huge

Scenario

A BasePage contains hundreds of methods:

click()

fill()

wait()

login()

search()

database()

api()

download()

upload()

What Would You Do?

Break the abstraction into business pages and reusable components.

pages/

    LoginPage.ts

    CheckoutPage.ts

    DashboardPage.ts

components/

    Header.ts

    ProductCard.ts

    OrderTable.ts

Interview-Ready Answer

“I would avoid a giant BasePage because it creates tight coupling and becomes difficult to maintain. I prefer focused Page Objects and composable components.”

Interview Tip

This is a framework-design question disguised as a POM question.

Scenario 9: Tests Contain Repeated Login Code

Problem

Every test contains:

await page.goto(‘/login’);

await page.getByLabel(‘Username’).fill(username);

await page.getByLabel(‘Password’).fill(password);

await page.getByRole(‘button’, {

  name: ‘Login’

}).click();

Solution

Use a Page Object or authentication fixture.

class LoginPage {

  constructor(private page: Page) {}

  async login(username: string, password: string) {

    await this.page.getByLabel(‘Username’).fill(username);

    await this.page.getByLabel(‘Password’).fill(password);

    await this.page.getByRole(‘button’, {

      name: ‘Login’

    }).click();

  }

}

Interview Tip

Explain the difference between reusable business behavior and simply wrapping every Playwright method.

Fixtures and Test-Data Scenarios

Scenario 10: Parallel Tests Modify the Same Customer

Scenario

Test A updates:

customer@example.com

while Test B deletes the same customer.

Both tests pass individually but fail in parallel.

Root Cause

Shared mutable test data.

Solution

Generate unique data.

import crypto from ‘node:crypto’;

const id = crypto.randomUUID();

const user = {

  email: `qa-${id}@example.com`,

  name: `Automation ${id}`

};

Interview-Ready Answer

“The problem is not parallel execution itself. The tests are not isolated. I would create worker- or test-specific data and ensure each test owns its resources.”

Interview Tip

This is a key distinction between scaling execution and simply increasing worker count.

Scenario 11: How Would You Use a Custom Fixture?

import { test as base } from ‘@playwright/test’;

type Fixtures = {

  testUser: {

    email: string;

  };

};

export const test = base.extend<Fixtures>({

  testUser: async ({}, use) => {

    const email =

      `qa-${Date.now()}@example.com`;

    await use({ email });

  }

});

Then:

test(‘profile’, async ({

  page,

  testUser

}) => {

  console.log(testUser.email);

  await page.goto(‘/profile’);

});

Interview-Ready Answer

“I use custom fixtures for reusable setup and dependencies while keeping individual tests isolated.”

API Testing and Network Mocking Scenarios

Scenario 12: API Response Is Inconsistent

Scenario

The same API occasionally returns:

200

and sometimes:

500

What Would You Do?

Don’t automatically retry the API until it passes.

Investigate:

  • Request payload
  • Authentication
  • Backend state
  • Test data
  • Environment
  • Server logs
  • Network conditions

API Example

const response = await request.get(

  ‘/api/orders/1001’

);

console.log(response.status());

console.log(await response.text());

expect(response.ok()).toBeTruthy();

Interview-Ready Answer

“I would establish whether the inconsistency is an application defect, environment problem, data issue, or test problem before introducing retries.”

Scenario 13: A Third-Party Payment API Is Unavailable

What Would You Do?

Mock the dependency for deterministic UI testing.

await page.route(

  ‘**/api/payment’,

  async route => {

    await route.fulfill({

      status: 200,

      contentType: ‘application/json’,

      body: JSON.stringify({

        status: ‘approved’

      })

    });

  }

);

await page.goto(‘/checkout’);

Interview-Ready Answer

“I would mock the external dependency for controlled functional scenarios, while keeping separate integration tests that validate the real integration.”

Interview Tip

This answer demonstrates test-layer thinking.

Parallel Execution and Flaky-Test Scenarios

Scenario 14: Test Becomes Flaky After Enabling Parallel Execution

Root Causes

  • Shared data
  • Shared files
  • Shared accounts
  • Global application state
  • Database contention
  • Environment limitations

Solution

First isolate resources.

Then tune workers:

export default defineConfig({

  fullyParallel: true,

  workers: process.env.CI ? 4 : undefined

});

Interview-Ready Answer

“I would not disable parallel execution immediately. I would identify the shared resource that makes the tests dependent on execution order.”

Interview Tip

This is an important senior-level answer.

Scenario 15: How Would You Handle Flaky Tests?

What Would You Do?

Create a classification system:

Locator flake

Timing flake

Data flake

Network flake

Environment flake

Application flake

Then track:

  • Failure frequency
  • First failure
  • Browser
  • Environment
  • Test owner
  • Root cause
  • Fix status

Retries can be configured:

export default defineConfig({

  retries: process.env.CI ? 2 : 0

});

Interview-Ready Answer

“Retries are a containment mechanism, not a permanent flaky-test solution. I would identify the underlying cause and track flakiness over time.”

Cross-Browser and Mobile Testing Scenarios

Scenario 16: Chromium Passes but Firefox Fails

What Would You Do?

Run the test specifically:

npx playwright test \

  –project=firefox

Inspect:

  • Locator behavior
  • Rendering
  • JavaScript behavior
  • Network timing
  • Application compatibility

Interview-Ready Answer

“First I would determine whether Playwright automation or the application is responsible. Browser-specific failures can reveal genuine product compatibility defects.”

Scenario 17: Desktop Test Must Also Run on Mobile

Configure a project:

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

export default defineConfig({

  projects: [

    {

      name: ‘desktop’,

      use: {

        …devices[‘Desktop Chrome’]

      }

    },

    {

      name: ‘mobile’,

      use: {

        …devices[‘iPhone 13’]

      }

    }

  ]

});

Interview Tip

Explain that device emulation tests browser behavior and responsive layouts under emulated conditions. It is not identical to testing every physical device.

Screenshot, Trace, Video, and Reporting Scenarios

Scenario 18: Screenshot Comparison Fails

Possible Causes

  • Actual UI regression
  • Different browser
  • Different viewport
  • Font rendering
  • Dynamic content
  • Animation
  • Date/time differences

What Would You Do?

Inspect the diff and trace before updating the baseline.

Interview-Ready Answer

“I would first determine whether the visual change is intentional. Updating the baseline without investigation could hide a real regression.”

Scenario 19: Report Is Not Generated in CI

Configure:

reporter: [

  [‘html’, { open: ‘never’ }],

  [‘list’]

]

And upload artifacts:

– name: Upload report

  if: always()

  uses: actions/upload-artifact@v4

  with:

    name: playwright-report

    path: playwright-report/

Interview Tip

The if: always() condition is important because a failing test job should still preserve diagnostic artifacts.

Scenario 20: How Do You Debug a CI Failure?

Use:

use: {

  trace: ‘retain-on-failure’,

  screenshot: ‘only-on-failure’,

  video: ‘retain-on-failure’

}

Then:

npx playwright show-trace trace.zip

Interview-Ready Answer

“I want the CI run to preserve enough evidence that I can diagnose the failure without reproducing it immediately on my laptop.”

CI/CD and GitHub Actions Scenarios

Scenario 21: Pull Requests Are Taking 45 Minutes

What Would You Do?

Do not simply add more workers.

First measure:

Browser startup

Test duration

Setup duration

API dependencies

Worker utilization

CI machine resources

Slow tests

Serial tests

Then consider:

PR smoke suite

+

Parallel workers

+

Selective browser matrix

+

Sharding for larger suites

Example

– run: npx playwright test –grep @smoke

Interview-Ready Answer

“I would optimize the test portfolio and infrastructure together. Fast PR feedback does not require running the entire release regression suite on every commit.”

Docker and Environment Scenarios

Scenario 22: Playwright Browser Is Not Installed

Problem

CI reports a browser executable error.

Solution

Install browsers:

npx playwright install

On Linux CI:

npx playwright install –with-deps chromium

Interview-Ready Answer

“I would verify that the Playwright package version and browser binaries are installed consistently in the CI environment.”

Interview Tip

Browser binaries and the Playwright package need compatible setup.

Scenario 23: Docker Tests Fail but Local Tests Pass

Root Causes

  • Missing system dependencies
  • Different fonts
  • Different environment variables
  • File permissions
  • Different timezone
  • Browser configuration
  • Network access

Debugging

Run the same test inside the container interactively and inspect:

Python/Node version

Playwright version

Browser version

Environment variables

Filesystem

Network

Interview-Ready Answer

“I would reproduce the failure inside the same container rather than comparing the container with my local machine indirectly.”

Advanced Enterprise Playwright Scenarios

Scenario 24: You Have 5,000 Playwright Tests. How Would You Scale Them?

What Would You Do?

Separate the problem into four areas.

1. Test architecture

Tests

Pages

Components

Fixtures

API

Data

Authentication

Utilities

2. Execution

Workers

+

Projects

+

Sharding

3. Infrastructure

CI machines

Docker

Browser matrix

Artifact storage

4. Quality

Flaky-test detection

Ownership

Reporting

Test prioritization

Interview-Ready Answer

“I would not solve a 5,000-test problem only by increasing workers. I would optimize architecture, test isolation, data creation, browser coverage, CI distribution, and flaky-test management.”

Scenario 25: How Would You Design a Browser Matrix?

A practical strategy might be:

PipelineChromiumFirefoxWebKitMobile
Local✓
Pull Request✓✓
Nightly✓✓✓✓
Release✓✓✓Critical devices

Interview-Ready Answer

“Browser coverage should be risk-based. Running every test against every browser on every PR can increase feedback time without proportional value.”

Scenario 26: How Would You Migrate a Selenium Framework to Playwright?

Approach

Current Selenium Suite

        ↓

Identify critical workflows

        ↓

Playwright proof of concept

        ↓

Compare stability and speed

        ↓

Define coding standards

        ↓

Migrate high-value tests

        ↓

CI integration

        ↓

Gradual expansion

Interview-Ready Answer

“I would avoid a big-bang migration. I would migrate incrementally and measure reliability, maintenance effort, execution time, and coverage.”

Playwright Coding Scenarios With TypeScript

Scenario 27: Create a Robust Login Test

import { test, expect } from ‘@playwright/test’;

test(‘successful login’, async ({ page }) => {

  await page.goto(‘/login’);

  await page.getByLabel(‘Username’)

    .fill(process.env.TEST_USERNAME!);

  await page.getByLabel(‘Password’)

    .fill(process.env.TEST_PASSWORD!);

  await page.getByRole(‘button’, {

    name: ‘Login’

  }).click();

  await expect(page).toHaveURL(

    /dashboard/

  );

  await expect(

    page.getByRole(‘heading’, {

      name: ‘Dashboard’

    })

  ).toBeVisible();

});

Interview Explanation

The test:

  1. Navigates to the login page.
  2. Uses semantic locators.
  3. Retrieves credentials from environment variables.
  4. Performs login.
  5. Validates URL.
  6. Validates a meaningful UI state.

Scenario 28: Create a Page Object

import { Page } from ‘@playwright/test’;

export class CheckoutPage {

  constructor(private readonly page: Page) {}

  private address =

    this.page.getByLabel(‘Address’);

  private placeOrderButton =

    this.page.getByRole(‘button’, {

      name: ‘Place order’

    });

  async completeOrder(address: string) {

    await this.address.fill(address);

    await this.placeOrderButton.click();

  }

}

Test:

import { test } from ‘@playwright/test’;

import { CheckoutPage } from ‘../pages/CheckoutPage’;

test(‘complete checkout’, async ({ page }) => {

  await page.goto(‘/checkout’);

  const checkout = new CheckoutPage(page);

  await checkout.completeOrder(

    ‘123 Main Street’

  );

});

Interview Tip

Explain that the Page Object exposes business actions, not unnecessary low-level implementation details.

Scenario 29: Create API Data Before a UI Test

import { test, expect } from ‘@playwright/test’;

test(‘verify newly created product’, async ({

  request,

  page

}) => {

  const response = await request.post(

    ‘/api/products’,

    {

      data: {

        name: ‘Automation Laptop’,

        price: 999

      }

    }

  );

  expect(response.ok()).toBeTruthy();

  const product = await response.json();

  await page.goto(

    `/products/${product.id}`

  );

  await expect(

    page.getByText(‘Automation Laptop’)

  ).toBeVisible();

});

Interview-Ready Answer

“I use the API to create controlled preconditions quickly, then use the UI to validate the customer workflow.”

Common Mistakes in Playwright Scenario-Based Interviews

1. Jumping directly to code

First explain your investigation.

2. Using waitForTimeout() as the universal solution

Explain state-based synchronization.

3. Increasing timeouts without investigation

A timeout may indicate an application or data problem.

4. Disabling parallel execution

Fix test isolation instead.

5. Using retries to hide flakiness

Find the root cause.

6. Using force: true immediately

Understand why actionability fails.

7. Reusing shared test accounts

Parallel tests can interfere with each other.

8. Updating screenshot baselines blindly

First determine whether the change is intentional.

9. Blaming Playwright for browser-specific failures

Investigate the application too.

10. Giving theoretical answers

Scenario questions require decision-making.

Playwright Scenario-Based Interview Preparation Roadmap

Level 1: Beginner

Prepare:

  • Locator failures
  • Assertion failures
  • Auto-waiting
  • Timeouts
  • Login automation
  • Screenshots
  • Basic browser problems

Level 2: Intermediate

Prepare:

  • POM
  • Fixtures
  • Authentication
  • API setup
  • Network mocking
  • Cross-browser testing
  • Reporting

Level 3: Senior SDET

Prepare:

  • Parallel execution
  • Test-data conflicts
  • CI/CD
  • Docker
  • Flaky-test management
  • Sharding
  • Framework architecture

Level 4: QA Lead / Automation Architect

Prepare:

  • Enterprise architecture
  • Migration strategy
  • Browser matrix
  • Test governance
  • Ownership
  • Observability
  • Infrastructure cost
  • Risk-based test execution
  • Large-suite optimization

Interview-Day Checklist

Before your interview, make sure you can explain:

FAQs About Playwright Scenario Based Interview Questions

What are Playwright scenario based interview questions?

They are practical interview questions where candidates must explain how they would solve real automation problems such as flaky tests, locator failures, CI failures, authentication issues, parallel execution conflicts, and browser-specific failures.

How should I answer Playwright scenario-based questions?

Use this structure:

Problem → Investigation → Root Cause → Solution → Prevention

This demonstrates practical engineering judgment.

What is the most common Playwright troubleshooting scenario?

A common scenario is a test that passes locally but fails in CI. Candidates should investigate environment configuration, timing, authentication, test data, browser versions, infrastructure, and application behavior.

Why do Playwright tests become flaky?

Common causes include race conditions, weak locators, shared test data, network instability, authentication expiration, animations, browser differences, and infrastructure contention.

Should I use retries for flaky Playwright tests?

Retries can help identify or temporarily contain transient failures, but they should not replace root-cause analysis and stabilization.

How do I handle Playwright tests that fail only in Firefox?

Run the test specifically in Firefox, inspect the trace, verify locators and application behavior, and determine whether the issue is in the automation or the application.

How do I scale Playwright tests?

Use appropriate test isolation, parallel workers, CI sharding, API-based setup, authentication reuse, risk-based browser matrices, optimized fixtures, and reliable reporting.

What scenario questions should a senior SDET prepare?

Senior candidates should prepare framework architecture, large-suite optimization, CI/CD bottlenecks, flaky-test management, sharding, test-data isolation, cross-browser strategy, Docker, authentication architecture, and Selenium-to-Playwright migration scenarios.

Leave a Comment

Your email address will not be published. Required fields are marked *