Session-Based Test Management: A Deep Dive into Structured Exploration

Session-based test management (SBTM) was invented by Jonathan and James Bach in 2000 to solve a real problem: exploratory testing was producing great bug finds but terrible accountability. Managers couldn't answer basic questions — how much testing was done, what was covered, where did testers spend their time?

SBTM answered those questions without turning exploration into scripted drudgery.

What Makes a Session

A session is a focused, uninterrupted block of testing with a clear mission. Three things define it:

1. A charter — the mission statement: what you're testing and why
2. A time box — typically 60–120 minutes of pure testing, no interruptions
3. A session sheet — the real-time log of what happened

The charter is not a test script. It says "Explore the payment flow using expired credit cards" not "Enter card number 4111... in field X, click Submit, verify error message Y." The how is up to the tester.

Session Sheet Anatomy

A session sheet captures everything during the session. The standard format from the Bach brothers looks like this:

SESSION SHEET
Charter: Explore checkout with international payment methods
Tester: Sarah Chen
Date: 2026-05-30
Start: 14:00
Duration: 90 minutes

TASK BREAKDOWN
Testing: 65%
Bug investigation: 20%
Setup/config: 15%

DATA FILES
- test-cards.csv
- locale-settings.json

TEST NOTES
14:05 - EUR payments work correctly, 3DS challenge fires as expected
14:22 - GBP with postal code validation fails for Northern Ireland postcodes (BT* prefix)
14:38 - JPY amounts round incorrectly — ¥1000 stored as ¥999.99
14:55 - CNY payment blocked entirely (expected per compliance docs)
15:10 - Investigated JPY bug: currency conversion runs before integer rounding

BUGS
B001: JPY amount stored with decimal places (blocker for JP launch)
B002: BT* postcodes rejected on GBP payments (medium)

ISSUES
No test data for KRW, ILS, or SAR — needed for full coverage

COVERAGE CHARTER: 70%
Charter was partially covered. CNY exclusion and missing test data left ~30% untested.

The task breakdown percentages are critical for metrics. They tell you whether testers are actually testing or spending the session fighting the environment.

The TBS Metric: Testing, Bug Investigation, Setup

SBTM tracks time across three categories:

• T (Testing): pure hands-on exploration
• B (Bug Investigation): deep-diving into found defects
• S (Setup/Config): environment prep, test data creation, tool configuration

A healthy session runs 70%+ on T. When S climbs above 25%, your test environment is broken and blocking exploration. When B climbs above 30%, you've either found a critical defect worth pursuing or you're getting pulled into debugging rather than testing.

Aggregate these across sessions to spot systemic problems. If every session shows 35% S, fix the environment before writing another charter.

Charter Writing That Works

Bad charter: "Test the login page"

Better charter: "Explore login with edge-case inputs (Unicode, extra-long strings, special characters) to find input validation failures"

Best charter: "Explore login as an attacker — try SQL injection, XSS payloads, and brute-force patterns — to assess authentication security"

The structure: "Explore [target] using [resources/techniques] to discover [information/risks]"

Charter scope matters too. A 2-hour charter covering the entire application is useless. Scope to a single feature, flow, or risk area. If you can't complete meaningful exploration in 90 minutes, split it into multiple charters.

Charter Sources

Where do charters come from?

• Risk analysis: what are the highest-impact failure modes?
• Requirement gaps: areas where specs are vague or missing
• Bug patterns: where have similar products failed before?
• User journeys: what does a real user actually do?
• Previous session issues: follow up on unexplored territory noted in prior sessions

Keep a charter backlog. Treat it like a test case backlog — groom it, prioritize it, retire stale charters.

The Debrief: Where the Value Is

The debrief is a short meeting after the session. 15–30 minutes max. The tester walks through the session sheet with a test lead or peer.

What happens in a debrief:

1. Bug triage: Are found bugs real? Reproducible? Severity correct?
2. Coverage review: What was actually tested vs. the charter?
3. Charter assessment: Was the charter too broad? Too narrow? Wrong area?
4. New charters: What unexplored areas surfaced?
5. Environment issues: What blocked testing?

Debriefs done right produce more charters. The session is not the end of exploration — it's input into the next round.

Teams that skip debriefs lose most of the value of SBTM. Session sheets pile up unread. Bugs get filed and forgotten. Coverage gaps never feed back into planning.

Scaling SBTM Across Teams

Individual SBTM is straightforward. Running it across 10 testers on 3 features simultaneously needs structure.

Session Assignment

Assign charters in advance, not ad hoc. The test lead owns the charter backlog and assigns sessions based on:

• Tester expertise (who knows payments best?)
• Risk priority (what needs coverage most urgently?)
• Session history (who already explored this area?)

Use a simple spreadsheet or board:

Coverage Tracking

SBTM doesn't give you percentage coverage in the test-case sense. Instead, track:

• Charters completed vs. backlog
• Average T% across sessions (is testing time healthy?)
• Bug density per charter (which areas are risky?)
• Open issues count (what's blocking exploration?)

When a charter hits 90%+ coverage across 2–3 sessions, retire it. Coverage doesn't mean "tested everything" — it means "explored sufficiently given the risk level."

Tooling for SBTM

Most teams start with a spreadsheet. That's fine. The format matters more than the tool.

Lightweight options:

• Notion or Confluence with a session sheet template
• Google Sheets with a master tracker tab
• Plain text files in a Git repo (session sheets as markdown)

Dedicated tools:

• Rapid Reporter — desktop app specifically for SBTM, outputs session sheets
• TestBench CS — supports exploratory sessions with charter tracking
• Xray for Jira — has exploratory session support

The tool trap: teams spend weeks evaluating tools instead of running sessions. Start with a template in whatever you already use. Switch tools only when the current approach creates actual friction.

SBTM in CI/CD Environments

Continuous delivery creates pressure on exploratory testing. Charters need to stay current with the codebase.

Practices that work:

Risk-based charter refresh: Before each sprint, review your charter backlog against the upcoming changes. New features get new charters. Changed features get refreshed charters.

Session time boxing per sprint: Allocate N hours of exploratory sessions per sprint. For a 2-week sprint, 8–16 hours of exploratory testing is a reasonable starting point, adjusted by risk.

Change-triggered charters: When a significant feature ships, auto-generate a draft charter: "Explore [feature] as shipped in release X.Y to discover regressions and integration issues." A tester refines and runs it.

Debrief in standup: In fast-moving teams, a 5-minute session summary in standup replaces the formal debrief. Brief, but keeps coverage visible.

Common SBTM Failures

Sessions without debriefs: Session sheets pile up, nothing feeds back into planning, bugs get lost.

Charters too broad: "Test the API" is not a charter. It produces unfocused sessions and meaningless coverage numbers.

Ignoring TBS metrics: Teams track bug counts and ignore S%. Meanwhile, testers spend half their session waiting for test environments to restart.

Coverage theater: Marking charters "100% complete" to show progress, when actual coverage was shallow. Coverage assessment should be honest — 70% is a valid answer.

No charter backlog grooming: Charters for removed features stay in the backlog. New risk areas never get charters. The backlog becomes noise.

Integrating SBTM with Automated Testing

SBTM and automated testing are complementary, not competitive.

Automated tests cover known scenarios reliably. SBTM covers unknown unknowns — the things you didn't think to automate because you didn't know they'd break.

Use automated test results to inform charter writing:

• New test failures → charter to explore the failure area
• Flaky tests → charter to understand the flakiness conditions
• Coverage gaps in automation → charter to explore manually first, then automate if patterns emerge

After a session finds a bug, ask: should this scenario be automated? If yes, add it to the automation backlog. The exploratory session becomes a source of automation requirements.

Metrics That Matter

At the session level:

• T/B/S breakdown
• Bugs found (and severity)
• Charter coverage estimate
• Issues/blockers encountered

At the program level:

• Total session hours by area
• Bug density per charter area
• Average charter coverage at completion
• Mean T% (should be >65%)
• Issues-to-bugs ratio (high ratio = environment problems)

These metrics help answer the manager's question: "How much have we tested?" without reducing exploration to test case execution counts.

When to Use SBTM

SBTM is high-value when:

• You're testing a new feature with incomplete specs
• You're doing pre-release risk assessment
• You've had unexpected production bugs and want deeper exploration
• You're testing a third-party integration with limited documentation
• Your automated coverage is high but you're still getting production surprises

SBTM adds less value when:

• The system is purely algorithmic with clear inputs/outputs
• Compliance testing requires documented, reproducible scripts
• You're running regression on a stable, well-understood system

For most teams, the answer is both: automated regression for the known paths, SBTM for the unknown risks.

Summary

Session-based test management gives exploratory testing the structure it needs to be credible without turning it into scripted testing. The core: time-boxed sessions, written charters, honest session sheets, and regular debriefs.

The key discipline is the debrief. Without it, sessions produce bugs but no learning. With it, each session makes the next round smarter.

Start small: pick one feature, write three charters, run sessions, debrief. The structure will make itself obvious.