Richard Seidl
Minimum Viable Test Strategy
Podcast Episode: Minimum Viable Test Strategy Written test strategies are endless and in the end nobody reads them. Many people are probably familiar...
Exploratory testing fails in most organizations because teams treat it as an excuse to avoid planning—or worse, as a chaotic bug bash that surfaces only surface-level issues. The real power of exploratory testing techniques lies in structured experimentation: timeboxed sessions focused on high-risk unknowns, particularly in non-functional requirements testing where performance, security, and usability have never been defined. When teams learn to scope exploration around what actually matters, document just enough to drive action, and convert discoveries into automated regression tests, they turn the unknown into a strategic advantage rather than a documentation nightmare.
Podcast Episode: Structured Exploratory Testing Strategies That Work
In this episode, I talk with Callum Akehurst-Ryan, a quality coach with nearly 20 years of experience, about why exploratory testing is far more than random button-pushing—and how teams waste it by using it in all the wrong places. Callum walks us through practical exploratory testing techniques that help uncover risks in non-functional requirements like performance and security, especially when no one has bothered to document what "good" should look like. We discuss how to structure exploration with timeboxes and risk-based scopes, when to turn findings into automated tests, and why retrofitting quality into existing systems demands a different software testing strategy than most teams realize.
"We do exploratory testing when things are unknown. But from the unknown, we get information. That makes things known." - Callum Akehurst-Ryan
Callum Akehurst-Ryan (he/him) is a testing specialist and quality coach with over 17 years of experience across a range of different industries and development methodologies. With a focus on holistic quality engineering and exploratory testing, Callum teaches others in core and agile testing concepts. He’s also a kick-ass dungeon master!
Highlights der Episode
- Exploratory testing finds information about unknowns, not pass/fail confirmation of known requirements.
- Scope exploration by risk and timebox sessions to avoid endless testing rabbit holes.
- Document what matters: defects, conversations, knowledge—not exhaustive test evidence in unregulated contexts.
- Turn exploratory findings into automated regression tests; exploration isn't meant for repeatability.
- AI tools can spider websites to document workflows, enabling golden master testing retroactively.
Unlocking Quality Through Exploratory Testing
Exploratory testing offers teams a powerful way to uncover risks, discover unknowns, and ultimately improve product quality—even when requirements are missing. In this episode recap, Software Testing Unleashed host Richie and veteran quality coach Callum Akehurst-Ryan dissect how, when, and why to make exploratory testing work for your organization.
What Exploratory Testing Is—and Isn’t
When Richie and Callum Akehurst-Ryan kicked off the session, they quickly addressed a common misconception: teams often use the term “exploratory testing” loosely, sometimes applying it to any unstructured testing session. As Callum Akehurst-Ryan explained, “exploratory testing is running experiments and looking for information that helps us confirm or learn about the unknown." It's about investigating areas where requirements don’t exist, risks haven’t been discussed, and where traditional pass/fail criteria won’t suffice.
Unlike scripted testing that tries to confirm if a system acts as expected, exploratory testing is proactive: it's an experimental probe to uncover information that can shape future requirements or escalate hidden risks. Importantly, it’s not just clicking around aimlessly or letting chaos rule the day—it can and should be structured, planned, and driven by prioritized risks.
When Should Teams Use Exploratory Testing?
Callum Akehurst-Ryan described three key contexts where exploratory testing shines:
Shifting Left: Early in the software lifecycle, when teams are reviewing designs or architectural documents, exploratory testing can identify uncertainties and spark discussion about risks. This upstream probing helps shape what eventually becomes the requirements and acceptance criteria.
Edge Case Discovery: Developers often cover happy paths—those flows most users will follow. Exploratory testing helps unearth unusual or negative scenarios that scripted unit tests might miss, ensuring robust coverage beyond what’s obvious.
Non-Functional Retrofits: Many companies, especially startups and scale-ups, release software without clear non-functional requirements (performance, security, usability, etc.). Exploratory testing lets you probe these qualities, gather baseline information, and build actionable feedback, even when initial requirements weren’t specified.
This approach is especially powerful when dedicated testers are scarce and quality expertise is spread thin. It turns uncharted territory into actionable intelligence that teams and architects can use to mature their products.
Structuring Exploratory Testing: Practical Strategies
To prevent exploratory sessions from turning into endless bug hunts, Callum Akehurst-Ryan advocates structured planning. He draws from Elizabeth Hendrickson’s “Explore It!”, recommending scope based on risk and strict timeboxes. By narrowing the playground to what matters most, testers achieve depth rather than superficial breadth.
Equally important is ego management: “Make sure that you’re thinking about finding information that’s really helpful and works with your team, rather than trying to prove that you’re a good tester,” said Callum Akehurst-Ryan. Focus only on issues the team cares about, and periodically stop to ask: “Is it worth deeper investigation?” This keeps efforts aligned, avoids wasted hours, and ensures findings are relevant.
Documenting Outcomes Without Overwhelming the Process
Documentation varies by context. Regulated sectors require audit trails, evidence, and screenshots, but for many agile teams, outcomes may be best captured through defect tickets, wiki pages, or quick Slack notes. For pair testing, one person can drive while the other jots down brief session notes, later distilled into useful summaries.
Critically, exploratory testing isn’t suited to repeated regression sweeps. When discoveries shift areas from unknown to known, translate them into automated or scripted tests to prevent retesting and drifting standards. This way, exploratory testing remains focused on freshly uncertain challenges instead of duplicating efforts.
AI and Automation: Amplifying Exploration
Emerging tools like Playwright are blending AI with browser automation to help map workflows and document behaviors. As Callum Akehurst-Ryan described, AI-powered tools can spider websites, identify common processes, and even help retrofit automated regression checks—useful when requirements are lost or product ownership has faded. While these tools are evolving, their ability to extract system behaviors gives testers a starting point, especially for legacy products or when retrofitting tests.
Stop Coding, Start Asking Questions
Communication gaps between software teams and stakeholders remain a fundamental challenge in many organizations, often resulting in misaligned...
What if Da Vinci had been a software tester?
Software testing sits between art and science. The lens of Leonardo da Vinci highlights habits that matter. Curiosity, close observation, and small...