Let me just start by saying that I think software validation is complete crap and an utterly unnecessary activity invented by regulators and bureaucrats. Also, the probability that you need is is zero. If you disagree with me, check out other websites. But if you’re like “hm, this dude might be onto something”, read on!
What Is Software Validation?
While I’m mostly a consultant for medical device compliance, the weird activity of software validation has found its way into other fields, too – a friend of mine works in the pharmaceutical industry, and those people have also weirdly come up with the concept that they need this “software validation” thing without questioning whether it provides any benefit.
Anyway, what are we talking about?
In short, software validation shows that the software you, well, validated, fulfils its intended purpose.
That’s it.
If you needed an explanation, this was it, and now you can hopefully move on with your life and direct your energy towards productive tasks in the economy. If you actually have to perform software validation for your company, my condolences, read on.
But first, let me bore you with some opinionated history on why the hell this whole activity exists and hopefully make you chuckle a bit while doing so.
Why Are We Doing It?
The funny thing is that, just like capitalism or brushing you teeth, it’s hard to pinpoint which weird human came up with this concept. My understanding goes like this: First, there was a group of crappy software developers. Their boss (or client) gave them a rough specification of what to develop. The crappy software developers went to work and, due to the nature of being crappy, produces a crappy piece of software.
The boss (or client) then looked at this crappy piece of software and went like “this is crappy!”. But then the boss took a step back and was like “hm, how can we prevent this in the future?”. The obvious solution, of course, would be to not hire crappy software developers. The boss, however, was also crappy and therefore incapable of recognising the obvious solution. Instead, he came up with his own idea and was like “oh right, we should add a process to this which ensures that all software must be validated to check whether it fulfils its intended purpose. Let’s call this activity software validation!”
And so software validation was born. It rests upon the promise that a process can compensate for crappy software developers – which, if you ask any developer, is obviously false, but.. I don’t know, the (over-)regulated medical device and pharmaceutical industry doesn’t seem to be very open to people calling out these false truths.
Side note #1: Who would you prefer to hire: An obviously awesome software developer who dropped out of school and currently works at Google, or the SAP Certified random developer with a 20-page CV full of typos? If you’d go by your process, you should hire the SAP Certified developer, however that one is obviously crappy. Everyone goes for the Google kid instead, yet no one seems to acknowledge that “process” is incapable of fixing crappy people when it comes to software.
Side note #2: By the way, this is actually quite similar to the Agile Development movement in software development: Because clients usually behave like children and don’t know what they want, the Agile Framework “solves” this by treating everyone like children. Like “oh, you didn’t write this as a Gherkin user story? Rejected! Back to the drawing board!”. Or “your effort estimation during our Estimation Poker was not a Fibonacci number? Invalid! Additional homework for you today!”.
Now you know the history, which is entirely made up by me, but I’m sure it overlaps (somewhat) with reality.. a bit.
Onwards to actually performing this useless activity.
How To Do Software Validation
Remember the incapable boss of the incapable software developers? His main effort when doing software validation will result in a table like this:
| ID | Requirement | Test | Test Result | Passed? |
| 1 | Users can log in with Google. | 1. Navigate to Login screen 2. Click “Login with Google” 3. User is redirected to dashboard | Dashboard is displayed. | Yes |
| 2 | Users can create a document | 1. Navigate to document list 2. Click on “new document” 3. Enter “Hello World” in document 4. Click “save” | Document is saved. | Yes |
If you’re smarter than the incapable boss, you’ve already understood what most of this is about. This table encapsulates everything you need to know about software validation. Everything else is just noise. Let me talk about that noise for a moment.
Defining Requirements (Useless)
In theory, for software validation, it would be required that you define your requirements for this particular part of software first, even before looking at which software to purchase. By the way, nobody does that. But let’s just entertain this thought for a bit and assume you’d be looking for a document editor (even though you’ve already settled on Google Docs, but, you know, let’s just assume you’re still looking around). You’d then write down some requirements for this document editor (ridiculous) which might look like so:
- Users can log in with Google.
- Users can create a document.
And then, in a regulator’s twisted mind, with those requirements in hand, you would very objectively venture out into the wide world and procure a software which meets those requirements. For each software under your consideration, you would create a table like the one above and, like a completely dumb person, “perform” those tests to actually remind yourself that, yes, this is a document editor where users can log in with Google.
And then, completely objectively, you would only settle on that software which fulfils your requirements.
That’s the point of software validation.
Oh, and if an evil employee ever procures some random software behind your back and it’s a crappy piece of software, you slap them on their wrists and cry out “you should have validated this software beforehand and followed the process!”. Because, obviously, the problem is not that your employee makes crappy decisions and, therefore, you made a crappy decision by hiring (or not training) that employee, no, obviously, the problem is that the employee didn’t follow the process. Again, we’re all believing the falsehood that process can compensated for crappy people, right?
Where was I.. aah. Yes. You define your requirements up front, at least that’s what an auditor believes in their weird auditor-mind.
Next, once you’ve defined your requirements, you have to prove that the software in question actually fulfils those requirements. Again, we’re all behaving like total idiots here because we all know that the damn software has already been purchased, installed and is currently being used by your team.
Testing The Requirements
For each requirements, you come up with some sort of “test”. These are typically manual tests. Please don’t come up with automated tests, you’ll just make everything worse. It’s not worth your time to automate anything, we’re just here to write a damn document and will be done in 10 minutes.
So, for each requirement, you write a step-by-step test of actions a user would have to take to actually achieve whatever the requirement stated.
So, for the “Login with Google” requirement, a “test” might look like this:
- Navigate to Login screen
- Click “Login with Google”
- User is redirected to dashboard
Again, like.. I mean, there’s no rational need to do any of this. The software vendor already has tested this, you already know it works, it’s only that some weird person expects you to write some weird software validation document, and this is what you have to write.
And then, once you’ve “performed” this test, you write down the result:
“Dashboard is displayed.”
Whether you actually perform this completely mindless test or just emulate it in your brain and write down the result, well, I’ll leave that up to you.
Conclusion, Templates & Bonus (Read On!)
And that’s all there is.
Don’t believe me?
We’ve passed multiple medical device audits which included quite a lot of software validation stuff, and our documentation never was questioned. Was our approach always as frustrated and as minimalistic as this article? Probably not, we actually did put in quite some work from time to time.
We’ve published all our templates for medical device compliance for free, this includes our software validation templates: SOP Software Validation, Software Validation Form and Software List. Just fill them out and you’re good to go.
I have a few more “bonus content” pointers for you if you’d like to save some time.
GAMP Categories For Software Validation
Everyone seems to be asking about GAMP categories, and no one seems to realise that they are mostly useless in practice. Even the Wikipedia article is completely useless. First, here are the GAMP categories:
- Category 1: Infrastructure software including operating systems, Database Managers (what is that?), etc.
- Category 3: Non-configurable software including commercial off the shelf software (COTS – who comes up with these abbreviations), Laboratory Instruments / Software, etc.
- Category 4: Configured software including LIMS (?), SCADA (??), DCS (???), CDS (????), etc.
- Category 5: Bespoke software (that’s software you developed yourself)
First off, what happened to category 2? Did the GAMP people forget about that? Hm.
Anyway, in theory, here’s what regulators tell you to do: For each software you validate, you have to assign it to a GAMP category. For some software, that’s obvious, e.g. your operating system (category 1) or for self-developed software (category 5). For most other software, it ends up being a roll of the dice: Is Postgres non-configurable or configured software? No one knows, so just flip a coin and choose category 3 or 4.
Now here’s the kicker while all of this was useless anyway: As a next step, you just move on and perform the software validation just as I described it above. Like, yeah, in theory you should do a more detailed validation for e.g. category 5 software because self-developed software is typically crappier than off-the-shelf software (I actually do agree with that), but in practice, this whole exercise is a completely useless documentation activity anyway, completely decoupled from reality, so the whole GAMP categorisation thing didn’t help us one bit.
“Validation During Use”, Or How To Save A Crapton Of Time
Here’s the biggest thing which I somehow buried at the bottom of this article (sorry, not on purpose). If you find a way to argue that a software is low risk (like, um, not GAMP category 5?), you could state that you “validate it during use”, which boils down to saying “we’re actually not complete idiots and will notice if the software starts breaking”.
For the document editor example, you would obviously notice once it no longer enables you to 1) log in with Google and 2) create documents. So you’d not perform the tests, i.e. skip the entire table and only write a one-line intended use for the software.
Huge time saver.
Do this for all of your software.
Except one.
As an auditor told me: “Software validation is mostly useless. My pro tip is to say that you do “validation during use” for all your software except one. For that one software, you write a great validation document with lots of tests, and that’s what you show around to auditors if they ever want to see an example of a software validation you performed.”
I can’t add anything to that.
Good luck.
