Collecting test evidence: screenshots, logs and records

Evidence does two jobs in testing. During the project, it lets developers see a problem without having to reproduce it from words alone. After the project, it is the record of what was checked, which matters when someone later asks whether a particular feature was tested before launch. Both jobs need the same thing: evidence that makes sense to a person who was not there.

Evidence for a single failure

Screenshots

A screenshot is the quickest evidence and can be enough. Make it useful:

• Include context. Show the address bar, or note the URL beside the image. A cropped picture of a broken button does not say which page it is on.
• Show the problem clearly. If the issue is small, add a simple box or arrow. Do not cover the surrounding content, which may matter.
• Capture the right size. For a layout problem on a phone, take the screenshot on the phone, or record the exact width if you used a desktop browser's responsive mode.
• Name files usefully. A name such as QA-014-contact-safari-iphone.png ties the file to the defect and the environment.

Screen recordings

Use a recording when the problem involves timing, movement or a sequence: a menu that closes too fast, content that jumps while loading, a form that loses data after an error. Keep it short, ten to thirty seconds, starting just before the problem. Recordings are easy to make on current operating systems; both desktop systems and phones include a built-in screen recorder.

Console and network information

When something fails silently, the browser's developer tools can show why. Open them before reproducing the problem:

• Console. Red errors here point developers to scripts that failed. Copy the error text into the report rather than only screenshotting it, so it can be searched.
• Network. A failed request, such as a form submission that returns an error status, shows up here. Note the request address, the status code and the time.

You do not need to understand these messages to report them. Copying them accurately is enough.

The details that make evidence trustworthy

• Environment. Browser and version, device, operating system.
• Time. When the attempt was made, which helps developers find matching server logs.
• Data used. The exact text entered, if it might matter.
• Repeatability. Whether it happened every time, and how many attempts were made.

Evidence for the whole test run

Individual screenshots show failures. The record of the run shows coverage, including all the things that passed. Without it, a clean defect list could mean careful testing or very little testing.

A test log can be as simple as a spreadsheet with one row per test case run:

The free test case builder exports cases with result, tester and date columns ready for this. Alongside the log, keep a short summary that states the scope: which pages, flows, browsers and devices were in, and which were out. The scope statement is what turns a log into an honest record.

What "passed" evidence looks like

For a routine passing test, the log entry is enough. For a few, it is worth keeping proof:

• Form delivery. A screenshot of the test message arriving in the real inbox, with the time.
• Redirects. The response headers showing a single permanent redirect from the old address.
• Security settings. The response headers showing the security headers that were present on the day.
• Accessibility checks. The automated checker output for each sampled page, alongside notes from the manual review.

These are the checks people ask about later, and a dated screenshot answers the question in seconds.

Organising evidence so it can be found

Evidence that cannot be found later is not much better than no evidence. A simple structure is enough for a small project:

• One folder per test round, named with the date, such as 2026-11-04-first-pass.
• File names that start with the defect ID, so evidence sorts next to its defect.
• The test log and scope statement at the top of the folder, so anyone opening it knows what it covers.
• A short note in each defect report saying where its evidence lives.
• Retest evidence saved beside the original, with "retest" in the file name.

If you use an issue tracker, attach evidence directly to the issue instead, and keep the scope and test log in the project's shared documents. The aim is the same: a person who joins the project months later should be able to answer "was this tested, and what happened?" in a few minutes.

Evidence when the problem is intermittent

Some defects appear only now and then. They are harder to reproduce, so evidence matters more for them. When a problem cannot be reproduced on demand, record every occurrence: the time, the page, the environment, what you were doing just before, and any error text. Keep the browser's developer tools open while testing so console errors are captured when the problem appears. Over several occurrences, a pattern can emerge, such as a time of day, a particular browser, or a step done quickly, and that pattern is what lets a developer find the cause.

Keeping personal data out

Testing websites with real content means screenshots can capture personal data: customer names in an admin panel, email addresses in a form, messages in an inbox. Treat evidence as you would any other record containing personal data.

• Use test accounts and invented details wherever you can. Choose names that are obviously fictional.
• Crop or blur personal details that are not needed to show the problem.
• Do not paste real customer data into bug reports in shared tools.
• Store evidence where only the project team can reach it, and delete it when it is no longer needed.

If a defect involves a real person's data, such as an order that went wrong, describe it in words and share the details only with the person who needs them.

How long to keep evidence

Keep test evidence for as long as it is useful and no longer. A sensible default is to keep the summary and test log with the project records, and to delete raw screenshots and recordings once the defects are closed and the release has settled, unless your organisation has a reason to keep them. If you work under contracts or regulations with retention rules, those rules decide.

Evidence for accessibility findings

Accessibility findings need slightly different evidence, because the problem can lie in how a page behaves rather than how it looks.

• Keyboard problems. A short recording of tabbing through the page shows a missing focus indicator or a trap far better than words.
• Contrast problems. Record the two colours and the measured ratio, along with a screenshot of the text in question.
• Missing labels or names. A screenshot of the browser's accessibility inspector, or the relevant line of markup, shows what assistive technology receives.
• Reflow and zoom. A screenshot at the width or zoom level where the problem appears, with that width or level noted.

Map each finding to the WCAG 2.2 success criterion it relates to, so the developer can read the criterion and its understanding document.

Evidence that does not age well

Some evidence loses meaning quickly. A screenshot of a staging site that has since been rebuilt, a console error from a script that no longer exists, or a performance figure measured before images were optimised can mislead anyone who reads it later without context. Two habits help: always record the date and environment, and when a defect is fixed, attach the retest evidence next to the original so the history is complete.

How evidence appears in our reports

Every defect in a Qaveridia report carries its own evidence: the page, the environment, the steps, the expected and actual result, and a screenshot or recording. The report also includes the scope statement and the test log, so it records what passed as well as what failed. The sample reports page shows the format with invented content.