Skip to content

Debugging and Trace Viewer Interview Questions for Playwright Testing

34 Debugging and Trace Viewer questions with answers for playwright testing roles — 10 easy, 18 medium, 6 hard.

About Debugging and Trace Viewer

Covers the Inspector, UI mode, page.pause, the VS Code extension, trace recording and the trace viewer, HTML reports, console logs and techniques to reproduce flaky failures. Almost every interview includes a 'test fails only in CI' scenario, so explaining a clear, evidence-based debugging process is one of the most valuable skills here.

Sheet progressStart 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 Playwright Inspector and how do you open it?

Save to ▾
Show answer
The Inspector is a debug window that lets you step through test actions one by one, see the locator being used and highlight it on the page. Open it with npx playwright test --debug, with PWDEBUG=1, or by calling page.pause(). It runs headed with no timeout, so you can explore the page at each step and edit locators live.
02

What does page.pause() do?

Save to ▾
Show answer
page.pause() stops the test at that line and opens the Inspector, as long as the test is running headed. You can then inspect the page, try locators and resume or step forward. It is useful for checking the state just before a failing step. Remove it before committing, because it would hang a headless CI run.
03

How do you open a trace file?

Save to ▾
Show answer
Download trace.zip from the test results or CI artifact. Run npx playwright show-trace path/to/trace.zip to open it locally, or drag the file into trace.playwright.dev, which processes it in the browser without uploading it. In the HTML report, failed tests with a trace show a trace link you can click directly.
04

What do headed mode and slowMo do?

Save to ▾
Show answer
--headed shows the browser window instead of running headless, so you can watch the test. slowMo, set in launchOptions, adds a delay in milliseconds before every action, which makes fast steps visible. Both help when you are writing or debugging a test. Do not leave slowMo on in CI, because it slows every action.
05

What is the HTML report and how do you open it?

Save to ▾
Show answer
The HTML reporter creates a playwright-report folder with every test, its steps, errors, attachments, screenshots and trace links. Open it with npx playwright show-report. You can filter by status, project and tags. In CI, upload the folder as an artifact so anyone can download and open it, and the report opens automatically locally when tests fail.
06

What does the Pick locator tool do?

Save to ▾
Show answer
In the Inspector, UI mode and the VS Code extension, Pick locator lets you hover over any element on the page and see the locator Playwright recommends for it, usually a role or label based one. You can copy it into your test. It is a fast way to write locators and to check whether an existing one is unique.
07

What does npx playwright test --last-failed do?

Save to ▾
Show answer
It reruns only the tests that failed in the previous run, using the results stored in the test-results folder. It saves time while you fix failures locally because you do not rerun the whole suite. Combine it with --headed or --debug to investigate. Run the full suite again before pushing to confirm nothing else broke.
08

Tell me about a hard bug you found while debugging a test.

Save to ▾
Show answer
Situation: a search test failed about once in ten runs. Task: find the cause. Action: I ran it with --repeat-each and traces, and saw two search requests return out of order, so the older result replaced the newer one. Result: I proved it was a real race condition in the app, developers fixed it with request cancellation, and the test became stable.
09

Tell me about the first time you used the trace viewer to solve a failure.

Save to ▾
Show answer
Situation: during my internship a login test failed only in CI and I could not reproduce it. Task: find the cause. Action: I enabled trace on first retry, downloaded the trace and stepped through the actions, and saw a cookie banner covering the sign-in button in the CI viewport. Result: I added a step to accept the banner, the test became stable, and I shared the method with my team.
10

How can you view a trace file without a local Playwright install?

Save to ▾
Show answer
Open trace.playwright.dev in a browser and drag the trace zip onto the page. It is a static web app that loads the trace locally in the browser, so the file is not uploaded to a server. This lets developers or managers look at a failed CI run quickly. For full features and offline use, npx playwright show-trace works too.
11

How does Playwright's trace viewer help?

Save to ▾
Show answer
It records screenshots, DOM snapshots, network calls and actions per step so you can replay a failed run and see exactly what happened.
12

What is codegen?

Save to ▾
Show answer
npx playwright codegen records user actions and generates test code with suggested locators, handy for starting tests.
13

How do you debug a Playwright test?

Save to ▾
Show answer
Use --debug or the Inspector, page.pause(), UI mode, the trace viewer and headed runs with slowMo.
14

How do you take screenshots and videos?

Save to ▾
Show answer
page.screenshot() for captures and config options use: { screenshot: 'only-on-failure', video: 'retain-on-failure' } for automatic evidence.
15

What are the options for the trace setting in playwright.config?

Save to ▾
Show answer
Values are 'off', 'on', 'retain-on-failure', 'on-first-retry' and 'on-all-retries'. 'on-first-retry' records only when a failed test is retried, which keeps the normal run fast and gives a trace for flaky failures. 'retain-on-failure' records every test but keeps only failed ones. 'on' records everything and is mainly for local investigation.
16

What does a Playwright trace contain?

Save to ▾
Show answer
A trace contains every action with its timing, DOM snapshots before and after each action, screenshots in a filmstrip, console messages, network requests with headers and bodies, the source line of each step and the error. Because the DOM snapshots are real, you can inspect elements after the run. It is usually the fastest way to understand a CI failure.
17

What is UI mode and how is it different from --debug?

Save to ▾
Show answer
UI mode, opened with npx playwright test --ui, is a dashboard to run, filter and watch tests, with a trace-like timeline for each one and a watch mode that reruns on file changes. --debug opens the Inspector to step through a single run live. Use UI mode for daily development and --debug for stepping through a specific action.
18

How do you record a trace manually with the tracing API?

Save to ▾
Show answer
Call await context.tracing.start({ screenshots: true, snapshots: true }) before the steps, and await context.tracing.stop({ path: 'trace.zip' }) after them. This is useful in scripts that use the library without the test runner, or when you want a trace of only part of a flow. tracing.group can label sections of steps.
19

How do you capture browser console messages and page errors?

Save to ▾
Show answer
Listen with page.on('console', msg => ...) for console.log, warnings and errors, and page.on('pageerror', err => ...) for uncaught exceptions. Collect them in an array and attach them to the report on failure. Traces also show console output. Uncaught page errors often explain why a button did nothing or a page stayed blank.
20

How do you fail a test if the page logs any console error?

Save to ▾
Show answer
test('no console errors', async ({ page }) => { const errors: string[] = []; page.on('console', m => { if (m.type() === 'error') errors.push(m.text()); }); page.on('pageerror', e => errors.push(e.message)); await page.goto('/dashboard'); expect(errors).toEqual([]); });
21

What does the DEBUG=pw:api environment variable do?

Save to ▾
Show answer
Setting DEBUG=pw:api prints detailed logs of every Playwright API call to the terminal, including waits and retries inside actions. It helps when a test hangs and you need to see exactly which step is waiting and why. Other channels such as pw:browser show browser process output. It is noisy, so use it only while investigating.
22

How do you read a Playwright timeout error message?

Save to ▾
Show answer
The error names the action and locator, for example locator.click: Timeout 30000ms exceeded, followed by a call log. The call log lists each attempt, such as waiting for the element to be visible, enabled and stable, or another element intercepting pointer events. The last lines show what blocked the action. Read it before changing timeouts.
23

A trace shows the click landed on an overlay instead of the button. How do you fix it?

Save to ▾
Show answer
The call log will say another element intercepts pointer events. Find what the overlay is, such as a loading mask, cookie banner or chat widget. Wait for it to disappear with expect(overlay).toBeHidden(), or close it in a fixture. Do not use force: true, because it hides a real issue: a user would also be blocked by that overlay.
24

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

Save to ▾
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.
25

How do test.slow() and longer timeouts help or hurt debugging?

Save to ▾
Show answer
test.slow() triples the timeout for a test that is genuinely long, such as a report export. It is honest and visible in code. But raising timeouts to make a flaky test pass hides the real cause, such as a missing wait or slow backend, and makes failures take longer. Investigate the trace first and change timeouts only with a reason.
26

How do you reproduce a flaky test locally?

Save to ▾
Show answer
Run it many times in isolation: npx playwright test cart.spec.ts -g 'apply coupon' --repeat-each=30 --workers=4 --trace=on. Repeating it with several workers creates the timing pressure CI has. Add --retries=0 so failures are not hidden. Once it fails, open the trace for that run and compare it with a passing run.
27

How do you inspect a specific network request in the trace viewer?

Save to ▾
Show answer
Open the Network tab in the trace viewer, which lists every request in the test. Click one to see method, URL, status, request and response headers and bodies, and timing. Selecting an action filters the list to requests around that step. This shows whether a UI failure came from a failed API, a slow response or unexpected data.
28

A test fails with 'Target page, context or browser has been closed'. What usually causes it?

Save to ▾
Show answer
Most often an action was not awaited, so the test finished and Playwright closed the page while the action was still running. Other causes are a test timeout closing the page, the code closing the page or context itself, or the browser crashing. Check the stack for the missing await, look at whether a timeout happened first, and turn on the lint rule for floating promises.
29

A test passes locally but fails in CI with a timeout on a click. How do you use the trace?

Save to ▾
Show answer
Open the CI trace and go to the failed click. Check the action log, which shows what Playwright waited for, such as the element not being visible or another element intercepting pointer events. Compare before and after snapshots and the network tab for slow or failed calls. Common causes are a slower environment, a cookie banner or different screen size.
30

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

Save to ▾
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.
31

What are the trade-offs of trace 'on' versus 'retain-on-failure' in CI?

Save to ▾
Show answer
'on' records and keeps every trace, which costs time, disk space and artifact storage for thousands of passing tests. 'retain-on-failure' still records everything but deletes traces of passing tests, so cost is mainly runtime. 'on-first-retry' is cheapest but gives no trace for a first failure without retries. Most teams use on-first-retry with retries in CI.
32

A test fails only in WebKit. How do you investigate?

Save to ▾
Show answer
Run it alone with --project=webkit --headed and record a trace. Compare it with the Chromium trace to see where behaviour differs, such as date input format, scrolling, font rendering or a missing browser API. Check the app's support matrix. If it is a real product bug, raise it, and skip the test for WebKit with a linked ticket until it is fixed.
33

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

Save to ▾
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.
34

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

Save to ▾
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.

Frequently asked questions

How important is Debugging and Trace Viewer in Playwright Testing interviews?

Covers the Inspector, UI mode, page.pause, the VS Code extension, trace recording and the trace viewer, HTML reports, console logs and techniques to reproduce flaky failures. Almost every interview includes a 'test fails only in CI' scenario, so explaining a clear, evidence-based debugging process is one of the most valuable skills here.

How should I use the Debugging and Trace Viewer sheet?

Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.