Session-Based Testing: A Practical Guide

Exploratory testing gets a bad reputation in some teams: "You can't measure it. You can't repeat it. You can't know what was covered."

Session-based testing (SBT) solves all three. It adds structure to exploratory testing without losing the freedom that makes exploration valuable. Here's how it works and how to apply it immediately.

What Session-Based Testing Is

Session-based testing organizes exploration into time-boxed, chartered sessions. Each session has:

• A charter: what to explore and what questions to answer
• A time box: typically 45-90 minutes of focused testing
• A session report: what was done, what was found, what wasn't covered

The charter gives direction. The time box creates focus. The report creates accountability.

Anatomy of a Testing Session

1. Write the Charter

A charter is a short, focused mission statement. Not a test script — a direction.

Good charter:

Explore: User profile editing
Mission: Discover what happens when users edit profile data 
         under adverse conditions (network failures, 
         concurrent edits, large inputs)
Duration: 60 minutes

Too narrow (scripted testing in disguise):

Verify: That the Save button on the profile page saves changes to the database

Too broad (unfocused):

Explore: The whole app

The charter should be narrow enough to focus effort but broad enough to allow unexpected discoveries.

2. Execute and Take Notes

During the session, take real-time notes. Not formal documentation — working notes.

Session: Profile editing — adverse conditions
Start: 14:00

14:02 — Normal edit: works as expected, changes save
14:08 — Edit with network offline: Save shows spinner, no error after 30s
  → Bug: no timeout handling on profile save
14:15 — Edit with 500-char bio: saves but display truncates without indication
  → Bug: no validation feedback for bio length limit
14:23 — Concurrent edit (two tabs): second save overwrites first silently
  → Bug: no conflict detection on concurrent edits
14:38 — Edit with script tags in name field: saves, renders as text (not injected) ✅
14:45 — Edit then navigate away without saving: no confirmation dialog
  → Potential UX issue: unsaved changes lost silently
14:58 — Large profile image upload: succeeds up to 8MB, fails at 10MB
  → No error message shown when upload fails

3. Write the Session Report

At the end, summarize:

Session Report: Profile editing — adverse conditions
Duration: 60 min (actual)
Coverage: Network failures, large inputs, concurrent editing, script injection

Bugs found: 4
  - No timeout handling on save request
  - No validation feedback for bio length limit  
  - Silent data overwrite on concurrent edits
  - No error shown on oversized image upload

Not covered: Mobile keyboard behavior, accessibility, 
             third-party auth profile sync

Notes: Concurrent editing is high risk — should be prioritized

The SBTM Metrics

Session-Based Test Management (SBTM) tracks four metrics:

These make exploratory testing measurable and comparable across releases.

How Many Sessions for a Feature?

A rough guide based on feature risk:

Pairing Sessions

Some of the best session-based testing is done in pairs — one person explores and one takes notes. The note-taker catches things the explorer missed and asks questions that prompt deeper investigation.

[!TIP] Pair exploratory sessions with developers on their own features before code review. A developer and a QA engineer running a 45-minute session together catches more than either would catch independently — and the developer gains context they can't get from reading their own code.

Getting Started

You can start using session-based testing today with no tooling investment:

1. Write a charter on a sticky note or in a doc
2. Set a timer for 60 minutes
3. Take notes in a plain text file
4. Write a 5-minute summary at the end

After three sessions, you'll have a rhythm. After ten, you'll have a catalog of what your testing has covered and hasn't. After twenty, you'll wonder how you shipped software without this structure.

Session-based testing isn't a process replacement. It's a lightweight framework that makes the intuitive work of exploration traceable and improvable over time.