Test Script: Report and Calculation Verification

This is a ready-to-use test script for verifying the calculations a GxP computerized system performs and the reports it generates. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and run it under an approved validation plan or protocol. A worked filled specimen follows the template so you can see how a completed version reads. A test script is contemporaneous GxP evidence: write each actual result as you observe it, in ink or in the validated tool, never reconstructed later. Verify each cited regulation against the current source before you rely on it.

What this script proves, and what it does not

This script demonstrates that the values the system computes are correct, that the reports it produces carry the right content in the right format, and that data flows from source to report without alteration. It does three things. First, it checks each computed value against an independent calculation performed outside the system, so a coding or configuration error in the formula is caught rather than trusted. Second, it confirms the report shows the correct data, in the correct layout, with the correct units, headers, ranges, and pagination. Third, it confirms rounding, significant figures, and unit conversion behave exactly as specified, since a result that is right to ten decimal places but wrong at the reported precision can still fail a specification or pass one it should not.

It is a functional verification, run in a qualified non-production environment with controlled test inputs, not a review of live production results. Verifying the report is correct does not relieve the user of reviewing each real report against its source on use. Decide the risk of each calculation and report first, then keep the scripted depth below for the ones that affect a result, a decision, or product quality. A pass-fail result derived from a computed value is the highest-risk case and is tested hardest here.

Document control header

1. Requirements traced

State exactly which requirements this script verifies, so the traceability matrix links each requirement to its evidence in both directions. Every requirement listed here must be exercised by at least one numbered step in section 7.

2. Objective

In one or two sentences, state what passing this script demonstrates.

<<FILL: objective, e.g. this script verifies that the system computes each in-scope calculation correctly against an independent calculation, applies the specified rounding and units, and generates reports that present the correct data in the correct format with a correct pass-fail evaluation, so that results used for GxP decisions are accurate, attributable, and fit for their stated purpose.>>

3. Prerequisites

List everything that must be true before execution starts. If any prerequisite is not met, do not execute; record the gap as a deviation and stop.

4. Test data and independent calculation

The test relies on inputs whose correct answer is known before execution. Compute every expected value independently first, record it here, then run the system and compare. Do not derive the expected value from the system you are testing.

4.1 Pre-computed expected values

5. Execution conventions

Read these before executing, then follow them for every step. They are the rules an inspector expects to see applied consistently.

• Record each actual result contemporaneously, as you observe it, in the actual result cell. Do not pre-fill, do not batch at the end.
• “Meets expected result” is not an actual result. Write what you actually saw: the exact value displayed, the unit shown, the number of decimal places, the on-screen or printed text.
• Compare the system value to the independent expected value at the same precision the system reports. A match at full precision but a mismatch at reported precision is a fail, and the reverse can hide a rounding defect.
• For a pass-fail or in/out-of-specification flag, record both the value and the flag the system applied, and confirm the flag follows from the value at reported precision.
• Use one unambiguous mark for pass or fail. A blank cell is incomplete, not a pass.
• For any single-line correction, strike through once, initial, date, and add a brief reason. Never obliterate the original entry.
• Capture objective evidence (screenshot, report PDF, calculation export, the independent calculation record) for every step whose pass depends on a system output, and give that evidence a unique reference recorded in the step.
• The moment any step does not meet its expected result, mark it Fail, stop if instructed, and open a deviation per section 10. Do not retest a failed step in place without a documented disposition.

6. Calculation tolerance convention

State once how close the system value must be to the independent value, and apply it everywhere. A calculation is correct or it is not; the tolerance accounts only for legitimate floating-point and display precision, not for a different answer.

7. Test steps

For each step give the action, the precise expected result, the actual result as observed, pass or fail, and the evidence reference. The expected result must be written before execution and must be specific enough that two people would agree on whether it was met. The blocks below cover calculation correctness, rounding and significant figures, units and conversion, report content and format, and the pass-fail evaluation.

7A. Calculation correctness against an independent calculation

7B. Rounding and significant figures

7C. Units and conversion

7D. Report content and format

7E. Pass-fail evaluation on the report

Add or remove rows so every requirement in section 1 is exercised. Number steps continuously; do not reuse a number after a revision.

8. Acceptance criteria

This script passes only when all of the following are true:

• Every step required to verify the requirements in section 1 is marked Pass, with a recorded actual result and, where applicable, an evidence reference.
• Each computed value matched the independent calculation within the tolerance in section 6, at reported precision, across normal, boundary, and out-of-specification cases (block 7A).
• Rounding followed the specified rule, applied only at the reporting stage, with no intermediate or double rounding, and the rounding-edge case resolved correctly (block 7B).
• Every reported value carried the correct unit, and any conversion matched the independent conversion (block 7C).
• The report presented the correct data, in the approved layout, with correct identifiers, pagination, and a faithful export (block 7D).
• The pass-fail evaluation followed from the value at reported precision and matched the independent determination, including at the specification boundary (block 7E).
• Every deviation raised during execution is resolved with a documented disposition, and any retest is recorded under its own step or attachment.
• The completed script is reviewed and approved per section 12.

A script with one or more open Fail steps, or unresolved deviations, does not pass and cannot support the conclusion in the parent report. A wrong computed value or a misrouted pass-fail flag is a high-risk failure, since it can release a failing result or reject a passing one.

9. Evidence index

List every piece of objective evidence captured, so a reviewer can find each one without hunting.

10. Deviations raised during execution

Any step that does not meet its expected result, any departure from the written steps, and any prerequisite not met is recorded here and managed per the parent protocol and <<FILL: deviation / test-incident SOP-ID>>. Cross-reference the deviation number on the failing step.

A failed step is not a finding against the tester. It is data. The discipline an inspector looks for is that the failure was captured honestly, classified, dispositioned, and that any retest is traceable to the original failure, not quietly overwritten. A wrong calculation or a pass-fail flag driven by an unrounded value is almost always critical, because the error propagates to every result the system produces, not just the test record.

11. Execution summary

12. Sign-off

The tester executes and signs; an independent reviewer who did not execute the test confirms the record is complete, the evidence supports each pass, the independent calculations were genuinely independent, and deviations are resolved. The reviewer should not be the same person who executed the script.

13. References

21 CFR 211.68 (automatic, mechanical, and electronic equipment), which requires that calculations be checked, and 211.194 (laboratory records), which requires complete records of all data and calculations. 21 CFR Part 11 (electronic records and electronic signatures), for the accuracy, completeness, and protection of records and report outputs. 21 CFR 211.160(b) (laboratory controls established by scientifically sound test procedures), for the basis of specification limits and pass-fail evaluation. EU GMP Annex 11 (Computerised Systems), section 5 (data: built-in checks for the correct and secure entry and processing of data) and section 6 (accuracy checks for critical data). EU GMP Chapter 6 (Quality Control) and Chapter 4 (Documentation), for records and reporting of results. ICH Q2(R2) (Validation of Analytical Procedures), where a reported value derives from an analytical method whose calculation is verified here. ICH Q9 (Quality Risk Management), for the risk basis of test depth. USP <1058> (Analytical Instrument Qualification), for the qualification context where the calculation runs on an analytical instrument or its data system. GAMP 5, Second Edition (a risk-based approach to compliant GxP computerized systems), including guidance on verifying calculations and reports. FDA Guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 (superseding the 24 September 2025 final) (risk-based scaling of test rigor; a calculation that drives a quality decision warrants scripted testing). For medical device software: 21 CFR Part 820 (QMSR, effective 2 February 2026, incorporating ISO 13485:2016) and IEC 62304.

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

14. Revision history

Filled specimen

The following shows the script executed for an example calculation: percent of label claim for a finished-product assay, with the system computing the result, applying rounding, and flagging against a 95.0 to 105.0 percent specification. The company, system, inputs, and numbers are illustrative; replace them with your own.

Header (extract)

Calculation under test

Percent of label claim = (measured concentration / label claim) x 100, reported to one decimal place, round half up, spec 95.0 to 105.0 percent of label.

Pre-computed expected values (extract)

Test steps (executed, extract)

Execution summary

Sign-off

In this example the tester computed each expected value in a separately verified spreadsheet before touching the system, compared at reported precision, exercised the rounding edge at the half-value, confirmed rounding happened only once at the report stage, and checked that the boundary case at 95.0 percent resolved per the inclusive-limit convention. Had step 7.7 instead returned 99.4 percent (truncation rather than round half up), or step 7.23 shown 94.9 percent passing because the flag read an unrounded 94.95 internal value, the tester would have marked the step Fail, opened a critical test incident, and held the conclusion, which is the behavior section 10 is built to capture.

Common inspection findings this script prevents

• A computed result accepted on faith, with no independent calculation on record to prove the formula is right.
• The expected value derived from the same system being tested, so a coding error is “verified” against itself.
• Rounding that truncates instead of rounding, or rounds at every intermediate step so a chained result is double-rounded and drifts.
• A pass-fail flag driven by an unrounded internal value, so a 94.95 result reported as 95.0 is shown as passing, or the reverse.
• Reported values with no unit, or a unit-conversion factor coded wrong, so a value is right in number but wrong in scale.
• A report whose layout, headers, or specification limits do not match the approved template, or that clips data at page breaks.
• Multi-page reports tested only on a single page, so pagination and repeated headers were never exercised.
• A report that can be edited after issue, or a regenerated report that cannot be told apart from the original.
• Only the normal case tested, with the boundary and out-of-specification cases never run, so the most decision-relevant behavior is unproven.
• One uniform level of scripted detail applied regardless of risk, with no documented basis, which is hard to defend now that test rigor is expected to scale with risk.

How to adapt this script

1. Set your test script ID, parent protocol, system version, and effective date in the header, and confirm you are testing in a qualified non-production environment.
2. List your real requirement IDs in section 1 and confirm each is exercised by at least one numbered step; keep the script and your traceability matrix in agreement in both directions.
3. Replace the example calculation with your own formula, and in section 4.1 pre-compute the normal, boundary, just-inside, just-outside, and rounding-edge values independently before execution.
4. State your one calculation tolerance and rounding rule in section 6, and confirm if your specification limits are inclusive or exclusive at the boundary.
5. Name the independent calculation tool in section 4 and attach its verification record; a spreadsheet used to verify a system must itself be verified, or the verification is circular.
6. Replace the report-format checks in block 7D with your approved template’s fields, headers, and pagination, and add the export formats you actually use.
7. Point the cross-references in sections 3, 10, and 12 to your real specification, deviation or test-incident procedure, and review and approval process.
8. Confirm every regulation in section 13 against the current published version before issue.