Question 1

How do you debug a test in Playwright? Walk through the tools.

Accepted Answer

I separate the context, because local and CI need different tools. Locally: my default is --ui — run in watch mode, time-travel through steps, pick locators live. When I need to inspect a specific point I drop in page.pause() and run with --debug. Breakpoint + Debug Test in the VS Code extension is another very fast loop. In CI: step one is downloading the trace artifact and opening it with npx playwright show-trace — it holds the DOM snapshot at the failure, the network requests and the timing, so I see rather than guess. My config is set up for this: trace: 'on-first-retry', screenshot: 'only-on-failure'. For flakiness: I measure the reproduction rate with --repeat-each, find and fix the root cause, then prove it with --repeat-each=20 --retries=0. It helps to close with: console.log is my last resort — the tools give more information, faster.

Question 2

Which part of a trace is the most valuable, and why?

Accepted Answer

For me, the DOM snapshots. The reason: in most failures the question isn't "what did the code do?" but "what state was the page in at that moment?". A screenshot only pictures it; the snapshot is interactive — you can browse the DOM, check whether the element really existed, what role/name it exposed, and what was covering it. A concrete example: an "element not found" failure. In the snapshot you see the element does exist but sits underneath the cookie banner — so the problem isn't the locator, it's the overlay. With only a screenshot you'd have seen the banner and still been guessing. The second most valuable part is the network tab: a 401, a 500 or a late-arriving request reveals the real cause of a UI failure at a glance — and that is very often a product bug rather than a test bug.

Question 3

What would you set up to reduce debugging time across the team?

Accepted Answer

I frame the goal as: whoever looks at a red test must find the cause without rerunning CI. To get there: (1) Artifacts always ready — trace: 'on-first-retry', screenshot: 'only-on-failure', video: 'retain-on-failure', and guaranteed artifact upload in CI (if: failure()). (2) The report within reach — the HTML report attached as an artifact and, where possible, published to static hosting (GitHub Pages or similar) so the link appears directly in the PR. Downloading an artifact is one step; clicking a link is zero. (3) A test.step() convention — long flows get named stages, so the report shows which stage broke at a glance. (4) Clear test names — the name in the CI list should already be a diagnosis. (5) Team knowledge — one 20-minute demo of the trace viewer. In practice the biggest problem isn't a missing tool, it's the team not knowing it exists. I measure the outcome: the average triage time for a red test. That metric both demonstrates the value and moves the conversation off "I feel like".

Symptom	First tool	What you look for
Fails in CI, passes locally	Trace viewer (the CI artifact)	The DOM snapshot at failure, network statuses, timing
The locator doesn't find the element	UI mode / Inspector "Pick locator"	The element's real role/name, whether it sits inside an iframe
A problem mid-way through a long flow	page.pause() + --debug	The page's live state at that exact moment
The test sometimes passes, sometimes fails	--repeat-each=20 --retries=0	The reproduction rate; proof the fix actually works
The test takes far longer than expected	The trace viewer timeline	Which step eats the time — usually a hidden wait or a slow request

Debugging techniques: trace viewer, UI mode, inspector

📚 Sources and documentation