Test Evidence: Proving Your Software Was Tested

Test evidence is the record that proves a piece of software was tested: what was tested, by whom, when, in which environment and with what result. It is what you show a client who asks "did anyone check this?", an auditor reviewing your quality process, or your own team trying to understand why a bug slipped through.

Without evidence, testing is a claim. With it, testing is a fact.

What good test evidence contains

Strong evidence answers every follow-up question before it is asked. Aim to capture:

• The item tested — the ticket, feature or requirement.
• The tester — a named person, not "QA".
• Date, time and duration — when the testing actually happened.
• The environment — QA, staging or production, and ideally the build or release.
• The result — pass or fail, per item.
• Supporting artefacts — screenshots, attachments and notes on failures.
• What happened next — retests, amended results and final outcome.

Capture it during testing, not after

The weakest evidence is written up from memory once a release is out. The strongest is captured as a side effect of doing the testing.

1. Test in organised runs rather than ad hoc, so every result has a home.
2. Record results immediately, ticket by ticket.
3. Attach evidence to failures as you log them.
4. Keep amendments visible. If a result changes, the history should show it, not overwrite it.
5. Close the run formally, so there is a clear end point.

Our step-by-step guide on how to run a test run shows this in practice.

Need proof your work was tested? See how Flow records test runs and sign-off as evidence. Get started with Flow →

Make evidence trustworthy

Evidence is only useful if people believe it has not been edited after the fact. That means:

• Records that cannot be quietly changed once finalised.
• A way for a third party to verify that a document is genuine.
• A clear link from the evidence back to the tickets and release it covers.

This matters most where you must show evidence to someone outside the team, such as a client, a regulator or an auditor working through an ISO 27001 audit for software teams.

Dedicated tools: TestRail and Xray

TestRail is a mature, dedicated test-management tool with detailed run histories and reports that many teams use as their evidence trail. Xray is a widely used test-management app for Jira, available through the Atlassian Marketplace, which keeps test executions next to Jira issues.

Both are capable choices. If you are evaluating a TestRail alternative or an Xray alternative, ask how each produces a document you can hand to someone outside the team, and how that person can tell it is authentic.

How Flow helps

Livex Flow captures test evidence as your team tests, then turns it into documents that hold up.

• Runs that record everything. The test-run wizard sets the tickets and testers; runs are started, paused and completed with time recorded, and each ticket gets a pass or fail.
• Failures with attachments. Log issues with attachments during a run, with auto-saved drafts, and see each ticket's failure history.
• Sealed, verifiable documents. Generate a Test Evidence Report (TER), plus a Client Sign-off Record (CSR) or Rejection (REJ) when the client decides. These are sealed and verifiable, so recipients can trust they have not been altered.
• Linked to releases. Tickets are attached to releases, so evidence connects to what actually shipped. That supports a clean QA sign-off.