Playwright Trace Viewer: investigate a failed checkout test step by step
Prepared with AI assistance and linked primary sources. Examples are illustrative unless stated otherwise.
When a Playwright test fails, compare the requirement, the actions taken and the observed result before changing the test. Trace Viewer helps you inspect the recorded run. A passing retry is useful evidence, but it does not explain the original failure or prove that the underlying problem has been fixed.
What the documented tracing update adds
Playwright’s version 1.63 release notes describe richer information for test steps, including parameters and subtitles, plus options to capture DOM, accessibility and screen snapshots in traces. These additions can give reviewers more context about an action. This article discusses the documented version; it does not claim that it was released today.
Our exercise uses a simpler existing trace configuration and does not require those optional snapshot settings. The goal is to practise a debugging decision: did the application behave incorrectly, or did the test expect the wrong result? More recorded detail is useful only when you connect it to that question.
Start with a requirement you can calculate
Use the SPOTHUB practice checkout, which displays a notebook priced at INR 100. Changing the quantity from one to two should display INR 200. There is no tax, delivery charge or discount in this demo. Write that expected result before opening the test file so you have an independent reference.
The debugging lab contains a deliberate fault mode: it changes the test’s expected total to INR 100 after selecting two items. The application can be correct while that assertion fails. This controlled mistake is an exercise, not a report of a real customer defect or a student placement project.
Reproduce the failure in a separate practice folder
Open the linked debugging lab and follow its setup instructions. Download debugging.spec.ts, playwright.config.ts and the demo HTML. The configuration targets Microsoft Edge and expects the demo at /labs/checkout.html on your local server. Use the lab’s documented LAB_BASE_URL setting if your server has a different address.
First run npx playwright test debugging.spec.ts with no fault switch. In PowerShell, set $env:LAB_EXPECT_WRONG='1' and run the same command again. A failed assertion is the intended result in this second run. Read the error before making changes: the expected value should be INR 100 and the observed value INR 200.
- Record the starting quantity, chosen quantity and independently calculated total.
- Keep the command output so another person can reproduce the same fault mode.
- Use only the provided synthetic demo; no real order or payment is involved.
Read the trace as evidence
The lab configuration records a trace. Open the trace.zip path printed by your run with npx playwright show-trace followed by that path. Trace Viewer lets you inspect recorded actions, snapshots and other details from the run. Begin at the failing assertion, then work backward to the quantity change.
Check three observations: the test selected quantity two, the page displayed INR 200, and the assertion asked for INR 100. Together with the written pricing rule, these observations support correcting the expected value. If the quantity never changed, you would need a different investigation; the same red test result can have several causes.
Fix the reason, then repeat the relevant check
For this exercise, remove the deliberately wrong expectation by running Remove-Item Env:LAB_EXPECT_WRONG in PowerShell, then rerun the test. The normal lab expects INR 200. Keep the failed and corrected run records so your explanation includes both the original evidence and the result after the change.
Avoid deleting the total assertion just to obtain a green result. That would remove the check which protects the requirement. Also distinguish an assertion failure from a missing browser or an unavailable local server: those setup problems require fixing the environment before this exercise can demonstrate anything about the total.
Why retries are not a diagnosis
Playwright distinguishes tests that pass initially, tests that pass on a retry and tests that still fail after retries. A retry can help reveal inconsistent behaviour, but this intentionally incorrect expectation should remain wrong on every attempt. Increasing the retry count does not change the pricing requirement.
For a portfolio or interview, explain the requirement, evidence, cause and correction in that order. Mention the scope: this lab checks a displayed browser total, not inventory, backend persistence or payment processing. Chennai learners considering Playwright training can use that explanation to discuss their current testing skills and where they need guided practice. Training does not guarantee employment.
Sources and further reading
- Playwright release notes: version 1.63 · checked 2026-09-20
- Playwright documentation: Trace Viewer · checked 2026-09-20
- Playwright documentation: test retries · checked 2026-09-20
- SPOTHUB practice lab: debugging with traces · checked 2026-09-20
Spot an error? Email info@spothub.in with the article link and correction.