Charter-based testing: session-based test management in practice

"How is the testing going?"

"Good. I found a few things."

"Which areas have you covered?"

"Um. Most of checkout, I think."

That conversation happens in stand-ups every day. The tester did good work. They cannot describe it, so their manager cannot plan around it, and next sprint the same guesswork starts again.

Session-based test management fixes that without turning exploratory work into scripted test cases.

Short version

A session is one timeboxed piece of testing with a written goal, called a charter.
Charters are one or two sentences. They point at an area and a risk, not at exact steps.
Take notes while you test, not from memory afterwards.
Split your time into three buckets: testing, bug work, and setup.
A short debrief with another person turns notes into something the team can use.

What session-based test management is

Exploratory testing means designing and running tests at the same time, using what you just learned to decide what to try next. It is powerful and it is hard to report on.

Session-based test management, usually shortened to SBTM, is a way of organising exploratory testing. Jonathan and James Bach introduced it in 2000, and the idea has barely changed since, because it is simple.

You break testing into sessions. Each session has four parts:

A charter. One or two sentences saying what you will explore and why.
A timebox. An agreed length, usually 45 or 90 minutes, uninterrupted.
Notes. Written during the session, not after.
A debrief. A short conversation, usually five to ten minutes, with a lead or another tester.

That is the whole method. No tooling required. A shared document works.

Writing a charter that works

A charter is not a test case. It does not list steps. It sets a direction and leaves the route to you.

The standard shape is:

Explore (target) With (resources) To discover (information)

Here is the difference a good charter makes.

Bad: "Test checkout."

Too broad. Two testers would do completely different work, and neither could say what was left.

Bad: "Open cart, add item, enter card 4111 1111 1111 1111, click Pay, verify success page."

That is a test case. It removes the thinking, which is the point of exploratory testing.

Good: "Explore the guest checkout flow with discount codes, on Slow 4G throttling, to discover cases where the total shown does not match the amount charged."

Clear target, clear conditions, clear kind of bug to hunt for.

Some charter starting points you can adapt:

Explore a feature with bad input to discover crashes and unclear error messages.
Explore a feature as a different role to discover permission gaps.
Explore a feature interrupted (refresh, back button, second tab) to discover lost work.
Explore a feature on a small screen to discover layout and reachability problems.
Explore a feature after a failed payment or failed upload to discover broken recovery paths.

Aim for a charter you can meaningfully attempt in 90 minutes. If it needs a day, split it.

A real charter

Here is the actual charter used in the session below, on a fictional but ordinary e-commerce staging site.

Charter: Explore guest checkout with promo codes on staging.example.com
         using Slow 4G throttling, to discover cases where the displayed
         total, the order confirmation, and the charged amount disagree.

Area:     Checkout / promotions
Timebox:  90 minutes (normal)
Tester:   Priya
Build:    staging.example.com, build 2026.07.09-rc3
Accounts: guest (no login), promo codes SAVE10, SAVE50, EXPIRED2025

Notice what is missing. There are no steps. Priya decides what to try, and the charter tells her when she has drifted off course.

What the 90 minutes looked like

These are the notes as they were written, lightly cleaned up. Real session notes are messy, and that is fine. They exist to support the debrief, not to be published.

09:02  Setup. Fresh Chrome profile, DevTools open, throttle Slow 4G,
       cache disabled. Cart: 1x Desk Lamp £42.00, 1x Bulb pack £8.50.

09:11  Baseline. Guest checkout, no code. Subtotal £50.50, shipping
       £4.99, total £55.49. Confirmation matches. Fine.

09:19  SAVE10 applied. Total drops to £50.44. Correct (10% of goods,
       shipping unchanged).

09:26  ISSUE 1. Applied SAVE10, then changed quantity of Desk Lamp
       from 1 to 2. Line total updates. Discount does NOT recalculate.
       Still shows -£5.05, should be -£9.25. Repeatable 3/3.

09:41  Tried removing and re-adding the code. Recalculates correctly.
       So the bug is only on quantity change.

09:48  ISSUE 2. Double-clicked "Apply" on SAVE10 during a slow request.
       Code applied twice. Total shows -£10.10. Order placed at the
       discounted price. Confirmation email shows the same. Looks like
       a real money bug, not a display bug. Flagged to Dev channel.

10:05  Bug write-up for issues 1 and 2, with screen recording.

10:22  EXPIRED2025. Error message reads "Error: promo_invalid".
       Raw code shown to the customer. Minor but ugly. Issue 3.

10:29  SAVE50 on a £8.50 basket. Total goes to £0.00 goods, shipping
       still charged. Seems intended, confirmed with product later.

10:33  Went offline mid-payment. Spinner stayed for 2 min, no message.
       Related to a known ticket, CHK-1180. Did not raise a duplicate.

10:35  Stopped. Ran over by 3 minutes.

NOT COVERED: logged-in checkout, saved cards, multiple codes stacked,
mobile Safari, currency other than GBP.

The "not covered" line at the bottom is the part managers value most. It is an honest statement of what is still unknown.

Splitting the time

At the end of a session, break the timebox into three buckets. This is where SBTM stops being a nice idea and becomes reportable.

Bucket	What it covers	This session
Test design and execution	Actually exploring the product	55 minutes
Bug investigation and reporting	Narrowing down and writing up findings	26 minutes
Session setup	Environment, data, accounts, tools	9 minutes

Add a rough coverage split too. Priya recorded 70% on the charter and 30% opportunity testing, which is anything interesting you find off to the side.

Two sessions like this and a pattern appears. If setup is eating 30 minutes every time, the fix is better test data, not more testing hours. If bug reporting eats half of every session, better capture tooling pays for itself quickly. Priya's 26 minutes of write-up dropped to about 10 once the team started reporting from the page with Crosscheck, because the screenshot, console logs, and network requests came along automatically.

The debrief

The debrief is a five to ten minute conversation right after the session. It is not a status meeting and it is not a performance review. Its job is to make the notes useful while they are fresh.

Ask these six questions, in this order:

What did you explore? In one sentence.
What did you find? The headline issues, not every detail.
What got in your way? Broken environment, missing data, slow builds.
What did you not cover? The honest list.
Do you feel this area is risky? Gut feeling from the person who just spent 90 minutes there.
What should the next charter be?

Priya's debrief produced three outputs in eight minutes: two bug tickets raised to high priority, one small ticket for the raw error string, and this next charter.

Charter: Explore promo code recalculation across every cart change
         (quantity, remove item, change shipping method, currency
         switch) to discover further cases where the discount does
         not update.

That is the real value. Each session tells you what the next session should be, and the plan grows from evidence instead of guesswork.

Common mistakes

Sessions that are not protected. If Slack, stand-ups, and desk visits interrupt the 90 minutes, it is not a session. Block the calendar.
Charters that are really test plans. If your charter has more than three sentences, split it.
Writing notes at the end. You will forget the small detail that made a bug reproducible.
Skipping the debrief. Without it, SBTM is just exploratory testing with extra paperwork.
Turning the time split into a target. The numbers exist to reveal friction, not to rate testers. The moment people are judged on them, they stop being true.
Only charging at new features. Old, stable areas with recent code changes nearby are often where the interesting bugs sit.

When to use it, and when not to

Session-based test management fits well when:

The feature is new and the requirements are still moving.
You need to report exploratory coverage to people outside the QA team.
You are testing a risky area before a release and want focused attention.
You are bringing a new tester up to speed. Charters give them a starting point without scripting their work.

It fits badly when:

You need exactly repeatable evidence for an audit or a regulator. Use scripted cases there.
The task is 15 minutes of confirmation on a one-line fix. Overhead beats value.
Nobody will read the debrief. Then you have paperwork, not a method.

Frequently asked questions

How long should a session be?

Most teams use 45 minutes for a short session and 90 for a normal one. Ninety minutes is about the limit of good focus for detailed work. Anything longer and the notes get thin near the end.

How many sessions fit in a working day?

Three or four at most. Sessions are intense, and you still need time for meetings, follow-up, and answering questions. A team planning eight sessions a day has misunderstood what a session is.

Do I still need written test cases?

Often yes, for the paths that must be checked identically every release, and for anything that has to be shown to an auditor. SBTM is not a replacement for that. It is how you cover everything those scripts do not.

Who runs the debrief?

Usually a test lead, but another tester works just as well. The value comes from explaining your session out loud to someone who was not there. If you work alone, write the debrief answers down instead and reread them the next morning.

What tool should I use to track sessions?

Start with a shared document or a spreadsheet with one row per session: date, tester, charter, timebox, issues found, areas not covered. Move to a dedicated tool only after the habit is established and you actually feel the limits of the spreadsheet.