Session-Based Test Management (SBTM)

What Is Session-Based Test Management? #

Session-Based Test Management (SBTM) was developed by Jonathan and James Bach to solve a fundamental problem: how do you manage, measure, and report on exploratory testing?

Scripted testing is easy to manage — you have test cases, you track which ones passed and failed, and you report a pass rate. But exploratory testing has no pre-written test cases. Without a management framework, it is invisible to managers and stakeholders.

SBTM solves this by dividing exploratory testing into sessions — uninterrupted blocks of focused testing time with a defined charter, fixed duration, and documented results.

Session Structure #

The Charter #

Every session starts with a charter — a mission statement that defines what to explore and what risks to investigate. Good charters were covered in Lesson 2.32.

The Time-Box #

Sessions have a fixed duration, typically:

• Short session: 45-60 minutes
• Normal session: 90 minutes (most common)
• Long session: 120 minutes

The time-box creates urgency and focus. The tester knows they have a limited window and must prioritize effectively. Sessions should be uninterrupted — no meetings, no emails, no context switching.

The Session Sheet #

During and after the session, the tester fills out a session sheet documenting what happened:

SESSION SHEET
=============
Charter: Explore the payment flow with expired and declined
         cards to discover error handling and recovery gaps.

Tester: Jane Smith
Date: 2026-03-19
Duration: 90 minutes (planned), 85 minutes (actual)
Environment: Staging, Chrome 120, macOS

TASK BREAKDOWN:
- Session setup: 5 min
- Test design and execution: 65 min
- Bug investigation and reporting: 15 min
- Session notes: 5 min (during)

DATA FILES:
- Screenshots: /screenshots/session-2026-03-19-payment/
- Logs: /logs/payment-errors-session.log

NOTES:
- Expired Visa card: Shows "Card declined" message correctly
- Expired Mastercard: Shows generic "Payment failed" — inconsistent
- Declined card (insufficient funds): No specific error message shown,
  just "Try again" — user doesn't know WHY it failed
- After 3 failed attempts, the order is silently cancelled without
  notifying the user — they discover it only when returning to the app
- Switching payment methods after a decline resets the cart items

BUGS:
1. BUG-1234 (High): Silent order cancellation after 3 payment failures
2. BUG-1235 (Medium): Inconsistent error messages between card types
3. BUG-1236 (Medium): Cart reset when switching payment methods

ISSUES:
- Q: Is the 3-failure limit by design or a bug?
- Q: Should the app suggest alternative payment methods?

% ON CHARTER: 75%
% OFF CHARTER: 25% (investigated cart reset behavior)

AREAS NOT COVERED:
- PayPal and Apple Pay error handling
- Payment timeout scenarios
- Concurrent payment attempts from multiple devices

The Debrief #

After each session, the tester meets briefly (10-15 minutes) with the test lead to review results:

• What was tested?
• What was found?
• What was not covered?
• What should be explored next?

The debrief is critical — it is where knowledge transfers to the team and where the next session’s charter is shaped.

SBTM Metrics #

SBTM provides quantitative metrics for exploratory testing:

Interpreting % On Charter #

• 90-100% on charter: Very focused session. The area was well-understood and the charter was well-scoped.
• 60-80% on charter: Normal. Some time was spent following unexpected leads — this is healthy exploration.
• Below 50% on charter: Either the area has many undiscovered issues (good — but rescope the charter) or the charter was too broad (bad — write a better charter).

SBTM in Practice #

Planning Test Sessions #

A test lead plans sessions based on risk:

SPRINT 12 — EXPLORATORY SESSION PLAN

HIGH PRIORITY (this sprint):
1. Charter: Payment flow error handling (90 min) — Tester: Jane
2. Charter: New search algorithm edge cases (90 min) — Tester: Mike
3. Charter: Mobile responsive layout breakpoints (60 min) — Tester: Ana

MEDIUM PRIORITY (if time permits):
4. Charter: Account settings cross-browser (60 min) — Tester: Mike
5. Charter: Performance under slow network (90 min) — Tester: Jane

DEFERRED:
6. Charter: Third-party integration failures
7. Charter: Accessibility compliance check

Reporting to Stakeholders #

SBTM enables clear reporting:

“This sprint we completed 5 exploratory sessions covering payment, search, and mobile layout. Total testing time: 6.5 hours. Found 8 bugs (2 high, 4 medium, 2 low). Coverage: 3 of 5 planned areas completed. Risk: payment timeout and third-party integrations remain untested.”

This is something you cannot do with unmanaged exploratory testing.

SBTM vs. Other Approaches #

SBTM occupies the sweet spot between the flexibility of exploratory testing and the accountability of scripted testing.

Exercise: Conduct an SBTM Session #

Part 1: Plan 3 Sessions

You are the test lead for a project management application (like Trello or Asana). The team just released a major update to the task board feature. Plan 3 SBTM sessions:

For each session, define:

• Charter (using the Explore/With/To discover format)
• Assigned tester
• Duration (45, 90, or 120 minutes)
• Priority (high, medium, low)
• Risk being investigated

Part 2: Fill Out a Session Sheet

Choose one of your charters and simulate conducting the session. Fill out a complete session sheet including:

• Charter, tester, date, duration
• Notes (at least 10 observations)
• Bugs found (at least 2, with severity)
• Issues/questions (at least 2)
• % on charter
• Areas not covered

Part 3: Conduct a Debrief

Write the debrief summary as if you are presenting to your test lead. Cover:

• Key findings (2-3 sentences)
• Recommended next session charter
• Overall risk assessment for the feature

Charter: Task drag-and-drop between columns
Tester: Jane Smith
Date: 2026-03-19
Duration: 90 min (planned), 88 min (actual)
Environment: Staging, Chrome 120 + Firefox 125

NOTES:
1. Drag single task from "To Do" to "In Progress" — works correctly
2. Drag task to same column (reorder) — smooth, order persists on refresh
3. Drag task to last column "Done" — works, triggers completion animation
4. Rapid drag: move task A to "In Progress", immediately drag task B — second drag sometimes fails silently
5. Multi-select drag (select 3 tasks, drag all): Tasks move but lose their relative order
6. Drag while another user is editing the same task: Task moves but the edit is lost
7. Drag to a column that was just deleted by another user: Task disappears, no error shown
8. Undo after drag: Works once but double-undo does not restore original position
9. Drag 50 tasks at once: UI freezes for 3 seconds, then completes
10. Drag task with long title: Title overflows during drag, obscuring drop targets
11. Drag during network latency (simulated 3G): Task returns to original position without feedback
12. Column scroll during drag: Smooth on Chrome, jumpy on Firefox

BUGS:
1. BUG-501 (Critical): Task disappears when dragged to a simultaneously deleted column. No error message. Task is not in any column and not in "Trash." Data loss.
2. BUG-502 (High): Concurrent edit + drag race condition causes edit data loss. When User A is typing a description and User B drags the task, User A's unsaved changes are discarded.
3. BUG-503 (Medium): Multi-select drag loses relative ordering of selected tasks.
4. BUG-504 (Low): Long task title overflows during drag animation.

ISSUES:
- Q: What is the expected behavior when dragging to a deleted column? Should there be a conflict resolution dialog?
- Q: Is there a maximum number of tasks that can be dragged at once?

% ON CHARTER: 80%
% OFF CHARTER: 20% (investigated undo behavior and network latency)

AREAS NOT COVERED:
- Keyboard-only drag (accessibility)
- Drag between different boards
- Touch-based drag on tablets

Key Takeaways #

• SBTM makes exploratory testing accountable by dividing it into managed sessions with charters, time-boxes, and debriefs
• Session sheets document what was tested, what was found, and what remains untested
• The debrief is the most important meeting — it transfers knowledge and shapes the next session
• Metrics (sessions completed, bugs per session, % on charter) enable reporting to stakeholders
• SBTM occupies the sweet spot between the flexibility of exploration and the accountability of scripted testing
• Plan sessions based on risk — high-risk areas get sessions first
• Session sheets serve as lightweight documentation that makes exploratory testing visible to the entire team