Audit Trail in Test Management: The Approval Log

A test case without history is just an assertion

A test case with a status of "reviewed" is a claim. It says someone looked, but it can't tell you who, when, or what they were looking at. Take the exact same case and attach a name, a timestamp, and the record of what changed just before it was accepted, and it becomes something else entirely: evidence.

The distance between those two is the whole reason a review queue exists instead of a checkbox marked "reviewed." A checkbox records a feeling. A queue records an event — a specific person accepting a specific version at a specific moment.

This is about that record: the approval log. What it has to capture, why the field most tools give you isn't one, and why the log belongs right next to the test case rather than in a separate system nobody keeps up to date.

What an audit trail has to record

For an approval log to be worth keeping, it has to capture four things. Miss any one and it can't answer the question you'll eventually be asked.

• Actor — who did it. A real, named person, not "the team" or a shared login.
• Time — when, to a timestamp, not "around the release."
• Before-state — what the case looked like beforehand.
• After-state — what it looked like after, so the change itself is on the record.

The first two answer "who, and when." The last two answer the harder question: "what, exactly, was accepted?" An entry that says "approved by Priya" but doesn't capture what Priya approved is half a record — and it's the half that leaves you exposed, because a case can change after the fact and the log won't know.

"Last modified by" is not an audit trail

Nearly every tool gives you two fields that look like history: "last modified by" and "last modified at." They feel like an audit trail. They aren't.

Those fields hold only the most recent change, and every edit overwrites them. They can't show the sequence of who did what, they can't tell you who approved an earlier version, and they can't reconstruct what a case looked like when it was signed off. The instant someone touches the case again, the record of the approval is gone.

That's why "who approved this test case?" is a question most tools genuinely cannot answer. If anyone edited the case after sign-off, "last modified by" now points at them, not the approver — and the approval has vanished. An audit trail is the history that survives the next edit. "Last modified by" is the history erased by it.

Generated cases raise the stakes

When cases were written by hand, one at a time, an informal approval was survivable. A nod in a review meeting, a comment on a ticket — sloppy, but the volume was low enough to get away with.

AI generation changes the arithmetic. Now dozens or hundreds of cases can enter the suite at once. If they join with no recorded approval, you've created a large body of tests that nobody can account for — no name, no date, no record of who decided each one was correct enough to trust.

The more you generate, the more indefensible an unrecorded approval becomes. Volume is precisely why the approval has to be captured as data, automatically, at the moment it happens — not written down later by someone who has to remember which of two hundred cases they actually checked. Scale turns a nice-to-have into a necessity.

What the review queue records

Here's the honest, un-embellished version of what a review queue does. Generated and drafted cases land in a holding area before they can enter the trusted suite. When a person approves one, the queue records who approved it, when, and the state of the case at that point. Only then does it join the suite.

The result is that every case in the record carries a name and a date, and nothing gets in without that step. That's the approval log, and it's worth describing plainly rather than overselling.

It's a record of who accepted what and when — not a magic guarantee. It isn't a certification, it isn't proof against a determined bad actor, and it doesn't by itself satisfy any particular standard. It's an honest, contemporaneous log, which is exactly what makes it useful. Tesbo keeps this record beside the case; it doesn't run or schedule your tests — that stays with your own tools.

Retention: how long, and who decides

An approval log is only useful if it survives long enough to be asked about. So how long should you keep it? Long enough to cover the period any release it touches could still be questioned — and that's a decision, not a default.

The honest answer is that it depends on what you're subject to. An audit can reach back years. A customer contract may specify a retention period. A regulated context may set its own. The point is that someone on your side — with your compliance or legal people, not a tool's default setting — should decide the policy deliberately and own it.

Don't let "however long the tool happens to keep things" become your retention policy by accident. Decide what you need to retain, for how long, and who's responsible for it — then make sure your system of record actually holds the log that long.

The case and its history belong together

Keep the approval log next to the case, not in a separate audit system that quietly drifts out of sync. A case should carry its own history — who wrote it, who approved it, when, and what changed — so its evidence is never a reconstruction project you start under pressure.

It's part of the same record a defensible release rests on: the case, its coverage, and its approval history, kept in one place. An assertion becomes evidence the moment it carries its own history — and that is the entire point of the queue.