Validation & Evidence

How Should Validation Test Deviations Be Recorded and Resolved?

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 13 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

The moment a test step fails, there is a strong pull toward tidiness: correct the script, rerun the step, file a clean pass, and move on. That instinct produces a validation package that looks flawless and proves less than it appears to. A test deviation, properly recorded, is evidence that the system was actually tested rather than merely executed against a script that happened to be right the first time.

Capture the actual result before deciding anything

The first discipline is sequencing: record what was actually observed before forming a view on why it happened. Write down the literal system behaviour, screen output, error message or absent result exactly as it appeared, with a timestamp, the tester's identity, and the step number in the approved script. This record should exist independent of, and before, any conclusion about cause. Once a tester has decided "this is just a script typo" and reruns the step without preserving the original observation, the evidence that a deviation occurred at all can be lost, and with it the ability for anyone reviewing the package later to independently judge whether the original classification was correct.

Classify the deviation before resolving it

Not every test failure means the system is defective. Three broad categories cover most validation test deviations, and the classification decision should be made deliberately, not assumed:

Script error. The test script itself contains an error: an incorrect expected result, a step performed in the wrong order, a precondition that was not actually met, or a reference to a requirement that changed after the script was written. The system may have behaved correctly; the script was wrong.
Execution error. The tester departed from the approved script: used the wrong test data, skipped a setup step, or misread the instruction. The system was not actually tested as intended, and the failure says nothing reliable about system behaviour.
System defect. The system genuinely did not behave as the approved, testable requirement said it should. This is the only category that should route to a defect/bug-fix process rather than a documentation correction.

Each category has a different resolution path, and conflating them is the most common way a validation package understates real risk. An execution error and a system defect can produce an identical-looking failed step; only investigation distinguishes them, and that investigation is itself part of the record, not a private judgement call made off the page.

What belongs in the deviation record

A usable test-deviation record should capture, at minimum:

unique deviation/incident identifier, linked to the specific protocol, script and step number;
date, time and identity of the person who observed and who investigated;
the actual result as observed, verbatim or by attached evidence (screenshot, log extract, output file);
the expected result from the approved script, for direct comparison;
classification (script error, execution error, system defect) and the reasoning that supports it;
root cause, where determinable, and any corrective action taken;
impact assessment: does this deviation affect only this step, or does it call into question other already-passed steps that shared the same assumption, data set or script author;
disposition and reference to the retest record, where retesting occurs;
reviewer sign-off, separate from the person who investigated and corrected the deviation.

The impact-assessment field is frequently skipped and is often where the real risk sits. A script error discovered in step 14 that stemmed from a misunderstood requirement may mean earlier steps built on the same misunderstanding passed only because the script, not the system, was consistent with itself.

When retesting is justified, and what must remain visible

Retesting is appropriate once the root cause is understood and, where needed, corrected: the script has been amended and re-approved, the tester has been given corrected instructions or data, or the system defect has been fixed and the fix itself brought under change control. What retesting should never do is quietly replace the record of the original failure. The finished package should show:

the original deviation, with its actual result, classification and investigation;
the correction applied (to script, execution conditions, or system);
the retest result, referencing back to the original deviation record rather than existing as an unconnected clean pass.

FDA's guidance on software validation frames validation evidence as needing to withstand scrutiny of the process by which it was produced, not only the final pass/fail outcome; a test record that shows no deviations across a large, complex script is often less credible on inspection than one that shows deviations properly investigated, corrected and closed. PIC/S guidance on computerised systems similarly expects deviation and error-handling procedures to be clearly documented and linked to change control, so that what looks like a testing anomaly and what is actually a system change are not silently merged into one undifferentiated record.

A boundary case worth naming explicitly

A step that fails, is investigated as a script error, corrected, and passes on retest is generally uncontroversial. The harder case is a step that fails, is retested without any documented correction, and passes: an intermittent result with no identified cause. Recording this as "resolved: passed on retest" without further comment understates the risk. An intermittent failure with no established root cause should be treated as an open risk to the validated state until a cause is found or a monitoring/compensating control is put in place, not closed simply because the second attempt happened to succeed.

Sources

U.S. Food and Drug Administration, General Principles of Software Validation; Final Guidance for Industry and FDA Staff.
Pharmaceutical Inspection Co-operation Scheme, PI 011-3: Good Practices for Computerised Systems in Regulated "GXP" Environments.

Navata practitioner view

I look for validation packages with zero recorded deviations across genuinely complex scripts with the same suspicion I would apply to a periodic review with zero findings. Complex systems produce test friction; a clean-looking package usually means the friction was resolved off the record rather than that it never occurred. When I do find deviations, the thing I check first is whether the classification (script, execution or system) is justified by evidence in the record itself, rather than asserted. A defect quietly reclassified as a script error, with no supporting detail on what was actually wrong with the script, is the pattern I send back, because that reclassification is doing exactly the work a real defect fix should have done, without the change control or retest rigour that a defect requires.