Session-Based Test Management

Session-Based Test Management (SBTM) is the formal practice that makes exploratory testing plannable, reportable, and scalable. It was developed by Jonathan and James Bach in the early 2000s as a response to the question every QA manager asks: "How do I track exploratory work the way I track scripted work?" The answer is to bundle exploration into time-boxed, charter-driven sessions and treat each session as a deliverable artefact.

The five elements of a session

A standard SBTM session has five parts:

1. Charter. A one-sentence mission for the session. "Explore the password reset flow on mobile devices to find usability and edge-case issues." A good charter is specific enough to focus the session but loose enough to allow real exploration.

2. Time box. Usually 60 or 90 minutes. Bach's original framing offered a useful three-tier system: short (60 min), normal (90 min), long (120 min). Anything longer than 2 hours drifts.

3. Tester(s). One or two people. A pair of testers ("paired exploration") often outperforms two solo sessions because the discussion surfaces ideas neither would have had alone.

4. Notes. Captured continuously during the session. Not a scripted record, but a running log of what was tested, what was found, and what surfaced for follow-up.

5. Debrief. A 10–15 minute conversation with another tester, lead, or developer at the end of the session, walking through findings.

What goes in the notes

Bach proposed a simple breakdown of session time:

• TBS (test design and execution) — the time spent actually testing.
• Bug investigation — time spent isolating something interesting.
• Setup — time spent preparing data, environments, or tools.

A typical session log might end up:

Charter: Explore checkout flow under intermittent network conditions.

Tester: Avani

Date/duration: 2024-05-02, 90 minutes

TBS: 55%, Bug investigation: 30%, Setup: 15%

Areas tested: Cart → Address → Payment → Confirmation

Bugs found: BUG-1421 (timeout error on Address step when offline mid-form), BUG-1422 (Confirmation page double-submits if user clicks back)

Concerns / follow-ups: Couldn't test Apple Pay (no test account); checkout timer behavior unclear; need to revisit shipping rules for international addresses

Notes: Tested with Network throttling at "Slow 3G" in Chrome dev tools and with airplane mode toggled at various stages. Confirmation page state seems fragile; recommend a deeper session focused there.

This artefact takes 5 minutes to write and gives a stakeholder a complete picture of the session.

Why time-boxing matters

Without a time box, exploratory testing has two failure modes: it runs too short (the tester gives up or gets distracted) or runs too long (the session loses focus and becomes random clicking). The time box creates urgency without panic. It gives the tester permission to defer interesting tangents into "concerns / follow-ups" instead of chasing every rabbit hole.

A team that runs four 90-minute sessions per day is doing far more disciplined exploratory testing than a team where one tester "does some exploratory work" for an unspecified afternoon.

The debrief is non-negotiable

The single biggest difference between SBTM done well and SBTM done badly is the debrief. A 15-minute conversation between tester and lead does five things:

1. Validates findings. Were the bugs real? Did they get logged correctly?
2. Surfaces tacit knowledge. "I noticed the page felt slow on the second load" never appears in the written log but might be critical.
3. Generates new charters. "We should run a follow-up session on…" is a common debrief outcome.
4. Improves the tester. A skilled lead can teach more in a 15-minute debrief than in any classroom session.
5. Demonstrates value. The lead leaves with a clear sense of what was found and what is still at risk — useful for the next stakeholder conversation.

Charters that work

A bad charter: "Test the checkout." A good charter: "Explore the cart-to-payment flow on mobile Safari with discount codes applied, looking for state-management issues."

The good charter has:

• Scope — what part of the system.
• Conditions — under what context (mobile Safari, with discount codes).
• Goal — what to look for (state-management issues).

Specific charters keep sessions focused. Vague charters produce vague sessions.

Tools for SBTM

Most teams use lightweight tools — a shared doc, a Notion database, a spreadsheet. A few purpose-built tools exist (BBST, Sense, Rapid Reporter, Test Explorer for Azure DevOps), but the format is simple enough that a markdown file works fine.

What you should walk away with

SBTM gives exploratory testing structure without strangling it. Charter, time-box, test, note, debrief — five steps that turn unstructured exploration into a measurable, scalable practice. The next lesson dives into the heuristics testers use to design those charters and find bugs faster.