Blog

INTRO

Yes, yes, we all test our software seriously, and yes it is flawless, user friendly, responsive, keen to eye and also Government compliant… Okay, none of us ever truly felt that way. At least not entirely, right?

However, we would like our software to be something that excels and at the same time to be ready for audit by anyone and everyone. Also, we would like to adopt Agile Software Development Methodology, partially because everybody does it and also because it is really effective. There is also internal organization, which we know varies greatly in different companies and also rules we must abide by in order for our software to see the light of the day.

PROBLEM

In order to make both our clients and Government happy, we need to balance these worlds. We need to have software do what our clients want but also do how the Government dictates. This symbiosis in its nature is very prone to errors. Why? For example, FDA General Principles of Software Validation was drafted June 9 1997 and the Document was issued on January 11, 2002. Do you really think the IT industry and needs haven’t changed for our clients in the last 20 years? Of course they have, and they do almost daily. Nevertheless, we still need to be compliant with regulations and in order to do so we need the balance we mentioned above. 

Also, a tone of work needs to be done every step of the way, in order to be compliant

• Planning, Defining, and Designing software with auditing in mind
• Building the product against provided specification
• Testing the product through all phases of the process (planning, designing, developing, etc)
• Deploying the software for our clients to use

Next thing that happens is we have our software and we sell it to our client who gets audited by its own client and asks us for the validation proof that our software works as expected. Oh, boy… Now what?

Now, we do it all manually

• We take our Git history
• Try to match Jira tickets to Git PRs
• Struggle to find Test Cases QA put somewhere to die
• Try to aggregate a list of known issues across so many Epics/Stories
• Try to pull a report out of it all and one of the ‘big guys’ need to sign it
• Lastly, pray we thought of everything along the way

THE SOLUTION

Naturally, we were thinking ahead. We knew how demanding the Government regulations can be and how to best comply and adhere to laws and regulations so our business and the business of our clients will not suffer – we automated the most crucial parts of this process! Why did we automate that and spend so many engineering hours into something that cannot make money? In order not to lose it, of course! The points that mostly made us consider automating these processes are

• Humans err, much!
• We need it on demand (and fast, always fast -> which makes it even more error prone)
• Because it needs to be complete (always, unless we want our auditing to fail)
• Because it needs to be consistent

In the end, our (semi) automated validation process was simple and easy to track. It looked something like this, chronologically:

• Planning, defining, and designing feature is complete
• While being developed by development team QA team will prepare test cases that will help developers do proper verification
• QA team will take that piece of software further validating it alongside the rest of the system (Story testing followed by regression runs and UAT)
• After the final QA approval we know our software is ready to be shipped

Now automated part of the process kicks in

• Pulling all User Stories that are the part of the release
• Pulling Test Cases and Test Runs referenced to them (together with videos, screenshots, logs…)
• Compiling a Note to file of list of known issues tied to the product
• Validation Plan and Validation Summary generation is done based on the data gathered
• Persons responsible for the Release sign the documents (electronically)

And that is how our clients get validation proof within minutes after they request it!