Automation changes the economics of regression testing, and not entirely for the better. When re-running everything costs an hour instead of a fortnight, the temptation is to stop deciding what needs re-running and simply run it all.
That feels rigorous. It is usually the opposite.
Why running everything is not the safe option
Three reasons, and the third is the one that bites.
- It hides the reasoning. "We re-ran the full suite" documents an action, not an assessment. An inspector asking why a particular function was re-tested deserves a better answer than "everything was".
- It produces noise. A full suite on a large system will surface unrelated intermittent failures, each of which now needs investigating, which is how teams learn to wave results through.
- It stops anyone thinking about what the change touched. This is the real cost. The impact assessment is the control; the test run is evidence that the control was applied. Skipping the assessment because the tests are cheap discards the control and keeps the evidence.
Scoping on what the change can reach
The assessment is not complicated, and it is much the same whether you are automated or not:
- What changed, precisely — which component, which configuration, which version.
- What depends on it. Directly, and one step further out. Shared components, integrations, reports that read the same data.
- Which GxP functions sit in that blast radius, and at what risk classification.
- Which protocols cover those functions. This mapping is the thing worth investing in — if your protocols are traceable to requirements and requirements to functions, scoping takes minutes.
The output is a named set of protocols, with a sentence of reasoning. That is what goes in the change record, and it is what makes the re-run defensible rather than merely thorough.
Where the cheapness genuinely helps
Having argued against running everything reflexively, there are three cases where low cost changes the right answer.
- A wide, shallow change — a platform patch, a runtime upgrade — where the blast radius genuinely is everything and the assessment says so.
- Periodic review. A full run on a schedule, as a check that the system still does what it did, is a good use of cheap execution and a reasonable thing to show at inspection.
- Before a release you cannot easily roll back. Belt and braces, deliberately chosen and recorded as such.
The distinction is whether the decision was made or defaulted to. Both can end in the same test run; only one of them is a control.
Keeping the mapping current
All of this rests on knowing which protocol covers which function, and that mapping decays quietly. A requirement is reworded, a protocol is revised, a function moves — and six months later the traceability matrix is a document rather than a tool.
Treat it as a live artefact: updated as part of the change, not reconstructed before an audit. See CSA services and GAMP 5 Second Edition consulting for how this fits a risk-based approach, and TraceDraft for keeping traceability attached to the source rather than maintained alongside it.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.