GxP Test Documentation, in Plain Terms

When "we tested it" isn't enough

One caveat before anything else: what follows describes how teams commonly think about GxP test documentation. It is not legal or regulatory advice, and it doesn't replace a qualified quality or regulatory professional who knows your product and standards. Use it as a working picture, then confirm the specifics with someone qualified.

In a GxP context — Good Manufacturing, Laboratory, or Clinical Practice, the quality standards that govern regulated life-sciences work — "we tested it" stops being an acceptable answer. The expectation becomes: show the documented evidence, controlled and traceable, that the testing happened and covered what was required.

The testing itself is usually the part teams do well. What trips them up is the shape of the documentation — controlled, versioned, traceable, reviewed — because a test tool used as a day-to-day working surface rarely produces records in that shape. This is about what GxP test documentation is actually asking for, in plain terms.

What GxP means for test documentation

Strip away the acronyms and GxP asks four things of your test documentation. Each is simple to state and easy to fall short on.

Documented. The evidence exists as a record, not as knowledge in someone's head or a green dashboard that shows only the latest state.

Controlled. The records are managed — versioned, access-controlled, with changes tracked — so you can trust that what you're looking at is the real, current version and can see how it got there.

Traceable. Each piece connects to the others: a requirement links to the case that verifies it, which links to the run that executed it and the result. Coverage is demonstrable, not asserted.

Reviewed. A named person examined and approved the record, and that approval is itself part of the evidence.

Miss any one and the documentation stops carrying weight. A controlled, reviewed record that traces nowhere proves little; a fully traceable record nobody approved proves little else.

The documents, and how they connect

GxP test documentation isn't one artefact; it's a set of connected records, and the connections are the point.

At a plain level you have the requirements or specifications, the test cases that verify them, the executed runs with their results, and the record of defects and their resolution — plus the approvals that sign off each stage. The value isn't any single document. It's that you can start at a requirement and follow the thread all the way to the evidence it was tested, or start at a failed result and trace back to what it affected.

That web of links is what an auditor actually examines. A pile of test cases with no traceable connection to requirements, and no linked runs, is a stack of paper that proves activity, not coverage. The documentation earns its keep in the links.

Change control and versioning

Here's the part teams underestimate: a test case is a controlled record, which means how it changes is as regulated as what it says.

When a case is edited — a step updated, an expected result tightened — a controlled system keeps the history: the previous version, who changed it, when, and ideally why. It doesn't silently overwrite the old version into oblivion. That matters because an auditor may ask what a case looked like when a particular run executed it, and "it says this now" isn't an answer if the case has changed since.

This is exactly where a working tool and a controlled record part ways. A tool optimised for day-to-day editing tends to show you the current state and quietly discard the rest. A record built for GxP keeps the versions, the approvals, and the change history, because that history is part of the evidence — not clutter to be cleaned up.

Common practice, not advice

Worth stating plainly again: this is a general description of how regulated teams approach test documentation, not a determination of your obligations. What your specific GxP context requires depends on your products, your intended use, your quality system, and your organisation's interpretation of the applicable standards.

Treat this as the shape of the thing, and confirm every specific with a qualified quality or regulatory professional. Nobody should take a blog post as the definition of what an auditor will accept.

Where a record helps

The honest role for a tool is to keep the records in a controlled shape as you work, so the documentation is a by-product rather than a scramble. A system that maintains requirement-to-case traceability, keeps runs as their own records, versions cases with their change history, and logs who approved what and when is producing GxP-shaped documentation as a matter of course — the same record a release rests on, kept under control.

The boundary has to be exact. Tesbo keeps the case record, its versions, and an approval log; it does not run, schedule, or execute your tests. And plainly: Tesbo is not certified, validated, or compliant with any GxP standard, and using it does not make you compliant. Controlled records are a foundation for evidence — not a substitute for validation or for an assessment by a qualified professional.