Validation Testing. Test Automation. CSV. CSA. The FDA. Pre-execution approvals. Post-execution approvals. Post Malone. What do they all have in common? I’ll be honest, Post Malone has nothing to do with any of those things other than “Post” is his first name, and “post”-execution approvals are generally considered a standard requirement of validation testing. Combining them for the title was just a dumb thought that popped in my head and since I am a child, I decided to start this blog by typing about it against my better judgment - and probably much to the chagrin of the company I represent.

At this point you may be asking yourself, is this leading anywhere relevant? Should not I as the author have been crafting an intro paragraph that gives you, our fine readers, a concise introduction to the topic and ideas that will be covered in this blog? The answers to your questions are no, my “Post-Malonexecution” jaunt is not leading anywhere relevant, and yes, I should have instead been constructing a concise and professional intro paragraph for you. My apologies on both counts.

Okay, since I’ve already wasted enough of your time, let me just get into the actual topic……

For many organizations, their CSV processes are very rigid and have often been in place for many years. Implementing changes to those processes can be difficult, but that doesn’t mean that change cannot occur. Further, just because something has been in place for years does not mean that it should not be questioned or modified where appropriate.

This is becoming increasingly important as more and more organizations are really starting to take a look at their current CSV processes to figure out where enhancement and streamlining efforts make sense. I actually covered a number of the drivers that are motivating this re-evaluation in a previous blog which can be found here if you are interested, but today, I would like to bring to the table one specific area of the CSV process that I am hearing a lot of debate about.

Post-execution approvals in the functional testing of regulated applications have been widely regarded as a standard practice. The test must be approved before it is executed through a formal pre-execution process and once the test is executed, appropriate team members should be reviewing the test execution and results to make sure that all the approved steps were executed and that the results are what they should be.

For something like manual testing, this makes perfect sense. There is the ever-present risk of human error and steps could be missed, not executed properly, or not captured adequately. However, does this approach of both a formal pre-execution and post-execution approval process still make sense when it comes to automated tests?

Presumably, once an automated test is created (whether that be script-based or scriptless/codeless) and that test is approved by all necessary parties through the pre-execution approval process, the execution of that test becomes a programmatic thing that is not subject to human error or deviation from the defined script/test.

A post-execution review, sure. If the test fails, yes, go back and remediate until it is resolved and passes. But is a formal post-execution review and approval process actually needed here assuming the already approved automated test passes? Does it add anything of value that drives quality, or does it just add unnecessary overhead and documentation to an already rigorous process?

Let’s be clear here, I’m not necessarily advocating one way or the other on this issue, but it is a topic that I have heard discussed many times not only amongst Tx3 employees but also amongst the various clients that we work with. 

Regardless of which side you fall on, I think that it does merit a real discussion and it’s one that seems to be taking place more and more in recent years as there is an increased utilization of technology and automation to replace what were previously manual processes for testing, compliance, and documentation. In addition, with the increasing interest and pursuit of a more CSA-oriented approach for non-product CSV, this type of exercise in streamlining and focusing on quality rather than documentation certainly makes sense.

Again, the purpose of this blog is not really to lay out any argument for or against this school of thought, but rather as a way to hopefully gather some feedback from folks within the industry and gauge what the broader audience of folks thinks about this.

Is this something you agree with? Is this something that you strongly disagree with? Is it something you have already implemented, or is there something holding you back from putting it into practice for fear of a compliance misstep?

We would love your feedback, so if you would fill out this brief survey to let us know your thoughts, we will share the results with everyone that participates (all results will be shown anonymously, of course). Get in the discussion and let’s get a real sense of where this issue stands!

Complete the quick survey here.

Also, since we’re talking about test automation, click the link below to download our white paper on setting up a strategic test automation framework for your GxP systems.

Download the white paper here.