.png)
This article is relevant for you if you are involved in the quality assurance of complex software systems and if your top priority is maximizing customer satisfaction and the value the software delivers.
One of our customer in the MedTech sector managed to save 700+ h per year!
Since lives rely on MedTech software, it is subject to strict regulations. And all the regulations pose challenges and don’t always support efficiency.
Our client was able to overcome them!
To make testing complex systems more efficient, precise, and reliable, they didn’t just switch to TestResults.io as their test automation platform—they also introduced some smart additional methods on their test automation projects.
We’ll reveal three of the methods they use!
You can apply these methods in non-regulated environments just as effectively when testing complex systems to save time, simplify processes, and ultimately deliver software that impresses customers.
Steal these methods and simplify your own testing of complex systems ⬇️
IQOQ is a common practice for medical devices and other regulated industries, and it helps when complex software systems are developed in your non-regulated field!
In regulated environments like health tech and medical devices, Installation Qualification (IQ) and Operational Qualification (OQ) are essential to ensure systems perform correctly in their specific environments.
Since we will go into more detail about IQ and OQ in this tip, it's good to know the definitions:
Installation Qualification (IQ) ensures that an instrument or device, subsystems, and ancillary systems are installed and configured according to the manufacturer's specifications or installation checklist.
Operational Qualification (OQ) is performed after the successful completion of IQ protocols.
OQ aims to verify that the device's performance meets the user requirements within the manufacturer-specified operating ranges.
Why this practice is also helpful for you:
When deploying a complex software system in a new environment (especially at a customer's site), performing a few sanity checks is crucial to ensure that the software is installed correctly and all dependencies are in place.
When done frequently, and since automation is usually already in place for testing during development, why not automate these IQ / OQ checks as well?
Provide self-contained IQ/OQ-Check software that executes these automated tests and gives you confidence that the software will run as intended.
Automating these tests gives you confidence that the software will run as intended and reduces the effort for service or operations engineers when installing the software system in a new environment.
When it's already standard practice for medical devices and other regulated industries, applying it in your non-regulated field is a no-brainer when complex software systems are developed.
You already know how vital good test reports are.
The game is simple: clear test reports -> easier debugging -> better software quality -> you’ve done a great job! 🏆
Capture and report an image of each element when the automated test interacts with it!
With the image, it’s immediately clear:
When done right, these reports serve as the basis for documentation such as user manuals.
You feed two birds with one scone!
99% of people in QA don’t remember what they automated a year ago.
It’s not because they’re forgetful but because it’s perfectly human not to keep all the small details of a test case in mind for an entire year.
You’re so active and accomplishing so much daily that if you could remember it all, one might argue you hadn’t done much.
So, don’t worry about remembering all the details of how you automated the test cases.
Just ensure excellent error handling so that remembering details isn’t necessary.
Already think about maintenance and debugging during the development of the automated tests!
If you do this now, you’ll be chilling when debugging a couple of months or years from now:
In case of a failed verification, always return the actual value that didn’t match the expected value.
Report something like this:
"The selected value on {element} was {actualValue} instead of the expected value {value}."
Report / Log fix suggestion when incorrect precondition or test data is detected.
Example:
Your test relies on a DB script that creates a record. I
f this record is not found during test automation, include a message that the DB script needs to be run before the test.
Perform retries for specific issues, such as network problems.
This will help improve the stability of your tests.
Dynamically monitor for unexpected popups and handle them.
Example:
Close an update notification that appears on top of your test system.
BTW: TestResults.io does this for you with its newest feature! 🚀
Become a member now and get your free account!
Your future self or even your colleague who didn’t do the automation themselves will be thrilled next year when they have to debug test failures from aborted cases and find this error handling in place!
P.S. In case you’re wondering who the 1% that remembers might be, I’m thinking of the Mike Rosses among us.
(Mike Ross is one of the protagonists in the lawyer show "Suits" who has a photographic memory)
With these tips, you’re one step closer to flawless test automation of complex systems!
But if you’re still struggling with the problem that you can’t access all technologies, meaning you can’t test the entire user journey automated because your tool can’t access all technologies, then it’s probably time to look into TestResults.io.
.png)
.png)
.png)