Exploratory testing has a visibility problem. The work is real: skilled, sustained, often the most valuable testing a team does. But without a record, it is invisible. Nobody outside the session knows what was tested, what was found, or what was not covered.

The session report solves this. Not as bureaucracy, but as communication.

What a session report contains

A session report is a structured summary of what happened in one session. It does not need to be long. It needs to be honest and complete.

The standard components:

Charter: the mission that defined the session. Copied from the charter you wrote before starting. If you deviated from the charter significantly, note that here.

Session ID: a short identifier linking this report to the session in your tracking system. Date and initials work. The goal is traceability, not elegance.

Duration: start time and total length. This is the denominator for your TBS estimate.

TBS breakdown: how much of the session time went to Test Design and Execution (T), Bug Investigation and Reporting (B), and Session Setup (S). A rough percentage estimate at the end of the session is sufficient. A healthy session spends most of its time on T.

Bugs: every defect found in the session. Each one should include enough context that a developer can reproduce and investigate it without asking you to explain it: steps, expected behaviour, actual behaviour, environment, and any reproduction notes.

Issues: questions or blockers from the session that are not product defects. A missing test environment. A requirement that turned out to be ambiguous. A decision nobody seems to own. Issues go to whoever can resolve them, not into the bug tracker.

Notes: everything else worth capturing: test ideas you did not get to, areas that need a follow-up session, patterns you noticed but could not confirm, risks that did not rise to the level of a bug.

The TBS ratio

TBS exists to give you calibration data, not accountability data.

If bug investigation (B) dominated your session, you found something significant. Log the bugs thoroughly and consider creating a follow-up charter focused on that area. Do not feel pressure to force your way back to T; following an important find is the right thing to do.

If session setup (S) dominated your session, your infrastructure has a friction problem. Time spent configuring environments and locating documentation is time not spent testing. The fix might be better documentation, a dedicated test environment, or a setup script. Name it in the Issues section.

If your T percentage is consistently low across sessions, that is a signal worth raising with the team.

The debrief

A session report written in isolation is less useful than one that comes with a brief conversation.

The debrief does not need to be formal. Five minutes after a session, walk a developer or test lead through what you found. Bugs get context. Issues get owners. Notes become shared knowledge rather than private memory.

The people most worth debriefing are the ones who will act on what you found. A developer who hears about a bug in conversation will understand its context better than one who reads a ticket filed three hours later. A product manager who hears about an ambiguous requirement will resolve it faster than one who sees an issue logged in Jira.

The debrief is also where your notes get used. The test ideas you did not have time for, the follow-up areas you flagged: these become the input for the next planning conversation.

Aggregate view across sessions

Individual session reports are useful to the tester. Aggregate reporting is useful to everyone else.

A lightweight coverage dashboard tracks all the charters for a feature: what was planned, what was covered, what was found, and what is still open. It replaces the need for status meetings. Anyone on the team can look at the dashboard and know where things stands.

Useful columns for each charter:

  • Charter description
  • Priority (which areas are highest risk)
  • Status (planned / in progress / done)
  • Coverage quality (your own assessment: thorough, partial, shallow)
  • Bugs found
  • Issues raised

The coverage quality column is the most important and the most honest. It is your own assessment of how well you covered the charter, not a binary pass/fail. A charter you ran for 30 minutes before a release might be "shallow" and you should say so. That is not a failure; it is useful information for whoever is making the ship/hold decision.

Making the work legible

The purpose of all of this is legibility: session reports, TBS, debrief, dashboard. The goal is to make exploratory testing visible to the people who need to see it.

A product manager asking "what have we tested?" should be able to get a real answer. A test lead trying to estimate how much coverage remains should have data. A developer looking for context on a bug should find it in the session report.

Exploratory testing produces that visibility when the work is recorded. Without records, the reputation problem remains: it looks like undirected clicking, because nobody outside the session knows any different.

The record is not the overhead. The record is the deliverable.

Who I follow

  • James Bach & Jonathan Bach Satisfice.com: the original SBTM papers define the session report format and the debrief process in detail
  • Michael Bolton DevelopSense.com: writing on what makes test reporting useful versus ceremonial
  • Elisabeth Hendrickson Explore It! (Pragmatic Bookshelf): covers debrief and coverage assessment in the context of exploratory charters
  • Katrina Clokie katrinatester.blogspot.com: practical writing on making testing visible in agile teams