Test Evidence for an Audit: Proving Testing Happened

An audit doesn't ask if you tested

An audit — or a customer's security review — never asks the question you expect. It doesn't ask "did you test this?" It assumes you'll say yes. It asks you to show it: show what you tested, show that it covered what was required, and show that a named person accepted the result on a specific date.

That's a different thing from testing well. Plenty of teams test thoroughly and still can't prove it, because they treated their test records as a working tool — something to clear out and move past each sprint — rather than as a record to keep. The gap between those two shows up in exactly one week: the week someone asks for an evidence pack.

And here's the trap. If the evidence doesn't already exist, you rebuild it from tickets, chat history, and memory while the clock runs. That reconstruction is how a fortnight disappears, and it produces a weaker record than if you'd simply kept one. This pillar is about keeping the record so the pack is something you export, not something you write.

The chain: requirement, case, run, defect

What an auditor actually follows is a chain with four links, and your evidence is only as strong as the weakest one.

Requirement — what the product was supposed to do. The rule, the acceptance criterion, the change in scope. Case — the test that verifies that requirement, so you can point from one to the other. Run — the record that the case was actually executed: when, on which build, in which environment, and with what result. Defect — what the testing found, and evidence that it was resolved or knowingly accepted.

The auditor walks it in order: show me a requirement, the case that covers it, the run that executed that case against what shipped, and the defects it turned up along with how they were closed. Break any link and the chain stops being evidence.

The link teams habitually break is the run. Requirements live in the tracker and cases live in the tool, but the run history gets overwritten — the case shows only its latest result, not the record that it executed on the version you actually released. You end up able to say a test exists, but not to prove it ran when it mattered.

What an evidence pack actually contains

"Evidence pack" sounds vague until you list what goes in one. For a given release, it's usually a concrete set of documents:

• The scope — the requirements or changes the release was meant to deliver.
• The traceability mapping — which test case covers which requirement, so coverage is visible rather than asserted. This is the requirements-traceability view an audit leans on.
• The run records — which cases ran, when, on which build and environment, and whether they passed.
• The defects — what was found, how severe, and how each was resolved: fixed and retested, or accepted with a reason.
• The sign-off — who approved the release, on what date, against exactly what.

Assembled, those five answer the audit's real question — not "did you test?" but "prove that you tested what was required and that someone owned the decision to ship." It's also the backbone of a release sign-off process worth the name.

Approval as data

Most teams think they have sign-off. What they usually have is an email that says "looks good to me," or a ticket dragged to Done. As evidence, that's thin, because approval that counts is data with three parts.

Who accepted it — a named person, not "the team." When — a timestamp, not "around the release." And what — the exact state of the artifact at the moment it was approved: the version of the case, ideally the diff of what changed just before it was accepted. "Reviewed by QA" carries none of these, so it proves almost nothing.

The reason the third part matters is subtle. Months later, the question isn't only whether something was approved — it's what was approved. If the case changed after sign-off, an approval with no captured state can't tell you whether the reviewer saw the version that shipped. A credible audit trail for test management pins the approval to the actor, the time, and the state, so the answer is on the record instead of in someone's memory.

Why reconstructing afterwards fails

When the request lands and the evidence isn't there, teams try to rebuild it. It fails on two fronts at once.

The first is cost. Reconstruction is archaeology — digging through old tickets, chat threads, commit logs, and half-remembered decisions to reassemble a story that was never written down. It's slow, it pulls your best people off delivery, and it always takes longer than anyone budgets. This is the fortnight that disappears.

The second is credibility, and it's worse. A record assembled after the fact, from memory, is inherently less trustworthy than one captured as the work happened — and auditors know it. A contemporaneous record carries weight precisely because it couldn't have been tidied up with hindsight. The act of reconstructing is itself a signal that the process wasn't there at the time, which tends to invite more scrutiny, not less.

The conclusion is simple: evidence has to be a by-product of doing the work, not a project you start when someone asks for it.

What a system of record has to do

For an evidence pack to be assembled rather than written, your system of record has to do a few things as a matter of course, while you work — not on demand:

• Keep requirements linked to cases, so traceability is maintained continuously instead of rebuilt by hand.
• Keep every run as its own record — never overwriting the last result — tied to the build, environment, and date.
• Record approvals as data: the actor, the timestamp, and the state that was approved.
• Retain all of it long enough to cover the period an audit can reach back to.
• Let you filter and export it for a single release, so the pack is a query rather than a scramble.

Do those five continuously and the evidence pack stops being a document you author under pressure and becomes a report you run.

This is the honest place a tool like Tesbo fits, and the boundary matters. Tesbo keeps the case record with its traceability, and its review queue records who approved what and when. It does not run, schedule, or execute your tests — that stays with your framework and CI.

And to be completely clear: Tesbo holds no certification, using it does not make you compliant with any standard, and good records are a foundation for evidence, not a substitute for an assessment.

This is common practice, not compliance advice

One important caveat, stated plainly: everything above describes how teams commonly assemble test evidence. It is not legal or regulatory advice, and it is not a substitute for a quality or regulatory professional who knows your specific framework.

What your auditor actually requires depends on the standard you're held to — SOC 2, ISO 27001, IEC 62304, FDA, or a customer's own security questionnaire — and those differ in real ways.

Treat this as a working mental model for the shape of the evidence, then confirm the specifics with someone qualified to sign off on them for your context. The goal here is to help you keep records that make an audit less painful, not to tell you what your obligations are.

The week before the audit

The teams that sail through an audit are not the ones who tested hardest. They're the ones for whom the evidence already exists as a by-product of how they work — requirement to case to run to defect, with named approvals and dates attached. When the request comes, they filter and export.

The teams that suffer treated their test records as disposable, and now have to invent a credible past in a week they don't have. You can't retrofit a contemporaneous record; the one thing an audit will never grant you is more time to have kept it. So keep it before you need it — the searcher with an audit date on the calendar already knows which team they'd rather be.