Playwright vs Selenium Interview Questions (1970)

Playwright is the modern, faster, TypeScript-first framework with native auto-wait, parallel-by-default execution, and trace viewer. Selenium is the mature, cross-language W3C-standard tool with the biggest install base and enterprise footprint. In 2026: pick Playwright for greenfield, Selenium for existing Java/Grid shops.

Playwright — often 2–5x on the same suite. Reasons: single WebSocket connection per browser (vs HTTP-per-command for WebDriver), workers run tests in parallel by default, and auto-wait eliminates dead sleeps.

Selenium: Java, Python, C#, Ruby, JavaScript, Kotlin. Playwright: TypeScript/JavaScript, Python, Java, .NET. Selenium wins on Ruby; Playwright wins on TypeScript ergonomics.

Playwright — every action waits for visible + stable + enabled + receiving-events before firing. Selenium requires explicit waits (WebDriverWait + ExpectedConditions).

Playwright — first-class BrowserContext and page.context().pages(). Selenium supports it via getWindowHandles(), but the API is more verbose and less isolated.

Selenium: Test → JSON Wire / W3C over HTTP → BrowserDriver → Browser. Each command is an HTTP round-trip. Playwright: Test → single WebSocket → Playwright driver → Browser (via CDP for Chromium, patched WebKit/Firefox). Fewer hops = lower per-command latency.

Playwright: npm i -D @playwright/test && npx playwright install — one command, bundles browsers. Selenium: add dependencies, drivers auto-download via Selenium Manager (4.6+), then wire in TestNG/JUnit.

No — Playwright is parallel-by-default via workers on a single machine. For horizontal scaling: shard with --shard=N/M across CI runners. Selenium needs Grid (or a cloud like BrowserStack) to fan out.

// Playwright
await page.goto('/login');
await page.getByLabel('Email').fill('qa@x.com');
await page.getByLabel('Password').fill('secret');
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page).toHaveURL('/dashboard');

// Selenium (Java + JUnit)
driver.get("/login");
driver.findElement(By.id("email")).sendKeys("qa@x.com");
driver.findElement(By.id("password")).sendKeys("secret");
driver.findElement(By.id("submit")).click();
new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.urlContains("/dashboard"));

Playwright: auto-waits for domcontentloaded/networkidle. Selenium: explicit wait on a stable element or URL change. Never rely on pageLoadTimeout alone for SPAs.

Playwright's getByRole, getByLabel, getByTestId are accessibility-first and self-healing. Selenium's By.* is lower-level: id, css, xpath, plus Selenium 4 relative locators. Playwright's locators are lazy and re-evaluate; Selenium's WebElement can go stale.

Playwright's expect(locator).toHaveText(...) auto-retries until the condition passes or times out. Selenium requires you to combine WebDriverWait + JUnit/TestNG assertion. Auto-retrying assertions are Playwright's single biggest flake-killer.

// Playwright
const frame = page.frameLocator('#pay');
await frame.getByRole('button', { name: 'Pay' }).click();

// Selenium
driver.switchTo().frame("pay");
driver.findElement(By.id("pay-btn")).click();
driver.switchTo().defaultContent();

// Playwright — auto-retrying
await expect(page.getByTestId('spinner')).toBeHidden();

// Selenium
new WebDriverWait(driver, Duration.ofSeconds(10))
  .until(ExpectedConditions.invisibilityOfElementLocated(By.id("spinner")));

Playwright, materially — auto-wait, auto-retry assertions, isolated BrowserContext per test, and the Trace Viewer for post-mortem. Selenium flakes are usually solvable with disciplined explicit waits and POM, but the ceiling is lower.

// Playwright — parallel by default; tune workers
// playwright.config.ts
export default { workers: 4 };

<!-- TestNG suite -->
<suite name="R" parallel="methods" thread-count="8">

Selenium also needs a ThreadLocal<WebDriver> to keep sessions isolated.

// Playwright — first-class
await page.route('**/api/users', r => r.fulfill({ json: [{ id: 1 }] }));

Selenium has to use Selenium 4 CDP (DevTools) or a proxy like BrowserMob — clunkier and Chromium-only.

Playwright: trace: 'on-first-retry' + open the Trace Viewer (DOM snapshots, network, console, actions timeline). Selenium: screenshots on failure via TestNG listener + Extent/Allure reports. Playwright's DX is meaningfully better here.

Both need add-ons. Playwright: built-in HTML reporter + Trace Viewer. Selenium: Extent Reports, Allure, or ReportPortal via TestNG listener. Trace Viewer wins for step-by-step debugging.

Neither — both are for web browsers. For native mobile you still need Appium (WebDriver-based). Playwright supports mobile emulation in Chromium/WebKit, but that's not real device testing.

Same strategy in both: bypass in test environments (test-mode CAPTCHA keys, direct-grant OAuth flows, seeded sessions). Neither tool magically solves CAPTCHAs.

• Existing Java/TestNG + Grid suite with hundreds of tests
• Need Ruby / C# / Kotlin support
• Enterprise / BFSI / gov shops with WebDriver-based tooling
• Real Safari on macOS via SafariDriver

• Greenfield project with TypeScript/JavaScript/Python
• Modern SPA (React/Vue/Angular) with heavy async
• Team wants fast feedback loops and low flakiness
• Cross-browser (Chromium + Firefox + WebKit) without infra

Deep dive: Playwright vs Selenium (2026 comparison).

1. Freeze new Selenium test additions
2. Port page objects one-by-one, keeping data models
3. Replace explicit waits with Playwright's auto-wait + expect
4. Add trace: 'on-first-retry' from day one
5. Run both suites in CI until parity, then delete Selenium

Depends on the market. India / US enterprise: Selenium still edges by JD count. US startups / EU product companies: Playwright is climbing fast and pays a premium. Ideal candidate knows both — see our Selenium 300 Q&A and Playwright Q&A.