Question 1

Is Playwright better than Cypress in 2026?

Accepted Answer

For new projects, yes — Playwright wins on cross-browser support (true Firefox + WebKit, not just Chromium), multi-tab and multi-origin handling, native free parallelism, the trace viewer, and out-of-the-box TypeScript ergonomics. Cypress still has a slightly more polished local UI for casual single-test exploration and a strong plugin ecosystem developed over a longer history, but the gap has closed substantially and Playwright's UI mode (`--ui`) now matches or exceeds it. Most teams (Razorpay, Postman, Microsoft, Vercel, Atlassian, Flipkart, Swiggy) have either migrated or started new projects on Playwright. The Cypress vs Playwright debate is largely settled in 2026 — pick Playwright unless you have an existing Cypress suite that works fine and the migration cost outweighs the benefits. Cypress is not going away, and small teams already invested in it can stay productive, but for new SDET hires across India, Playwright proficiency is what employers screen for first.

Question 2

How much does a Playwright/SDET engineer earn in India?

Accepted Answer

₹6-22 LPA in 2026 for QA automation engineers and SDETs with Playwright as a primary skill. Entry-level QA automation roles start at ₹6-9 LPA, mid-level SDET roles with 3-5 years of experience at ₹12-16 LPA, senior SDETs and QA leads with 6+ years at ₹18-22+ LPA. Principal/Staff SDETs at top product companies can reach ₹30+ LPA. Companies hiring heavily for Playwright skills include Razorpay, Postman, Flipkart QA teams, Swiggy, Microsoft India, Atlassian Bangalore, Vercel, Zoho, Freshworks, and most YC-backed startups in Bangalore. Roles that combine Playwright with strong TypeScript skills and CI/CD experience consistently pay 30-40% above pure manual QA roles.

Question 3

Should I learn Playwright with TypeScript or JavaScript?

Accepted Answer

TypeScript, without question. Playwright's API is designed type-first — IDE autocomplete, parameter validation, fixture types, and Page Object Model refactors all work dramatically better with TypeScript. Custom matchers, fixtures, and reporters are far cleaner with proper generic types. Every Playwright job posting in India in 2026 expects TS familiarity. Even if your dev team writes the application in plain JavaScript, write your tests in TypeScript — Playwright's `tsconfig.json` is self-contained and runs `.ts` files directly without a separate build step.

Question 4

Can Playwright replace Selenium completely?

Accepted Answer

For modern web apps, almost always yes. Selenium retains an edge in two scenarios: (1) testing on real mobile devices via Appium, where Playwright's mobile emulation is browser-only and cannot drive a real Android or iOS device, (2) supporting older browsers (Internet Explorer, very old Safari versions, niche embedded browsers) — Playwright supports only the three modern engines (Chromium, Firefox, WebKit). For 95% of web E2E needs in 2026, Playwright is faster, less flaky, and easier to maintain than Selenium. Migration patterns vary by team — some big-bang convert, others run both in parallel during transition and gate new test creation to Playwright only. The Selenium IDE record-and-playback tool is still useful for non-developers, but Playwright's Codegen (`npx playwright codegen`) covers similar ground while producing far better code.

Question 5

How long does it take to learn Playwright if I know JavaScript?

Accepted Answer

Two to three weeks of dedicated practice to be productive — write your first useful tests in a day, master fixtures and Page Objects in a week, become comfortable with network interception, trace viewer, parallelism, and CI integration in two-to-three weeks. The skill that takes longest to develop is writing non-flaky tests at scale and architecting a suite that stays trustworthy as it grows past a few hundred tests — that comes from 6-12 months of real-world exposure to a large suite, debugging actual production-grade flakes, and learning when to mock vs hit real services. For interview prep, focus on locator strategies, the difference between locators and ElementHandle, network interception patterns, parallelism modes, and being able to walk through a debugging session in the trace viewer. The official Playwright docs are excellent and contain interactive examples — they are the best starting point. Pair them with hands-on practice on a real application (open-source or your own), not just isolated example sites.

Question 6

Does Playwright work for mobile app testing?

Accepted Answer

Playwright tests mobile web (responsive sites and mobile browsers via device emulation), not native iOS or Android apps. For native app automation, you still need Appium, Detox (React Native), or platform-specific frameworks like Espresso (Android) / XCUITest (iOS). In India, most companies pair Playwright (for the web product) with Appium or BrowserStack App Live / Sauce Labs Real Devices (for native apps). Playwright's mobile emulation is excellent for catching responsive bugs, mobile-specific UI behavior, touch event handling, and small-viewport regressions — but is not a substitute for testing on a real device for performance characteristics, native gesture interactions, or hardware-dependent features like Camera, Bluetooth, NFC, biometric authentication, and push notifications. If your mobile web traffic is significant (which is true for most Indian consumer products), invest in Playwright mobile projects covering Pixel and iPhone profiles as a minimum.

Question 7

What is Playwright and why has it become the industry standard over Cypress?

Accepted Answer

Playwright is an open-source end-to-end testing framework released by Microsoft in 2020, built by the team that previously created Puppeteer at Google. It enables automated testing of web applications across Chromium, Firefox, and WebKit (Safari engine) using a single unified API. Tests can be written in TypeScript, JavaScript, Python, .NET, or Java, though the TypeScript runner ships with the most features and is the de-facto default in 2026. Three reasons it has displaced Cypress as the 2026 default: (1) true cross-browser support — Cypress only added WebKit/Firefox parity recently and it is still limited, while Playwright runs identical tests on Chromium, Firefox, and WebKit from day one with no extra configuration. (2) Multi-tab, multi-origin, and iframe handling — Cypress runs inside the browser so it cannot cross origins or open multiple tabs, while Playwright drives the browser externally via the Chrome DevTools Protocol (and equivalent protocols for Firefox/WebKit) and has no such restriction. This matters enormously for OAuth flows, payment redirects, and multi-user scenarios. (3) Native parallelism — Playwright runs test files in parallel workers by default, while Cypress has historically required paid Cypress Cloud for proper parallelism. Add in auto-waiting that eliminates 90% of `sleep` calls, the trace viewer that has changed how teams debug flaky tests, async/await TypeScript ergonomics, and free open-source parallel execution, and the choice for new projects is fairly clear. Microsoft, Vercel, Postman, Razorpay, Flipkart QA teams, and Swiggy have all adopted Playwright as their primary E2E framework.

Question 8

How do you install Playwright and write your first test?

Accepted Answer

Run `npm init playwright@latest` in your project. The installer scaffolds a `playwright.config.ts` file, installs the browser binaries (Chromium, Firefox, WebKit) into a managed cache directory, creates an `e2e` folder with example tests, and adds the necessary npm scripts. It also asks whether you want TypeScript (recommended), a GitHub Actions workflow, and where your tests should live. The browser binaries are version-pinned — Playwright never uses your system Chrome — which is what makes tests reproducible across developer machines and CI runners. A test file uses `import { test, expect } from '@playwright/test'` and runs with `npx playwright test`. The default config runs tests in parallel across all installed browsers — you can scope to one with `--project=chromium`. Run `npx playwright test --ui` to launch the interactive UI mode, which shows a list of tests, a live time-travel debugger that scrubs through every action, and lets you pick locators visually by clicking the page. This is the single best onboarding tool for new team members and the fastest way to write a new test — write the skeleton, then watch and tweak in UI mode until it passes.

Question 9

What are locators in Playwright and why are they preferred over CSS/XPath selectors?

Accepted Answer

A locator is a lazy reference to one or more DOM elements on the page. Unlike traditional Selenium-style `findElement` calls, locators are not resolved until you act on them — which means they survive page reloads, re-renders, and DOM mutations that happen between when you create the locator and when you use it. Modern Playwright pushes user-facing locators: `getByRole`, `getByText`, `getByLabel`, `getByPlaceholder`, `getByAltText`, `getByTitle`, and `getByTestId`. These mimic how a real user (or assistive technology like a screen reader) finds the element, which makes them resilient to refactoring. The official priority order is: getByRole > getByLabel (for form fields) > getByPlaceholder > getByText > getByTitle > getByTestId, with CSS/XPath as a last resort. CSS and XPath selectors are still supported via `page.locator('.btn')` or `page.locator('//button')` but discouraged — they break when designers tweak class names, restructure the DOM, or migrate to a new component library. The rule of thumb: prefer ARIA roles first because they double as accessibility checks (if `getByRole('button')` fails, your button is probably not accessible), fallback to test IDs (`data-testid` attributes you add specifically for testing) for elements that have no good user-facing identifier like a custom icon button. Locators also chain: `page.getByRole('list').getByRole('listitem').filter({ hasText: 'Active' })` reads naturally and updates lazily.

Question 10

How does Playwright's auto-waiting mechanism work?

Accepted Answer

Before performing an action like `click()`, `fill()`, `check()`, or `selectOption()`, Playwright runs a set of actionability checks on the target element: it must be attached to the DOM, visible (non-zero size, not display:none, not visibility:hidden), stable (not animating — bounding box has not changed for two consecutive animation frames), enabled (not disabled), and able to receive events (not covered by another element at its center). If any check fails, Playwright keeps polling until the default action timeout (30 seconds) is hit. This eliminates almost all `sleep()` or `waitFor()` calls that plague Selenium tests. Web-first assertions like `expect(locator).toBeVisible()`, `toHaveText()`, `toHaveURL()` work the same way — they retry until the condition is met or the assertion timeout (5 seconds by default) is reached. The result: you write tests as if everything were synchronous, and Playwright handles the timing. The implication is that you should NEVER add `page.waitForTimeout(2000)` calls — they are anti-patterns that slow down tests without helping reliability. If a test feels like it needs `waitForTimeout`, it actually needs a web-first assertion to wait for the correct UI state. You can tune timeouts per-action (`locator.click({ timeout: 60_000 })`), per-test (`test.setTimeout(60_000)`), or globally in config.

Question 11

What is the difference between `page.locator()` and `page.$()`?

Accepted Answer

`page.$()` is the legacy method — it returns an `ElementHandle` representing a single resolved element at that moment in time. If the DOM changes after the call (a React re-render, a list re-sort, a modal close), the handle becomes stale and your action fails with a `Node is detached from document` error. This is the same problem Selenium has with `StaleElementReferenceException`. `page.locator()` returns a `Locator` object, which is a lazy reference described by a query. The actual DOM lookup happens each time you act on the locator, so it remains valid across re-renders and the action just retries against the current DOM. Playwright 1.27+ deprecated `$` and `$$` in favor of locators, and the deprecation warnings now appear directly in the test output. In 2026 code, you should never use `page.$()` — Playwright will warn you, the team lead will reject the PR, and the resulting tests will be flaky in ways that are painful to debug. The only legitimate use of `ElementHandle` today is when you need to pass a DOM reference into `page.evaluate()` for low-level scripting, and even then `locator.evaluate()` is usually preferable.

Question 12

How do you write assertions in Playwright tests?

Accepted Answer

Playwright bundles its own `expect` from `@playwright/test`. It is a superset of Jest's `expect` with a class of web-first matchers that auto-retry: `toBeVisible()`, `toBeHidden()`, `toHaveText()`, `toHaveURL()`, `toHaveValue()`, `toBeEnabled()`, `toBeDisabled()`, `toBeChecked()`, `toBeFocused()`, `toBeEmpty()`, `toHaveCount()`, `toHaveAttribute()`, `toHaveClass()`, `toContainText()`, `toHaveScreenshot()`, `toHaveTitle()`. These retry the underlying query until the assertion passes or the assertion timeout (5 seconds by default) is hit — no manual waiting required. Non-retrying matchers (`toBe`, `toEqual`, `toContain`, `toMatchObject`, `toBeGreaterThan`) are also available for plain JS values like numbers, strings, and objects. Always prefer the retrying matchers when checking DOM state, otherwise you reintroduce flakiness. A subtle but important rule: always pass the locator to `expect`, not the result of `await locator.textContent()`. The former retries until the DOM matches, the latter takes a snapshot at one moment and asserts on it. Negating retrying matchers works the same way — `await expect(loader).not.toBeVisible()` polls until the loader disappears or times out. You can also assert on async values with `await expect.poll(() => api.fetchOrders())` which retries the function until it returns a value matching the chained matcher — useful for backend state assertions.

Question 13

How do you handle navigation and page loading in Playwright?

Accepted Answer

`page.goto(url)` navigates the page and by default waits for the `load` event. You can change this with the `waitUntil` option: `'commit'` (HTTP response received, before any HTML is parsed — useful for testing that a request happened at all), `'domcontentloaded'` (DOM parsed, scripts may still be loading — faster for SPAs), `'load'` (default, all sub-resources loaded), or `'networkidle'` (no network activity for 500ms — sounds useful but is unreliable in SPAs that poll, so prefer waiting for specific elements via assertions). For navigation triggered by clicking a link or button, you typically do not need to wait at all — Playwright's auto-waiting on the NEXT action handles it. If you must explicitly wait, use `page.waitForURL(/pattern/)` or the assertion form `await expect(page).toHaveURL(/pattern/)`. Avoid `page.waitForNavigation()` unless absolutely needed — it has been superseded by `waitForURL`. A common gotcha: if your app uses `History.pushState` for client-side routing (Next.js, React Router), navigation events fire but resources don't reload; `waitUntil: 'load'` returns immediately. For SPAs, assert on a visible DOM element from the new page instead. Another tip: set a `baseURL` in your config so `page.goto('/dashboard')` works without hardcoding the host across every test.

Question 14

What are fixtures in Playwright Test?

Accepted Answer

Fixtures are Playwright Test's dependency injection system, conceptually similar to pytest fixtures or React hooks. Built-in fixtures include `page` (fresh tab per test), `browser` (the underlying browser instance), `context` (isolated incognito session), `browserName` (the project's browser name like 'chromium'), and `request` (API client). You declare a fixture as a function parameter in your test, and Playwright creates it before the test runs and disposes of it after — you never manually instantiate or clean up. The killer feature is custom fixtures — you can extend the base `test` to add your own (an authenticated user, a populated database row, a feature flag toggle, a Mailosaur inbox, a Stripe test customer) and they compose cleanly: fixture A can depend on fixture B, Playwright resolves the dependency graph per test. Fixtures have configurable scope: `test` (default, fresh per test — isolation by default) or `worker` (shared across all tests in the worker — useful for expensive one-time setup like spinning up a database container or compiling a binary). Worker-scoped fixtures are how teams cut authentication setup time from 30 seconds per test to 0.1 seconds per test on a 500-test suite. Fixtures replace the messy `beforeEach`/`afterEach` patterns of older frameworks — they are typed, composable, and lazy (only initialized if a test actually requests them as a parameter).

Question 15

What is a browser context and how does it differ from a page?

Accepted Answer

A `BrowserContext` is an isolated browser session — conceptually equivalent to an incognito profile. It has its own cookies, localStorage, sessionStorage, IndexedDB, cache, service workers, and permissions. A `Page` is a single tab within a context. A single `Browser` instance can have many contexts running simultaneously, and each context can have multiple pages (tabs or popups). This three-level hierarchy (Browser → Context → Page) is why Playwright tests can run in parallel without cross-contamination — every test gets its own context by default, so cookies and localStorage from one test never leak to another. Use this hierarchy deliberately: testing multi-user scenarios (chat between two users, marketplace flows between buyer and seller, social media interactions, collaborative document editing) is just two contexts in the same test. Each context can be initialized with its own storageState (different authenticated user), viewport (one mobile + one desktop), geolocation, locale, timezone, and permissions. Reusing a single browser across contexts is also much faster than launching a new browser per test — Playwright does this automatically across workers.

Question 16

How do you take screenshots and record videos in Playwright?

Accepted Answer

Screenshots: `await page.screenshot({ path: 'screen.png', fullPage: true })` captures the visible viewport or the full scrollable page (full page captures everything including content below the fold). You can scope to a single element with `await myButton.screenshot({ path: 'btn.png' })` for component-level captures. Options include `clip: { x, y, width, height }` for a specific rectangle, `omitBackground: true` for transparent screenshots of elements, and `animations: 'disabled'` to freeze CSS animations for stable captures. For visual regression testing, use the web-first assertion `await expect(page).toHaveScreenshot('homepage.png')` which captures, compares against a baseline image stored in `__screenshots__`, and writes a diff PNG on mismatch. The first run creates the baseline; subsequent runs compare pixel-by-pixel with configurable thresholds (`maxDiffPixels`, `maxDiffPixelRatio`, `threshold`). Videos: configure in `playwright.config.ts` with `use: { video: 'retain-on-failure' }`. Other options: `'on'` (record every test, expensive but useful when debugging a stubborn flaky test), `'off'` (default), `'on-first-retry'` (only the retry run, balances cost and coverage), and `'retain-on-failure'` (recommended for most CI setups — record everything but delete passing runs to save disk space). Videos are saved per test as `.webm` files in `test-results/` and shown inline in the HTML report — they are invaluable for debugging CI failures you cannot reproduce locally. Combined with the trace viewer, these three artifacts (screenshot, video, trace) give you full forensic detail on every failure with zero overhead on passing runs.

Playwright Interview Questions

What is Playwright and why has it become the industry standard over Cypress?

How do you install Playwright and write your first test?

What are locators in Playwright and why are they preferred over CSS/XPath selectors?

How does Playwright's auto-waiting mechanism work?

What is the difference between `page.locator()` and `page.$()`?

How do you write assertions in Playwright tests?

How do you handle navigation and page loading in Playwright?

What are fixtures in Playwright Test?

What is a browser context and how does it differ from a page?

How do you take screenshots and record videos in Playwright?

How do you run Playwright tests in headed mode versus headless?

What is the Playwright config file and what are its most important options?

How do you intercept and mock network requests in Playwright?

How do you implement the Page Object Model (POM) in Playwright?

How do you handle authentication across many tests efficiently?

What is the trace viewer and how do you use it to debug flaky tests?

How do you run Playwright tests in parallel and what is sharding?

What is the difference between `test.describe.serial`, `test.describe.parallel`, and the default mode?

How does Playwright handle iframes and how do you interact with them?

How do you use the Playwright API request fixture for API testing without a browser?

How do you handle file uploads and downloads in Playwright?

What are some common causes of flaky Playwright tests and how do you fix them?

How do you do visual regression testing with Playwright?

How do you handle mobile and responsive testing with Playwright?

How do you organize a large Playwright test suite at a company like Razorpay or Flipkart?

How do you write custom matchers and extend the expect API in Playwright?

How do you do component testing with Playwright instead of just E2E?

How would you architect a Playwright test suite for a 10,000+ test microservices platform?

How do you write a Playwright reporter or plugin for custom CI integration?

How do you handle authentication in a multi-tenant SaaS platform with Playwright?

Companies Hiring Playwright

Salary Insights

Frequently Asked Questions