Exploratory and session-based testing

Exploratory testing is testing where designing the test, running it and learning from it happen at the same time. You are investigating rather than following a script.

Session-based test management (SBTM) is the way it is made accountable. Each session gets a charter (one sentence saying what you are investigating), a timebox (usually ninety minutes) and notes that are reviewed afterwards in a short debrief.

It is not the same as ad hoc testing, which has no charter, no timebox and no record.

A detective and a tourist both walk around a city.

The tourist goes where the streets look interesting and comes home with photographs. The detective starts with a question, follows what the evidence suggests, writes down what they find, and comes home with an answer.

Both are walking. Only one is working.

Exploratory testing is the detective. It is often confused with the tourist, which is why some managers think it means clicking around hoping for luck.

The terms you will hear

• Charter. The one-sentence mission for a session. What you are exploring, and what you are looking for.
• Session. One timeboxed, uninterrupted block of exploring, usually ninety minutes.
• Timebox. The fixed duration. It is what makes exploring plannable rather than open-ended.
• Debrief. A short conversation afterwards about what was found and what to do next.
• Ad hoc testing. Unstructured poking with no charter or record. Not the same thing, despite the confusion.
• Heuristic. A rule of thumb for where bugs hide, such as boundaries, interruptions and repeats.

The three things that make it real work

• A charter. One sentence saying what you are investigating. "Explore partial gift-card redemption, focusing on the money maths, to find rounding or double-spend problems."
• A timebox. Usually 90 minutes. Long enough to get somewhere, short enough to stay sharp and to be planned around.
• Notes. What you tried, what you saw, what you did not get to, and any question you could not answer.

That is session-based test management, and the whole method fits on a postcard. Everything else people write about it is detail.

Why it still matters when everything is automated

Automated checks are excellent at the things somebody already thought of. That is their nature: a test exists because a person imagined a case and wrote it down.

Nothing in the suite will notice the thing nobody imagined. The order-of-operations bug. The state you can only reach by going back in the browser. The behaviour that is technically correct and useless to a customer.

Say a suite of 400 automated checks is green, and a customer reports that applying a discount, removing an item, then reapplying the discount doubles it. No automated check covered that sequence because nobody thought of the sequence. Someone exploring for ninety minutes would.

How to run a session

1. Write the charter before you touch anything. One sentence. If it takes three sentences, that is two sessions.
2. Pick the area by risk, not by curiosity. The risk table says where being wrong is expensive. Start there.
3. Set a timer for 90 minutes. Treat it as a meeting with yourself and protect it.
4. Keep a running note as you go. A plain text file is enough. What you tried, what happened, what surprised you.
5. Follow surprises, not the plan. A charter is a starting direction rather than a script. Anything odd is a thread worth pulling.
6. Stop on time. Then write three lines: what you covered, what you found, what you did not reach.
7. Turn findings into cases. Anything worth catching again becomes a permanent case, written as in a case somebody else can run.

A real session, written up

For example, here is one session on the gift-card release at Willow Books, a small online bookshop. The whole write-up took four minutes at the end.

The double-spend across two tabs is the one to notice. No written case would have contained it, the criteria never mentioned it, and it puts a negative balance in a money system. Ninety minutes of structured curiosity found it.

How to show you know it

• A session sheet like the one above. Charter, notes, findings, gaps. It answers the "what did you actually do for two hours" question permanently.
• A defect nobody had a case for. Especially one involving order, timing or two things at once.
• The not-covered line. It shows you know a session is a sample rather than a sweep.
• A question you could not answer. Recorded questions are how missing requirements get found, which is the same instinct as naming your oracle.