Learn how to execute validation protocols Log In Register

Validation Protocol Execution Tips – Top 10

 

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!

Author


Graham O’Keeffe
CEO
www.askaboutvalidation.com
www.learnaboutgmp.com
graham.okeeffe@learnaboutgmp.com

Related Reading

What do you think about this story? Have your say by leaving your comments below.

7 thoughts on “Validation Protocol Execution Tips – Top 10

  1. Good article, although I would say that you dont always have the luxury of starting the protocol when it is convenient for you. I have found that when performing OQ and PQ on plant, you will need trained operatives available (as you wont be allowed to work on the equipment unspervised) and you have to work around them and not the other way round! I have had to execute protocols at the end of the working day, and I know people who have had to work during the night, as it was the only time operators were available!

    Would also say that for point 5, you would have the protocol reviewed and approved anyway under GMP. You must NEVER use any unapproved qualification documents!

    A tip:
    When working on a GMP plant ensure that you have been sufficiently trained to be allowed on plant without supervision (ie gowning procedures) as that can be a real pain if operators are busy and cant spare the time to escort and supervise you. Are you fully trained in the company’s procedures for writing and executing protocols, and deviations? If not – forget doing any validation work!

  2. It is a very nice article, as it reminds me actually the things we got during execution. We should do the dry run as real run and must be reviewed by any one else.

  3. One often forgetten point, but in my opinion important point is ORGANIZATION…that is create a binder or package to pre define what you are to collect in the field…i.e. cal certs, screen shots, software back ups, test results sections….often during execution, there is not enough time to ensure that the correct screen shots, or data sheets are collected or data sheets are are fully completed, or BI request / Lab request paperwork is not completed,
    Organize the binder…it will amke for a much easier report closure session
    john saenz

  4. It is a very nice article, informative and concise. Would you mind to publish/share information about how to prepare equipment qualification and process validation protocols and what are the guidelines which we need to refer to before preparing such a protocol and report.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 New Posts

    ...
Privacy | Terms © 2006 - 2014 askaboutvalidation. All Rights Reserved
Single Sign On provided by vBSSO