The limits of classical testing
In classical testing, we assume that we are aware of what we know and don’t know and can therefore design test cases to address it. Classical testing provides structure, repeatability and regulatory confidence. But this approach has natural limits.
Especially in complex systems, for example those with highly branched menu structures, it is simply not possible to cover every transition or edge case with a specific requirement. These “unknown unknowns” cannot be captured by scripted tests, simply because they were never thought of in the first place.
So, if classic testing alone is not enough, what complements it?
Exploratory testing in practice
Exploratory testing follows a different paradigm. Instead of strictly following predefined steps, testing and learning happen simultaneously. Testers continuously adapt their testing based on observations, using their experience and system understanding to guide the exploration.
This does not mean the process is unstructured. On the contrary, exploratory testing can follow clearly defined goals and focused sessions, supported by structured techniques such as test charters, test tours or heuristic models like SFDIPOT.
In practice, exploratory testing is especially valuable in two phases:
- Early in development, when features are still evolving and requirements may be incomplete. Exploratory testing enables the early detection of defects by examining workflows, verifying architectural assumptions, and identifying integration risks before they spread to later development phases at a stage when they can be resolved with minimal effort and low cost.
- Towards the end of a project, as an independent quality check before release. Here, it challenges the hopefully finished product, evaluates system robustness and adds an additional layer of confidence before market entry.
Business value: small effort, high impact
The earlier a defect is detected, the lower the cost to fix it. This well-established principle is often described as the “Rule of Ten”. Fixing a defect typically becomes ten times more expensive with each phase it progresses through: from development to system testing, acceptance and finally to the field.
In practical terms, a defect that costs relatively little to fix during development can quickly escalate to thousands during testing and millions once it hits the market. In the medical device industry, these costs go far beyond technical fixes and can include regulatory consequences, corrective actions, recalls and lasting reputational damage.
At the same time, a robust test strategy is never built on a single approach. It relies on a combination of complementary methods: manual and automated testing, different test levels, and both scripted and unscripted test execution. Each of these perspectives uncover different types of defects. While automated and requirement-based tests ensure coverage and consistency, more flexible approaches are needed to identify unexpected behavior.
This is where exploratory testing adds significant value. By extending the test plan with this additional perspective, teams can identify defects that would otherwise remain hidden, particularly those outside predefined requirements or test cases.
Compared to the potential cost of late defects or recalls the investment required for targeted exploratory testing is minimal. Even a limited number of focused sessions can act as a highly effective risk mitigation measure.
More than bug finding
Exploratory testing goes beyond identifying technical defects. It expands the scope of testing by revealing unanticipated scenarios and potential weaknesses in workflows.
It not only challenges what is considered “complete” and exposes gaps between intended and actual system behavior especially in complex, safety-critical environments but also helps to avoid operational blindness, since teams can overlook obvious weaknesses after repeatedly testing the same scenarios.
Exploratory testing is therefore not a replacement for classical testing, but a powerful complement. It strengthens existing verification strategies by addressing what fixed tests inherently cannot cover and helps to close the gap between documented requirements and real-world system behavior.
