One of the biggest challenges with exploratory testing is balancing freedom and structure. If testing is completely unstructured, it becomes hard to repeat, explain, or manage. If it is too scripted, you lose the flexibility that makes exploratory work powerful. Session-based exploratory testing, driven by charters, solves this by giving shape to testing while preserving creativity.
Charters and Time-Boxed Sessions
A charter is a short statement that describes the mission of a test session. It answers the question, what are we exploring and why? A session is a fixed block of time in which a tester works on that mission, usually between 45 and 120 minutes. At the end, the tester produces notes, findings, and follow-up ideas. This approach makes exploratory testing visible and schedulable, which helps teams integrate it into regular sprint work.
# Example charters for a web application
Charter 1: Explore search filters for edge cases in the orders list.
- Try combinations of date ranges, statuses, and free text.
- Observe how performance changes with large result sets.
- Look for confusing messages and partial matches.
Charter 2: Explore error handling for payment failures.
- Simulate card declines, timeouts, and network interruptions.
- Observe how the UI guides users to retry or contact support.
- Check logs and monitoring for useful diagnostic information.
Session-based exploratory testing also fits well with team-level reporting. You can track how many sessions were executed, which areas they covered, and what types of findings they produced. This is more meaningful than counting only the number of test cases executed, because it emphasises learning and risk coverage.
Structuring Session Notes
Good notes capture what you did, what you observed, and what you want to do next. They do not need to be formal test cases, but they should be clear enough that someone else can follow your thinking. Many testers divide notes into actions, observations, bugs, and ideas. This structure makes it easier to extract defects, update test plans, or design automation from the session.
Common Mistakes
Mistake 1 โ Writing charters that are too vague
If a charter is unclear, the tester and stakeholders will not share the same expectations.
โ Wrong: Charter explore the app with no further detail.
โ Correct: Charter explore profile update flows for data validation and error handling on mobile.
Mistake 2 โ Skipping debriefs after sessions
Without a short review, important findings can get lost or misunderstood.
โ Wrong: Ending a session and filing a few bugs without sharing context.
โ Correct: Spend a few minutes summarising coverage, key risks, and follow-up ideas with the team.