What is Session Based Testing? A practical guide for modern teams

Traditional testing starts with paperwork. Someone writes test cases up front, each with steps, inputs and an expected result, often before the feature is finished. Later, a tester works through them one by one, marks each as passed or failed, and logs bugs along the way. It looks thorough on paper. In practice, the cases describe the product someone imagined weeks ago — and the tester's attention goes into following the script, not into how the end user would love the product to behave.

Session Based Testing flips the order. There's no script to write first. A session sets a scope instead: one application, the features in play, and optional session instructions that point at a known risk. It also sets a time box. Whoever participates in the session designs and runs tests at the same time, following what they would expect as an end user. Every bug, question or improvement is logged as a finding the moment it's spotted. The effort goes into exploring, not documenting — and the record builds itself as they go.

That shift changes who can take part. A session needs no test-case library to maintain, so the developer who just built a change can run one. So can a product owner checking it does what they asked, or a business analyst walking a flow. Quality becomes something the whole team does, not a phase handed to one role.

Planning gets simpler too: just pick the features to test, a time slot and you're ready to send out the announcement! Reporting is generally automated and stops being a chore.

What Session Based Testing actually is

Session Based Testing (SBT) wraps exploratory testing in three things: a stated scope, a hard time box, and a reviewable record of what was found. Strip away the terminology and you have a session: a bounded block of testing time against one application, with a start and an end. Add whatever the tester logs during it, and that's SBT.

Someone coordinating the testing sets the scope before the session opens. Often that's a Test Manager or Test Lead. They choose the application and the features in play. They can provide session instructions to flag a known risk, a recent change, or a user flow worth hammering on. That's called "the charter". It's guidance, not a script. The person testing still decides, moment to moment, what to poke at.

From there, the tester explores. When they hit something worth flagging, they log a finding on the spot. A finding is a bug, a question, or an improvement. Bugs get a severity. Every finding gets enough detail for someone else to act on it later without a re-explanation. Once the session closes, those findings sit in a shared backlog, ready for triage by the right person — not in a personal notebook. Bugs go to the Test Lead, questions to the Product Owner, etc.

James and Jonathan Bach first wrote the method up as Session-Based Test Management. It organises testing around activity rather than documentation artefacts. Two decades on, the core idea still holds: keep the freedom of exploration, lose the disappearing act.

"Isn't this just exploratory testing with extra steps?"

This is the most common pushback. It's worth taking seriously, because it's half right. SBT doesn't replace exploratory testing. It's a way of running it.

The Agile Alliance's definition of exploratory testing describes an approach that interleaves test design, execution, and learning. It leans on the tester's skill and judgement rather than a fixed script. SBT changes none of that. A tester in a session still explores, follows their instincts, and decides in real time what to test next.

The research backs the exploring part. In a controlled experiment, exploratory testing found as many defects as predesigned test cases — for about a sixth of the effort, and with half the false reports. A later study that included practitioners found it caught significantly more. But the same researchers named its weak spots: logging what was tested, and managing and controlling the work. That's the gap session-based test management is designed to fill.

What SBT adds is scaffolding around that skill:

• A scope, so the exploration has a direction.
• A time box, so "still looking into it" has an end.
• A record of findings, so the insight outlives the session.

Without that scaffolding, exploratory testing is a mindset in one person's head. With it, it's a practice a team can plan, staff, and point to.

If your team already explores well, SBT won't feel like a new skill. It'll feel like the good work you already do, finally visible to everyone else.

How a session actually runs

On paper, "a scope, a time box and a record" can sound abstract. In practice, it's a handful of steps most teams already half-do:

• Scope it. A Test Manager, or whoever is coordinating the testing, schedules a session against an application. They pick the features in play. They add session instructions if there's something specific to focus on. "The new discount code path has been completely refactored by the devs" beats "test checkout."
• Send out announcements. Send the participants the session instructions and start/end times, so they know it's on.
• Kick-off. At its start time, the clock now runs toward the preferred end time. Some teams do a 5-minute team meeting as a last-minute sync-up.
• Explore and capture. A team member (could even be a project sponsor!) works the application and logs findings the moment something's worth flagging.
• Review and triage. Every finding logged gets triaged and if needed converted to a backlog item on the project work tracker.

Invited to a session and not sure what's expected? Here's a step-by-step guide for participants.

A real-world example

Picture a session on a new checkout flow. One afternoon might produce these findings:

• Finding 1 — Bug, Sev 2. Feature: Discount codes. Steps: apply a valid code on a mobile viewport, submit. Expected: the total updates and a confirmation shows. Actual: the field clears silently, with no error and no discount applied.
• Finding 2 — Bug, Sev 3. Feature: Form validation. Steps: enter an invalid postcode, correct it, resubmit. Expected: the error clears once the field is valid. Actual: the original error message stays on screen.
• Finding 3 — Improvement. Feature: Empty states. The "no saved addresses" state offers no next action. A one-line prompt to add an address would remove the dead end.

Nothing here needed a test script. The tester followed their own judgement about where checkout felt fragile. And nothing here is abstract either — three findings, each tied to a feature, each ready for someone to act on.

Capturing findings is also where exploring usually stalls. Switching to a bug tracker, filling in a form and finding your way back costs more than the minutes it takes — it breaks the train of thought that found the bug. With Session Based Testing, findings are logged from an in-browser side panel next to the page under test, with lots of metadata attached automatically. See how the browser extension keeps capture in the flow.

"How do we know we've actually covered anything?"

This is the objection that matters most to whoever coordinates the testing, and it's fair. From the outside, freeform exploration can look like wandering.

SBT's answer isn't a coverage percentage. It's the charter and the record. The scope set before the session states what was meant to be covered. The findings, each attributed to a feature, show what was actually touched. A Test Lead reviewing a series of sessions can see which features got real attention and which didn't. No tool calculated coverage. The record simply makes the gap visible.

Ministry of Testing's glossary on session-based test management frames it the same way. The value isn't only in doing exploratory testing. It's in producing something a manager or teammate can understand afterwards. So you may not know you've covered everything. But you know exactly what you did cover — a far more honest and useful thing to know.

Ad-hoc exploratory testing vs Session Based Testing

These aren't different activities. The tester's skill and judgement are the same in both. What differs is what survives once the browser tab closes:

Neither column is "wrong." Plenty of good bugs get found in the left column. The difference shows up downstream, when someone who wasn't in the room needs to know what was tested and found.

Where teams get this wrong early on

Teams new to SBT tend to make two mistakes. Both come from overcorrecting, in opposite directions.

• Over-scoping the charter. Session Instructions that read like a full test script defeat the point. The tester stops exploring and starts ticking off a checklist. That's scripted testing in a session's clothes. Point the scope at a feature and a risk, not at every click.
• Under-specifying the finding. A bug logged as "checkout looks broken", with no severity and no steps, is barely better than no record at all. The value of capturing during a session is that the detail gets written down while it's fresh. Skipping it saves no real time and loses the point of the method.

Both are easy to fix once named. Keep charters focused on features and risks, not steps. Keep findings specific enough that someone who wasn't in the room can act on them.

Why this matters more as delivery gets faster

The case for SBT gets stronger on teams that ship quickly. That includes teams where an agentic coding agent turns a spec into a merged PR in an afternoon. Faster code doesn't make loose exploratory work acceptable. If anything, the record matters more. There's less calendar time between a session and the next release for a half-remembered finding to resurface.

A session scales down to that pace without losing its shape. Charter a 30-minute session against the feature an agent just touched. Let someone on the team explore it. The findings land in triage as fast as the code landed in the branch, meaning testing effort (even ad-hoc, by anyone in the team) can keep up with delivery pace.

Getting started without overhauling how your team works

None of this needs a process rollout.

Run a single session against one application, with one feature in scope and a clear instruction. Schedule it, let someone explore, and look at the findings list when it closes. That's the whole trial.

Is the record more useful than the tester's memory would have been a week later? Then you've seen the point of the method. The rest is doing it again, deliberately, across more of the product.

If your sessions run fine but the findings scatter into chat threads, capture is the gap. With Session Based Testing, testers log findings from a side panel while they explore, with the page URL and much more metadata attached automatically. The record exists even before the session ends, so triaging might even be done within the session. Sign up now for the "Allways Free" subscription (no credit card needed).