In regulated industries, compliance, consistency, and safety are paramount. Structure and predictability are the hallmarks of a regulated test strategy. As a result, software testing is often limited to step-by-step, scripted procedures.
Yet, unscripted exploratory testing is emerging as a modern best practice, even in highly regulated domains.
At first glance, exploratory testing may appear to be at odds with the rules of a regulated industry. It relies on experience and spontaneity rather than scripted instructions. But delve deeper, and you’ll find that it complements and enhances the rigid testing we've come to rely upon.
In fact, regulatory bodies, such as the US FDA, now recommend exploratory testing as an effective tool for building a more risk-based approach to software testing.
As we review exploratory testing, this article will show its usefulness and alignment with industry regulations. We'll discuss real-world use cases and provide a roadmap for adding exploratory testing into a regulated test strategy.
When we think about software testing in regulated industries, we almost always think about scripted testing. These are test scripts with step-by-step instructions for the tester:
|
Exploratory testing, however, is a form of unscripted testing.
ISO/IEC/IEEE 29119-1:2022 defines it as:
”experience-based testing in which the tester spontaneously designs and executes tests based on the tester's existing relevant knowledge, prior exploration of the test item (including the results of previous tests), and heuristic “rules of thumb” regarding common software behaviors and types of failure.” |
In simpler terms, exploratory testing is when the tester creates a test script as they go. They rely on their intuition and experience to decide what to do next based on what happens in the software.
Scripted testing is like following a GPS with exact turns and stops. Exploratory testing is like wandering through a city, using intuition and experience as your guide.
Yes. Definitely.
First, exploratory testing doesn’t replace the scripted testing we’re already doing. It’s added on top.
Furthermore, it provides several benefits that align with regulated software testing goals:
Users are unpredictable. They try things we never anticipated, and they sometimes expose bugs in the process. Exploratory testing is better equipped to find those bugs than scripted testing. You can only write a script for the errors you anticipate in advance.
Exploratory testing lets testers rely on their experience and intuition rather than a script. This will help you identify and mitigate unanticipated software hazards early.
In the life sciences industry, we spend a lot of time on testing overhead:
Maintaining accurate test scripts requires a lot of overhead.
In practice, it is common for teams to find more defects in their scripts than in their software.
It’s a lot of extra work that is important for high-risk, safety-relevant testing. However, that additional work is unnecessary overhead for lower-risk testing. Exploratory testing is a great way to cover low-risk scenarios quickly and without the overhead.
This is what the US FDA says about using unscripted testing to support a risk-based strategy:
“In contrast, for software features, functions, and operations that are not high-risk, manufacturers may consider using unscripted testing methods such as ad-hoc testing, error-guessing, exploratory testing, or a combination of methods that is suitable for the risk of the intended use.” – Draft Guidance: Computer Software Assurance for Production and Quality System Software, September 13, 2022 |
Note: The above reference is from a draft (non-binding) guidance document. Yet, it clearly shows the regulator’s current thinking on exploratory testing.
Here are a few use cases where exploratory testing can provide tremendous value:
These are the basic steps for adding exploratory testing into a formal test strategy:
Step 1: Create an exploratory testing workflow. An exploratory testing workflow looks a lot like a scripted testing workflow. The only difference is that you will replace your test script with a test charter.
Otherwise, you’ll follow the familiar regulated testing workflow, including pre-execution and post-execution approval:
When defining your test goals and the test scope, it’s important to know the difference. While test goals define the objectives of testing, such as identifying bugs or validating functionality, test scope delineates the boundaries of testing, outlining the specific features or aspects to be tested.
As specified under item 1.4, when it comes to regulated industries, it's important to add requirements coverage as applicable, ensuring comprehensive testing that adapts to evolving project needs¹.
² Standard Operating Procedures are detailed, written instructions designed to achieve uniformity in performing specific functions, crucial in regulated industries. |
Step 2: Update your verification and validation (V&V) plan. You’ll need to add a few declarations:
Note: Of course, you may need to make more updates. That depends on the content of your current V&V plan and the advice of your quality stakeholders.
Step 3: Choose a tool set. We’ll look at that next;
Step 4: Start testing!
Exploratory testing doesn’t need expensive technology. Some common toolsets are:
Exploratory testing can transform your test strategy. You will find more bugs much earlier in your process than ever before. Most importantly, you can use it in a way that is compliant with industry regulations.
I encourage you to get started right away:
For expert guidance tailored to the life science industry, consider collaborating with Agile-Innovations.Tech, a seasoned expert specializing in the life science industry.