Cross-Browser Testing Interview Questions 2026 — Playwright Multi-Browser Support for Chromium, Firefox, and WebKit, Selenium Grid vs Cloud Providers (BrowserStack, Sauce Labs, LambdaTest), Visual Regression Testing with Percy and Playwright Screenshots, Browser-Specific Bug Detection and Debugging Strategies, Responsive and Device Testing Strategy, When Cross-Browser Testing Matters vs When It's Unnecessary, and How to Balance Coverage Against Execution Speed — With Playwright/TypeScript Code Examples

It's Friday afternoon. The sprint ends in three hours. Your pipeline just turned red on Firefox — again — and the same test passed perfectly on Chromium twenty minutes ago. The developer is already packing up. The product manager is asking whether we can just "ship it on Chrome and fix Firefox later." Your automation suite takes 45 minutes to run across three browsers, and every CI run feels like a tax on velocity. Meanwhile, you've got an SDET interview on Tuesday, and you know — with the certainty that only pre-interview anxiety can provide — that someone on the panel is going to ask: "How do you approach cross-browser testing? What's your strategy for balancing coverage against speed? How do you decide which browsers to test?" You have experience running tests on multiple browsers, but do you have a strategy? Could you defend it? Could you whiteboard the architecture? Could you explain why Playwright's multi-browser model is fundamentally different from Selenium Grid's — and why that difference matters at scale? If the answer to any of those questions is "I'm not sure," you're in the right place.

Cross-browser testing is one of those topics that seems simple on the surface — "just run the same tests on Chrome, Firefox, and Safari" — until you've actually done it at scale. Then you discover that browsers don't agree on how CSS Grid works, that Safari's WebKit engine handles cookies differently than Chromium, that Firefox's geolocation API returns promises where Chrome returns callbacks, that visual diffs between browsers are a bottomless pit of false positives, and that running your full suite across six browser/OS combinations takes longer than the lunch break you're about to skip for the third day in a row. The engineers who excel at cross-browser testing interviews aren't the ones who've memorised every browser quirk. They're the ones who can articulate a decision framework — who can explain not just how to test across browsers, but why you'd test certain browsers for certain applications, when cross-browser testing is worth the investment, and what trade-offs you're making when you limit your browser matrix. This guide gives you those frameworks.

Inside: a complete breakdown of Playwright's multi-browser engine architecture and how it differs from WebDriver-based approaches, the Selenium Grid vs cloud provider decision matrix with real cost and maintenance trade-offs, visual regression testing strategies from Percy pipelines to Playwright's built-in screenshot comparison with practical threshold configuration, browser-specific bug detection patterns and debugging workflows using Trace Viewer and DevTools, responsive and device testing strategy with viewport matrices and priority tiers, the decision framework Mitchell has used across government and enterprise projects for determining whether cross-browser testing is essential, a cost-of-omission model or unnecessary overhead, and practical patterns for balancing browser coverage against CI/CD execution speed using sharding, risk-based selection, and parallelisation. Every section includes Playwright/TypeScript code examples you can adapt immediately, and everything is mapped to the interview questions Mitchell's panels have asked consistently across two decades of SDET hiring. The SDET Interview Coach iOS app includes a dedicated cross-browser testing topic with 25+ mock interview questions that test exactly the frameworks in this guide — download it and practise before your interview.

Playwright Multi-Browser Engine Architecture — What Every SDET Interviewer Expects You to Know

The single most important thing to understand about Playwright's cross-browser model — and the thing interviewers are probing for when they ask "why Playwright instead of Selenium?" — is that Playwright doesn't use a protocol translation layer. Selenium speaks the WebDriver protocol (W3C standard), which each browser vendor implements independently, which means every browser supports a slightly different subset of commands, with slightly different timing characteristics, and slightly different edge-case behaviour. Playwright speaks each browser's native debugging protocol directly: Chrome DevTools Protocol (CDP) for Chromium, Firefox's remote protocol for Firefox, and WebKit's remote debugging protocol for Safari/WebKit. This architectural difference has profound implications for reliability, speed, and capability:

In an interview, the answer that scores highest isn't "Playwright is better" — it's the answer that demonstrates you understand why the architecture creates those differences, and that you can articulate the trade-offs in specific, technical terms. The WebDriver model has one genuine advantage: it's a W3C standard, which means any WebDriver-compliant tool (Selenium, Appium, WebDriverIO) can theoretically drive any WebDriver-compliant browser. Playwright's per-engine approach means the Playwright team must build and maintain a separate protocol integration for each browser engine — which they do, excellently, but it's a dependency they own rather than a standard they consume. Understanding that trade-off signals architectural thinking, not tool evangelism.

Here's how you configure Playwright for multi-browser execution — and more importantly, how you explain each configuration decision in an interview:

// playwright.config.ts — Multi-browser project configuration
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  // Global timeout: 60s per test. Cross-browser tests need a bit more
  // headroom because Firefox cold-start is slower than Chromium.
  timeout: 60_000,

  // Retry flaky tests once on CI, never locally.
  // Browser-specific flakes (looking at you, Safari animations) are real —
  // but retrying masks them. Use retries as a safety net, not a strategy.
  retries: process.env.CI ? 1 : 0,

  // Run tests in parallel within each browser project.
  // Fully-parallel mode gives the fastest wall-clock time but requires
  // test isolation — no shared state between test files.
  fullyParallel: true,

  // Workers: number of parallel test files per browser project.
  // On CI with 4 CPUs, 3 workers per browser × 3 browsers = 9 concurrent tests.
  workers: process.env.CI ? 3 : undefined,

  projects: [
    // === Chromium (Desktop Chrome + Edge) ===
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        // Channel: 'chrome' uses the installed Chrome binary.
        // Use 'chromium' (no channel) for the bundled Chromium.
        channel: 'chrome',
        // Viewport: override device defaults if needed.
        viewport: { width: 1440, height: 900 },
      },
    },

    // === Firefox ===
    {
      name: 'firefox',
      use: {
        ...devices['Desktop Firefox'],
        viewport: { width: 1440, height: 900 },
      },
    },

    // === WebKit (Safari engine) ===
    {
      name: 'webkit',
      use: {
        ...devices['Desktop Safari'],
        viewport: { width: 1440, height: 900 },
      },
    },

    // === Mobile Chrome (Pixel 7 emulation) ===
    {
      name: 'mobile-chrome',
      use: {
        ...devices['Pixel 7'],
        // isMobile: true triggers touch events, mobile user-agent,
        // and mobile-appropriate viewport defaults.
      },
    },

    // === Mobile Safari (iPhone 14 emulation) ===
    {
      name: 'mobile-safari',
      use: {
        ...devices['iPhone 14'],
      },
    },
  ],

  // Web server: start the app before tests.
  webServer: {
    command: 'npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});

The critical interview point here isn't the config syntax — it's the project model. Playwright's project-based architecture lets you define each browser/device combination as a separate project with its own configuration, while sharing the same test files. This means you write your tests once and Playwright handles the matrix multiplication. When an interviewer asks "how would you structure cross-browser tests?", the answer they want isn't "I'd write separate test files for each browser" — it's "I'd use a project-based configuration where browser targets are declarative, tests are shared, and CI can selectively run subsets of the matrix based on risk, change detection, or cost constraints." That's the difference between someone who's run cross-browser tests and someone who's architected a cross-browser strategy.

Selenium Grid vs Cloud Providers — The Decision Framework Interviewers Test

Every cross-browser testing interview eventually reaches the infrastructure question: "Do you use Selenium Grid, a cloud provider, or something else — and why?" The wrong answer is a one-word brand name. The right answer is a decision framework that considers cost, maintenance burden, browser coverage requirements, execution speed, debugging tooling, and organisational constraints. Here's the framework Mitchell has used to evaluate this decision across government projects (where cloud providers were often blocked by security policy) and private-sector roles (where speed-to-market drove the decision in the opposite direction):

The hybrid strategy — which scores highest in interviews because it demonstrates pragmatic thinking — is: run your primary browser (Chromium) on CI with Playwright's built-in browser binaries (fast, free, zero infrastructure), and use a cloud provider for the long-tail of browser/OS/device combinations that matter for your audience but don't justify dedicated infrastructure. This gives you fast feedback on every commit (Chromium CI run takes 3-5 minutes) and comprehensive coverage on a schedule (full cross-browser suite runs nightly or pre-release, takes 20-40 minutes on the cloud). You're not choosing between speed and coverage — you're layering them.

// playwright.config.ts — Hybrid strategy: local browsers on CI, cloud for long-tail
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    // === Tier 1: Always run on CI (fast, local browsers) ===
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },

    // === Tier 2: Run on a schedule or pre-release (cloud) ===
    {
      name: 'webkit-cloud',
      use: {
        // Connect to BrowserStack/cloud provider
        connectOptions: {
          wsEndpoint: process.env.BROWSERSTACK_WS_ENDPOINT,
        },
        // BrowserStack capabilities
        ...devices['Desktop Safari'],
      },
    },
    {
      name: 'mobile-chrome-cloud',
      use: {
        connectOptions: {
          wsEndpoint: process.env.BROWSERSTACK_WS_ENDPOINT,
        },
        ...devices['Pixel 7'],
      },
    },
    {
      name: 'mobile-safari-cloud',
      use: {
        connectOptions: {
          wsEndpoint: process.env.BROWSERSTACK_WS_ENDPOINT,
        },
        ...devices['iPhone 14'],
      },
    },
  ],

  // CI: only run Tier 1 (fast feedback). Scheduled run: all projects.
  // Control this via an environment variable or separate config.
});

In an interview, explicitly state that you'd use CI environment variables or separate Playwright config files to control which tier runs when. For example: playwright.config.ci.ts includes only Tier 1 projects, used in pull-request pipelines. playwright.config.full.ts includes all projects, used in nightly or release pipelines. This demonstrates that you've thought about the operational reality, not just the theory.

Visual Regression Testing — Percy, Playwright Screenshots, and the False-Positive Problem

Visual regression testing is where cross-browser testing gets genuinely hard — and where interviewers separate candidates who've read about it from candidates who've actually done it. The concept is simple: take a screenshot, compare it to a baseline, flag differences. The reality is a minefield of anti-aliasing differences between operating systems, sub-pixel rendering variations between browser engines, animation frames captured mid-transition, dynamic content (dates, timestamps, randomised data) that changes every run, and the fundamental question of what constitutes a "meaningful" visual difference vs an acceptable rendering variation.

Playwright's Built-In Screenshot Comparison (toMatchSnapshot)

Playwright provides expect(page).toHaveScreenshot() and expect(screenshot).toMatchSnapshot() for pixel-level comparison. It's zero-cost, zero-infrastructure, and works across all three browser engines — but it comes with caveats you must articulate in an interview:

// visual-regression.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Visual Regression — Checkout Flow', () => {
  test('checkout page matches baseline across browsers', async ({ page }) => {
    await page.goto('/checkout');

    // Wait for all images, fonts, and animations to settle before capturing.
    // Without this, you'll get false positives from partially-loaded pages.
    await page.waitForLoadState('networkidle');

    // Mask dynamic content that changes every run.
    // Without masking, timestamps, random IDs, and dates break every snapshot.
    await expect(page).toHaveScreenshot({
      fullPage: false, // Capture viewport only — fullPage captures the entire
                        // scrollable page, which is useful for long-form content
                        // but introduces scrollbar rendering differences.
      mask: [
        page.locator('[data-testid="timestamp"]'),
        page.locator('[data-testid="order-number"]'),
        page.locator('[data-testid="cart-total"]'), // Prices fluctuate
      ],
      maxDiffPixelRatio: 0.01, // Allow 1% pixel difference.
                                // 0 = exact match (unrealistic across browsers).
                                // Too high = you'll miss real bugs.
                                // 0.01 is a pragmatic starting point for same-browser.
                                // Cross-browser baselines may need 0.02-0.03.
      threshold: 0.2, // Per-pixel colour difference threshold (0-1).
                       // 0 = every pixel must match exactly.
                       // 0.2 = a pixel can differ by 20% in colour before it's flagged.
                       // Anti-aliasing on different OSes can cause 1-5% pixel colour
                       // differences — threshold accommodates that.
      animations: 'disabled', // Critical: stops CSS animations and transitions
                               // mid-capture. Without this, you're photographing
                               // a moving target.
    });
  });

  test('visual regression across all project browsers', async ({ page, browserName }) => {
    await page.goto('/dashboard');
    await page.waitForLoadState('networkidle');

    // Per-browser baselines: each browser engine renders slightly differently.
    // Use browserName in the snapshot name to create separate baselines.
    // Interview point: you're not comparing Chromium to Firefox —
    // you're comparing Chromium-today to Chromium-last-week. Cross-browser
    // visual comparison is a different (and much harder) problem.
    await expect(page).toHaveScreenshot(`dashboard-${browserName}.png`, {
      maxDiffPixelRatio: 0.015,
      threshold: 0.25,
      animations: 'disabled',
    });
  });
});

Percy (BrowserStack) — Managed Visual Testing at Scale

Percy (now part of BrowserStack) is a dedicated visual testing platform that addresses the operational challenges Playwright's built-in snapshots don't solve: snapshot storage, diff review UI, approval workflows, cross-browser visual diffs with intelligent anti-aliasing detection, and integration with PR workflows. Here's when to choose each approach — and how to articulate that choice in an interview:

// @percy/playwright integration
import { test } from '@playwright/test';
import percySnapshot from '@percy/playwright';

test('visual regression — pricing page', async ({ page }) => {
  await page.goto('/pricing');
  await page.waitForLoadState('networkidle');

  // Percy captures the DOM snapshot, not just a screenshot.
  // This allows cross-browser rendering in Percy's infrastructure —
  // one snapshot, rendered across all configured browsers.
  await percySnapshot(page, 'Pricing Page — Default State', {
    widths: [375, 768, 1440], // Responsive breakpoints captured in one call
    percyCSS: `
      /* Hide elements that animate or change per-run */
      [data-testid="live-counter"] { visibility: hidden; }
      .animated-banner { display: none; }
    `,
  });

  // Percy automatically diffs against the baseline and posts results
  // to the Percy dashboard and (if configured) to your PR.
});

The interview answer that demonstrates real experience: "We use Playwright's built-in snapshots for component-level visual tests in CI — they give us fast, free feedback on every commit. We use Percy for full-page, cross-browser visual tests that run on the nightly pipeline — they give us managed baselines, cross-browser rendering, and a review workflow that our design team can participate in. The key insight is that Playwright snapshots and Percy solve different problems — one is a testing primitive, the other is a visual testing platform. Having worked with both, I'd choose the built-in approach for teams early in their visual testing journey, then add a managed platform when snapshot volume, cross-browser baselines, or team size make the operational overhead unsustainable."

Browser-Specific Bugs — Detection, Diagnosis, and the Debugging Workflow

Every browser engine has its quirks, and every cross-browser testing interview includes some variant of: "Tell me about a browser-specific bug you found and how you debugged it." The interviewer isn't looking for a war story — they're probing for your debugging methodology. Here are the categories of browser-specific issues you should know, and the debugging workflow that demonstrates systematic thinking:

Common Browser-Specific Bug Categories

The Systematic Debugging Workflow (Interview Answer Template)

When an interviewer asks you to describe debugging a browser-specific bug, structure your answer as a methodology, not a story:

1. Isolate the browser: "First, I reproduce the failure in the target browser and confirm it passes in at least one other browser. This confirms it's a browser-specific issue, not an environmental or data issue."
2. Capture the failure with Playwright Trace Viewer: "I use trace: 'on-first-retry' in the Playwright config so every failure automatically captures a trace. The Trace Viewer shows me the DOM snapshot at the moment of failure, the console output, the network requests, and a timeline of Playwright actions — all browser-specifically."
3. Reduce to a minimal reproduction: "I strip the test down to the smallest possible interaction that triggers the bug — remove setup steps, hardcode values, eliminate dependencies. A minimal reproduction is 10x faster to debug and essential if I need to file a bug report with the browser vendor or framework maintainers."
4. Compare browser behaviour at the protocol level: "For rendering issues, I use browser DevTools to inspect computed styles. For JavaScript differences, I check MDN's browser compatibility table (the 'BCD tables' on every MDN page). For network issues, I compare the request/response headers between browsers. For storage issues, I inspect Application → Storage in DevTools."
5. Apply the fix or workaround, test across all browsers: "Once I understand the root cause, I apply the fix — sometimes it's a code change in the application, sometimes it's a test adjustment (e.g., increasing a timeout for Firefox's slower cold-start), sometimes it's a Playwright capability like browserName-conditional logic. I then run the test across all browsers to confirm the fix doesn't regress elsewhere."
6. Document the browser-specific behaviour: "If it's a genuine browser quirk rather than an application bug, I add it to our team's browser-compatibility knowledge base with the pattern, the workaround, and the affected browser versions. This prevents the next engineer from spending two hours debugging the same Safari date-parsing issue I just solved."

// Example: browser-conditional test logic in Playwright
import { test, expect } from '@playwright/test';

test('date picker works across browsers', async ({ page, browserName }) => {
  await page.goto('/booking');

  // Browser-specific workaround: Safari has a known issue with
  // native date inputs clearing on rapid re-focus.
  if (browserName === 'webkit') {
    // Use a slower, stepped interaction to avoid the Safari race condition.
    await page.locator('#checkin-date').click({ delay: 300 });
    await page.locator('#checkin-date').fill('2026-06-01');
    await page.waitForTimeout(200); // Allow WebKit's internal state to settle.
  } else {
    await page.locator('#checkin-date').fill('2026-06-01');
  }

  // Validate the date was set correctly across all browsers.
  await expect(page.locator('#checkin-date')).toHaveValue('2026-06-01');

  // Browser-specific assertion: Firefox renders date inputs differently.
  // The visual appearance differs but the semantic value is what matters.
  // Don't assert on visual rendering of native inputs — it varies by engine.
  if (browserName === 'firefox') {
    // Firefox uses dd/mm/yyyy display format based on system locale.
    // The underlying value is still yyyy-mm-dd.
    await expect(page.locator('#checkin-date')).toHaveAttribute(
      'value',
      '2026-06-01'
    );
  }
});

The meta-point interviewers are evaluating: do you treat browser-specific bugs as nuisances to work around, or as systematic problems to investigate, document, and prevent? The second mindset is what distinguishes a senior SDET from a mid-level test automation engineer.

Responsive and Device Testing Strategy — Beyond "Does It Fit on a Phone?"

Responsive testing in 2026 isn't about testing every possible screen size — that's combinatorially impossible. It's about testing the right breakpoints with the right depth, using a risk-based matrix that accounts for your actual user analytics. Here's the strategy framework that scores well in interviews because it demonstrates you think in terms of risk, data, and pragmatism — not exhaustive checklists:

The Viewport Priority Matrix

// playwright.config.ts — Tiered viewport strategy
import { defineConfig, devices } from '@playwright/test';

// Tier 1: Always-on CI projects
const tier1 = [
  {
    name: 'desktop-1440',
    use: {
      ...devices['Desktop Chrome'],
      viewport: { width: 1440, height: 900 },
    },
  },
  {
    name: 'mobile-375',
    use: {
      ...devices['iPhone SE'], // 375×667
    },
  },
  {
    name: 'tablet-768',
    use: {
      ...devices['iPad Mini'], // 768×1024
    },
  },
];

// Tier 2: Nightly visual regression viewports
const tier2 = [
  { name: 'vp-320', use: { viewport: { width: 320, height: 568 } } },
  { name: 'vp-480', use: { viewport: { width: 480, height: 854 } } },
  { name: 'vp-1024', use: { viewport: { width: 1024, height: 768 } } },
  { name: 'vp-1280', use: { viewport: { width: 1280, height: 800 } } },
  { name: 'vp-1920', use: { viewport: { width: 1920, height: 1080 } } },
];

export default defineConfig({
  projects: [
    ...(process.env.TEST_TIER === 'full' ? [...tier1, ...tier2] : tier1),
  ],
});

Device Emulation vs Real Devices — The Interview Answer

"Playwright's device emulation (via devices) accurately emulates the viewport size, device pixel ratio, user agent string, touch events, and geolocation. It does not emulate the browser engine's rendering pipeline, GPU behaviour, font rendering (system fonts differ per OS), or the performance characteristics of mobile hardware. For most functional testing, device emulation is sufficient and vastly faster than real-device testing. I reserve real-device testing for: (1) touch-interaction-heavy features where gesture timing matters, (2) features that use hardware APIs (camera, Bluetooth, NFC), (3) pre-release regression gates where the cost of a missed mobile-specific bug exceeds the cost of cloud-device minutes, and (4) browsers that don't have a desktop equivalent (Safari on iOS uses WebKit but iOS WebKit has mobile-specific behaviours that macOS WebKit doesn't exhibit)."

This answer demonstrates you understand the technical limitations of emulation without dismissing it — and that you make infrastructure decisions based on risk, not dogma. For more on mobile-specific testing strategy, see our Mobile Test Automation Interview Questions 2026 guide.

When Cross-Browser Testing Matters — And When It's Unnecessary Overhead

This is the strategic question that separates senior SDETs from engineers who just run tests on everything indiscriminately. Not every application needs cross-browser testing. Running a full browser matrix when your user base is 98% Chrome on a single OS is wasteful — it slows down CI, increases flakiness, and burns engineering time on issues that affect zero users. But failing to test cross-browser when your audience uses diverse browsers means you're shipping bugs to real users. The skill is knowing when each scenario applies:

The decision framework Mitchell teaches: cross-browser testing investment should be proportional to (user impact of a browser-specific bug) × (probability of a browser-specific bug occurring) × (percentage of users on that browser). If any factor is near zero, the investment should be near zero. If all three are significant, cross-browser testing isn't optional — it's a fundamental quality requirement. In an interview, explicitly walking through this framework with a concrete example ("for our public-facing checkout flow where 22% of users are on Safari and a rendering bug would directly impact revenue, cross-browser testing is non-negotiable") demonstrates strategic thinking that most candidates lack.

For the full framework design patterns that support this kind of risk-based testing strategy — including how to design a test architecture where browser selection is a configuration concern, not a code concern — see our Test Automation Framework Design Interview Guide.

Balancing Browser Coverage Against Execution Speed — Practical Patterns That Work

This is the operational question every team faces and every interview panel asks: "Your full test suite takes 30 minutes on Chrome. Running it on 5 browsers would take 2.5 hours. How do you handle that?" The answer isn't a tool — it's a strategy built from layered tactics. Here are the patterns that work in production, in order of implementation priority:

Pattern 1: Risk-Based Browser Selection (The 80/20 Rule of Cross-Browser Testing)

Run your full suite on your primary browser (determined by analytics, typically Chromium) on every commit. Run a smoke-test subset on secondary browsers on every commit. Run the full suite on all browsers nightly or pre-release. This gives you fast feedback on the browser that matters most while maintaining comprehensive coverage at a cadence that doesn't block development. The smoke-test subset should include: authentication flows, checkout/payment flows, core navigation paths, and any feature that has historically produced browser-specific bugs. Use Playwright's test.describe.configure({ mode: 'serial' }) or tag-based filtering to separate smoke tests from full-regression tests.

Pattern 2: Sharding Across Browsers

Playwright's sharding distributes test files across multiple worker processes. When combined with the project model, you can shard within each browser project, running, say, 4 shards on Chromium, 2 on Firefox, and 2 on WebKit simultaneously:

# CI script — Run sharded across browsers
npx playwright test --project=chromium --shard=1/4 &
npx playwright test --project=chromium --shard=2/4 &
npx playwright test --project=chromium --shard=3/4 &
npx playwright test --project=chromium --shard=4/4 &
npx playwright test --project=firefox --shard=1/2 &
npx playwright test --project=firefox --shard=2/2 &
npx playwright test --project=webkit --shard=1/2 &
npx playwright test --project=webkit --shard=2/2 &
wait

With sufficient CI runners (8 in this example), a 30-minute suite becomes a ~4-minute run — fast enough for every PR. The trade-off is CI cost: more runners cost more money (or consume more of your free-tier minutes on GitHub Actions). The interview answer: "I'd use sharding on the primary browser for per-commit speed, and sequential execution without sharding on secondary browsers for nightly runs — prioritising cost-efficiency on the long tail."

Pattern 3: Test-Level Browser Annotations

Not every test benefits from cross-browser execution. Tests that verify backend API integration logic don't need to run on Firefox. Tests that verify visual layout do. Use Playwright's test annotations to declare which tests require cross-browser execution:

// playwright.config.ts — Tag-based browser filtering
import { defineConfig } from '@playwright/test';

export default defineConfig({
  projects: [
    {
      name: 'chromium',
      use: { /* Chromium config */ },
      // Chromium runs ALL tests — it's the primary browser.
    },
    {
      name: 'firefox',
      use: { /* Firefox config */ },
      // Firefox only runs tests tagged @cross-browser or @visual.
      grep: /@cross-browser|@visual/,
    },
    {
      name: 'webkit',
      use: { /* WebKit config */ },
      grep: /@cross-browser|@visual/,
    },
  ],
});

// example.spec.ts
import { test, expect } from '@playwright/test';

// This test only runs on Chromium — it validates API data, not rendering.
test('API response contains expected fields', async ({ request }) => {
  const response = await request.get('/api/products');
  expect(response.ok()).toBeTruthy();
  const body = await response.json();
  expect(body.products[0]).toHaveProperty('id');
});

// This test runs on all browsers — it validates cross-browser rendering.
test('product grid renders correctly @cross-browser @visual', async ({ page }) => {
  await page.goto('/products');
  await expect(page.locator('.product-grid')).toBeVisible();
  await expect(page.locator('.product-card')).toHaveCount(12);
});

Pattern 4: Parallel Workers × Browsers Matrix

Playwright runs tests within each project in parallel using worker processes. With 3 browser projects and workers: 4, you get 12 simultaneous tests. The configuration:

// playwright.config.ts — Maximising parallelism
import { defineConfig } from '@playwright/test';

export default defineConfig({
  // Each browser project gets its own worker pool.
  // With 3 projects and workers=4, up to 12 tests run simultaneously.
  workers: process.env.CI ? 4 : 2,

  // fullyParallel: each spec file runs in its own worker.
  // Without this, tests within a file run serially.
  fullyParallel: true,

  projects: [
    { name: 'chromium', use: { /* ... */ } },
    { name: 'firefox', use: { /* ... */ } },
    { name: 'webkit', use: { /* ... */ } },
  ],
});

The interview meta-answer: "Cross-browser testing doesn't have to mean cross-browser slowness. With Playwright's project-based parallelism, risk-based browser selection, test annotation filtering, and CI sharding, you can achieve comprehensive browser coverage without sacrificing the fast-feedback loop that keeps developers productive. The key insight is that not all tests are created equal for cross-browser purposes — annotate the ones that are, run them on every commit, and run the full suite on a schedule. This is a strategy, not a configuration file — and it's the strategy that interview panels want to hear you articulate." See our Playwright Interview Questions 2026 guide for all six categories of Playwright knowledge every interview tests, and our Selenium Interview Questions 2026 guide for the WebDriver ecosystem perspective.

What to Expect in the Interview — The 6 Cross-Browser Testing Question Categories

After 20 years of running SDET interview panels, Mitchell has observed that cross-browser testing questions cluster into six categories. Understanding these categories — and preparing for each — transforms cross-browser testing from a blind spot into a strength:

The SDET Interview Coach iOS app includes a dedicated Cross-Browser Testing topic with 25+ mock interview questions covering all six categories above. The AI interviewer scores your answers across technical accuracy, completeness, and communication — the same dimensions Mitchell's panels have used across 20 years of SDET hiring. Download the app, work through the cross-browser questions, and walk into your interview with frameworks, not just facts.