Learning Objectives
By the end of this lesson you will be able to:
- Categorize session notes into bugs, issues, and coverage notes
- Produce a structured session debrief that is useful for team communication
- Use debrief data to improve future exploratory sessions
The Three Categories of Notes
During an exploratory session, you are constantly taking notes. After the session, you organize them into three buckets:
1. Bugs Found
Defects that are clearly incorrect behavior — they contradict the specification or break basic usability. These go straight to your bug tracker with reproduction steps.
For each bug, record:
- Brief description and severity
- Exact steps to reproduce
- Expected vs. actual behavior
- Environment details (browser, version, data state)
2. Issues Observed
Behavior that concerns you but may not be a confirmed bug. "The system accepts a promo code twice in 5 seconds — is that intended?" or "The error message for an invalid state transition just says 'Error' — should it be more specific?"
Issues become questions for the development team, product owner, or specification review. Some turn into bugs; some turn into documentation updates; some get closed as "by design."
3. Test Coverage Notes
What you explored and what you didn't. This is the most often neglected part — and the most valuable for the team.
Format: "Coverage: Explored valid promo codes (6 cases), invalid codes (4 cases), edge cases on amount boundary (3 cases). Did not explore: weekend vs. weekday timing, concurrent applications."
This note tells everyone: if we haven't tested concurrent applications yet, we should.
The Debrief Report
A complete session debrief fits on one page (or one ticket comment):
Session: Promo Code Logic — Boolean Conditions
Charter: Discover AND/OR bugs in eligibility
Duration: 75 min
Completion: 80% of charter covered
BUGS (2):
[HIGH] Promo code SAVE20 applies to returning customers even when
total is under €100 — AND condition not enforced
[LOW] Success message shows even when discount was not applied
ISSUES (1):
[QUESTION] Applying two different codes: is this intentional?
System allows code2 to override code1 silently.
COVERAGE:
- New customer scenarios: ✓ (3 cases)
- Returning customer scenarios: ✓ (4 cases)
- Weekend/weekday: ✓ (4 cases)
- Concurrent code application: ✗ (not covered — needs separate session)
Using Debrief Data for Improvement
Periodically review your debriefs:
- What bugs did you find? Which categories do they fall into?
- How much of each charter did you typically complete in a session? (calibrates charter scope)
- Which "not covered" items most often contain bugs when finally tested?
This turns a pile of session notes into a continuous improvement feedback loop.
Pro Tip: At the end of each sprint, review all session debriefs and compile a "not covered" list. Present it to the team: "These areas have had zero exploratory coverage this sprint." It keeps exploratory testing honest and visible.
Summary
The debrief is where exploratory testing earns its credibility. It transforms a subjective "I tested the feature" into an objective "I explored these areas, found these bugs, and these areas still need attention." Three categories — bugs, issues, coverage — give the debrief its structure and its value to the team.