Early on, "exploratory testing" meant I opened the app and clicked around until something broke. It found bugs, but I couldn't explain what I tested or why. Charters fixed that.
What a Charter Is
A charter is a one-line mission for a time-boxed session. The format I use comes from Session-Based Test Management:
Explore [target]
With [resources/tools]
To discover [information]
A real example from a booking module:
Explore the date-range picker
With boundary dates and timezone changes
To discover validation and off-by-one errors
My Session Structure
- Time box: 60 minutes, timer on.
- Setup (5 min): open notes, start a screen recorder.
- Explore (45 min): follow the charter, but chase interesting smells.
- Debrief (10 min): write up findings, file bugs, note new charters.
Note-Taking During the Session
I split notes into three columns as I go:
| Tested | Bugs | Questions |
| Past/future dates | End date before start accepted | What timezone does the server assume? |
The Questions column is where the next charter usually comes from.
Why Boundaries Pay Off
In one session against the date picker, I found that selecting an end date before the start date didn't error — it silently swapped them and booked a negative-length stay. No scripted test covered it because the requirement never described it.
The Debrief Is the Deliverable
A charter session that produces no written debrief is just play. The debrief — what I covered, what I found, what I'd explore next — is what makes exploratory testing defensible in a process that otherwise loves scripted coverage.