Test Failure Scope and Impact Assessment Form

This is a ready-to-use form. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current published source before you rely on it, and treat this as an educational reference to adapt rather than as legal or regulatory advice.

One form covers one incident. Complete it before defining the corrective action and before authorizing any re-execution, because scope determines what the correction has to reach and what the re-test has to cover. The governing process sits in SOP: Validation Test Incident Management, and the authorization that consumes this output is Validation Retest / Re-execution Authorization.

Why this form exists

A test failure arrives looking local. One step, one screen, one value. The instinct is to fix that one thing and move on, and under schedule pressure that instinct usually wins.

The scope question is what separates a fixed defect from a fixed symptom. A rounding rule is rarely confined to one field. A misconfigured parameter is rarely confined to one object, because the person who set it wrong that day probably set several the same way. A shared function called by one screen is usually called by others.

This form makes the scope question a completed record rather than an informal conversation. It also creates the two conclusions reviewers most often find missing: which already-passed tests are now in question, and what happened to data already generated.

Field table

1. Header

2. The defect and its mechanism

Scope cannot be assessed from the symptom. It is assessed from the mechanism, because the mechanism is what tells you where else the same thing can happen.

The “when it began” field matters more than teams expect. Everything executed between that date and the correction ran against a defective condition, and that boundary is what makes section 4 answerable.

3. Scope expansion

Work every dimension. Record a finding for each even where the answer is “not applicable”, and record the evidence that supports the finding. A blank row is an unasked question, and an unasked question is the pattern reviewers look for.

3.1 Scope expansion conclusion

4. Previously passed tests now in question

A test that passed while a defective condition was present did not necessarily pass on its merits. Some passed because they never exercised the defect. Some passed because the defect happened not to bite on the values used. Both need to be told apart, and only one of them stays PASS.

Take every test case executed between the defective condition start date (section 2) and now, and disposition it.

Decision rule. Where the third column is Yes and the fourth column is No or Not determinable, the test did not challenge the defect and its PASS is not evidence about the defective behaviour. Re-execute it with the defective condition added to the test, rather than simply repeating the original steps, otherwise the second PASS carries the same blind spot as the first.

Not determinable. If the executed record does not capture which values, roles, or paths were used, the test cannot be dispositioned from the record and is re-executed by default. Record this outcome, because it also identifies an evidence-capture gap worth correcting in the protocol template.

5. GxP data already created

Assess every dataset that could carry a value produced by, or a decision influenced by, the defect. Cover the validation environment, any environment where real data was entered, and production if the defect predates release or exists in a released system.

Where production data is affected, the assessment is not complete until each affected record has a stated disposition: verified unaffected, corrected under a controlled correction, annotated with the defect reference, or reprocessed. Note that 21 CFR 211.192 expects an unexplained discrepancy investigation to be extended to other batches that may have been associated with the failure, which is the same logic this section applies to test and system data.

6. Required re-test list

The output of this form. Everything below feeds the re-execution authorization and, where applicable, the regression scope on that form.

7. Conclusion

<<FILL: three to six sentences. State the mechanism, how far it reached, what that did to already-passed tests, what it did to data, and what must now be re-tested. Write it so that someone reading the validation package two years from now, with no memory of the project, can follow the reasoning without asking anyone.>>

8. Approvals

9. References

21 CFR 211.192, which requires thorough investigation of unexplained discrepancies and extension of the investigation to other batches that may have been associated with the failure. That extension requirement is the regulatory shape of the scope question this form asks. 21 CFR 211.100(a), for the design of production and control procedures to assure product quality. 21 CFR Part 11, where the defect touches electronic record or signature behaviour. EU GMP Annex 15, Qualification and Validation (2015), which requires deviations from validation protocols to be documented with appropriate justification under quality risk management. EU GMP Annex 11, Computerised Systems (2011, currently in force), for assessment of deviations arising during validation. The draft revision published 7 July 2025, consultation closed 7 October 2025, is not final. ICH Q9(R1), Quality Risk Management, for the proportionality of the assessment effort. FDA guidance “Computer Software Assurance for Production and Quality Management System Software”, issued 3 February 2026, for the risk-based assurance context. FDA 2018 data integrity guidance, MHRA GxP Data Integrity Guidance and Definitions, and PIC/S PI 041-1, for the treatment of affected records. ISPE GAMP 5 Second Edition (2022), for the lifecycle context. Reference only.

Confirm the current version and clause numbers of each reference before issue.

Filled specimen

The following shows the form completed for a defect found during the OQ of an electronic batch record module supporting a viral vector manufacturing process. The company, system, names, and numbers are illustrative.

Header and mechanism

Scope expansion

Previously passed tests

GxP data already created

Required re-test list

Conclusion

A single shared expression library function converting millilitres to litres was configured with a divisor of 10 instead of 1000, so every conversion on the instance returned a value 100 times too high from 22 June 2026 onward. The mechanism is instance-wide rather than local, reaching 11 calculated fields across 4 recipes and two downstream interfaces, and the same configuration specification gap that allowed it, function names listed without their constant values, applies to all 9 constants in the library. Five previously passed test cases were passed without ever checking a calculated value and are re-executed with the value check added, and one is re-executed because its evidence does not show what was displayed. No production data and no released product is affected, because the library version was never deployed outside the qualification instance and the scheduled production deployment is held. Fourteen re-tests are required in total, six of them re-executions of existing test cases and eight of them new test cases written to close the systemic gap, all under protocol addendum 1.

Notice what the form forced. Dimension 2 made the team check the two other constants changed in the same deployment, which turned out fine, and that “checked, no further defect” record is itself worth having. Dimension 6 turned a single wrong constant into a specification gap covering nine constants, which is what the eight new test cases exist to close. Section 4 found that five tests had passed without ever looking at a calculated value, which is a test design weakness the original protocol review should have caught. Section 5 established, with a deployment record rather than an assumption, that production was untouched.

Common inspection findings this form prevents

• A defect corrected only where it was found, with no record that anyone asked whether the same defect existed elsewhere.
• Scope stated as “this test case only” with no basis given, so the conclusion rests on an assumption rather than a check.
• Test cases left marked PASS although they were executed while a known defective condition was present.
• A test re-executed with the same steps that missed the defect the first time, producing a second PASS with the same blind spot.
• No assessment of whether data already generated in validation, training, or production carries values produced by the defect.
• Downstream systems left holding incorrect values because the interface was never included in the scope question.
• A production deployment proceeding on a build carrying a defect already found in the qualification environment.
• The systemic cause left unaddressed: one wrong parameter corrected while the specification gap that allowed it stays open for the next build.
• An investigation that never checked whether the same or a similar defect had been raised before, so a recurring problem is treated as a first occurrence each time.
• The 21 CFR 211.192 expectation to extend an investigation to other potentially associated batches applied to batch records but not to the systems and data that produce them.

How to adapt this form

1. Set your assessment numbering scheme and link it to your incident and deviation numbering so the three records reconcile.
2. Add expansion dimensions specific to your technology in section 3. Recipe inheritance hierarchies, multi-tenant configuration, report template libraries, master data governance, and analytical method parameter sets each deserve their own row. Removing a dimension is a decision; leaving one blank is an omission.
3. Where you run a system with a strong dependency map or a where-used report, name that report in section 3 so the SME reaches for evidence rather than memory.
4. Decide your default for the “not determinable” outcome in section 4. Re-execute is the safer default, and it also surfaces evidence-capture weaknesses in your protocol templates.
5. Tune section 5 to the data populations you actually hold. If you hold clinical data, add rows for the trial master file, the clinical database, and any transfer to a sponsor or partner. If you hold distribution data, add rows for serialization and traceability records.
6. Set the escalation trigger in section 5 to point at your real product impact, recall assessment, and data integrity investigation procedures.
7. Where the assessment concludes that production data or released product is affected, require the higher-authority signature in section 8 and treat the timeline as an escalation, not a validation task.
8. Confirm every regulation in section 9 against the current published version before issue, in particular the status of the EU GMP Annex 11 revision, which was still in draft at the time of writing.