When a Playwright test fails, its trace is the fastest way to see what the browser was actually doing at that moment. If the trace reached Qase with the result, you can open it from the result itself.

What changed

Reading a trace used to mean four steps: find the trace.zip in the result's attachments, download it, open trace.playwright.dev, and upload the archive there.

Now it is one. Open the failed result and click Play trace. Qase opens the Playwright trace viewer in a new tab and loads the archive straight from the attachment. It is the same viewer you already know, hosted by Qase, so nothing leaves for a third-party site.

Opening a trace

Open the test run and click the failed case. The result opens on its Execution tab, where the Play trace button sits below the attachments.

The Execution tab of a failed result, showing the error message, the trace.zip and error-context.md attachments, and the Play trace button beneath them

Click it, and the viewer opens in a new tab with the timeline, the DOM snapshots, the network log, and the console output for that test. Select any action on the left to see the page exactly as it was before and after that step.

The Playwright trace viewer open on a failed checkout test, with the failing click selected in the action list and the page snapshot showing the validation error

If a test was retried, each attempt uploads its own archive under the same name. Play trace always opens the newest one. The earlier archives stay in the attachment list and can still be downloaded.

What has to be true

The button appears only when the result actually carries a trace archive. Four things put one there.

Requirement	Detail
Playwright records a trace	Set the `trace` option in your Playwright config. `on`, `retain-on-failure` and `on-first-retry` all produce an archive; the default `off` produces nothing to play.
The trace is uploaded to Qase	The reporter uploads Playwright's attachments while the `testops.uploadAttachments` option is on, which is its default.
The archive is named for a trace	Qase looks for `trace.zip`, or a prefixed name such as `login-trace.zip`. A trace renamed to something else is not recognised and is treated as an ordinary attachment.
You are signed in to the workspace	The button is part of the result view in your workspace.

Nothing here depends on your subscription. Any workspace that receives a Playwright trace on a result gets the button.

Troubleshooting

What you see	What it usually means
No Play trace button, but there is a `trace.zip` in the attachments	The archive's name does not match the pattern Qase looks for, or you are viewing a result outside your workspace.
No Play trace button and no `trace.zip` at all	Playwright never wrote a trace for this test, or the reporter did not upload attachments. Check the `trace` option in your Playwright config and the `testops.uploadAttachments` option in your Qase config.
The viewer opens but stays empty	The viewer could not fetch the archive. Download the same attachment from the result: if that fails too, the file did not upload cleanly and the next run will have to produce a fresh one.
The trace shows an older attempt	You are looking at a different result in the retry history. Each attempt keeps its own trace.

Test Runs — how results reach a run in the first place.
Playwright's own documentation for the trace option, at playwright.dev.
Reporter configuration and every option named above, at developers.qase.io.

Play a Playwright trace from a test result

What changed

Opening a trace

What has to be true

Troubleshooting

Related