It’s a standard approach that after validation test scripts/protocols have been executed they need to be reviewed and approved by the Validation Team, (minimally, the System Owner, End-User Representative, and QA). What a lot of people don’t realise is that pre-approval of the validation tests needs to be done aswell.

That is BEFORE any testing is done on the system, the tests and challenges to be presented to the system are reviewed by the Validation Team to ensure that:

• The Test are sequentially numbered so that a removed test is immediately obvious to an inspector.
• An accurate table of contents lists all tests.
• Test Objectives are clearly derived from the specifications.
• A Traceability Matrix is included to show in which test each requirement was verified.
• Test ordering is in compliance.
• Field Verification with Invalid/Valid, Borderline, and Special-Case data (if applicable) has been done for all GxP fields.
• Actual Inputs and Actual Outputs are provided for on every test.
• Tests are thorough and comprehensive, challenging all cGxP logic and error messages.
• Tests are complete, with no blank Test Steps or Expected Results.
• Expected Results clearly achieve the Test Objective.
• There is sufficient stress testing of the system.
• Test Steps can be marked each with a Pass or Fail status (this is important in order to be able to tell where a lengthy failed test started going wrong).
• There is sufficient space available on the test forms to record Actual Results if different from Expected Results.

Post-Approval

If any of the above are found not to be in place, then the Pre-Approval phase stops validation from progressing until the test scripts are Post-Execution Reviewed/Approved to ensure that:

• All Tests have been documented in accordance with Good Documentation Practices.
• All Tests have been completed.
• No tests or pages are missing.
• White spaces are lined-out, initialed an dated so that “results” can’t be added in after-the-fact.
• All Attachments are documented completely, reviewed and approved by the Testers, System Owner and QA, and are all closed out with either a Workaround or Change Control Number etc.

Related Reading

• Writing Effective Test Scripts
• Test Scripts
• Why Validation Projects Take So Long – Paperwork!
• Do You Dry Run Your Test Scripts?

Author

Tamara Follett has an M.S. in Computer Science and over 20 years experience in all aspects of cGxP Computer Validation. As an Independent Consultant serving the Pharmaceutical, Clinical Trials and Medical Device Industries, she developed and executed many large-scale computer validations and re-validations, identifying such critical deviations as data loss and data corruption prior to the system going into production.

She has generated and maintained Master Plans, Validation Plans/IQ/OQ/PQ/Final Reports/Deviation Logs/Deliverable Lists, and other project documentation such as procedures, work instructions and guidelines. She has developed comprehensive Life Cycle Documentation for numerous legacy and new systems, including Requirements, Specifications, Traceability Matrices, SOPs, Training/User Guides, and other SDLC deliverables, including: Needs Analysis, Vendor Gap Analysis, Risk Assessments, Disaster Recovery Plans, etc.

Ms. Follett has conducted numerous Compliance Audits, Quality Audits and 21 CFR Part 11 Audits. Considered to be a Subject Matter Expert in Computer Validation by Stat-A-Matrix, CSSC, and other validation industry leaders, she is a sought-after speaker and auditor.