Senior SDET Interview Questions &amp; Answers

Show answer

A test-scoped fixture is created and torn down for every test, which keeps tests isolated. A worker-scoped fixture is set up once per worker process and shared by all tests that run in it, which suits expensive things like a started server or a seeded account. Declare it with { scope: 'worker' }. Worker fixtures cannot depend on test fixtures.

How do you debug a test in VS Code with the Playwright extension?

Debugging and Trace ViewerMedium

Show answer

Install the Playwright Test for VS Code extension. Open the Testing panel to see tests, then set a breakpoint in the test file and click Debug Test. Execution stops at the breakpoint with the browser open, so you can inspect variables. Turn on Show browser to watch runs, and use Pick locator or Record at cursor to add steps.

Tests are flaky in CI. How do you debug them?

Show answer

Turn on trace: 'on-first-retry', open the trace viewer, check network and timing, replace hard waits with web-first assertions, isolate test data and check for sharding conflicts.

How does URL matching work in page.route?

Show answer

The first argument can be a glob string, a regular expression or a function that receives a URL object. Globs like '**/api/users*' are simple but * does not cross slashes and ** does. Regex gives precise control over query strings. A predicate function suits complex rules, for example matching host plus a specific search parameter.

Why should the Playwright Docker image version match your package version?

Show answer

Each Playwright version expects specific browser builds. The official Playwright Docker image tagged v1.x.y-noble contains the browsers for that exact version. If package.json has a different version, tests fail because browsers are missing or mismatched. Pin both together and update them in the same pull request.

Ten engineers write tests and quality varies a lot. How do you keep the framework consistent?

Show answer

Write a short contribution guide with examples. Add ESLint with the Playwright plugin and the no-floating-promises rule, plus Prettier, enforced in CI. Require reviews from framework owners for shared fixtures and page objects. Provide generators or templates for new page objects, and run regular sessions to review flaky tests together.

What is testInfo and what can you do with it?

Show answer

testInfo is passed as the second argument to tests and hooks. It gives the test title, project name, retry number, status and output path. You can attach files, add annotations, change the timeout with testInfo.setTimeout, or skip conditionally. For example, attach extra logs only when testInfo.status differs from testInfo.expectedStatus.

Show a config with a setup project and a browser project that reuses its login.

Show answer

projects: [ { name: 'setup', testMatch: /auth\.setup\.ts/ }, { name: 'chromium', use: { ...devices['Desktop Chrome'], storageState: '.auth/user.json' }, dependencies: ['setup'], }, ],

What are the key options in playwright.config.ts?

Framework Design and CI/CDEasy

Show answer

Main options are testDir for where tests live, timeout, retries, workers, fullyParallel, reporter, and the use block for shared settings like baseURL, trace, screenshot and video. projects define browsers or setups, and webServer can start the app before tests. Most values can depend on process.env.CI so local and CI runs behave differently.

Describe a time you had to decide which testing level a feature belonged to.

Component TestingHard

Show answer

Situation: a pricing table had many discount rules shown in the UI. Task: decide how to test them. Action: I proposed unit tests for the calculation, component tests for how each rule rendered, and one end-to-end test for buying a discounted plan. I explained the runtime and maintenance cost of each. Result: the team agreed, we covered 30 rules in under a minute, and the approach became our default.

How do you mock WebSocket traffic in Playwright?

Network MockingHard

Show answer

Use page.routeWebSocket with a URL pattern. The handler gets a WebSocketRoute: you can reply to messages with ws.onMessage and ws.send without any server, or call connectToServer() to sit in the middle and change messages in both directions. This lets you test live dashboards and chat apps, for example pushing a fake price update.

What does eslint-plugin-playwright help with?

Show answer

It is a lint plugin with rules for common Playwright mistakes, such as missing await on assertions, leftover test.only or page.pause, forced clicks, fixed waits with waitForTimeout and element handles instead of locators. Running it in pull requests stops bad patterns before review. Teams usually enable the recommended rule set and add a few stricter rules over time.

A beforeAll creates one user and tests in the same file fail randomly in parallel mode. Why?

Show answer

With fullyParallel, the file's tests run in different workers, so each worker creates its own user, or tests in one worker share one user and change its state. Shared mutable data causes random failures. Give each test its own data through a test-scoped fixture, or create a unique user per worker with workerInfo.workerIndex in the name.

A component test passes alone but fails when the full component suite runs. What do you check?

Component TestingHard

Show answer

Look for state that leaks between mounts: global stores or singletons created at module level in index.tsx, timers or listeners not cleaned up on unmount, and shared mock data mutated by one test. Make the providers create fresh state in beforeMount each time and reset mocks per test. Running with --repeat-each and a single worker often reproduces the leak quickly.

How do you attach a screenshot or log to the report from inside a test?

Show answer

test('report', async ({ page }, testInfo) => { await page.goto('/reports'); await testInfo.attach('report page', { body: await page.screenshot(), contentType: 'image/png', }); await testInfo.attach('meta', { body: 'build 42', contentType: 'text/plain' }); });

How do you test a flow that needs two user roles, such as an admin and a customer, in one test?

Show answer

Create two browser contexts in the same test, each with its own storageState file, for example admin.json and user.json made by a setup project. Wrap them in fixtures like adminPage and userPage so tests stay short. The admin approves an order in one context and the customer sees the update in the other, with fully separate cookies.

How do you reduce the execution time of a 2000-test suite?

Show answer

Run in parallel with sharding, reuse authentication state, set up data through APIs, avoid unnecessary waits, run smoke on every commit and the full suite nightly.

What are fixtures in Playwright?

Show answer

Reusable setup/teardown units injected into tests (page, context, request). You can extend test with custom fixtures such as loggedInPage.

The suite has a 3 percent flaky rate. How do you find and fix the causes systematically?

Debugging and Trace ViewerHard

Show answer

Collect data first: flaky results from the reports across a few weeks, grouped by test, browser and error message. Run the worst offenders with --repeat-each and traces on. Fix common causes such as missing awaits, shared data, fixed sleeps and order-dependent tests. Quarantine tests you cannot fix quickly with a tag and a ticket, and track the rate weekly.

Describe a time you designed a fixture layer that other teams adopted.

Show answer

Situation: three product teams each had their own login and data setup code. Task: give them one reliable layer. Action: I built shared worker-scoped auth fixtures, test-scoped data builders with automatic cleanup, and page object fixtures, published them as an internal package with examples and versioned releases. Result: two more teams adopted it within a quarter, duplicate setup code disappeared and onboarding time for new testers dropped from weeks to days.

What reporters does Playwright provide?

Show answer

List, dot, line, HTML, JSON and JUnit reporters, plus integrations such as Allure, configurable per environment.

A worker-scoped fixture holds shared data and some tests see stale values. How do you fix it?

Show answer

Worker fixtures live across many tests, so any test that changes their data affects the next ones. Keep worker fixtures read-only, such as a connection or a reference catalogue. Move anything a test modifies into a test-scoped fixture that creates fresh data. If sharing is needed for speed, reset the relevant state in the test fixture before use.

Tell me about a time mocking helped you test a hard edge case.

Show answer

Situation: we could not reproduce a bug where the cart broke when the stock API returned zero for one item. Task: cover it with a test. Action: I mocked only the stock endpoint with route.fetch and changed one item's quantity, then asserted the out-of-stock label. Result: the bug was fixed and the test now protects that case on every run.

How do you run tests against a preview deployment created for each pull request?

Show answer

Make baseURL come from an environment variable, such as process.env.BASE_URL, with a default for local runs. In the pipeline, wait for the preview deployment to be ready, read its URL from the deployment step and pass it to the test job. Add a quick health check request first, so a failed deployment is reported clearly instead of as hundreds of test failures.

When should you avoid mocking, and how do you balance mocked and real tests?

Network MockingHard

Show answer

Avoid mocking in a small set of critical end-to-end journeys, such as signup, payment and checkout, where integration matters most. Use mocks for UI states, error handling and third-party services. Back the mocks with API contract tests so they match reality. A healthy split is many fast mocked component-level tests and a thin layer of full-stack tests.

How do you reuse login state across tests?

Show answer

Log in once in global setup, save storageState to a JSON file and set use.storageState in the config so every test starts logged in.

The app polls a status endpoint every few seconds. How do you test the change from Pending to Done?

Show answer

Mock the endpoint with a counter: return Pending for the first two calls and Done after that. Then assert the UI shows Pending and later Done using web-first assertions with a suitable timeout. You can also use page.clock to speed up the polling interval instead of waiting real seconds. This makes a slow real-world process quick and deterministic.

Tests pass with one worker but fail with eight. How do you debug this?

Debugging and Trace ViewerHard

Show answer

This usually means tests share something: the same user account, the same records or a global server setting. Run the failing file with --workers=8 and --repeat-each to reproduce it. Look at which tests run at the same time in the report. Fix it by giving each test unique data, using workerIndex in names, or isolating shared settings per worker.

Your mocked route never fires. What do you check?

Show answer

Check that the route is registered before the request is sent, usually before goto. Compare the pattern with the real URL in the trace network tab, including query strings and host. Make sure a service worker is not handling the request, and set serviceWorkers: 'block' if it is. Also check that another handler is not matching first or the route was not removed.

How do you use keyboard shortcuts in Playwright?

Playwright CoreMedium

Show answer

Use locator.press('Enter') for a key on a focused element, or page.keyboard.press('Control+A') for page-level shortcuts. Modifiers combine with a plus sign, and ControlOrMeta picks Ctrl on Windows and Linux and Cmd on macOS. keyboard.down and keyboard.up hold keys. Use pressSequentially only when the app needs real keystrokes, such as autocomplete.

Why mock the network in UI tests at all?

Network MockingEasy

Show answer

Mocking makes tests fast, stable and independent of backend data or third-party outages. It also lets you test states that are hard to create for real, such as empty lists, errors or huge responses. The trade-off is lower confidence that frontend and backend work together, so keep some unmocked end-to-end tests for critical journeys.

How do you keep API tests independent of environment data?

API TestingHard

Show answer

Do not depend on records that happen to exist in a shared environment. Each test or fixture creates what it needs through the API and cleans up after. Read environment-specific values such as base URL and credentials from config. For reference data that must exist, seed it in a setup project and verify it before tests run.

Retries make the build green, but nobody notices flaky tests. How do you surface them?

Show answer

Playwright already marks tests that passed on retry as flaky in the HTML and JSON reports. Read the JSON report in a small script after each run, post flaky test names to the team channel, and fail the build if the flaky count crosses a threshold. Over time you can track trends per test and per area.

How can you run only the tests affected by a code change?

Show answer

Use npx playwright test --only-changed=origin/main. It looks at files changed against that git reference and runs the test files that changed or that import changed files. It suits fast pull request feedback in a large suite. It cannot see backend or config changes that tests do not import, so still run the full suite before release.

Describe how you handled a flaky test that was blocking releases.

Debugging and Trace ViewerHard

Show answer

Situation: a payment test failed randomly and blocked three release builds. Task: unblock releases without hiding a real problem. Action: I quarantined it with a tag and a ticket, kept it running in a separate job, and used traces from twenty runs to find a missing wait on a redirect. Result: it was fixed in two days and releases continued meanwhile.

A setup fixture creates expensive test data and suite time has doubled. How do you redesign it?

Show answer

Measure first with the report timings. Then create data through the API instead of the UI, move read-only shared data into a worker-scoped fixture, and seed common reference data once in a setup project. Keep per-test data only for things a test changes. Cache login with storageState. This usually cuts setup time sharply without losing isolation.

How do you upgrade Playwright safely in a large suite?

Show answer

Read the release notes for breaking changes and deprecations. Upgrade on a branch, update the browsers and the Docker image to the same version, and run the full suite on all projects several times. Compare visual snapshots, which often change after browser updates. Upgrade regularly in small steps rather than skipping many versions.

How do you combine reports from sharded CI jobs?

Show answer

Use the blob reporter in each shard job, upload each blob-report folder as an artifact, then in a final job download them all into one folder and run npx playwright merge-reports --reporter html ./all-blob-reports. This gives one HTML report for the whole run instead of one per shard, which makes reviewing failures much easier.

How would you structure a large Playwright framework for a team?