Session-Based Test Management (SBTM): Exploratory Testing That Scales

Exploratory testing is powerful, but it has a management problem: how do you measure coverage, report progress, or coordinate across a team when tests aren't written in advance? Session-Based Test Management (SBTM) solves this by adding structure to exploratory testing without eliminating its flexibility.

Developed by James and Jon Bach in 2000, SBTM provides accountability through sessions — bounded units of exploratory work with defined goals, time limits, and documented results.

The Core Concept: A Session

A session is an uninterrupted block of time spent doing exploratory testing. Sessions have:

• A charter — the mission: what to explore and why
• A time box — typically 60-120 minutes, no interruptions
• A session sheet — notes taken during the session
• A debrief — a structured review after the session ends

The session is the unit of measurement. Instead of counting test cases executed, you count sessions completed per charter area. Instead of pass/fail metrics, you track bugs found, coverage areas, and remaining risk.

Writing Charters

A charter states the mission for one session. The standard format is:

Explore [target] with [resources/approach] to discover [information/risks]

Examples:

Explore the checkout flow with different payment methods to discover edge cases and error handling

Explore user account settings with concurrent browser sessions to discover data consistency issues

Explore the file upload feature with unusual file types and sizes to discover validation and error behavior

Charters are not test cases. They don't specify exact steps. They identify an area and an approach, leaving the tester free to follow what they discover.

Charter Granularity

Charters should be achievable in one session (60-120 minutes). If a charter would take days, split it:

Too broad: Explore the admin panel

Better:

• Explore admin user management with role assignment and permission changes
• Explore admin reporting with date filters and export functions
• Explore admin audit logs with search and bulk operations

Too narrow: Click the Submit button on the registration form

Better: Explore the registration form with edge case inputs and error recovery

Charter Backlog

Before a testing cycle, create a charter backlog — a list of all the areas you want to explore. This serves as your test plan. You won't always get through all of them; prioritize by risk.

The Session Sheet

During a session, record everything in a session sheet. This is your raw note-taking artifact. It doesn't need to be pretty, but it needs to be complete.

A basic session sheet includes:

Session: Checkout flow — payment methods
Date: 2026-05-22
Tester: Sarah
Duration: 90 minutes
Charter: Explore checkout with different payment methods to discover edge cases

NOTES:
- Visa: works normally. Order confirmation email received. [09:15]
- Mastercard: works. 3DS challenge appeared, completed OK. [09:22]
- Amex: form accepted it but 3DS didn't trigger — expected? [09:31]
- Test with expired card: generic error "Payment failed", no guidance. BUG?
- Declined card: same generic error. Doesn't tell user why.
- Saved card + different billing address: form clears billing on save. BUG.
- PayPal: redirects to PayPal, returns to cart (not checkout). Bug or feature?

BUGS:
1. Generic payment error messages — no differentiation between expired/declined
2. Billing address cleared when selecting saved card

ISSUES/QUESTIONS:
- Does Amex skip 3DS intentionally?
- PayPal redirect behavior — confirm with PM

COVERAGE NOTE: Tested 4 payment types. Did not test Apple Pay, Google Pay, 
or bank transfers. Did not test with cart timeout during payment.

The coverage note is critical — it tells the team what you didn't get to.

Session Metrics

SBTM provides three key metrics:

Sessions — how many sessions have been completed vs. planned. This tells you how much exploratory testing has happened.

Bugs/session — average defects found per session. A high number means the area is defect-rich; a declining number suggests the area is becoming stable.

Coverage — what percentage of charter areas have at least one session. This is your proxy for exploratory test coverage.

These metrics let managers answer "how much exploratory testing have we done?" without requiring scripted test case counts.

The TBS (Time Budget Split)

Jonathan Bach introduced the TBS metric, which categorizes how time in a session is spent:

• Testing — time actually exploring the software
• Bug investigation — time reproducing and documenting found bugs
• Session setup — time configuring the environment, reading specs, setting up data

A healthy session is roughly 70% Testing, 20% Bug investigation, 10% Setup. If setup is consuming 50% of sessions, that's a process problem worth fixing.

The Debrief

After each session, a brief debrief (15-30 minutes) with the manager or team lead covers:

1. What did you test? — a brief summary of what was explored
2. What did you find? — bugs filed, risks identified, questions raised
3. What wasn't tested? — gaps and follow-up charters needed
4. How do you assess the area? — confidence level (high/medium/low)

The debrief catches misunderstandings about the charter, coordinates follow-up work, and transfers knowledge from tester to the wider team. Without it, the value of the session stays locked in the tester's head.

SBTM in a Team Setting

Dividing Charter Areas

Assign charter areas to testers based on their expertise. A tester with deep knowledge of your payment integrations should own the checkout charters. A new tester can start with lower-risk, lower-complexity areas.

Use a simple tracking sheet:

Pair Exploratory Testing

Two testers working the same charter find more bugs than either would alone — different knowledge, different mental models, different heuristics. One tester operates; the other observes and suggests.

Pairs also share knowledge: the experienced tester mentors the newer one by explaining what they're looking for and why.

Integrating SBTM into Agile

SBTM works well in sprints. A typical integration:

Sprint planning — identify charter areas for the features being built. Add them to the charter backlog.

During sprint — as features reach testable state, testers pull charters from the backlog and run sessions. Bugs go into the bug tracker immediately.

Sprint review — present session metrics: sessions completed, coverage percentage, bugs found by area.

Retrospective — discuss which charter areas surfaced the most bugs (invest more there) and which were consistently clean (potentially reduce coverage there).

Agile teams sometimes allocate a fixed time budget per sprint for exploratory testing (e.g., "10% of tester capacity"). SBTM makes that budget measurable.

When Not to Use SBTM

SBTM adds overhead — session sheets, debriefs, charter management. For very small teams or quick sanity checks, it's overkill. Use lighter-weight exploratory testing (just take notes and debrief informally) when:

• Testing a small change with low risk
• Running a quick smoke test before a release
• You're the only tester and the product is simple

Apply SBTM's full structure when:

• Multiple testers need coordination
• Stakeholders need coverage reporting
• The area is high-risk and complex
• You're testing a new feature from scratch

Tools

SBTM doesn't require special software — a text file or spreadsheet works. But dedicated tools help:

• Rapid Reporter — free Windows/Mac/Linux tool for session notes with built-in timer and export
• TestBuddy — session-based testing tool with debrief support
• Xray for Jira — supports exploratory sessions within Jira
• qTest — enterprise test management with exploratory session tracking

For teams already using Jira, a simple Jira issue type for "exploratory session" with fields for charter, tester, and findings is enough to get started without extra tooling.

The Bottom Line

SBTM gives exploratory testing the accountability of scripted testing without its rigidity. Sessions are measurable, coverage is trackable, and knowledge is captured. It's the difference between "we did some exploratory testing" and "we completed 8 sessions covering 6 charter areas, found 12 bugs, and have 3 charter areas with low coverage we plan to address next sprint."

That difference matters when you're explaining testing progress to a stakeholder or deciding whether a feature is ready to ship.