Pre-Execution Approval of Validation Test Scripts – What To Look Out For!

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.

[polldaddy poll=”6611595″]

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.

Author

Tamara Follett

Subject Matter Expert in Computer Validation The 100 Worst Mistakes You Can Make