SBTM Methodology

Exploratory testing is not "clicking around." It is simultaneous test design, execution, and learning, guided by a charter and bounded by time. Session-Based Test Management (SBTM), formalized by James Bach, brings structure and accountability to exploratory testing without killing its creative power.

What Is Exploratory Testing?

Exploratory testing is a style of testing that emphasizes the personal freedom and responsibility of the individual tester. The tester simultaneously designs tests, executes them, and learns about the system under test — all at the same time. Unlike scripted testing, where you follow predefined steps, exploratory testing adapts in real time based on what you discover.

When Exploratory Testing Excels

• New features with unclear requirements — you are learning the feature as you test it
• Areas with high complexity — too many paths for scripted tests to cover
• After automation catches regressions — exploration finds what scripts miss
• Usability evaluation — scripts cannot assess whether an interface "feels right"
• Time-pressured releases — exploration finds critical bugs faster than writing scripted tests first

When Scripted Tests Are Better

• Regression testing across stable features
• Compliance testing with auditable evidence
• Data-driven testing with hundreds of input combinations

The SBTM Framework

SBTM provides three core elements: charters, sessions, and debriefs.

Charters

A charter is a mission statement for your testing session. It answers: "What am I testing, and why?"

Good charters are specific and bounded:

Explore the checkout flow with international addresses
to discover currency conversion and tax calculation issues.

Explore the file upload feature with edge-case formats (.svg, .webp, 0-byte files)
to discover handling gaps and silent failures.

Explore the admin user management panel under concurrent usage
to discover race conditions in role assignment.

Bad charters are vague:

• "Test the login page" (too broad — what are you looking for?)
• "Find bugs" (not a charter — it is a wish)
• "Test everything in the settings module" (no focus, no time boundary)

Writing Effective Charters

Use the formula: Explore [target] with [resources/approach] to discover [information].

Prepare 2-3 charters before a session. If you finish one early, move to the next. If you discover something unexpected, pivot — but document the pivot.

Sessions

A session is a focused, uninterrupted block of testing, typically 60-90 minutes. The time constraint is essential: it prevents exploration from becoming aimless wandering.

Session Structure

Rules During a Session

1. No interruptions. Treat it like a focused work block. Close Slack, mute notifications.
2. Stay on charter. If you discover something outside your charter, note it as a new charter for a future session.
3. Take notes continuously. If you stop taking notes, you stop doing exploratory testing and start doing random testing.
4. Time-box strictly. When time is up, stop. You can always schedule another session.

Session Metrics

Track these metrics across sessions to understand your testing effort:

Debriefs

After each session, conduct a brief (10-15 minute) debrief with a peer, test lead, or the entire team. Debriefs serve three purposes:

1. Share knowledge — what did you learn about the system?
2. Validate findings — are the bugs real? Are the risks valid?
3. Adjust strategy — should the next session target a different area?

Debrief Questions

• What was your charter?
• What did you actually test?
• What did you find?
• What are you concerned about that you did not have time to explore?
• What should the next session focus on?

Heuristics for Exploratory Testing

Heuristics are mental shortcuts that guide your exploration. Some widely used ones:

SFDPOT (San Francisco Depot)

Created by James Bach:

FEW HICCUPPS

Used for consistency oracles (how to decide if something is a bug):

• Familiar problems — does it have bugs you have seen in similar products?
• Explainability — can you explain the behavior to a user?
• World — does it match how the real world works?
• History — has this area had bugs before?
• Image — does it match the company's brand and quality standards?
• Comparable products — how do competitors handle this?
• Claims — does it match what the documentation says?
• User expectations — would a typical user be confused?
• Product — is it consistent with other parts of the same product?
• Purpose — does it fulfill its intended purpose?
• Standards — does it comply with relevant standards and regulations?

SBTM vs Ad-Hoc Testing

SBTM does not constrain creativity — it channels it. The charter gives direction without dictating every step.

Practical Exercise

Plan and execute a 30-minute exploratory session:

1. Choose a web application you use regularly (your email client, a social media site, a shopping site)
2. Write a charter: "Explore [specific feature] with [specific approach] to discover [specific type of issue]"
3. Set a timer for 30 minutes
4. Take notes every 2-3 minutes: what you tried, what you observed, what questions arose
5. When the timer ends, stop and review your notes
6. Write a brief summary: bugs found, areas of concern, recommended next charters

Key Takeaways

• Exploratory testing is disciplined investigation, not random clicking
• SBTM provides structure through charters, time-boxed sessions, and debriefs
• Good charters are specific: target + approach + information sought
• Session notes are the evidence that distinguishes exploration from ad-hoc testing
• Heuristics like SFDPOT guide exploration without constraining it
• Debriefs create a feedback loop that improves testing over time