What happens in a session debrief, and who takes part in it?
answer
- A short conversation, not a filing step
- One listener whose job is to push back
- Past, results, obstacles, outlook, feelings
- Fresh memory is the whole point
- Produces the next area's outlook
basics
~20 sA debrief is a short conversation, usually a few minutes, in which the tester walks one other person through the session sheet: what happened, what was found, what got in the way, and what the area needs next.
solid answer
~50 sThe debrief happens soon after the block ends, between the tester and one other person — the test lead, or simply another tester. A widely used checklist for it is summarised by the mnemonic **PROOF**: what **p**ast work actually happened, the **r**esults against the charter, the **o**bstacles that got in the way, the **o**utlook for the area, and how the tester **f**elt about the session. The listener's job is to challenge, not to receive: is the coverage claim supported by the notes, is that obstacle really an obstacle, does the tester's unease about an area deserve another session? The outputs are a sheet that has been accepted or corrected, obstacles routed to whoever can clear them, and an informed view of what this area needs next. Debriefs also do the quiet work of coaching — it is where a lead hears how a tester reasons, which no written sheet conveys.
go deeper
Know that a session ends in a short conversation with someone else, not just a filed document, and that it covers what happened, what was found, what got in the way and what the area needs next.
Be able to walk through the debrief structure and say what each step produces. The distinguishing detail is that the listener challenges the sheet rather than merely receiving it, and that obstacles get routed to someone who can clear them.
Show that you can run one: pushing on a coverage claim the notes do not support, spotting an obstacle that is really a product defect, and turning a tester's vague unease into the next charter rather than dismissing it.
Own the cost question. Debriefs are the first thing dropped under delivery pressure, so be ready to say what you would degrade to — peer debriefs, sampled debriefs, sheet review — and what signal you lose at each step.
### Why the technique insists on it Everything else in session-based testing is an artefact; the debrief is the only part that is a conversation, and it is the part teams drop first. That is a mistake, because the debrief is what makes the sheet trustworthy. A sheet nobody reads becomes a form. A sheet somebody asks questions about stays honest, because the tester writes it knowing it will be discussed. ### Who takes part Two people is the norm: the tester who ran the session and one other — the test lead, a peer tester, or whoever owns the area. It should be someone who can push back. Debriefing to yourself is not a debrief, and debriefing to a room is a status meeting, which is a different animal with a different purpose. Where a team runs many sessions, a lead may debrief several back to back; where the team is small and mutually skilled, peers debrief each other and the lead only reads the sheets. ### The shape of the conversation A useful checklist is captured by the mnemonic **PROOF**. - **Past** — what actually happened in the block, as opposed to what the charter said would happen. The gap between the two is often the most informative sentence in the whole session. - **Results** — what was found, what was covered, what was deliberately not covered. - **Obstacles** — what got in the way of testing: data that could not be created, an environment that was down, a question nobody could answer. - **Outlook** — what this area needs next. Is it done for now, does it need three more sessions, has something been found that changes the risk picture? - **Feelings** — how the tester feels about the area. This is not sentimentality. A tester who says "the notes look fine but I don't trust this area" is reporting a real signal from a mental model that has not yet been articulated, and it is frequently right. A debrief is short — commonly five to ten minutes for a 90-minute session. If it routinely runs to half an hour, either the sheets are unreadable or the debrief has absorbed a status meeting. ### What comes out of it Three things. The sheet is **accepted or amended** — the listener may push back on a coverage claim that the notes do not support, or on an obstacle that turns out to be a product defect in disguise. **Obstacles are routed** to whoever can clear them; an unresolvable obstacle that is quietly recorded session after session is pure waste. And the **outlook** informs what gets tested next: an area that is finished, an area that needs more, or a newly interesting area that came out of an incidental finding. ### A worked example A tester debriefs a 90-minute session on an online bookstore's gift-card redemption. Past: the first 40 minutes went on building card data by hand, because the seeding tool cannot produce cards that expire in the past. Results: cards expiring within the current hour are rejected as already expired — one node in the redemption path is running about eleven minutes ahead of the others, so the expiry comparison fires early; roughly 70% of the block was on-charter. Obstacles: no data seeding, and nobody could say which service is authoritative for time. Outlook: the tester wants two more sessions here, one on redemption near locale boundaries and one on partial redemption, but neither is worth running until the data problem is fixed. Feelings: uneasy, because a clock difference that affects expiry probably affects other time comparisons too. The lead's response is not to schedule the two sessions — it is to get the data seeding fixed first and to raise the question of clock discipline, which is a much larger finding than the single defect. That reframing is exactly what a debrief is for, and it does not happen if the sheet is merely filed. ### Failure modes The debrief becomes a status update, with the listener only asking "how many bugs?". It gets batched to Friday, by which point nobody remembers the session. It is skipped for experienced testers as a mark of trust, which removes the coaching and the challenge from precisely the sessions whose findings carry most weight. Or the feelings step is dropped as unprofessional, which quietly discards the earliest available warning about an area.
- Why does a debrief checklist ask how the tester feels about the session?Because unease is often a mental model that has formed faster than the tester can articulate it. Someone who says the area looks fine on paper but feels wrong has usually noticed an inconsistency they cannot yet name, and that intuition is a cheap, surprisingly reliable pointer to where the next session should go. Dropping the question as unprofessional throws away the earliest signal you have.
- Can a debrief be replaced by simply reading the session sheet?Not entirely. Reading catches what was written; the debrief catches what was not — a coverage claim the notes do not support, an obstacle the tester downplayed, an area they are quietly worried about. It is also where a lead hears how a tester reasons, which is the main coaching channel the technique has. Reading sheets is a reasonable fallback under load, but it is a downgrade, and it should be named as one.
It is closer to a pilot's post-flight debrief than to a status report: the point is not how many minutes were flown, but what surprised you and what the next flight should watch for.
saying these in an interview costs you the question
- Treating the debrief as a headcount of bugs found
- Batching all debriefs to the end of the week
- Skipping debriefs for senior testers as a courtesy
- Debriefing to a room instead of to one listener
- Never challenging a coverage claim in the notes
- Letting a five-minute debrief become a status meeting