manual-test-debrief
Session debrief template + tour-coverage tracker - captures the SBTM PROOF format (Past, Results, Obstacles, Outlook, Feelings) plus three-bucket time accounting (test design / setup / bug investigation), the tours applied + areas covered + areas skipped, and the per-session quality-of-attention signal. Output is the artifact a charter delivers into; the team aggregates debriefs across sessions to track what's been explored vs what's still uncharted. Use after every exploratory session - without the debrief, the session's findings disappear.
Install with skills.sh (any agent)
npx skills add testland/qa --skill manual-test-debriefmanual-test-debrief
Overview
The Session-Based Test Management (SBTM) framework ends every session with a PROOF report - a five-section debrief the team can aggregate, compare, and act on. Skip it and the session's findings live only in the tester's head: no team learning, no audit trail, no follow-up. This skill provides the template and the aggregation conventions.
When to use
PROOF format
The acronym from the original Bach & Bach SBTM paper:
| Letter | Section | What it captures |
|---|---|---|
| P | Past | What was tested - areas covered, paths walked, tours applied. |
| R | Results | What was learned - confirmed-working items, surprises, novel observations. |
| O | Outlook | What's left - areas NOT covered; what to explore next session. |
| O | Obstacles | What slowed the session - broken setup, missing test data, environment instability. |
| F | Feelings | Tester's qualitative read on product quality (confident / uneasy / unsure). |
Feelings is the load-bearing field teams skip. Keep it - the tester's qualitative judgment is signal no metric captures.
Step 1 - Debrief template
Fill one per session, within 30 min of session end. The blank spine:
# Session debrief - `<session-id>`
**Charter:** [link] **Tester:** ____ **Date:** ____
**Time-box:** 90 min **Actual:** ___ min **Build / Env:** ____
## Past - what was tested
Tours applied (per `exploratory-tours-reference`); areas covered;
notable paths walked.
## Results - what was learned
Confirmed-working items; bugs found (with bug IDs); surprises;
confirmed-fixed vs prior session.
## Outlook - what's left
Areas not covered (out of time / scope); recommended next charter;
open questions for PM / dev.
## Obstacles
Setup pain; environment instability; recommendations for next session.
## Feelings
Quality of attention; confidence in the feature; unease about untested
areas; recommendation to the release manager.
## Time accounting (3-bucket)
| Bucket | Minutes |
|---|--:|
| Test design | __ |
| Setup | __ |
| Bug investigation | __ |
| **Total actual** | __ |A fully worked example (a promo-code checkout session, every field filled with real bug IDs and time splits) is in references/debrief-examples.md. A high setup % is a signal the environment or test data needs investment, not that the tester is slow.
Step 2 - Aggregation across sessions
Individual debriefs are useful; aggregating them surfaces patterns - which areas are well-covered, which are stale, which have never been touched, and where bugs cluster. Charter authoring uses the rollup to pick where the next session should focus. The Feelings section also yields a per-session quality-of-attention signal worth tracking over time; when it stays low for a tester or area, change something (tester, time-box, tour, or scope). The full quarterly rollup table and the attention tracker are in references/debrief-examples.md.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Skipping the Feelings section | Loses the qualitative signal; rollup is metric-only. | Always fill it (Step 1). |
| Debrief written days later | Memory faded; details lost. | Author within 30 min of session end. |
| Debrief without bug IDs | Findings can't be tracked; team can't follow up. | Every "Result" links to a bug ID OR is logged as a quirk. |
| One-line Past section ("tested promo") | Coverage gap invisible at rollup time. | List tours, areas, paths walked (Step 1). |
| No Outlook section | Next session has no continuity; same areas re-explored. | "Recommended next charter" is the chain to next session. |
| Aggregating without acting | Rollup data sits; team doesn't reallocate sessions. | Action items per rollup (Step 2). |
| Debrief in chat / Slack DMs | Not searchable; not in version control. | Markdown file in docs/sessions/<session-id>.md (or wiki / Notion DB). |
Limitations
References
Worked debrief, rollup, and attention tracker
View source (opens in new window)Worked debrief, rollup, and attention tracker
Deep reference for manual-test-debrief SKILL.md. The skill body carries a blank PROOF template; this file holds the fully-filled example plus the two aggregation artifacts.
A fully worked debrief (promo-code checkout session)
# Session debrief - `<session-id>`
**Charter:** [link to charter]
**Tester:** _______________
**Date:** _______________
**Time-box:** 90 min **Actual:** ___ min
**Build / Environment:** _______________
## Past - what was tested
**Tours applied:**
- [x] Money tour (per `exploratory-tours-reference`)
- [x] Bad-data tour
- [ ] Configuration tour (skipped - out of time)
**Areas covered:**
- Promo code input field - full coverage including SQL/XSS payloads
- Promo discount math - 10% / 50% / 100% / fractional cent edge cases
- Promo + tax interaction - covered for US tax states only
**Paths walked (notable ones):**
- Apply WELCOME10 to $24.99 cart -> $22.49 (pass)
- Apply two stackable promos -> second silently overrides first (BUG-987)
- Apply expired promo -> graceful error message (pass)
## Results - what was learned
**Confirmed working:**
- Single-promo apply
- Promo code expiration enforcement
- Free-shipping promo
**Bugs found:** (with bug IDs)
- BUG-987: Stacking two promos doesn't combine - second silently overrides first.
- BUG-988: SQL injection in promo input field returns 500 instead of 400.
- BUG-989: $0.01 cart with 50% off rounds to $0.00 instead of $0.01.
**Surprises:**
- Discount is applied to subtotal BEFORE tax, but the original SOW
said after-tax. Need to clarify with PM.
- "WELCOME10" code is case-sensitive; "welcome10" silently rejected
with no helpful message.
**Confirmed-fixed (vs prior session):**
- Previous BUG-832 (promo input losing focus) is fixed. (pass)
## Outlook - what's left
**Areas not covered (out of time / scope):**
- EU tax cases (covered separately by next session's charter).
- Multi-currency promo behavior.
- Promo + subscription billing.
**Recommended next charter:**
- "Explore the EU tax + promo interaction" (90 min).
- "Explore promo + subscription billing edge cases" (60 min).
**Open questions for PM / dev team:**
- Confirm: discount before vs after tax (cited as "before" in
current implementation; SOW says "after").
- Confirm: should case-insensitive promo codes be supported?
## Obstacles
**Setup pain:**
- Stripe test card kept timing out at checkout - added 5 min to
the session.
- Required test promo codes weren't pre-seeded; had to create them
manually.
**Environment instability:**
- Staging was down for ~10 min mid-session; lost momentum.
**Recommendations for next session:**
- Pre-seed promo codes via a fixture per `synthetic-data-tool-selector`.
- Verify staging is up before session start.
## Feelings
**Quality of attention this session:** Strong (focused throughout;
caught the BUG-987 cluster early which sustained interest).
**Confidence in the feature:** Mixed. The single-promo path is
solid; the multi-promo path has architectural issues that aren't
just bugs (SOW ambiguity on discount-before-tax suggests the
business hasn't fully decided).
**Unease about untested areas:** Moderate. Multi-currency promos
weren't touched; gut says there are bugs there.
**Recommendation to release manager:** Block release until
BUG-987 (stacking) and BUG-988 (SQL injection) are fixed.
BUG-989 (rounding) is low impact; can ship with known-issue note.
## Time accounting (3-bucket)
| Bucket | Minutes |
|-------------------|--------:|
| Test design | 35 |
| Setup | 25 |
| Bug investigation | 30 |
| **Total actual** | 90 |Aggregation across sessions
Aggregating debriefs surfaces patterns individual reports can't:
## Quarterly debrief rollup - Q2 2026
**Sessions completed:** 47
**Bugs raised:** 138
**Average session: 90-min charter, 3-bucket: 38 / 28 / 24**
### Areas by coverage
| Area | Sessions | Bugs found | Last covered |
|----------------------------|---------:|-----------:|--------------|
| Checkout - promo flow | 8 | 34 | 2026-04-28 |
| Checkout - payment | 6 | 19 | 2026-05-02 |
| Account - subscription | 4 | 12 | 2026-05-05 |
| Account - profile | 3 | 8 | 2026-04-15 |
| Admin panel | 1 | 2 | 2026-03-20 | (stale)
| Reports | 0 | 0 | (never) | (uncovered)
### Action items from rollup
- Schedule sessions for Admin panel + Reports areas (under-covered).
- Subscription area surfaced 12 bugs - investigate root-cause
pattern.
- Average setup time (28 min) is high - invest in fixture tooling.The rollup shows what's been explored vs what's stale vs what's never been touched. Charter authoring uses this to pick where the next session focuses.
Quality-of-attention signal
The Feelings section produces a per-session subjective signal. Track it over time:
| Session | Feelings (numeric: 1-5) | Notes |
|---|---|---|
| ses-201 | 4 | Strong; BUG cluster found early. |
| ses-202 | 2 | Weak; tester sick / distracted. |
| ses-203 | 5 | Excellent; new tester, fresh eyes. |
When attention is consistently low across a tester / area, change something - different tester, different time-box, different tour, different scope.
Related skills
bug-bash-facilitator
Builds a structured bug-bash session - pre-bash kit (charter, test-data prep, environment setup, sign-up sheet), in-bash structure (role rotation across cohorts, shared backlog board, real-time triage), scoring rubric (severity weighting, novelty bonus), and a post-bash same-day wrap-up authored by the facilitator (not a standalone debrief: for post-session writeups without a live bash, use manual-test-debrief). Use when a team needs a coordinated multi-tester sweep before a release or after a major change - converts an ad-hoc "everyone test for an hour" into a recorded, comparable session with deliverables.
crusspic-stmpl-heuristic
Pure-reference catalog of James Bach's CRUSSPIC STMPL heuristic - thirteen quality criteria (quality attributes / non-functional requirements) a tester can evaluate a system against. CRUSSPIC: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility. STMPL: Supportability, Testability, Maintainability, Portability, Localizability. Use when checking a product's quality attributes or non-functional requirements, or picking which quality characteristics a test session evaluates - a checklist for judging product quality holistically; complementary to the ISO/IEC 25010 software product-quality model.
decision-table-test-design
Derives human-readable manual test cases from a business-rule spec via a decision table: identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column (each feasible column is one coverage item per ISTQB CTFL v4.0 section 4.2.3). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input.
exploratory-tours-reference
Pure-reference catalog of the seven exploratory testing tours from Whittaker's Exploratory Software Testing (2009): Feature, Money, Landmark, Intellectual, Bad-data, Configuration, and Garbage-collector's, each a themed mission with the signal it surfaces and a worked example. Use as the menu a charter author picks session themes from. Distinct from the mnemonic catalogs sfdpot-exploratory-heuristic (what to vary) and hiccupps-f-heuristic (oracles), and from session-based-test-management-reference, which manages the sessions.
fcc-cuts-vids-heuristic
Pure-reference catalog of Michael Kelly's FCC CUTS VIDS touring heuristic (2005): eleven tours - Feature, Complexity, Claims, Configuration, User, Testability, Scenario, Variability, Interoperability, Data, Structure - each a reconnaissance sweep that builds familiarity with an unfamiliar application. Use when onboarding onto a product or opening a first session on an unknown area, before a charter is scoped. Distinct from exploratory-tours-reference (Whittaker's seven tours, which frame a bug-hunting mission on a product the tester already knows), sfdpot-exploratory-heuristic (what to vary), hiccupps-f-heuristic (oracles), and crusspic-stmpl-heuristic (quality criteria).
hiccupps-f-heuristic
Pure-reference catalog of Michael Bolton's HICCUPPS-F oracle heuristic - the reference points a tester consults to decide 'is this a bug?': History, Image, Comparable products, Claims, Users' desires, Product (internal consistency), Purpose, Standards/statutes, plus Familiar problems. Use mid-session to test an observation against each oracle. For what to VARY use sfdpot-exploratory-heuristic, for touring an unfamiliar product use fcc-cuts-vids-heuristic, for quality criteria use crusspic-stmpl-heuristic.
manual-test-script-author
Builds stakeholder-readable scripted manual test cases from a feature spec - emits either a step-table format (preconditions / steps / expected result / actual / pass-fail / notes) for spreadsheet review or a Gherkin Given/When/Then format for BDD-aware teams. Each script is self-contained (no implicit team knowledge), single-scenario (one happy + N edge per script), and includes the data setup the tester needs without being a developer. Use when a feature can't be (or shouldn't be) fully automated and a human tester needs an executable script - UAT, regression baselines, certification testing, exploratory follow-up scripts.
manual-testing-overview
Teaches human-driven testing end to end: when a predefined scripted test case is the right instrument versus a time-boxed exploratory session, how session-based test management works (charter with a stated mission, time box, session notes, debrief) with a worked charter and a filled-in session sheet, a decision rule for what to automate versus what to keep human, and what makes a manual bug report actionable (exact reproduction steps, observed versus expected, build and environment, evidence). Use when planning or running testing a person performs by hand, writing a charter for an exploratory session, deciding whether a check belongs in an automated suite or in a human session, or fixing bug reports that developers keep returning as not reproducible.
session-based-test-management-reference
Pure-reference catalog of Session-Based Test Management (SBTM) - the Bachs' framework for running exploratory testing as time-boxed sessions: the session (60-90 min), the charter (Explore X with Y to discover Z), the session-sheet structure, the TBS metrics, the cross-session dashboard, and the PROOF debrief. Use when authoring exploratory-testing charters, reviewing session sheets, or setting up time-boxed test sessions. Distinct from manual-test-debrief (the PROOF debrief template), exploratory-tours-reference (the session themes), and the heuristic catalog hiccupps-f-heuristic.
sfdpot-exploratory-heuristic
Pure-reference catalog of James Bach's SFDPOT heuristic - 'San Francisco Depot' - a 'you are here' framework that catalogues what a tester can vary in a system to find bugs. Six dimensions: Structure, Function, Data, Platform, Operations, Time. Use as a what-to-vary checklist during an exploratory session, complementing HICCUPPS-F (which catalogues what to compare against).
state-transition-test-design
Derives human-readable manual test cases from stateful behavior: identify states, events, transitions, and guard conditions, draw the state table including invalid (empty-cell) transitions, choose a coverage level (all states, valid transitions / 0-switch, transition pairs / 1-switch per Chow, all transitions including invalid ones), then derive one test case per coverage item as an event sequence with per-step expected states (ISTQB CTFL v4.0 section 4.2.4). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use for lifecycle entities (accounts, orders, subscriptions), workflows, and UI wizards where the response to an event depends on the current state.
test-execution-checklist
Converts a regression suite (or test plan) into an executable manual checklist for cases when automation isn't viable - a release-day smoke checklist, a post-incident verification list, or a periodic compliance check. Outputs a per-TC checkbox list with the minimal preconditions, the action, and a one-line "what to look for" - short enough to fit on one page per major flow. Use when the team needs a focused human-runnable list (not full step-tables), e.g., for production smoke after deploy or for the on-call rotation's quick verification.
uat-script-author
Emits User Acceptance Testing scripts in stakeholder-readable format - pre-conditions / business-language steps / expected business outcome / pass-fail / sign-off. Tailored for non-developer testers (end users, SMEs, solution owners) per the UAT canonical definition. Output is one TC per stakeholder-meaningful scenario with explicit sign-off, suitable for compliance / contract / audit records. Use when a release requires formal UAT before sign-off - typical for B2B contracts, regulated industries, or any delivery where the customer's acceptance is the contractual gate.