So you’ve finally reached the stage where you are now free to execute your validation protocol after months of development, review and approval. It would be a real shame at this stage if the execution went horribly wrong and the protocol was strewn with errors and deviations….after all this hard work this is what you will be judged on so it’s critical that you take the execution aspect very seriously.

Below are my top 10 tips to help you achieve execution success!

Tip 1: Develop the Protocol from Approved Design Specifications

Ensure that the protocol has been written from an approved design document. There’s no point in developing tests from an unapproved FS (Functional Specification) or DS (Design Specification) if the design is going to change. Your protocol needs to reflect what is in your approved design document.

This is especially significant when developing software validation test scripts, for equipment qualification the tests may come from approved OQ and PQ protocols that are not linked to requirements….the we’ve always done it this way approach!

Tip 2: Test Objectives Clearly Defined

The tests should be written in a manner where the objectives are clearly defined and each test is unambiguous. Having well defined requirements will assist with this but if you don’t you should make every effort possible to craft each test step in a manner that is easy to understand.

Remember if may not always be you who are executing the script you developed so keep that in mind throughout the development process.

Tip 3: Sufficient Space in the Protocol

If you are not executing your protocol electronically then you are using the traditional paper approach of handwriting on the paper print-out. If this is the case make sure that you leave sufficient space in the expected result columns to add sufficient test results.

There is nothing more frustrating for the reviews to have to use a magnifying glass to see what you have written.

Tip 4: Tester needs to have Testing Knowledge

Has the person who is developing the test script prior experience with this type of work? Testing is a skill and is one that is often overlooked. Great testers don’t just test the obvious functions they think outside the box and ensure other angles aside from the intended use are covered.

Tip 5: Time to Dry Run

It may not always to be possible to dry run your test script before the official execution but good project managers will factor in dry run executions as part of the project timelines. It’s amazing what you will find wrong with your script if you take the time to dry run it before official execution.

This may seem like extra work at the time but it will save you a huge amount of work overall. Treat the dry run as a real run, document all of your test results like you would the real run (You’ll be surprised what you find!)

Tip 6: Make Sure the QA Review is not just a Formatting Review

Does the QA person pre-approving your protocol really understand what they are reviewing? I have seen it time and time again where the QA review turns into a formatting review where you get the document back with only formatting changes. If that is the case either your protocol is perfect (which is never the case) or the QA person is not technical enough to really understand what is been tested.

For example if you are testing for Part 11 compliance does the QA person know what that means?

Tip 7: Execute in the Morning

This may seem like an obvious tip but try and schedule your execution times in the morning when you are fresh and not rushing to get home. Give yourself sufficient time to execute, this isn’t a speed test you need to take a quality driven approach to your executions.

Tip 8: Remember to Read the Pre-Requisite Section Carefully

Ensure that all of the pre-requisites have been performed before execution. Many protocols have a pre-requisite section where set-up data needs to be configured before the actual testing can commence.

There is little point in rushing through the protocol only to find out mid-way through the test that you forget to input the set-up data that allows you to execute the test.

Tip 9: Easily Accessible Deviations Forms

Deviations are part and parcel of any validation execution, its human nature to make mistakes and making mistakes with validation protocols is no different. Whether they come from the actual or expected results or from not executing a test correctly it is good practice to have a bundle of deviation forms at hand to populate at the time the deviation occurred.

This will ensure that you remember exactly what the issues were instead of trying to recall later.

Tip 10: Attach Test Evidence Correctly

Usually test evidence needs to be generated to support validation executions, from print-outs of equipment pressure and temperatures to screen-shots of software applications. Ensure that each additional print-out or attachment is numbered correctly and also references the protocol number.

You need to be able to pass the drop test!