How do you report exploratory testing progress when there is no test-case count?

### The problem A scripted approach reports itself: 412 cases, 380 run, 366 passed. It is a badly flawed measure of anything that matters, but it is legible, and legibility is why leads reach for it. Exploratory work has no such number, and the first instinct — reporting hours, or defect counts — produces something worse. Hours say nothing about what was looked at. Defect counts reward the areas that happen to be broken and punish a tester who spends a week confirming that a risky area is solid. The technique's answer is to report the unit it created: the session. ### The four things worth reporting **Sessions completed against sessions planned.** "Nine of fourteen planned sessions run against checkout this week." This is a statement about effort delivered, and it is honest as long as nobody dresses it up as a statement about quality. It has the useful property of exposing its own shortfall: if only nine of fourteen ran, the missing five have a reason, and the reason is usually in the obstacles. **An area-by-session grid.** List the product areas the team reports in — down one side, sessions across. What the grid shows best is emptiness. In a rebuilt bookstore checkout with 23 named areas, if 6 of them have had no session at all, the grid says so at a glance, and no defect count or percentage can convey that. This is the closest thing exploratory work has to a coverage claim, and its honesty comes from being explicitly about *attention applied*, not about anything measured inside the product. **The on-charter share.** Aggregated across sessions, this says how much of the week's testing went to the missions the team agreed. A high share means the plan matched reality. A share that has fallen to 55% is not misbehaviour; it usually means the charters were written against the wrong model of the product and the testers are following the real risk. Either way it is a prompt for a conversation, not a rebuke. **The live obstacles.** The issues that are currently making sessions expensive, and who owns each. This is the part of the report a lead can act on this week. ### A worked example An online bookstore is releasing a rebuilt checkout. The report reads: eleven sessions planned this week, eight run; three lost because the payment sandbox was unavailable for a day and a half. Areas: gift-card redemption, address validation and split shipments have each had sessions; currency and locale handling, and the confirmation email, have had none. On-charter share about 70%, dragged down by a clock-difference finding in gift-card expiry that pulled two sessions sideways into time handling. Obstacles: no way to seed gift cards with past expiry dates, and no authoritative answer on which service owns time. One incidental observation is parked for a session of its own — the confirmation page is missing its stated budget of 2.4 seconds at the 92nd percentile. Every line of that is checkable and none of it claims more than it knows. A reader learns what was looked at, what was not, why three sessions vanished, and what to fix so next week goes better. ### What not to report, and what to say when pressed Do not report defect counts as an achievement, because it makes the tester's output a function of how broken the code happens to be. Do not report a percentage that implies completeness — "checkout testing is 68% done" — because the denominator does not exist and inventing one converts a good report into a false one. Do not let "all planned sessions completed" be read as "this area is safe"; sessions are effort, and the judgement about whether an area has had enough belongs to a person looking at the risk, not to a counter reaching a target. When a stakeholder insists on one number anyway, the productive move is to give them the sessions-completed figure with the areas grid attached and to state its limit out loud, in one sentence, every time it is reported: this says where we spent attention, not how much risk is left. A number that travels with its own caveat survives; a number that does not gets quoted back to you in a release meeting as a guarantee.