Protocol: Verification Testing of a GxP Script, Notebook, or Dashboard

This is a ready-to-use verification test protocol for one analytics tool. Approve it before execution, record actual results and evidence at the time of execution, and handle any failure as a documented deviation rather than a quiet correction. Replace every <<FILL: ...>> placeholder with your own specifics. A worked filled specimen with real arithmetic follows. This content is educational reference, not legal or regulatory advice; verify each cited regulation against the current source before you rely on it.

Approval page

Testing does not begin until this page is signed.

Pre-execution approvals

Post-execution approvals

1. Objective

To verify that <<FILL: tool name>>, at the version identified on the approval page, performs as stated in <<FILL: specification reference>> when executed in the controlled environment, and to record documented evidence sufficient to support release for its intended GxP use.

Specifically, this protocol demonstrates that:

1. The calculation agrees with an independently derived reference on representative inputs.
2. The tool behaves correctly at boundaries, including the rounding boundary.
3. The tool fails visibly and produces no result on corrupt, missing, or invalid input.
4. The tool is reproducible: the same input produces the same output, and the tagged version reproduces an archived result.
5. Where the tool is a dashboard, each measure agrees with an independent calculation on the same source data, and filters, joins, and row-level security neither drop nor duplicate rows.

2. Scope

In scope: <<FILL: the specific tool, version, and environment>>

Out of scope, with the control that covers each:

3. Description of the tool and its environment

Any difference between the test and production environments is stated here and assessed. Testing in an environment that differs from production in a way that could affect results invalidates the reproducibility conclusion.

4. Prerequisites

All of the following are confirmed before the first test case is executed. Record the evidence reference for each.

Expected results must be written down before execution. An expected result derived from the tool’s own output is not a test; it is a description.

5. Roles

6. Acceptance criteria

Testing is acceptable, and the tool may proceed to release, when all of the following are true.

A test case marked pass with no recorded actual result and no evidence does not satisfy AC1.

7. Test data

Test data containing production GxP data is handled under <<FILL: SOP-ID for data handling>>. Constructed data is documented so that a reviewer can see what was constructed and why.

8. Test cases

Scale the case count to the risk class. Class A executes all applicable groups with pre-approved expected results. Class B executes groups 8.1, 8.2, 8.3, and 8.4 in reduced form. Class C may execute group 8.1 only, recorded as a verification note.

Record actual results verbatim. “As expected” is not an actual result.

8.1 Known-answer verification

8.2 Boundary and edge cases

8.3 Error handling and negative tests

8.4 Reproducibility

8.5 Notebook-specific tests (execute where the tool is a notebook)

8.6 Dashboard-specific tests (execute where the tool is a dashboard or visual data-preparation flow)

Every specified measure gets its own row. Do not sample measures.

9. Deviation handling

1. A test case whose actual result does not match the expected result is recorded as Fail. The tester does not adjust the input, the expected result, or the tool to obtain a pass.
2. Every failure raises a test deviation under <<FILL: SOP-ID for validation deviations>>, recording: test ID, expected, actual, evidence, and the immediate assessment of whether other executed cases are affected.
3. The validation lead classifies the deviation:

4. A deviation is closed only when the corrective action is complete, the affected cases have been re-executed and passed, and the closure is approved by the validation lead and Quality Assurance.
5. Where a code change is made, note that AC9 requires the new commit to have been code-reviewed before re-execution.

10. Traceability

Untested requirements: <<FILL: none, or ID and justification>>

11. Summary and conclusion

Conclusion statement:

<<FILL: state whether the tool, at the identified version and in the identified environment, is verified against its specification and suitable for release for its intended use, and name any limitation that must appear on the release statement>>

12. Attachments

Filled specimen

Executed test-case block for tool ANL-0007, the class A stability regression script, at tag v1.0-validated, commit a3f19c4, executed 05 May 2026 on analytics server ANSRV-01 in container image sha256:9c1d4b....

Reference dataset, lot <<FILL: lot ID>>, long-term condition, seven timepoints:

Expected values were derived on 30 April 2026 by hand calculation by the process statistician and confirmed in a second statistical package, and were signed and dated before the tool was run. The hand calculation gave: sum of t = 72, t_bar = 10.285714 months, sum of y = 683.5, y_bar = 97.642857%, Sxx = 429.428571, Sxy = -104.785714, slope = -0.2440% per month, intercept = 100.1527%, residual standard deviation = 0.040432%, one-sided t at 95% with 5 degrees of freedom = 2.0150.

Known-answer verification

Boundary and rounding-boundary cases

Error handling

Reproducibility

One deviation raised during this execution

That deviation is the reason the rounding boundary is tested at all. The default rounding behaviour of several common numerical libraries is round-half-to-even, which disagrees with the half-up convention many validated laboratory systems use, and the disagreement only ever appears at the boundary. Without TC-09a the script would have gone into production quietly reporting a different value from the LIMS on one input in twenty.

Dashboard specimen extract, for contrast

Executed for tool ANL-0021, the class B release results dashboard, on a frozen dataset covering <<FILL: period>>.

TC-D16 is the case worth keeping in every dashboard protocol. Three repeat test records in a set of 52 lots is exactly the sort of small, ordinary data condition that turns a correct measure into an inflated one, and it is invisible unless somebody counts.

Common inspection findings this protocol prevents

• Testing was performed but the expected results were taken from the tool’s own output, so the test could not have failed.
• The protocol was executed against a version that cannot be identified, so the evidence does not apply to the version in production.
• Results were recorded as “OK” or “as expected” with no value and no evidence.
• A test failed, the code was quietly changed, and the case was re-executed with no deviation record and no re-review of the change.
• The rounding boundary was never tested, and the tool disagrees with the validated laboratory system on one value in twenty.
• The tool returns a plausible number on corrupt input because no negative testing was performed.
• Reproducibility was assumed rather than demonstrated, and the archived result cannot be regenerated.
• Only some of a dashboard’s measures were tested, and the untested ones are the ones that are wrong.
• A dashboard measure is correct on the full dataset but doubles when a filter is applied, because no row-count reconciliation was performed.
• Row-level security was configured but never tested, so one site sees another site’s data, or a set of records is visible to nobody and silently absent from every total.
• Testing was performed in an environment that differs from production, and the difference was never assessed.

How to adapt this protocol

1. Scale by risk class before you scale by effort. Removing the negative tests to save time removes the tests most likely to find something, because a defect that produces a plausible wrong number is exactly what normal use will not reveal.
2. Derive and sign the expected results before execution, on a separate dated page, and attach it as attachment C. This one practice is the difference between verification and demonstration.
3. Where automated unit tests already encode the known-answer cases, reference the test run record as evidence for those cases rather than repeating them manually, provided the test code is under version control and was itself reviewed.
4. Give every dashboard measure its own test row. Sampling measures is the most common shortcut and the one that most reliably leaves a wrong number in production.
5. Add the row-count reconciliation at every transformation step for any tool that joins tables. It costs one row per step in the protocol and it catches the failure mode that produces confidently wrong charts.
6. Keep group 8.4 even for class C tools if the output has any retention obligation. Reproducibility is the requirement that becomes impossible to retrofit once the environment has moved on.
7. Set the extrapolation, minimum-count, and range limits in the specification first, then write the boundary tests against them. Boundary tests written without a specified boundary test nothing.
8. Confirm the current status of every cited regulation and guidance in the governing SOP before issue.