Exploratory Testing — How to Do It Professionally
Exploratory testing isn't random clicking. Learn test charters, session-based testing, how to document findings, and when this approach gives the most value.
“Just click around and see what breaks.”
If this is how exploratory testing is described in your team, it’s being done wrong — or more accurately, it’s not being done at all. What’s being done is ad hoc testing: unstructured, undocumented, unrepeatable.
Exploratory testing, done properly, is one of the most sophisticated skills in software quality engineering. It’s the technique that finds the bugs your scripted tests can never find, because scripted tests can only verify what you anticipated. Exploratory testing finds what you didn’t.
What Exploratory Testing Actually Is
Elisabeth Hendrickson, one of the pioneers of professional exploratory testing, defines it as:
Simultaneous learning, test design, and execution.
Each of those three words matters:
- Learning — you’re building your understanding of the system as you test. You don’t test with a complete mental model; you build it during the session.
- Design — you’re deciding in real time what to test next, based on what you just found. Test design and execution are interleaved.
- Execution — you’re actually running the tests, not just thinking about them.
Compare this to scripted testing: design happens first (test cases), execution happens later (run the cases). The knowledge you have when designing is incomplete — which means the cases will always have gaps.
Exploratory testing fills those gaps.
Why Scripted Tests Aren’t Enough
Scripted tests (automated or manual) can only verify behaviour you anticipated when writing them. They’re excellent at catching regressions and verifying known requirements.
But software systems fail in unexpected ways. A user with unusual data, an edge case in data formatting, a combination of features that no one designed together, a race condition that only appears under certain load — these are the bugs that reach production despite a green test suite.
Exploratory testing is specifically designed for these failure modes. The tester approaches the system as an intelligent adversary: “How can I make this fail in a way the developer didn’t anticipate?”
Test Charters — Structure Without Scripts
The most important technique in professional exploratory testing is the test charter. A charter provides direction and scope for a session without prescribing exact steps.
The standard format is:
Explore [target area] with [resources/tools/techniques] to discover [information/risks]
Examples
"Explore the checkout flow with a guest user on mobile Safari
to discover friction points and error states"
"Explore the user settings page with simulated slow network (3G)
to discover loading, timeout, and partial-save issues"
"Explore the CSV file upload feature with unusual file formats,
encodings, and edge-case content to discover validation gaps and
security issues"
"Explore the API rate limiting behaviour under rapid repeated
requests to discover error handling, recovery time, and message
quality"Notice what a charter does and doesn’t do:
- ✅ Defines the area of focus
- ✅ Specifies the approach or resource
- ✅ States what kind of information you’re looking for
- ❌ Does NOT tell you what steps to take
- ❌ Does NOT specify what the expected result is
The tester decides the steps in real time based on what they observe. That’s the point.
Session-Based Testing (SBTM)
Session-Based Test Management (SBTM) is the framework that gives exploratory testing measurability and reportability. It was developed by Jonathan and James Bach to address the most common objection to exploratory testing: “You can’t manage what you can’t measure.”
Structure of a Session
Every SBTM session has four components:
- Charter — the direction for the session (see above)
- Timebox — a fixed duration, typically 60–90 minutes, with no interruptions
- Notes — a running record of what you did and found during the session
- Debrief — a short discussion with a stakeholder to share findings
The timebox is crucial. Sessions without time limits tend to drift. A 90-minute focused session with a clear charter is worth more than four hours of undirected clicking.
The SBTM Session Worksheet
Here’s a template you can use directly:
=========================================
SESSION WORKSHEET
=========================================
Charter: [Explore X with Y to discover Z]
Tester: [Name]
Date: [YYYY-MM-DD]
Start time: [HH:MM]
Duration: [minutes]
Build/version: [e.g. v2.3.1-staging]
-----------------------------------------
TEST NOTES (narrative)
-----------------------------------------
[Running notes of what you tried and what you observed]
HH:MM - Navigated to checkout as guest user
HH:MM - Entered card details with expiry in the past → error shown ✓
HH:MM - Left card number field empty, submitted → no validation error shown ← BUG?
HH:MM - Refreshed mid-checkout → cart preserved ✓
HH:MM - Tried checkout with VPN active → strange redirect to /en-us/
-----------------------------------------
ISSUES FOUND
-----------------------------------------
1. Empty card number field allows form submission
Steps: Guest checkout → Skip card number → Click "Pay"
Expected: Validation error on empty required field
Actual: Form submits, shows generic API error
Severity: High
Screenshot: [link]
2. VPN active causes redirect to /en-us/
Steps: Enable VPN (US server) → Attempt checkout
Expected: Normal checkout flow
Actual: Redirected to US localised version mid-flow, cart lost
Severity: Medium
-----------------------------------------
QUESTIONS / FOLLOW-UP
-----------------------------------------
- Is there server-side card number validation? (ask developer)
- Is the VPN redirect intentional? (ask PO)
- What happens with 3DS authentication on mobile?
-----------------------------------------
IDEAS FOR NEXT SESSION
-----------------------------------------
- Explore the same checkout flow logged in as a returning user
- Explore the payment error states with different card types
- Explore mobile Safari specifically (different keyboard behaviour)
-----------------------------------------
METRICS
-----------------------------------------
Session duration: 75 minutes
Charter coverage: ~70% (ran out of time on mobile tests)
Bugs found: 2
Questions raised: 3
=========================================Metrics from SBTM
Session-based testing produces measurable outputs:
- Bug/session ratio — how many issues per session? Useful for comparing areas of the product.
- Charter coverage — what percentage of the charter did you get through in the timebox?
- Session count per feature — tracks investment in testing quality.
- Opportunity areas — recurring question types indicate design gaps.
This is how you make exploratory testing visible to management: not by converting it to test cases, but by tracking session outputs.
How to Take Good Notes During a Session
Note-taking is a skill that takes practice. Bad notes make sessions unrepeatable; good notes make bugs reproducible.
Practical guidelines:
- Timestamp your notes — you’ll thank yourself when trying to reproduce a bug
- Note what you expected, not just what happened
- Screenshot or record video immediately when you see something suspicious
- Don’t stop the session to investigate a finding deeply — note it and continue
- Distinguish between: confirmed bug / observation / question / idea
Tools: A plain .md file, Notion, OneNote, Confluence — whatever doesn’t interrupt the flow. The tool doesn’t matter; the discipline of writing does.
When Exploratory Testing Gives the Most Value
| Situation | Why exploratory testing helps |
|---|---|
| New feature just released to staging | First real interaction with the feature as a whole; scripted tests only tested parts |
| After a large refactor | Regression exploration — find emergent interactions between old and new code |
| High-risk areas from sprint planning | Invest session time proportionally to risk |
| Just before a major release | Final check on critical paths; fresh pair of eyes |
| After a production incident | Find related issues before users find them |
| Sprint retrospective findings | ”Users reported X was confusing” → dedicated exploratory session |
Common Mistakes
No charter → no direction → no value. Starting a session with “explore the checkout page” is almost as bad as no charter. Be specific about what information you’re looking for.
No timebox → sessions drag or get skipped. If exploratory testing is scheduled as “whenever there’s time,” it will never happen. Block it in the sprint calendar.
No notes → findings disappear. Without notes, bugs found during exploration are reported informally and often forgotten. Everything must be written down.
No debrief → findings don’t reach the team. The session worksheet is only useful if someone reads it. A 10-minute debrief with a developer or PO after each session closes the loop.
Treating it as “free time.” Exploratory testing is structured professional work, not a break from writing test cases. Charter it, timebox it, document it.
The 60-Minute Rule
If you haven’t found anything interesting in 60 minutes, one of two things is true: either your charter is too vague, or the area is more stable than expected. Either way, stop, debrief, and revise the charter for the next session.
Don’t continue an unproductive session hoping something will turn up. Time-box, debrief, adapt.
Conclusion
Exploratory testing is a discipline — not an accident, not a fallback, not “random clicking.” When done professionally, with charters, timeboxes, and documentation, it’s the highest-ROI testing activity available to a QA engineer.
It finds the bugs that automated tests can never find, because it brings human intelligence, experience, and curiosity to the system — not a predetermined script.
Start this sprint: Write one charter for the riskiest feature currently in test. Run one 60-minute session. Write up the findings. Share them in your next standup. That’s how it begins.
This is the sixth and final post in the Series 1 — QA General series. Series 2 — ISTQB Foundation Level — begins next week.