Exploratory testing has a reputation problem. To people outside the discipline, it looks like undirected clicking. No script, no traceability, no way to know if anything useful happened. That reputation is mostly earned by teams that do exploration without structure.
Session-Based Test Management (SBTM), developed by James Bach and Jonathan Bach, is the structure. It does not constrain the freedom that makes exploratory testing valuable. It makes the work legible to everyone around you.
What a session is
An uninterrupted block of reviewable, chartered test effort.
Each word in that definition carries weight.
Chartered means every session has a mission: a specific target and intent. You are not just testing. You are exploring this area to discover this kind of information. The charter is written before the session starts.
Uninterrupted means exactly that. No email, no Slack, no meetings, no calls. A broken session is not a session. It is a series of context switches that produce shallow observations. Protecting the time is not a nicety, it is the mechanism.
Reviewable means the session produces a record. What was tested, what was found, how time was spent. A third party (a test lead, a product manager, a developer) should be able to read the session sheet and understand what happened without asking you to explain it.
Session length
Sessions come in three sizes:
- Short: 30–45 minutes. Useful for a quick focused sweep, smoke testing a build, or verifying a bug fix in context.
- Moderate: 45–90 minutes. The standard. Long enough to go deep, short enough to stay sharp.
- Long: 90–120 minutes. Reserved for complex areas where setup time is significant or the problem space demands sustained attention. Use sparingly.
The right length depends on the charter. A narrow, well-defined charter fits a short session. A broad area with many unknowns needs more time. Do not pad a session to fill a slot. End when you have found what you came to find or run out of productive moves.
Anatomy of a session
Every session divides its time across three activities:
Test Design and Execution: actively scanning the product, generating ideas, and running them. This is the core of the session: probing the application, watching how it responds, looking for behaviour that does not match expectations.
Bug Investigation and Reporting: what happens once something looks wrong. Reproducing the issue, understanding the conditions, and writing it up clearly enough that a developer can act on it. This is not the same as test execution and should not be conflated with it.
Session Setup: everything that makes the first two activities possible. Configuring a test environment, locating documentation, writing the session report itself. Necessary but not the goal.
These three activities are tracked in the TBS breakdown: an estimate of how much of your session time went to each.
- Test design and execution (T),
- Bug investigation and reporting (B), and
- Session setup (S).
You do not need a stopwatch. A rough estimate at the end of the session is sufficient and honest.
A healthy session spends the majority of its time on T. If B dominates, you have found something significant and should probably continue in a focused follow-up session. If S dominates, your test infrastructure or documentation needs attention.
On Charter vs On Opportunity
A charter defines what you came to do. Opportunity testing is what you notice along the way that does not fit the charter.
In exploratory testing, deviating from a charter is acceptable, expected even. The goal is learning, and the most important thing you find might not be in the area you planned to look. If you stumble into an off-charter problem that looks important, note it, investigate briefly to understand whether it is real, then decide: continue the current charter and log the opportunity find, or pivot to a new charter around what you found.
The distinction matters because it preserves traceability. Your session record captures what you chartered to do and what you found beyond it. A manager reading the report can see both.
Bugs, Issues, and Notes
Three types of artefacts come out of a session, and mixing them up creates noise.
Bugs are concerns about product quality: behaviour that deviates from what is correct or expected. These go into your bug tracker.
Issues are questions or problems about the test process or project context, not defects in the product, but signals that something in the broader situation needs attention. An unclear requirement, a missing test environment, a decision that nobody seems to own. These go to whoever can resolve them.
Notes are everything else. Test ideas you did not get to. A function list you want to explore next session. A pattern you noticed but could not confirm. Risks you want to raise. Notes are a free-form capture. They do not belong in a bug tracker, but they should not be lost either.
Keeping these three categories distinct makes your session sheet useful rather than noisy.
The 7-step approach
1. Create a visual model
Before testing starts, build a picture of what you are testing. Reference the product documentation, sync with the developer who built the feature, talk to the product manager who owns the requirements. The goal is to understand the system well enough to form useful hypotheses about where it might break.
A mind map works well here. The feature at the centre, key areas and behaviours as branches, known risks and open questions noted as you go.
2. Review the model
Share the model with someone, inside or outside the team. A second perspective surfaces assumptions you did not know you were making and fills in gaps you cannot see because you are too close to the work.
3. Break scope into sessions
Decompose the feature or area into charters, one per session. Each charter should be completable in the time you have allocated. If a charter feels too big, it probably is. Split it.
Create a sub-task for each charter. This gives the team visibility into what is being tested and makes it easy to track progress without synchronous check-ins.
Charter syntax:
Explore {target} with {resources} to discover {information}Good charters are specific enough to be actionable and broad enough to allow genuine exploration:
Explore editing profile with injection attacks to discover security vulnerabilities
Explore editing profiles with various login methods to discover surprises
Bad charters are either too narrow (a test case wearing a charter's clothing) or too broad (impossible to fulfil in any finite session):
Explore editing the last name field with the value D'silva to discover if the last name field can handle an apostrophe (too specific, this is a scenario)
Explore system security with all the hacking programs you can find to discover any security holes (too broad, no session will ever close this)
The charter is the agreement between you and the people tracking your work. Write it so that someone who was not in the room can read it and understand what you intended to test.
4. Identify baseline scenarios
Before execution starts, create a set of baseline scenarios: the core flows and conditions the feature must handle correctly. These are not a complete test plan. They are anchors: things you will definitely cover in addition to whatever the exploration surfaces.
5. Execute
Run each charter as a proper session: chartered, uninterrupted, time-boxed. As you test, introduce new scenarios as you encounter them. If you discover an area that needs its own focused exploration, create a new charter. Do not try to expand the current one to cover everything.
The value of exploratory testing comes from the freedom to follow interesting signals. The structure of SBTM ensures that freedom does not become aimlessness.
6. Share the session report
After each session, produce a session sheet. The report covers: the charter, time spent across TBS, bugs found, issues raised, notes captured, and what you did not get to.
A lightweight dashboard works well for teams that need a shared view across multiple charters. Track each charter with its priority, assessment of coverage quality, progress status, and any bugs found. This replaces the need for lengthy status meetings.
7. Track session time
Record start time and total session duration. Total time breaks down into the TBS estimate. This data is not for micromanagement. It is for calibration. Over time, TBS ratios across your sessions tell you whether your testing is balanced, where setup friction is costing you, and whether bug investigation is crowding out exploration.
SBTM is not a heavyweight process. It is a lightweight accountability layer on top of skilled exploratory testing. The sessions stay flexible and human. The records make the work visible to everyone who needs to see it.
Start with one charter. Run the session properly. Write the sheet. The rest follows from there.