Most testers we talk to do some exploratory testing every week. Fewer of us do it in a way we can explain afterward. When a manager asks “what did you cover?”, the honest answer is often “a lot of clicking around.” Session-based testing fixes that without turning exploration into a script. Here is a version you can try this week with nothing more than a notes file and a timer.
Where this comes from
Session-based test management was developed by James Bach and Jonathan Bach in the early 2000s. The idea is simple: break exploratory work into short, focused, uninterrupted blocks of time, each with a stated mission, and talk about the results afterward. Elisabeth Hendrickson’s book Explore It! is also a good guide to writing the missions, which she calls charters.
Step 1: Write one charter
A charter is one or two sentences saying what you will explore, what you will use, and what you hope to learn. For example:
- Explore the password reset flow using expired and reused links to find out how the system handles stale tokens.
- Explore the CSV import using files with odd encodings and very long rows to see where validation breaks down.
Keep it narrow enough to finish in one sitting. If you have five ideas, write five charters and pick the riskiest one first.
Step 2: Set a timer and protect the time
Pick a fixed length. Many teams use 60 to 90 minutes. Close chat, silence notifications, and tell people you are heads down. An interrupted session tends to drift back into “clicking around.”
Step 3: Take notes as you go
Use a plain text file or a single page in whatever your team already uses. Capture:
- What you tried, in short lines, so someone could repeat it.
- Bugs you found, with enough detail to file later.
- Issues that are not bugs yet: questions, confusing behavior, things that blocked you.
- New charter ideas that came up but were off mission. Write them down and keep going.
Step 4: Track where the time went
At the end, estimate roughly what share of the session went to three things: actually testing, investigating and writing up bugs, and setup (getting data, configuring environments, reading docs). The Bachs called this a task breakdown. If setup keeps eating half your sessions, that is useful information to bring to your team, because it points to a test environment or test data problem rather than a tester problem.
Step 5: Debrief for 15 minutes
Sit down with a lead, a developer, or another tester. Walk through the charter, what you covered, what you found, what got in the way, and what should come next. This is where the session turns into shared knowledge instead of notes on one person’s laptop. It is also a good coaching moment for newer testers.
Try it once before you change anything
You do not need a new process or a tool rollout. Run one session this week on the part of your product that worries you most, debrief with one person, and see what you learn. If it helps, do two next week.
We would love to hear how it goes, and session-based testing would make a good topic for a future NOSQC conversation. If you work in software quality in Northern Ohio, come join us at nosqc.org/join.