Session-based testing
Session-based testing is a method for managing exploratory testing in which the work is split into uninterrupted, time-boxed sessions, each with a written charter naming what to explore, and each ending in a session report that records what was covered, what was found and how the time was spent. It gives exploratory testing the accountability that scripted testing has by default.
The longer version
A session is a fixed block of time, long enough to get past setup and short enough to report accurately, and it is protected: no meetings, no other tickets. Before it starts, the tester takes a charter, one sentence such as explore the invoice export with unusual currencies, looking for rounding and formatting errors. During the session the tester keeps notes. At the end the tester writes the session report: the charter, the build, the areas touched, the bugs filed, the questions raised, and a rough split of the time between testing, investigating bugs and setting up. A short debrief with the test lead follows, where the report is reviewed and the next charters are chosen.
Session-based testing, also written session-based test management, is the management layer on top of exploratory testing, and the two are often used as if they were the same thing. Exploratory testing is the approach: design and execute tests at the same time, learning as you go. Session-based testing is how a team plans, measures and reports that approach, so that a lead can answer how much testing was done, on what, by whom, and what remains. Without it, exploratory testing is invisible in a test report and impossible to defend when the release decision is questioned.
A session report written after the fact is paperwork. A tester who fills in the form later, from memory, produces a report that says the charter was covered and nothing else, and the debrief becomes a formality. It also fails when the charters are too broad: explore the admin area cannot be covered in one session, so the report cannot say what was left. Charters should be narrow enough to finish, and the time split should be honest, because a session that spent most of its time setting up test data is a finding about the test environment.
Common questions
What is the difference between session-based testing and exploratory testing?
Exploratory testing is the testing approach: the tester designs and runs tests at the same time, guided by what the product reveals. Session-based testing is the method for managing it: time-boxed sessions, written charters, session reports and debriefs. A team can do exploratory testing without sessions; session-based testing is exploratory testing made accountable.
What goes in a session report?
The charter, the tester, the build and environment, the start time and duration, the areas actually covered, the bugs filed with their identifiers, the issues that blocked testing, the questions that came up, and a rough split of time between testing, bug investigation and setup. The report is written at the end of the session, not later.
How long should a test session be?
Long enough to get past setup and into real investigation, and short enough to stay focused and be reported accurately, with the length fixed before the session starts and the charter sized to fit it. A session that needs a whole day has a charter that should have been split.
What is a debrief in session-based testing?
The debrief is a short conversation between the tester and the test lead at the end of each session, held over the session report. The lead checks that the charter was covered, asks about the bugs and the questions raised, judges whether the time split was reasonable, and decides what the next charter should be. The debrief is the mechanism that turns individual sessions into a managed test effort rather than a series of solo explorations.
What metrics does session-based testing produce?
The time split per session between testing, investigating bugs and setup, which shows how much of the effort reached the product; the sessions completed per charter and per area, which shows coverage; and the bugs and questions raised per session. Read together over a cycle they tell a lead which areas have had real attention, where the environment is eating the time, and which charters still need a session.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.