Keep the failure evidence before you rerun

An illustrative test opens a settings page, submits a change, and fails because the expected value never appears. Someone posts the last screenshot. It shows an empty panel. Was the user signed out? Did the save request fail? Did the assertion run against the wrong record? The image cannot answer those questions by itself.

A test failure is a sequence, not a photograph. This article proposes a small evidence packet that a QA engineer or developer can read without repeating the whole exploration. The aim is to reduce avoidable investigation, not to collect every possible byte or promise an automatic diagnosis.

Start with the action and its context

Playwright's Trace Viewer lets you inspect a recorded test trace with an action timeline and associated snapshots. Its documentation describes examining source, errors, console output and network activity. Those views answer different questions: what the test attempted, what the page showed, and what the application exchanged. A screenshot remains useful, but it is one view inside a larger packet.

Record the test identifier, code revision, environment, initial account role and the assertion that failed. Describe the expected state in plain words. Keep secrets out of the description. The evidence should say which staging role was used, not publish a session cookie or a real customer's identity.

The five-field handoff

Use five fields for each failure: expected result, actual result, first failing step, trace or artifact location, and reproduction conditions. Under actual result, distinguish a received error response from an absence of visible content. Under conditions, note the relevant seeded record and whether a parallel test could have changed it.

Do not let an agent's explanation replace the original evidence. A confident narrative is a hypothesis until the action log or application state supports it. Mark suspected causes as suspected. If the artifact is unavailable, state that gap rather than writing a plausible sequence from the final screenshot.

This format helps both kinds of team. A QA lead gets a reviewable handoff instead of a wall of generated text. A company without a dedicated QA engineer gets an incident another developer can pick up after the original tester leaves the desk. Neither requires a fictional root cause to sound complete.

Choose when to collect a trace

Playwright's test options document trace modes, including retaining a trace on failure and recording on the first retry. The choice matters. A first-retry trace records that later attempt, which may behave differently from the original failure. If evidence from the first attempt is needed for a critical flow, do not assume a retry-only recording contains it.

Choose an artifact policy for each risk class and check that it actually produces the needed file. Capturing every run may cost storage and time. Capturing too little may cost investigation. Measure those costs on your suite instead of adopting a universal rule from a demo.

Protect the packet before sharing it

Traces and screenshots can contain page content and request details. Use synthetic staging data, limit artifact access and set a retention window. Review the actual contents before sharing a trace outside the team. Removing a filename that looks sensitive does not remove the session or personal data inside the file.

AnyTest's public page describes observations at each step and failure reasons. That is useful product context, but it is not a claim that its output is identical to a Playwright trace. Keep vendor evidence formats separate and verify what your chosen runner actually retains.

Measure the investigation, not the screenshot count

During a pilot, record the minutes from first failure to a reproducible description, then to a confirmed cause. Separate time spent fetching missing artifacts from time spent fixing the product. Agentic QA saves investigation time only if the evidence is usable and the reviewer can trust its provenance. A smaller packet that answers the question is better than a large archive nobody opens.