Session-Based Test Management, Explained

How to trust exploratory time without scripting it

A lead's problem with exploratory testing is real: if there's no script, how do you know what got tested, or plan around it? "I spent the afternoon exploring" isn't something you can put in a release report or repeat next time. So exploratory work gets squeezed out, not because it's low-value, but because it looks unaccountable.

Session-based test management is the answer to that problem. It adds just enough structure to make exploratory testing plannable and reportable — without turning it back into a script and killing the thing that made it useful. Three pieces do the work: a charter that focuses the session, a timebox that bounds it, and notes that record what happened.

That's the whole idea. You don't script the steps; you frame the session. The tester still explores freely inside that frame, but now the work has edges you can point at, report on, and repeat.

The mechanics

Session-based testing has four moving parts, and they're deliberately lightweight.

The charter. A short statement of what this session is for — the area, feature, or risk to explore. It focuses the tester without telling them how to do their job. One session, one charter.

The timebox. A fixed block of time, usually somewhere between half an hour and two hours. The timebox is what makes a session a unit: you can say "three sessions on checkout this week," plan them, and compare them.

The notes. A running record of what the tester tried, what they saw, and the questions that came up — captured as they go, not reconstructed later. Notes are what turn a session from an experience into evidence.

The debrief. A short conversation after the session: what was covered, what was found, what's worth doing next. The debrief is where a lead stays in the loop and where findings get triaged into actions.

None of this is heavy. The point is the lightest structure that makes exploration countable — anything more and you've reinvented the script.

The charter: how to write one

The charter is the piece that does the most work and is easiest to get wrong. Write it too broad — "test the app" — and the session has no focus. Write it too narrow — a list of exact steps — and you've written a script.

A good charter names a target and, ideally, a risk or angle to probe. "Explore the checkout flow, focusing on what happens when the network is slow." "Explore bulk import with malformed spreadsheets." "Explore the permissions screen as a user who was just downgraded." Each gives the tester a clear mission and a hunch to chase, while leaving how they chase it entirely to them.

The best charters come from risk. Ask where a problem would hurt most, or where the product feels least certain, and point sessions there. A charter derived from "this area was just rewritten and nobody's poked at it" is worth ten derived from "we should probably look at this."

Reporting to a lead

Here's where session-based testing pays back the structure. Because each session is a bounded unit with a charter and notes, you can report exploratory work in a way a lead can actually use — without a heavy document.

A useful session report is three lines, not three pages: what area was covered (the charter), what was found (the notable bugs and risks), and what's worth doing next (follow-up sessions, cases to write, areas still untouched). Across a week, those roll up into a real picture — "we've had eyes on checkout and permissions, not yet on reporting" — which is exactly the coverage view a lead never gets from "we did some exploratory testing."

That's the quiet win. Session-based testing doesn't just make exploration more disciplined; it makes it legible to the people who plan releases, which is what earns it a permanent place on the calendar instead of being the first thing cut.

From session to documented case

A session's notes are a means, not the end. The end is what survives after the session: the bugs filed, and — the part teams miss — the findings promoted into documented cases the suite keeps.

When a session surfaces something worth guarding against, it should leave two things behind. A bug report, if there's a defect to fix. And a documented case, if the discovery is worth checking again — a clear precondition, steps, and a specific expected result, so the next regression in that area gets caught. The session found it once; the case makes sure you don't have to find it the hard way twice.

This is where the record matters. A finding worth keeping becomes part of the trusted case record, reviewed like any other case before it's relied on. Tesbo helps draft and manage those cases, with a person approving each promoted finding — it does not run, schedule, or time your sessions. The structure of the session is yours to run; the record of what it produced is what Tesbo keeps.