Validation Test Plan

This is a ready-to-use validation test plan. It sits above the individual IQ, OQ, and PQ protocols and tells the team how testing for one system will be run end to end: what gets tested, in what order, in which environment, with what data, who does what, how defects and deviations are handled, and what evidence each test must capture. 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. Confirm each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This plan defines how testing will be planned, executed, and documented to demonstrate that <<FILL: SYSTEM NAME>> is installed correctly, performs as specified, and meets its intended use in the live process. It states the test types in scope, the criteria to start and finish each phase, the environments and data to be used, the rules for capturing evidence, and how failures are handled, so that a reviewer can reconstruct what was tested, why, and with what result.

2. Scope

This plan covers installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ) for <<FILL: SYSTEM NAME>> at <<FILL: site / area>>. It governs the depth and rigor of testing in proportion to feature risk, in line with FDA’s Computer Software Assurance approach. It does not redefine requirements (held in <<FILL: URS ID>>), the risk classification of features (held in <<FILL: risk assessment ID>>), or the overall project sequencing (held in <<FILL: validation plan / VMP ID>>). For the method allocation that decides scripted versus exploratory versus supplier evidence per feature, see <<FILL: CSA test plan ID>>.

3. Test types in scope

State which test types apply to this system and what each one proves. Not every system needs every type; record the rationale for any omission.

Depth of testing follows feature risk. High-risk, direct-impact functions get scripted tests with recorded evidence; lower-risk functions can be covered by unscripted testing or assessed supplier evidence. The per-feature decision lives in the CSA test plan; this plan sets the overall structure and the IQ/OQ/PQ flow.

4. Roles and responsibilities

A tester does not approve their own executed test. The reviewer must be someone other than the executor for that script.

5. Test environments

The build under test must be under change control and frozen for the duration of a formal run. If the environment changes mid-run, record it as a deviation and assess what must be retested. Functions verified only in a non-representative environment cannot be claimed as verified for production without a documented equivalence rationale.

6. Test data

Test data must let a test prove both the pass case and the failure case. A calculation test, for example, needs at least one input where the right answer is known in advance, plus a boundary input and an invalid input, so the test shows the system computes correctly and rejects bad data. Where masked production data is used, the masking must not change the behavior being tested.

7. Entry criteria

A test phase does not start until all of its entry criteria are met and recorded. List the criteria per phase.

Starting a phase before its entry criteria are met, for example running OQ on an un-approved protocol, is a common finding and undermines the whole record.

8. Exit criteria

A phase is complete only when all of its exit criteria are met. Open items at exit are explicitly dispositioned, not silently carried.

9. Defect and deviation management

Distinguish a defect (the system does not do what a test expected) from a deviation (a departure from the approved protocol or plan during execution). Both are recorded; the routing differs.

9.1 Defect severity

9.2 Defect workflow

1. Record the defect with the test ID, the expected and actual result, the build/version, and the evidence at the moment it was found.
2. Assign a severity using the table above and confirm it with QA for any critical or major defect.
3. Resolve, then retest with a new dated execution; do not edit the original failing result.
4. Confirm no regression in related functions.
5. Close the defect with the retest evidence referenced.

9.3 Deviations during execution

Any departure from the approved protocol (a changed step, an environment change, an unplanned data substitution, a test run out of sequence) is logged as a deviation per <<FILL: deviation SOP-ID>>, assessed for impact, and approved by QA before the affected result is accepted. Do not annotate around a deviation in the margin and move on.

10. Evidence and screenshot rules

Evidence is what makes a recorded result credible to someone who was not in the room. Apply these rules to every test that captures objective evidence.

1. Capture evidence at the moment the step is executed, not reconstructed afterward.
2. Each screenshot or printout shows enough context to prove the step: the system identity, the relevant data, and where possible the date/time and the logged-in user.
3. Label each piece of evidence with the protocol ID, the test/step number, the date, and the executor’s initials.
4. Cross-reference each evidence item from the test step so a reviewer can match step to proof without guessing.
5. Capture audit-trail and system-clock screenshots where the test claims the audit trail or timestamping works.
6. Record actual results in ink or in the validated tool as they happen; corrections follow good documentation practice (single line, initial, date, reason), never overwrite or obscure the original.
7. Page, number, and attach evidence so nothing can be added or removed without it being obvious.

A recorded “pass” with no supporting evidence, or evidence that does not actually show the claimed condition, is treated by inspectors as no evidence.

11. Traceability

Every requirement in scope traces to at least one test, and every test traces back to a requirement and its risk classification, through the traceability matrix <<FILL: RTM-ID>>. At phase exit, confirm there are no requirements without a test (a coverage gap) and no tests without a requirement (scope creep or an untraceable test). High-risk requirements must be covered by scripted tests with evidence.

12. Acceptance criteria

Testing is acceptable when all of the following are true:

• Every in-scope requirement is traced to an executed test with a recorded result.
• All tests were executed in a controlled, change-frozen environment with controlled data.
• Actual results and supporting evidence were recorded at the time of execution and support each recorded outcome.
• No critical defect is open; major defects are resolved or formally accepted with QA approval and an interim control.
• All deviations are logged, impact-assessed, and closed or accepted.
• Each phase met its entry and exit criteria, and a test summary is reviewed and approved.

13. References

21 CFR Part 11 (electronic records and signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems), sections 4 (validation) and 11 (periodic evaluation). EU GMP Annex 15 (Qualification and Validation), 2015 revision (DQ/IQ/OQ/PQ). FDA Guidance, Computer Software Assurance for Production and Quality Management System Software (issued 3 February 2026, superseding the 24 September 2025 final). FDA General Principles of Software Validation (2002), for software-specific testing concepts. GAMP 5 (Second Edition), A Risk-Based Approach to Compliant GxP Computerized Systems. ICH Q9, Quality Risk Management (for the risk-based depth of testing).

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

14. Test summary (record generated at close)

15. Revision history

16. Approvals

Filled specimen

The following shows the plan completed for an example laboratory information management system (LIMS) configuration, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

In this example the team caught a critical calculation defect because the test data included a boundary input with a pre-calculated known answer, fixed and retested it on a new build, ran regression, and held the phase exit until QA approved. The deviation for running a test before its data was reloaded was logged and the test re-executed rather than quietly accepted. That sequence, controlled environment to known-answer data to caught defect to fix to retest to clean exit, is exactly what a reviewer is expected to demonstrate.

Common inspection findings this plan prevents

• Tests executed against an un-approved protocol, or a phase started before its entry criteria were met.
• A recorded “pass” with no evidence, or screenshots that do not actually show the claimed condition.
• Actual results back-filled after the fact, or original failing results overwritten instead of retested on a new dated execution.
• Critical defects deferred to “a later release” so the system could go live, with no risk justification or interim control.
• The same person executing and approving their own test.
• Testing done in a development environment that does not represent production, then claimed as production verification with no equivalence rationale.
• Requirements with no corresponding test (coverage gaps), or tests that trace to nothing.
• Calculations verified with no known-answer or boundary data, so a rounding or boundary error is never exposed.
• Deviations during execution annotated in the margin and moved past, with no impact assessment or QA approval.

How to adapt this plan

1. Set your document number, owner, and effective date in the header, and link your URS, risk assessment, validation plan, and IQ/OQ/PQ protocol IDs.
2. In section 3, mark which test types apply and record the rationale for any you omit; point the per-feature scripted-versus-exploratory decision to your CSA test plan.
3. Fill the environments and test-data sections with your real environments, your masking approach, and your known-answer datasets so any test can be reproduced.
4. Tune the defect severity definitions and the entry/exit criteria to your own validation procedure, keeping critical defects non-deferrable.
5. Point the cross-references in sections 2, 9.3, and 11 to your real deviation procedure, traceability matrix, and validation plan.
6. Confirm every regulation in section 13 against the current published version before issue, including the CSA guidance finalization date.