Session-Based Test Management (SBTM)

What problem SBTM solves

Unmanaged exploratory testing is hard to plan and hard to report. A manager asking “how much of checkout have we tested?” gets an answer like “quite a lot”, and a tester who spent the morning fighting a broken environment looks as productive as one who spent it testing. SBTM keeps the freedom of exploration but puts a unit of work around it — the session — so that effort can be planned, recorded and compared.

The ISTQB Foundation Level syllabus (CTFL v4.0) describes the same idea in general terms: exploratory testing conducted within a defined time-box, guided by a test charter that contains test objectives. SBTM, published in 2000, is an earlier and more detailed method built on the same idea.

• Charter — the mission of one session: what to explore, with what, to find what.
• Session — an uninterrupted, time-boxed period of testing against one charter.
• Session sheet — the structured record of the session: charter, tester, times, notes, bugs, issues, data files and the time breakdown.
• Debrief — a short conversation between the tester and a lead soon after the session.
• Metrics — counts and time proportions aggregated from session sheets and used to steer the next sessions.

Writing charters

A charter is one or two sentences that tell the tester where to go and why, without telling them what to click. A widely used template from Elisabeth Hendrickson’s Explore It! has three parts: Explore <target> with <resources> to discover <information>. The target is an area, feature or risk; the resources are data, tools, configurations or techniques; the information is the kind of problem or knowledge you are after.

Good charters come from risks, requirements, recent changes, clusters of past bugs, questions raised in debriefs and gaps in automated coverage. Write more charters than you can run, rank them by risk and run the top of the list. For example, for the checkout of a fictional online store that sells in SAR:

• Too broad: “Explore checkout.” — no guidance, and it cannot be finished in one session.
• Too narrow: “Enter coupon SAVE10 and verify the total is 90.00.” — that is a test case, not a charter.
• About right: one area, one kind of risk, finishable in one session, with room for the tester to choose tactics.

C-01  Explore the order total with discounts, coupons and 15% VAT
      to discover rounding and calculation errors.
C-02  Explore payment with declined, timed-out and 3-D Secure sandbox cards
      to discover how failures are handled and whether orders are duplicated.
C-03  Explore checkout interrupted at each step (Back, refresh, closed tab,
      lost network) to discover lost or inconsistent orders.
C-04  Explore the cart in two tabs and on two devices for the same user
      to discover state conflicts between sessions.
C-05  Explore the Saudi National Address form with Arabic, English and mixed
      input to discover validation and display problems.
C-06  Explore the confirmation email, invoice PDF and order history
      to discover inconsistencies with what checkout showed.

Try it: AI Risk-Based Test Generator Try it: Test Scenario Generator

Running a time-boxed session

A session is uninterrupted: no meetings, chat or email for its duration. In the original description a normal session lasts about ninety minutes, give or take; one closer to forty-five minutes counts as short and one closer to two hours as long, and sessions are not timed strictly. Uninterrupted time matters because exploration builds a mental model of the product that is lost every time you switch context.

Stay on charter, but not rigidly. If you find something important outside the charter, note it and either follow it briefly — that time is “opportunity” work and is recorded as such — or propose a new charter for it. If the charter turns out to be wrong or blocked, end the session early and say so on the sheet; that is useful information, not a failure.

• Before: read the charter, prepare test data and accounts, check the build and environment, open a notes file and start a screen recording if your team uses them.
• During: test, take timestamped notes, capture evidence for anything suspicious, keep a list of questions and new charter ideas.
• At the end: stop at the time box, spend a few minutes tidying the notes, estimate the time breakdown, and draft the bug reports.

Try it: Test Data Factory

The session sheet

The session sheet is a plain-text or form record that makes a session reportable. In the original method the sheets used fixed headings so that a small tool could parse and aggregate them; today any tracker, spreadsheet or wiki template works, as long as every sheet uses the same fields. The example below is illustrative and follows the spirit of the original headings.

• Bugs are problems in the product. Issues are anything that threatened the session or needs a decision — blocked environments, missing data, open questions.
• Notes serve the tester and the debrief; they are not a script, but they must be enough to reconstruct what was covered.
• Keep data files (recordings, captured traffic, logs) next to the sheet so that bug reports can reference them.

CHARTER
  C-03  Explore checkout interrupted at each step (Back, refresh, closed tab,
        lost network) to discover lost or inconsistent orders.

AREAS     Checkout | Payment | Order history | Web, Chrome 129, Windows 11
BUILD     5.2.0 (staging)
START     2026-09-28 09:30
TESTER    Omar K.
DURATION  normal (90 min)

TASK BREAKDOWN
  Test design and execution         60%
  Bug investigation and reporting   25%
  Session setup                     15%
  Charter vs opportunity            85 / 15

DATA FILES
  c03-notes.txt   c03-recording.mp4   c03-checkout.har

TEST NOTES
  09:41  Refresh on shipping step keeps the address. OK.
  09:52  Network off right after "Pay": spinner never ends, no retry message.
  10:05  Back after payment success returns to the pay step; "Pay" enabled.
  10:11  Paid again from that page -> second order ORD-7781 created.  BUG
  10:30  Opportunity: order history lists ORD-7781 twice after refresh.

BUGS
  BUG-2214  Back after successful payment allows a second charge
  BUG-2215  No error or retry when the network drops after "Pay"

ISSUES
  - Payment sandbox timed out 3 times (about 10 min lost to setup).
  - Is paying again after Back ever valid? Asked the product owner.

Tracking where the time goes

SBTM asks the tester to estimate how the session time split between three kinds of work: test design and execution (looking for problems), bug investigation and reporting (reproducing, isolating and writing up what was found), and session setup (preparing environments, data and tools, and dealing with obstacles). The sheet also records how much time went to the charter versus opportunities found along the way. In the original method the three proportions describe the on-charter part of the session and the opportunity share is reported beside them, so on-charter testing time is roughly the session length × the charter share × the test share: for the C-03 sheet, 90 min × 85% × 60% ≈ 46 min, which the report below shows as 0.8 h. Rough percentages are enough; the goal is a trend across many sessions, not a timesheet.

The split is diagnostic. Only the first category directly adds test coverage, so when it shrinks something is eating the testing time — and the other two categories tell you what.

• Setup time high across many sessions — unstable environments, slow deployments or missing test data; fix the infrastructure, not the testers.
• Bug investigation time high — the area is buggy (useful input for risk) or bugs are hard to reproduce, which points to a need for better logs and diagnostics.
• Opportunity share high — the charters may be badly aimed, or the product keeps surprising testers; review the charter list.
• Test time high with few bugs over several sessions — the area may be solid; consider moving sessions to riskier areas.

Debriefing a session

The debrief is a short conversation between the tester and a test lead or peer soon after the session, while memory is fresh. It turns one person’s exploration into shared knowledge; it is where the lead coaches, checks the quality of the notes and bug reports, and decides what to test next.

A debrief ends with concrete outcomes: the session sheet is accepted or corrected, bugs are filed, questions get an owner and the charter list is updated. In the checkout example, the debrief would add a charter on repeated payment requests and send the double-charge bug straight to triage.

• What happened? What did you cover, and what did you not get to?
• What did you find — bugs, issues, questions? Are the bug reports ready to file?
• What got in the way — environment, data, access, unclear requirements?
• What should happen next — new charters, follow-ups, areas that need more sessions?
• How do you judge the area now — risky, solid or still unknown?

Reporting from session sheets

Because every session has a charter, an area and a time breakdown, sheets can be aggregated: sessions per area, time spent actually testing, bugs and issues per area, and charters still open. That answers the manager’s question honestly — for example, “checkout had six sessions this sprint and about five and a half hours of on-charter testing; payment failure handling still has two open charters and one critical bug”.

Compare coverage with risk: a high-risk area with few sessions is a gap, and a low-risk area that consumed many sessions may be over-tested. Treat the numbers as prompts for conversation. Session and bug counts are poor productivity measures for individuals, and using them that way encourages short, shallow sessions and trivial bug reports; choosing and using test metrics in general is covered in the test metrics guide.

Area               Sessions  On-charter testing  Bugs  Issues  Open charters
Order total            2          2.1 h            1      0          0
Payment failures       2          1.4 h            3      2          2
Interrupted flow       1          0.8 h            2      2          1
Address (Arabic/RTL)   1          1.2 h            1      0          0

Introducing SBTM in a team

• Start small — one feature, a list of five to ten charters, one or two sessions a day and a debrief after each.
• Use a template you already have — a tracker ticket type, a wiki page or a shared document per session; consistent fields matter more than the tool.
• Tie charters to the workflow — draft charters during refinement for each risky story and run them once the story reaches a test environment.
• Link sessions to bugs and regression — each bug links back to its session, and each regression case that comes out of a session gets an owner and, where it has a stable expected result, an automated check in the CI pipeline.
• Pair up — a tester with a developer or product owner at one screen spreads product knowledge and finds different bugs.
• Review the charter list every sprint — close covered charters and add new ones from debriefs, incidents and changes.

Try it: AI Bug Description Generator Try it: AI Bug Title Generator Try it: AI Regression Test Generator

Common mistakes with SBTM

• Sessions that are not really uninterrupted — a 90-minute session with meetings and chat inside it is several short, shallow ones.
• Skipping debriefs when the schedule is tight, which removes the coaching and learning SBTM depends on.
• Filling in the session sheet from memory the next day.
• Charters written as test cases, which turns exploration back into scripted testing with extra paperwork.
• Not ending a blocked session early — the sheet should show the obstacle, not an hour of “setup”.
• Using session and bug counts to rank testers.
• Findings that stay in the notes — bugs not filed, questions not asked, regression ideas never turned into cases.

Frequently asked questions

References

• Session-Based Test Management (Jonathan Bach)Satisfice, Inc. · 2000The original description of session-based test management: chartered, time-boxed exploratory sessions, session sheets and debriefs.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Explore It! Reduce Risk and Increase Confidence with Exploratory Testing (Elisabeth Hendrickson)The Pragmatic Bookshelf · 2013The discipline of exploratory testing: charters, heuristics for varying inputs and states, and how it complements scripted tests.
• Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001Practical lessons on bug reporting, test design, automation and managing testing — the context-driven school.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.