18 Browser Automation Migration Scenarios for Playwright Interviews

Migration interviews test whether a candidate can change a system without losing confidence. Replacing syntax is easy; preserving business coverage while changing waits, isolation, data ownership, execution topology, and failure evidence is the real work.

These scenarios cover Selenium and Puppeteer estates moving to Playwright. Answer them as a staged program: inventory the legacy contract, redesign one representative slice, compare evidence in dual runs, and retire old coverage only when explicit exit criteria are met.

Define the Migration Evidence

The official Puppeteer to Playwright migration guide recommends locators and web-first assertions instead of ElementHandle-heavy inspection and unnecessary explicit waits. A senior migration plan uses that principle without assuming API similarity guarantees behavioral parity.

Before coding, agree which suite gates each scope during overlap. Otherwise two tools can disagree while everyone assumes the other result is authoritative.

Inventory and Pilot Selection

1. Why should migration begin with a risk and dependency inventory?

File count does not reveal what the suite protects. I would map business journeys, browsers, test data, authentication, external systems, selectors, wait patterns, runtime, flake signatures, and artifact quality. This exposes duplicated low-value checks and critical gaps before they are copied. It also identifies infrastructure that Playwright will not replace, such as account provisioning or environment health, so those dependencies receive explicit owners.

2. How would you choose the first workflow to migrate?

I would choose a valuable and representative scenario with known behavior, controllable data, and enough interaction complexity to test the proposed framework. It should exercise navigation, assertions, and cleanup without being the most entangled payment or compliance path. The pilot must answer architecture questions, not merely produce an easy green test. Its acceptance criteria include diagnostic artifacts and maintainability, not only execution.

3. Why might you stop adding new tests to the legacy framework?

A controlled feature freeze prevents the target from moving and encourages teams to use the new path, but a blanket freeze can leave urgent coverage undone while foundations are incomplete. I would set a date and exception policy: defects in unmigrated critical areas may still need legacy tests, while new suitable coverage uses Playwright. Ownership and sunset dates keep exceptions from becoming indefinite expansion.

API and Synchronization Redesign

4. Why should ElementHandle code become locator-based behavior rather than a direct wrapper?

Locators re-resolve against current DOM state, participate in auto-waiting, and enforce strict targeting for single-element actions. Wrapping an old stored handle preserves staleness and selector coupling. I would translate the user intent using role, label, text, or deliberate test ID locators, then use web-first assertions. The migration should remove stale-reference workarounds rather than reproduce them under new names.

5. How would you migrate a suite full of explicit sleeps?

I would classify why each sleep exists: rendering, network response, animation, backend processing, or shared-data race. Then replace it with the corresponding observable state, event promise, or bounded poll. Some waits may reveal product testability gaps that need ready signals. I would not globally delete sleeps and hope auto-waiting covers service completion; actions and assertions wait for specific conditions, not every business process.

6. Why are implicit-wait settings not a concept to carry into Playwright?

Playwright's actions and web-first assertions apply operation-specific waiting through locators. A global implicit delay would blur which condition a test expects and make failures slow. I would set focused assertion and test budgets, use event promises before triggers, and inspect call logs during migration. The goal is an explicit readiness contract at each step, not a new framework-level knob that imitates the old runner.

7. How would you migrate a Puppeteer test that reads text with page.$eval?

I would express the element as a locator and use a retrying assertion such as toHaveText or toContainText. If the value must feed later logic, retrieve it only after asserting readiness and validate nullability. The matcher gives better waiting and failure output than one-time extraction. I would also reconsider whether the later branching belongs in one test or should be parameterized from deterministic data.

import { test, expect } from '@playwright/test'

test('customer saves a new delivery address', async ({ page }) => {
  await page.goto('/account/addresses')

  await page.getByRole('button', { name: 'Add address' }).click()
  await page.getByLabel('Street address').fill('42 Test Lane')
  await page.getByLabel('City').fill('Pune')

  const saved = page.waitForResponse(response =>
    response.url().endsWith('/api/addresses') &&
    response.request().method() === 'POST',
  )
  await page.getByRole('button', { name: 'Save address' }).click()
  expect((await saved).ok()).toBeTruthy()

  await expect(page.getByRole('status')).toHaveText('Address saved')
  await expect(page.getByText('42 Test Lane')).toBeVisible()
})

Isolation and State

8. How would browser contexts change a legacy shared-browser design?

I would make each test receive an isolated context and page, then move expensive non-browser resources into explicit fixtures where safe. Shared cookies and navigation order should disappear from test assumptions. This may expose hidden dependencies in the legacy suite, which is useful migration evidence. If a multi-user scenario needs two identities, create two contexts within that one test rather than sharing state across tests.

9. How would you migrate login setup without repeating UI login in every test?

Authenticate in a dedicated setup flow or API-backed fixture, store only the browser state needed for the target environment, and apply it through projects or contexts. Keep a small set of UI login tests for the authentication journey itself. Storage state must use test accounts, be protected as sensitive, and be regenerated when invalid. Fast setup should not turn credentials into committed artifacts or shared mutable sessions.

10. Why must test data be redesigned before enabling parallel execution?

Legacy suites often rely on fixed customers, newest records, or cleanup by broad queries because they ran sequentially. Playwright parallelism will expose those collisions. I would create run- and test-aware identifiers, lease scarce resources, and make cleanup idempotent. Concurrency should be increased in stages. Reducing workers can diagnose a collision, but the migrated design is complete only when ownership replaces accidental serialization.

Incremental Rollout

11. When is an adapter layer useful during migration?

An adapter can preserve a stable domain client, data builder, or reporting interface while the browser implementation changes. It is less useful when it makes Playwright imitate Selenium's waits and element abstractions. I would time-box adapters, define their deletion criteria, and keep Playwright-native APIs available inside the new framework. Compatibility is valuable at true organizational boundaries, not around obsolete mechanics.

12. How would you compare legacy and Playwright results during a dual run?

Run both against the same commit and equivalent environment, then classify differences by coverage, product defect, test defect, data, and infrastructure. Compare first-attempt outcomes, duration, artifacts, and diagnosis effort rather than expecting identical timing. A mismatch is an investigation queue, not automatic proof one tool is wrong. The mapping from old case to new risk should be reviewable.

13. Why should migrated tests move into CI in slices?

Small slices limit blast radius, reveal runner capacity and dependency issues, and let teams adjust artifact, shard, and data policies before the full cutover. I would begin non-gating, then make the slice authoritative after exit criteria are met and delete its legacy duplicate. Running both indefinitely doubles cost and creates ownership ambiguity, so every slice needs a planned promotion and retirement date.

14. How would you introduce cross-browser coverage during migration?

I would start from supported user risk and the legacy matrix, then use Playwright projects for a deliberate browser sample. Running every new test everywhere may multiply cost without proportional signal. Critical journeys and browser-sensitive components deserve broader coverage; deeper suites can use the primary environment. Differences found during the pilot should drive targeted expansion, with project-specific baselines and artifacts handled explicitly.

Failure and Organizational Scenarios

15. Why can an initially lower Playwright pass rate be useful information?

The new suite may reveal hidden shared state, inaccessible controls, strict-locator ambiguity, or product timing that legacy waits masked. I would classify each difference instead of weakening the new assertions to match the old result. Some failures will be framework mistakes, others genuine defects. Migration success is not manufactured parity; it is an explained result with a more trustworthy contract and usable evidence.

16. How would you prepare a team accustomed to the legacy tool?

I would teach locator semantics, web-first assertions, fixtures, contexts, tracing, async discipline, and the local debugging workflow through migrated domain examples. Reviews should pair framework owners with product teams initially. A concise golden path and templates help, but teams also need room to challenge abstractions. Training success appears in independent contributions and diagnoses, not attendance or copied boilerplate.

17. What rollback plan would you require for a gating cutover?

Keep the previous job definition available for a limited window, pin compatible environments, and define who can switch authority back if the new lane has platform-level failure. Product defects discovered by Playwright are not rollback triggers. The plan should distinguish tool outage, framework regression, and genuine red tests. Any rollback creates a repair deadline so the organization does not silently abandon the migration.

18. How would you declare the migration complete?

Every in-scope risk has a mapped Playwright replacement or an approved retirement decision, migrated suites own their release gates, legacy jobs and dependencies are removed, and teams can maintain the new framework. I would verify browser, data, artifact, security, and flake policies under normal CI load. Completion also includes deleting temporary adapters and dual-run dashboards; otherwise the organization still pays for two systems.

Migration Review Checklist

• Inventory business risk and dependencies before counting files.
• Choose a representative pilot with explicit architecture questions.
• Redesign locators, waits, assertions, and isolation using Playwright semantics.
• Namespace data before increasing concurrency.
• Compare dual runs by cause, evidence, and diagnosis quality.
• Promote and retire each slice on stated criteria.
• Keep rollback authority clear and time-box compatibility layers.

Retire the Old Contract Deliberately

End a migration answer with a cutover decision. Name the workflow being moved, how its behavior is redesigned, what dual-run evidence is required, and when the legacy test loses authority. Preserve business intent without preserving brittle mechanics. A successful Playwright migration leaves one understandable execution model, one owner for each release signal, and no permanent bridge back to accidental shared state.