Exploratory testing is an investigative approach used to find information about software quality where no requirements or expected results exist. It runs experiments to uncover unknowns, such as security vulnerabilities, performance limits, or edge cases. Structured through risk-based scoping and timeboxing, it focuses effort on what the team cares about rather than testing exhaustively.
Key Takeaways
- Exploratory testing covers unknown territory: it runs experiments to gather information where no requirement or expected result exists, not to confirm a known outcome.
- Time-boxing exploration to a fixed session, then checking with the team before continuing, prevents both endless rabbit holes and work on defects nobody will fix.
- Exhaustive testing is mathematically impossible: the character combinations for a single 100-character input field exceed the number of seconds the universe has existed.
- Findings from exploratory sessions should feed scripted or automated tests once the behavior is understood, because exploratory testing is a poor mechanism for repeatable regression checks.
- Golden master testing, capturing what a live system currently does and writing tests to confirm it stays that way, is a valid strategy for retrofitting regression coverage when original requirements are gone.
Exploratory testing means running experiments, not clicking around
Exploratory testing is the work of running experiments to find information that helps confirm or learn about the unknown. It serves a different purpose than traditional testing, where you state what should happen and then check whether it did.
The dividing line is the expected result. When you already know what a feature should do, you can write a yes-or-no test. Exploratory testing fits the moments when you have no expectation and sometimes not even a requirement. You go in to learn what the system actually does.
Take performance as an example. If you have no benchmark and no idea how the system behaves under load, you run experiments to find that out. The point is not to pass or fail a check. The point is to gather the information that lets you decide later whether the behavior is acceptable.
That framing also corrects a common misreading. Exploratory testing is not the same as random poking. Callum Akehurst-Ryan describes it as a spectrum: at one end the loose bug hunt where people push buttons and wait for defects to fall out, at the other end something planned and technical, including runs supported by AI and automation. Both ends are valid. Neither defines the whole.
Why teams reach for exploration when documentation is missing
You explore when there is nothing to test against. Many organizations have built large amounts of software without writing down what good looks like, so the requirements you would normally check simply do not exist.
Callum works as the only quality engineer in his organization, alongside software development engineers of varying levels. In that setting, three uses of exploration come up again and again.
The first is shifting left. You explore designs, user stories, or architecture documents before anything is built, looking for risks worth discussing. There is no pass or fail criteria yet, only a hunt for what could go wrong.
The second is edge cases. Engineers tend to favor the happy path and the smallest set of unit tests they can get away with. Exploring the system surfaces the cases they did not think to cover.
The third is retrofitting non-functional requirements. Security, performance, maintainability, usability, accessibility, deployability: many products were shipped without anyone defining thresholds for these. You explore not to meet a stated bar, but to produce a first honest picture. Page loading is this fast except here. The system handles this many users. These vulnerabilities exist.
This gap is structural, not accidental. Organizations now run with fewer quality experts, so knowledge of what good software looks like has thinned out. Architects, engineers, and product people focus on shipping features and forget that features are not the only source of value. Startups and scale-ups in particular skip the documentation on purpose, letting customers surface problems through feedback. That is a legitimate choice. It just means that when a quality expert arrives, there is little to test against, and exploration becomes the way in.
Scope by risk, then put a clock on it
Structure exploratory testing by scoping it to risk and then timeboxing that scope. Without those two moves, exploration sprawls. You could test everything, and you would never finish.
This approach draws on Elizabeth Hendrickson’s book Explore It!. The logic is simple: decide what matters to the team, narrow your testing to those risks, and give yourself a fixed window. The risk-based scope keeps you on what is important. The timebox stops you from disappearing into one shiny problem for hours.
Callum adds a third discipline: take your ego out of it. Look for information that helps the team, not for proof that you are right or that you are a good tester. He puts the trap vividly:
It might be very exciting that when Venus is in alignment with Mercury and you’re a Leo, and you are eating lime gelatin, the system doesn’t work, but that’s such a weird edge case that no one will ever fix it.
So the three questions that shape a session are: What do we care about? What is important to us as a team? What would we actually fix? The answers define your playground. Inside that playground, you find useful information instead of noise.
The contrast with an unscoped bug bash makes the case for depth. When people click around at random, they find what they personally dislike or the shallow issues sitting on the surface. They go wide and stay shallow. A narrow scope and a fixed hour push you deeper, where the issues that matter tend to hide.
How a session ends: the timebox as a decision point
The end of the timebox is not just a stopping signal, it is a conversation trigger. When the hour is up, you go back to the team and report what you found and where you got stuck.
If you hit something that feels significant, you ask whether the team cares. If yes, you spend another hour on it. If the answer is that nobody would have cared, you have saved that hour and can move on. The cutoff forces the prioritization that keeps exploration honest.
This rhythm also protects you from the opposite failure: getting stuck on something nobody values and burning two hours on it alone. The playground keeps you inside what matters, and the clock keeps returning you to the team to recheck the boundary.
You cannot test everything, so prioritization is the whole game
Exhaustive testing is impossible, and accepting that is what makes exploration effective. The math is unforgiving. A single field of a hundred characters, across the available character sets and regexes, holds more combinations than there have been seconds in the age of the universe. One field. If each test took a second, the universe would not have lasted long enough.
So the question is never “how do I cover everything.” It is “what matters and what would we fix.” Prioritization is not a compromise forced by limited time. It is the core skill.
For a solo tester, there is no room for three weeks of open-ended exploration anyway. Callum moves testing earlier instead, to stop bugs before they happen and to get engineers thinking about risk. A few practical moves carry most of the weight:
- Three Amigos sessions at story refinement, where you raise negative cases and ask what happens to performance or to an edge condition. This gets engineers building fixes for problems before the code exists.
- Risk mind maps on an existing ticket, breaking risk down by layer. At the API layer, here is what could go wrong. At the UI layer, here is what could go wrong. Performance, security, each gets its own branch.
- Pairing to run the actual exploration, agreed up front: we will spend three hours total across these three areas, and no more.
The shared rule across all of it: do not try to be perfect all at once. Good enough often looks like one hour, then a decision based on what came out of it.
Document for your context, not for an audit you do not have
Match your documentation to the environment, not to a banking-grade audit trail. Much of testing’s documentation culture grew out of finance, which is why people assume every test needs screenshots and evidence. For many teams, that assumption is wrong.
In an agile, unregulated setting, the lasting output of exploration can be the defects raised, the conversations had, and the knowledge the team gained. A few lines in a Slack channel, a wiki page, a new ticket, or simply the code change that follows: any of these can be the record.
Callum’s own habit is light. He keeps a pad and pen, jots brief notes as he goes, then distills them into a short report after the hour. The report says what he looked at, what was fine, what he has questions about, and what might be a problem. That report drives the conversation with the team, and anything actionable becomes a ticket.
Other formats work too, depending on how you pair and what you need. Some testers record video and watch it back. When two people pair, one drives the screen while the other writes, and they shape the notes into something meaningful afterward.
Exploration feeds your automated tests, it does not replace them
Exploratory testing is a poor way to run repeatable tests, and that is by design. Picture a line from the known to the unknown. You explore at the unknown end. What you learn there moves things toward the known end, and anything known is a candidate for scripted or automated tests.
So the way to avoid re-treading the same ground each week is to convert what you have learned into automated checks, at the code level or the feature level, wherever it matters. That is your regression suite. Running a large manual regression pass through exploration invites drift, because you will not do it the same way twice.
This is also where teams misuse the technique. Some avoid planning and automating altogether and call the result exploratory testing: no scripts, no documentation, just two weeks at the end of a month to see what happens. That is an approach, but it is not a sound testing strategy. Exploration belongs to the unknown. It prepares the structured testing that follows, rather than standing in for it.
Where AI fits: spider the unknown, then lock it down
AI tooling extends exploration by mapping what an application does and turning that map into rerunnable tests. The field is new, and nobody should claim mastery of it yet, but the direction is concrete.
Playwright integrates with language models, and the pattern works like a functional version of a security spider such as OWASP ZAP. You point the tooling at a site, let it explore and crawl, identify the common workflows, and document them. From that documentation you can retrofit automation, then rerun it as often as you like. You will get some good and some bad out of it, but it is a usable starting point.
There is a named discipline behind this, and it predates the AI tooling. Golden master testing assumes the running product is the spec. You no longer have the requirements, the tickets are gone, the product owner has no time to reconstruct intent, so you write tests that confirm whatever the system currently does. Software engineers do the equivalent at the code level, called characterization testing: they read the existing logic and write tests that capture its current behavior, regardless of what was originally intended.
The honest caveat: you are testing what the product does, not what it was supposed to do. That is weaker than testing against intent. Still, it has real value. Capturing current behavior and guarding it against unintended change is a genuine improvement, and AI-assisted exploration is a fast way to produce that first picture.
