Test Script (Generic)

This is a ready-to-use test script. 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 a test script is, and is not

A test script is the executable record that proves one requirement, or a tight group of related requirements, behaves as specified. It is not a protocol and not a summary report. The protocol or validation plan says what you will test and why; the script says exactly how, captures what actually happened step by step, and ties back to the requirement it verifies. Under a modern Computer Software Assurance approach, the rigor of the script should scale with the risk of the feature it tests: a high-risk function that affects product quality or patient safety earns scripted, step-by-step verification like the template below, while a low-risk feature may justify unscripted or limited testing with a lighter record. Decide that risk before you write the script, not after.

Document control header

1. Requirement traced

State exactly which requirement this script verifies, so the traceability matrix can link the requirement to its evidence in both directions. One script may cover more than one requirement, but every requirement listed here must be exercised by at least one numbered step below.

2. Objective

In one or two sentences, state what passing this script demonstrates. Example: this script verifies that the system captures a complete, attributable, time-stamped audit trail entry whenever a reportable result is modified, and that the entry cannot be edited or deleted by an ordinary user.

<<FILL: objective>>

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 accounts used

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 value, the message text, the screen state, the timestamp.
• 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 printout, data export) 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 9. Do not retest a failed step in place without a documented disposition.

6. 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.

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

7. 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.
• No step is left blank or ambiguous.
• 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 11.

A script with one or more open Fail steps, or unresolved deviations, does not pass and cannot support the conclusion in the parent report.

8. Evidence index

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

9. 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.

10. Execution summary

11. 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, and deviations are resolved. The reviewer should not be the same person who executed the script.

12. References

21 CFR Part 11 (electronic records and signatures), where the system is Part 11 in scope. 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems), validation and testing principles. EU GMP Annex 15 (Qualification and Validation), 2015 revision. 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). GAMP 5, Second Edition (a risk-based approach to compliant GxP computerized systems). ICH Q9 (Quality Risk Management), for the risk basis of test depth. 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.

13. Revision history

Filled specimen

The following shows the script executed for an example chromatography data system, verifying that a result change is captured in the audit trail and cannot be altered by an ordinary user. The company, system, accounts, and numbers are illustrative; replace them with your own.

Header (extract)

Requirement traced

Test steps (executed)

Execution summary

Sign-off

In this example the tester recorded the exact values and message text seen, not “meets expected”, captured a screenshot for every output-dependent step, and a reviewer who did not run the test confirmed the evidence supported each pass. Had step 6.5 instead allowed the analyst to delete the entry, the tester would have marked it Fail, opened a test incident, and held the result, which is the behavior section 9 is built to capture.

Common inspection findings this template prevents

• Test steps marked “Pass” with the actual result column filled in only as “meets expected result”, giving no evidence of what was actually observed.
• Expected results written or amended after execution, so the test cannot fail.
• A requirement in the traceability matrix with no executed step that actually exercises it, or a step that tests something the requirement never asked for.
• Screenshots or printouts referenced but not retained, or evidence that cannot be tied back to the step it supports.
• A failed step quietly retested and overwritten, with no test incident, no disposition, and no link between the failure and the eventual pass.
• The same person executing and reviewing the script, with no independent check that the evidence supports the conclusion.
• Testing run in production, or against a different software version than the one being released, with no record of the actual build tested.
• One uniform level of scripted detail applied to every function 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 template

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. Decide the risk of the function first, then choose scripted, limited, or unscripted testing and record that basis. Reserve full step-by-step scripts for higher-risk functions.
3. List the real requirement IDs in section 1 and confirm each one is exercised by at least one numbered step; keep the script and your traceability matrix in agreement in both directions.
4. Write every expected result before execution, specific enough that two people would agree on the outcome.
5. Point the cross-references in sections 3, 9, and 11 to your real protocol, deviation or test-incident procedure, and review and approval process.
6. Confirm every regulation in section 12 against the current published version before issue.