Scripted test cases tell you whether the app still does what it did yesterday. Exploratory testing tells you what the app actually does — including the parts nobody wrote requirements for. The problem is that "go explore the app" produces wandering, not testing. Exploratory testing charters fix that: they add structure and accountability without turning the session into a script.
What an exploratory testing charter is
A charter is a one-sentence mission for a testing session. The template I use comes from the classic session-based test management format: Explore [target], to discover [information], using [resources or constraints]. It defines a direction and a scope, but no steps — what you do inside the session is driven by what you find, not by what you planned.
Timebox it: 30 to 45 minutes
A charter gets a timebox of 30 to 45 minutes of uninterrupted focus. Shorter than that and you barely get past the surface; longer and attention degrades, and the notes quietly stop being written. When the timer ends, the session ends. If the area clearly deserves more, that is evidence for chartering a follow-up session — not a reason to drift on for two hours.
Example charters
- Explore checkout with an expired saved card, to discover how payment failures are surfaced to the user, using a throttled network.
- Explore the profile screen in Arabic, to discover RTL layout and truncation issues, using the smallest supported device.
- Explore order history with a brand-new account, to discover empty-state and pagination issues, using freshly seeded data.
Notice how each one narrows the hunt without dictating a single step. The RTL charter is a personal staple: as a native Arabic speaker I test the right-to-left builds, and one focused session finds layout bugs that scripted English-language tests structurally cannot.
Notes are the deliverable
During the session I keep a running plain-text log: what I tried, what surprised me, bugs found (with timestamps, so I can match them to the screen recording later), and questions for the team. The format is rough on purpose — polishing notes mid-session steals attention from testing. After the timebox, ten minutes of cleanup turns the log into filed bug reports, questions posted to the team, and a short summary attached to the JIRA task. That summary is what makes exploratory work visible instead of vaguely trusted.
Feed the findings into automation
Charters and automation are complements, not rivals. Every bug an exploratory session uncovers is a candidate for a regression test — that is one of the main ways our Maestro suite grows. The division of labor is clean: automation guards what we already know can break; charters hunt for what we do not know yet. Pairing them also keeps sessions interesting, because you rarely burn a timebox re-walking ground the suite already covers.
Takeaway: write tomorrow's first charter today, in one sentence — explore the riskiest recent change, to discover whatever worries you most about it, using the most hostile realistic conditions you can set up. Then give it 45 undisturbed minutes.
Charters gave my exploratory work something it always lacked: a way to say what was covered. "I tested around checkout" is a shrug. "Three charters — payment failures, RTL layout, empty states — here are the notes and four tickets" is a report a team can plan around.