40 questions for Test Architect interviews — 12 medium, 28 hard.
About the Test Architect role
Designs the overall test strategy across unit, component, API and end-to-end levels and decides which tools and patterns teams use. With Playwright, a test architect sets up component testing, fixture architecture, mocking strategy, visual and accessibility gates and CI scaling. Interviews focus on trade-offs between test levels, cost and speed of feedback, handling experimental features, data isolation for parallel runs and influencing several teams toward one consistent approach.
Test strategy design Test pyramid trade-offs Fixture architecture CI scaling Cross-team influence
Solved for this roleStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What is the difference between workerIndex and parallelIndex?
workerIndex is a unique number for every worker process started during the run, so it keeps growing when a worker is restarted after a failure. parallelIndex is a slot number from 0 to workers minus 1, and a restarted worker reuses its slot. Use parallelIndex, also exposed as TEST_PARALLEL_INDEX, to pick a fixed test account or database per slot.
Call context.setOffline(true) to cut all network access for the context, then check that the app shows an offline banner or queues actions. Switch back with setOffline(false) and verify it syncs. You can also set offline: true in the context options. For a single failing endpoint, use route.abort instead of going fully offline.
03
How do you add or change request headers for only some requests?
Register a route for the matching URLs and call route.continue({ headers: { ...route.request().headers(), 'x-test-mode': 'true' } }). Other requests are untouched. For headers on every request, use extraHTTPHeaders in the config instead. This is useful for feature toggles, tenant ids or bypass tokens that only certain endpoints accept.
04
A worker-scoped fixture holds shared data and some tests see stale values. How do you fix it?
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.
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.
reportSlowTests makes Playwright list test files that took longer than a threshold at the end of the run. You set max, the number of files to show, and threshold in milliseconds, for example { max: 5, threshold: 60000 }. It is a cheap way to find files worth splitting, because one slow file can hold up a worker or a whole shard.
It is the entry file bundled into the component test page, so it runs in the browser before every mount. You import global CSS, fonts and theme files there, and register beforeMount and afterMount hooks to wrap components in providers such as a router, theme or state store. Keeping this setup in one place means individual tests can mount components without repeating boilerplate.
08
A component under test needs a complex class instance as a prop and the test fails to serialise it. What do you do?
Create a small test story component in a separate file that builds the class instance inside the browser and renders the real component with it. The test then mounts the story with simple props, such as an id or a scenario name. This keeps the data creation on the browser side of the boundary and also documents test scenarios as reusable stories.
09
Tell me about a disagreement with a developer over a failing test.
Situation: a developer said a failing checkout test was flaky and asked to skip it before release. Task: decide based on evidence. Action: I shared the trace showing the total stayed wrong after a coupon was removed and reproduced it manually. Result: we agreed it was a real bug, it was fixed before release, and we started reviewing traces together.
10
How do you mock a paginated endpoint that returns different data per page?
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.
12
How do you test a component that reads from a global state store?
Wrap the mounted component in the store provider inside beforeMount, and use hooksConfig to choose the initial state for each test, such as a logged-in user or an empty cart. Build the store in the browser side of index.tsx, not in the test file. Then interact with the component and assert on the rendered output rather than reading store internals.
13
What is a fixture option and how do you define one?
An option is a fixture whose value is configured rather than computed, declared with { option: true } and a default, for example defaultUser: ['standard', { option: true }]. Projects or test.use can override it, so one suite can run as admin in one project and as a viewer in another. Other fixtures can read the option to decide what to set up.
14
Mocked responses drift from the real API and tests pass while production breaks. How do you prevent this?
Generate mock data from the API schema or real recorded responses instead of hand-writing it. Validate mocks against the OpenAPI schema in a unit test. Add contract tests on the backend side and re-record HAR files on a schedule. Keep a few unmocked end-to-end tests that run after each deploy. Treat mock files as code with owners and reviews.
15
Describe a time you had to decide which testing level a feature belonged to.
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.
16
How do you rerun only the tests that failed in a sharded CI run?
--last-failed works only on the machine that kept the .last-run.json file, so it does not help across shards. Instead collect the failed tests from the merged JSON report or the blob reports, then run them in a follow-up job by file and line or with --grep on their titles. Many teams simply rely on retries and treat any test needing a rerun as flaky.
17
How do you test a dropdown component's keyboard support in a component test?
Mount the dropdown, focus the trigger and press Enter or ArrowDown to open it. Assert the listbox is visible and the first option has aria-selected or focus. Press ArrowDown again and check the active option moves, then press Enter and assert the trigger shows the chosen value and the list is closed. Finally press Escape on an open list to confirm it closes without changing the value.
18
How do project dependencies differ from globalSetup?
A setup project is a normal test file that other projects list in dependencies. It shows in the HTML report, can use fixtures, and records traces, so failures are easy to debug. globalSetup is a plain function that runs before everything without fixtures or traces. The docs now recommend project dependencies for login and data seeding.
19
How would you build a flaky-test dashboard from Playwright results?
Write a custom reporter or parse the JSON report after each CI run, and store per test: id, status, retry count, duration, branch and commit. A test that passed after a retry counts as flaky. Aggregate over the last few hundred runs to rank tests by flake rate and duration, and show trends. Use it to assign owners and quarantine tests above an agreed threshold.
20
Why can beforeAll run more than once in a Playwright run?
Each worker is a separate process with its own state. When tests from a file are split across workers, or a worker restarts after a failure, beforeAll runs again in the new worker. So never assume it runs only once globally. For one-time setup across the whole run, use a setup project with dependencies or globalSetup.
21
One shard finishes in 4 minutes and another takes 15. How do you balance them?
Check whether fullyParallel is off, because file-level sharding puts big files together. Turn it on if tests are independent, or split the largest files. Use reportSlowTests and the merged report's durations to find heavy files, and move slow setup into API calls or shared storage state. Also check that one shard is not getting all the tests of a slow project such as WebKit.
22
A component test passes alone but fails when the full component suite runs. What do you check?
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.
23
How does sharding split tests when fullyParallel is on compared with off?
With fullyParallel off, Playwright shards by test file, so one large file always lands on one shard and shards can be uneven. With fullyParallel on, it shards by individual test, giving much more even distribution. Either way the split is deterministic, so the same shard number always gets the same tests for a given set of files, which helps reproduce failures.
webServer tells Playwright to start your app with a command, such as npm run start, and wait until a URL or port responds before running tests. reuseExistingServer: !process.env.CI lets you use an already running dev server locally. You can define several servers, for example frontend and a mock API. It shuts them down after the run.
25
How do you decide how many shards a suite should use?
Start from the target wall-clock time and the total test time per machine. If one machine with its workers takes 40 minutes and the goal is under 10, you need about four or five shards, plus some margin for setup like installing browsers. Past a point each shard spends more time on setup than on tests, and the app or test data may become the bottleneck, so measure each change.
Start the job and assert the 202 status and the returned job id. Then poll the status endpoint with expect.poll, with sensible intervals and a timeout, until it reports completed. Finally fetch the result and validate it. Also test the failure path, for example invalid input leading to a failed status with a clear error message.
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.
29
Which methods does the Playwright Reporter interface provide?
The main ones are onBegin with the config and full suite, onTestBegin and onTestEnd for each test, onStepBegin and onStepEnd for steps, onStdOut and onStdErr for output, onError for errors outside tests and onEnd with the overall result. onEnd can be async, so you can send results to an API before the process exits. You register the reporter by path in the reporter config.
30
Describe how you handled a flaky test that was blocking releases.
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.
31
Why do component tests run in two processes, and what limits does that create?
The test code runs in Node while the component runs in the browser. When you write mount(<Button title='Save' />), Playwright serialises the JSX and props and rebuilds them in the browser bundle. So props must be plain data such as strings, numbers, arrays and objects, plus callbacks, which Playwright proxies back to Node. Class instances, complex objects or live references cannot cross that boundary directly.
32
A fixture mocks every /api call, but one test needs a different response for /api/cart. How do you override it?
Register a new page.route for /api/cart inside that test. Handlers run in reverse order of registration, so the newer one runs first. Fulfil the cart request with the special data, and for anything else call route.fallback() so the request moves on to the fixture's general handler. This keeps the shared mock untouched and makes the override local and easy to read.
33
Two test files edit the same global settings page and break each other when run in parallel. How do you handle it?
The best fix is to remove the shared resource, for example by giving each test its own tenant or user whose settings it can change. If that is impossible, put those tests in one file with test.describe.configure({ mode: 'serial' }), or in a separate project that runs with one worker after the main project. Document why, so the exception does not quietly spread.
34
Write a minimal custom reporter that prints the titles of failed tests at the end.
Separate tests, page objects, fixtures, utilities, test data and config; use tags, projects, shared auth setup, linting, code review and a CI pipeline with sharding and reports.
36
How can you run only the tests affected by a code change?
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.
37
How do you filter a list of locators by text or by a child element?
Situation: managers only heard pass or fail and could not tell flaky tests from real bugs. Task: make results useful. Action: I added a custom reporter that posted a short summary to our team chat with failures, flaky tests and a report link, and a weekly trend of flake rate. Result: flaky tests dropped by half in two months because owners could see them.
39
When should you avoid mocking, and how do you balance mocked and real tests?
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.
40
What are the risks of relying on an experimental testing feature in a large codebase?
APIs may change between minor versions, so upgrades can break many tests at once, and documentation or community examples are thinner. To reduce risk, pin versions, wrap mount setup in shared helpers, keep stories simple and read release notes before upgrading. Also keep the end-to-end suite healthy so you are not dependent on one tool for all UI confidence.
Frequently asked questions
What does a Test Architect do?
Designs the overall test strategy across unit, component, API and end-to-end levels and decides which tools and patterns teams use. With Playwright, a test architect sets up component testing, fixture architecture, mocking strategy, visual and accessibility gates and CI scaling. Interviews focus on trade-offs between test levels, cost and speed of feedback, handling experimental features, data isolation for parallel runs and influencing several teams toward one consistent approach.
Which skills are tested in a Test Architect interview?
Expect questions on Test strategy design, Test pyramid trade-offs, Fixture architecture, CI scaling, Cross-team influence. Most rounds also ask you to explain a project and solve one practical problem live.
How do I prepare for a Test Architect interview?
Revise Component Testing, Fixtures and Hooks, Parallel Runs, Sharding & Reporting, Network Mocking first using the topic sheets, practise the questions on this page aloud, then do one full mock interview to practise timing.