Exploratory Testing: What It Is and How to Do It Right
Most bugs found in production were not covered by the test plan. That is not an indictment of scripted testing — it is a reflection of how software actually breaks. Real-world failures tend to emerge from sequences of events no one thought to prescribe upfront: an unusual user journey, an edge-case data combination, a timing condition triggered only when three things happen in the wrong order.
Exploratory testing exists to catch exactly these kinds of bugs. It is the practice of learning about a system and testing it simultaneously — using observations and curiosity to guide what you investigate next, rather than following a predetermined script. Done well, it is one of the highest-value activities in a QA team's toolkit.
This guide covers everything you need to know: what exploratory testing actually is, how it differs from scripted testing, the structured frameworks that keep it rigorous, and practical techniques for running sessions that consistently surface bugs worth fixing.
What Is Exploratory Testing?
Cem Kaner, who coined the term in 1984, defined exploratory testing as "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project."
In plain language: the tester designs and executes tests at the same time, using what they discover to shape what they investigate next. Every observation becomes an input to the next decision.
This is fundamentally different from scripted testing, where test cases are written in advance, approved, and then executed step by step. In scripted testing, the tester follows a map. In exploratory testing, they are drawing the map as they go.
There is an important distinction to make here: exploratory testing is not the same as ad hoc testing. Ad hoc testing is unplanned, undocumented, and produces no accountable output. Exploratory testing is structured — it uses charters, timeboxes, and session reports. It is disciplined, repeatable, and measurable. It simply applies that discipline differently than scripted approaches.
Exploratory Testing vs. Scripted Testing
Both approaches serve legitimate purposes. The difference lies in what they optimise for.
Scripted testing is optimised for consistency and compliance. Every tester follows the same steps and produces a verifiable audit trail. It is the right tool when requirements are stable, when regulatory obligations mandate specific test evidence, or when you need automated regression coverage over hundreds of test cases.
Exploratory testing is optimised for discovery and efficiency. Research has shown that while scripted and exploratory testing produce similar defect detection rates, exploratory testing finds bugs faster — more defects per hour — because testers spend zero time upfront writing test cases and can redirect their focus instantly when they spot something interesting.
| Scripted Testing | Exploratory Testing | |
|---|---|---|
| Planning | Extensive upfront test case design | Charter-based — planned at session level |
| Flexibility | Fixed — deviating from script requires change control | High — tester adapts in real time |
| Best for | Regression, compliance, stable requirements | New features, complex systems, tight timelines |
| Documentation | Pre-written test cases | Session notes, bugs filed, debrief reports |
| Skill required | Accessible to junior testers | Rewards domain knowledge and curiosity |
The most effective QA programs use both. A 2023 PractiTest survey found that 82% of companies use exploratory testing while 61% still rely on scripted test cases — most blend both approaches across different phases of development.
Session-Based Test Management (SBTM)
The structured framework most widely used to govern exploratory testing is Session-Based Test Management, or SBTM. Developed by Jonathan Bach and James Bach, SBTM adds accountability and measurability to exploratory testing without sacrificing its adaptive nature.
SBTM organises testing into three core elements:
1. The Charter
A charter defines the focus of a single testing session. It answers two questions: what are you testing, and what are you looking for? A good charter is specific enough to provide direction but broad enough to allow real discovery.
Elizabeth Hendrickson popularised a concise charter template in her book Explore It! that many teams find highly effective:
- Explore: What feature, workflow, or area are you investigating?
- With: What resources, data, permissions, or tools do you need?
- To discover: What is the intended outcome beyond "find bugs" — a specific risk, a user flow, a performance threshold?
Example: Explore the checkout flow with a guest account and an expired payment card to discover whether the error states are handled gracefully and whether retries create duplicate orders.
That charter is actionable without being prescriptive. It tells you where to start and what to watch for, while leaving room for the discoveries that scripted tests cannot anticipate.
A common mistake is writing charters that are too vague ("test the payment module") or too narrow ("verify that clicking Cancel on step 3 closes the modal"). The first provides no useful direction. The second is just a scripted test case in a charter wrapper.
2. The Timebox
Sessions are time-boxed — typically 60 to 90 minutes — to maintain focus and prevent fatigue. During that window, the tester commits to uninterrupted exploration. No email, no Slack, no context switching. The constraint creates urgency and sharpens attention.
Teams new to SBTM often start with shorter sessions — 25 to 45 minutes — and extend them as testers build skill and stamina. Shorter sessions also work well when investigating a specific, bounded area rather than a broad workflow.
Timeboxing does something else: it makes exploratory testing measurable. You can report session counts, areas covered, and bug densities per session. That satisfies stakeholders who want visibility into manual testing effort without requiring exhaustive pre-written test plans.
3. The Session Report and Debrief
At the end of each session, the tester produces a brief report covering: what was explored, what bugs were filed, what questions emerged, and what follow-up sessions are warranted. This output is the accountability mechanism that distinguishes SBTM from ad hoc testing.
Teams running SBTM at scale often hold short debriefs — 10 to 15 minutes — where the tester walks a lead or manager through their findings. This surfaces patterns across sessions, identifies risk areas being missed, and keeps exploratory testing connected to broader project goals.
When Exploratory Testing Is Most Valuable
Exploratory testing adds the most value in specific contexts:
New or rapidly changing features. When requirements are still evolving, scripted tests are expensive to write and immediately stale. Exploratory testing gives you quality feedback without the upfront investment.
Complex integrations. Systems with many interacting components tend to fail in ways no individual script anticipated. A human tester following curiosity across module boundaries will find integration failures that automated regression tests miss by design.
Tight deadlines. Writing comprehensive scripted test cases takes time. When a critical hotfix ships and you have two hours, exploratory testing gives you meaningful coverage without the overhead of documentation.
After major refactors. When the underlying code changes significantly but the UI stays the same, existing automated tests may all pass while subtle behavioral changes slip through. An experienced tester exploring the refactored area with fresh eyes will catch those regressions.
Usability and user journey validation. Automated tests verify that buttons do what buttons are supposed to do. They cannot tell you whether the overall flow makes sense, whether error messages are helpful, or whether a real user would know what to do next. Exploratory testing surfaces these issues naturally.
Tips for Running Effective Exploratory Testing Sessions
Know the system before you explore it
Exploratory testing rewards domain knowledge. The more you understand the application — its architecture, its user base, its known failure modes — the better your intuition will be about where to probe. Before a session, spend five minutes reviewing recent bug reports, release notes, or user feedback in that area. That context shapes better charters.
Use a risk-based approach to prioritise charters
Not all areas of the application carry equal risk. Focus your exploratory effort where failures would hurt most: payment flows, authentication, data synchronisation, third-party integrations, and any feature with a history of defects. High-complexity, high-impact areas deserve multiple sessions from different angles.
Keep detailed notes in real time
Do not rely on memory. During a session, log what you try, what you observe, and what feels off — even if you cannot immediately confirm it as a bug. These notes become the raw material for your session report and often reveal patterns that only become visible after the session ends.
Vary your approach across sessions
For a given charter, try different experiments in different sessions: different data, different starting states, different user roles, different browser conditions. Bugs that do not appear under one set of conditions may surface under another. The best exploratory testers think like adversaries — they look for the sequences of events that the system was not designed to handle.
Pair test for complex areas
Two testers exploring together often outperform one tester twice as long. One tester operates the application while the other observes and asks questions. This real-time dialogue triggers hypotheses that neither tester would have formed alone. Pair exploratory sessions are particularly effective for new team members learning a product area.
File bugs with enough context to act on them
An exploratory session that surfaces ten bugs but produces vague ticket descriptions is not a win. Developers need repro steps, the sequence of actions that led to the issue, any relevant console errors or network failures, and screenshots or video. The more complete the report, the faster the bug gets fixed — and the more credibility exploratory testing earns with your engineering team.
How Crosscheck Makes Exploratory Testing More Effective
Exploratory testing has always had one practical problem: the moment you find a bug, you have to remember — and reconstruct — everything that led to it. What did you click? What network request failed? What was in the console at the time? If you were not recording your session, some of that context is gone.
That is exactly the problem Crosscheck solves.
Crosscheck is a Chrome extension that automatically captures console logs, network requests, user actions, and performance metrics throughout your browsing session — running silently in the background while you explore. When you find a bug, its Instant Replay feature retroactively captures the last 1 to 5 minutes of your session, assembling a complete picture of everything that happened before you noticed the problem.
This is a particularly powerful fit for exploratory testing. By definition, you do not know when you are going to find a bug — that is the point. You cannot predict which actions will expose an issue, which means you cannot start recording at exactly the right moment. Crosscheck does not require you to. It captures everything, continuously, so that when you do find something, the full context is already there.
From the same interface, you can file a complete bug report — with all captured context attached — directly to Jira or ClickUp in a single click. No copy-pasting console output. No manual screenshots. No reconstructing repro steps from memory. The entire session is documented and actionable before you move on to your next charter.
For teams running SBTM, Crosscheck also makes session reporting faster. The captured session data serves as a ready-made audit trail of what was explored, reducing the manual effort of writing up session notes.
Start Exploring — Without Losing a Single Bug
Exploratory testing is one of the most effective quality activities available to a QA team. It surfaces the bugs that scripted tests cannot anticipate, validates the user experiences that automation cannot evaluate, and does both faster per hour than any alternative. Structured with charters and SBTM, it is rigorous, measurable, and accountable — not a shortcut, but a complement to the rest of your testing strategy.
The one thing holding exploratory testing back has always been documentation: capturing enough context about what you found, and how you found it, to make the bug report useful. That is no longer a limitation.
Install Crosscheck for free and run your next exploratory session with automatic capture of console logs, network requests, and user actions. When you find a bug — and you will — every detail is already captured. File it to Jira or ClickUp in one click and get back to exploring.
