A regulated environment is basically any controlled environment. Usually controlled by government agencies and institutions such as MedTech, life science, pharma, fintech, and so on. As I’ve been working on multiple projects that were regulated by the U.S. FDA (Food and Drug Administration), that’s what I’ll use as an example.
The content of this post will mostly be applicable to most regulated industries as their goals are usually the same. In general, to comply with any regulated environment means to ensure that any operation with the data can be later reproduced.
When talking about testing and software quality in regulated environments one often hears the terms validation and verification. But what’s the difference between the two?
Verification involves ensuring that each element of the device meets the specifications and standards, while validation is more concerned with the end product.
We first verify the components of a product to ensure that they are developed according to specification and then validate that the end product, when all the components are put together, meets the needs.
A very simple answer would be that it’s required by the FDA. A more detailed one would be that it’s part of the risk control.
In the risk assessment phase, risks are evaluated and ranked based on the following criteria:
Risks are evaluated and rated based on those criteria. Depending on the evaluation we get to the risk control, that will also be our main topic for this post.
Basically, after deciding whether the risk is above an acceptable level, we have to evaluate what can be done to reduce or eliminate the risks. There are a couple of mitigations available, technical documentation of the component, code reviews of the component, and unit tests are possible risk reduction tools.
After the risk assessment, we start with risk control. As already mentioned, testing is a valid risk reduction tool. After components and their respective risks are identified, different scenarios that can lead to the occurrence of a certain defect are specified and incorporated into tests to ensure that the behavior of the system is as expected.
Due to the FDA requirement of being able to reproduce the process at a later date, the system needs to be automated while providing a certain level of documentation.
Documentation is the data of which tests were executed and what the results of the execution were. For that purpose, a DevOps environment or a revision-based test automation tool should be used. You can find some hints on setting up a DevOps environment in the following post: How to Unit Test: A Guide to a Clean Environment
Another important point to consider is to ensure that the tests are not modified by mistake. This is against the guidelines and would invalidate the tests. For that test signing has to be used. Every change to a test that is used for risk reduction has to be documented.
As previously mentioned, validation is an important part of the software development process in regulated environments to ensure that the end product is doing what it’s supposed or expected to be doing.
Specific test cases are written for the product features that need to be validated. It’s important to write them in a way that the results are reproducible later on. The best way to write them is in a simple, human-readable form with actions and expected results. For example:
Those instructions can now be used by a test engineer to validate parts of the system. As an alternative, an automated testing environment, such as testresults.io can be used to execute the test case.
The product’s lifecycle usually doesn’t end with the release of version 1.0. There are bug fixes and change requests that are incorporated and delivered on a regular basis even after the product was accepted and is being used.
This means that the validation will have to be executed again and again, while the test cases and mostly the product itself do not change. That’s the biggest advantage of using a test automation framework such as TesResults.io compared to having the tests manually executed by the testing engineers.
Besides that, if the manual tester in charge leaves, you need to hire someone else and invest time and money to get him to the same knowledge base. That’s why it’s important to have clearly defined test steps and if possible, a test automation tool, that does the work for you.
By the way, TestResults.io is the only test automation solution that is built for regulated environments with all the reports you need (revision-based of course), zero intrusion, and is easy to use – no special skills are needed for test automation. Book your demo now!
.png)
