Blog
Test Charter: What it is and How to Write One
Published on
July 8, 2026
Pricing
Live Webinar: The Rise of Autonomous QA for the AI Era - Register Now
What a test charter is, its anatomy, the six charter types, a step-by-step method, worked examples, and how it structures exploratory testing sessions.
A test charter is a short, focused mission statement that guides an exploratory testing session. It names what will be tested, what resources will be used, what information the tester is trying to discover, and how long the session will last. The charter is the hypothesis the session sets out to investigate, the session is the investigation, and the debrief is the finding.
This guide covers where the charter came from, the anatomy of one that produces useful sessions, the six charter types most teams need, a step-by-step method for writing them, worked examples from realistic enterprise scenarios, the session structure that turns a charter into a finding, and why the AI-coded era has made this kind of exploration more valuable rather than less.
A tester is told to spend a few hours exploring the new release and let the team know what they find. The tester opens the application, clicks around, takes some notes, reports a handful of observations that nobody acts on, and the day ends.
Same tester, same application, different brief. Explore the new returning-customer checkout flow on the mobile site for ninety minutes, using last week's test data, looking specifically for issues that could affect loyalty-tier promotions. Three bugs in ninety minutes, two of them release-blocking.
The difference is not talent, it is intent, and the artefact that holds the intent is the charter. Everything else on this page follows from that single observation, that exploration with a direction finds what exploration without one misses.
A test charter is a brief written statement that guides an exploratory testing session. It is short by design, usually one to three sentences, and it answers four questions, namely what to explore, what to explore with, what to discover, and within what time window.
The charter sits inside Session-Based Test Management, the framework articulated to address a long-standing problem in the QA discipline. Exploratory testing produced value that scripted testing missed, but the value was difficult to plan for, account for, or improve, because the sessions were ad hoc, the findings were anecdotal, and the management visibility was poor.
The charter, paired with a time-boxed session and a structured debrief, gave the work a shape that could be planned, measured, and refined without flattening its essential creativity.
A useful working definition is that a test charter is the smallest written hypothesis that turns a wandering tester into a focused investigator. The definition does specific work. It says the artefact is small, which separates the charter from the larger structures of test plans and test cases. It says the artefact is a hypothesis, which reframes exploratory testing as scientific inquiry rather than freeform play. And it says the artefact focuses the tester, which is the operational outcome a good charter produces.
Charters are sometimes confused with three other artefacts, and the distinction is worth drawing clearly. They are not test cases, which prescribe specific steps and expected results. They are not test scenarios, which describe conditions or workflows to be verified. And they are not test plans, which scope the whole testing effort. The charter occupies a position none of the others fills, giving a single session a direction without telling the tester exactly what to do once they start.
A team that uses all three artefacts well has a clearer testing discipline than a team that uses any one of them alone, because the three serve different jobs.
Each artefact captures a different relationship between tester and software.
Three relationships, three artefacts, all useful, and none interchangeable.
A useful charter carries four mandatory components and one optional one. None of the mandatory components is heavy, and none of them can be skipped.
What is being explored, meaning a specific feature, journey, area, integration point, or risk surface. The target should be narrow enough that the session can produce useful findings within the time-box, and broad enough that the tester has room to explore.
What the tester will use during the session, meaning test data, accounts, environments, tools, browsers, or devices. A charter that lists no resources tends to produce sessions that stall while the tester hunts for working data or a stable environment.
What the session is trying to discover, which is what separates a charter from a vague brief.
"Look for bugs" is not an information goal, whereas "identify issues affecting the returning-customer flow under loyalty-tier conditions" is, and the specificity of the information goal is the strongest single predictor of session productivity.
How long the session will run, typically between sixty and one hundred and twenty minutes. The time-box is not a deadline for finishing exploration, it is a deadline for the current session, and multiple sessions on the same area are normal and often valuable.
What the tester suspects might be wrong, or what would be most damaging if wrong. The risk hint points the tester at likely-fertile ground without prescribing what to do, and charters with risk hints tend to produce findings faster, while charters without them remain valid for genuinely open exploration.
The Bach pattern compresses the components into a single sentence, namely "Explore [target] with [resources] to discover [information goal] in [time-box]."
A charter for a banking application might read, "Explore the new returning-customer mobile checkout flow with the loyalty-tier test accounts to discover issues affecting promo eligibility within ninety minutes." The sentence carries the target, the resources, the information goal, and the time-box, so the tester reading it knows what to focus on, what to work with, what to look for, and how long to look.
Different sessions serve different purposes, and six charter types account for nearly all the exploratory work most teams need.
Broad exploration of a new or recently changed area, where the goal is to learn the territory rather than to find specific bugs.
Survey charters answer questions such as what the feature actually does, what user paths through it are possible, and where the boundaries are, and the output is often a map of the area rather than a list of defects.
Focused exploration of a specific sub-area, often following a survey. Where a survey traces the territory broadly, a deep dive probes a narrow path in detail, and deep dives are where the most surprising findings tend to emerge, because the tester has spent enough time in the area to know what is unusual.
Targeted exploration with an explicit defect-finding intent, where the tester suspects a problem and goes looking for it. These tend to follow customer reports, support tickets, or quiet hunches from the development team, and the output is typically a confirmed defect or, equally usefully, a confirmed absence of one.
Exploration oriented around a known risk, which might be technical, such as a new third-party integration that has not been load-tested, business, such as a regulatory feature with high downside if wrong, or contextual, such as a change affecting a journey customers complain about often.
The charter aims the tester at the most leveraged investigation given the risk profile.
Dedicated exploration of a newly built feature, often before its formal acceptance, where the goal is to find issues the planned acceptance tests would not catch, particularly around interaction with the existing system.
Feature charters are the most common kind in agile teams and are often run during the same sprint the feature is built.
Exploration of an area after a major change, designed to find regressions the automated regression suite cannot anticipate. They complement rather than replace automated regression, since the automation handles the known-known regressions while the chartered session handles the unknown-unknown ones.
Most teams use all six types over the course of a year, often without naming them explicitly, and recognising the type a particular session belongs to helps shape the charter, the resources allocated, and the expected outputs.
Six steps capture the working discipline.
Begin by naming the target. The area should be narrow enough to be exploreable within the time-box and broad enough to deserve a dedicated session, so whole applications are too broad and single fields are too narrow, while features, journeys, integrations, and sub-flows are about right.
A useful heuristic is that if the area can be described in five to fifteen words it is probably scoped well, and if it takes a paragraph it is probably too broad.
State what the session is trying to discover, in language a stakeholder would understand. The information goal is the question the charter is asking, and specificity matters more than length, so "issues affecting promo eligibility in the returning-customer flow" is better than "any bugs in the checkout," because the first directs attention and the second invites everything and surfaces nothing. If multiple information goals seem to apply, prefer the one that addresses the highest-stakes risk in the available time, since a charter that chases three goals usually achieves none.
List what the tester will use, including test accounts, test data, environments, tools, browsers, devices, and supporting documentation.
Resources that need preparation should be flagged before the session begins, because sessions that start without prepared resources usually end without findings.
A practical check is to ask whether a tester who knew nothing about the project could begin the session given just the charter and the listed resources, and if the answer is no, the resources list is incomplete.
Choose a session length. Sessions shorter than forty-five minutes rarely produce substantive findings, since the tester is still warming up when the session ends, and sessions longer than one hundred and twenty minutes start to lose focus as the tester drifts into wandering, so the Bach-recommended range of sixty to one hundred and twenty minutes accommodates most useful sessions.
The time-box is a deadline for the session rather than for the exploration, and areas worth deeper investigation can have multiple sessions, with many of the most productive programmes running a series of chartered sessions on the same area across a release.
If specific concerns are known, note them as hints, keeping them light, a phrase or two pointing the tester at likely-fertile ground without telling them what to do.
A risk-hinted charter for the same checkout flow might add "particularly the interaction between the new loyalty-tier discount and the existing volume-discount stacking rules."
The tester can follow the hint or deviate, since the hint exists to help rather than to constrain.
A two-minute conversation with another tester or with the product owner before the session begins is the most underused practice in chartered testing.
The conversation surfaces ambiguities, such as whether "loyalty tier" means the new five-tier scheme or the legacy three-tier one, gaps, such as whether the post-checkout email confirmation should be in scope, and resource needs, such as diagnostic-mode access.
The review takes less time than discovering the same gaps mid-session, and teams that review charters routinely report meaningfully more productive sessions than teams that draft and execute in isolation.
Abstract descriptions of any technique only go so far, so the charters below are drawn from realistic industry archetypes and span different charter types.
"Explore the customer self-service portal's new bill-payment flow with a sample of mid-tier postpaid accounts to map all user paths through the payment journey, including failure and recovery paths, within ninety minutes."
The target is the new bill-payment flow, the resources are mid-tier postpaid test accounts, the information goal is a map of user paths including failure and recovery, and the time-box is ninety minutes.
The charter is a survey, run before more focused exploration, and its purpose is orientation rather than defect finding, so the output will likely be a path diagram and a list of follow-up charters for deep-dive sessions.
"Explore the new annual premium calculator with the regulatory test scenarios for whole-of-life and unit-linked policies, looking for premium values that deviate from the legacy system by more than the agreed tolerance, within sixty minutes."
The target is the new premium calculator, the resources are the regulatory test scenarios for two policy types, the information goal is premium values deviating from legacy by more than the agreed tolerance, and the time-box is sixty minutes.
The charter is bug-hunting with a clear definition of what counts as a finding, and the narrow information goal makes the session highly focused, so a deviation would be a finding while the absence of deviations is itself a result worth recording.
"Explore the cross-border shipment booking flow after the routing-engine refactor, with test data covering the five most common origin-destination pairs and three vehicle types, looking for behaviour changes versus the pre-refactor baseline, within one hundred and twenty minutes."
The target is the cross-border booking flow, the resources are test data for five origin-destination pairs and three vehicle types, the information goal is behaviour changes versus the pre-refactor baseline, and the time-box is one hundred and twenty minutes.
The charter is regression-oriented with the baseline explicitly named as the reference point, so the tester is not looking for defects in absolute terms but for differences from the known-good prior behaviour, and the output should be a list of observed differences, each annotated as expected or unexpected.
"Explore the new clinician availability-scheduling feature with two test clinics configured for overlapping shift patterns, to discover issues in how the feature handles double-booking and cancellation, within ninety minutes, particularly where a cancelled appointment should release a held slot."
The target is the new scheduling feature, the resources are two configured test clinics, the information goal is double-booking and cancellation handling, and the time-box is ninety minutes, with a risk hint pointing at slot-release behaviour. The charter is a feature charter run before formal acceptance, aimed at the interactions the acceptance tests are least likely to cover.
These four span survey, bug-hunting, regression, and feature charters across four industry archetypes, each focused enough to produce findings in the available time and each open enough for the tester's judgement to operate.
A charter without a session is a document, and a session without a debrief is a private investigation, so the full discipline runs the charter through three stages.
Five to ten minutes at the start. The tester reads the charter, confirms the resources are available, starts the session timer, prepares note-taking, and notes any deviations from the charter that have already become apparent.
Setup is brief but critical, since sessions that skip it tend to drift.
The bulk of the time-box. The tester uses the resources to investigate the target against the information goal, taking notes as the session proceeds, recording bugs found, risks identified, follow-up areas, and questions arising.
The tester is free to follow leads that emerge during the session even if they were not in the original charter, as long as the deviation is recorded, and sessions that produce surprising findings usually involve at least some deviation from the original plan.
This is where the Bach concept of on-charter versus on-opportunity testing matters. On-charter testing is the work the charter asked for, and on-opportunity testing is the valuable investigation that presents itself once the tester is in the application and was not anticipated in the charter.
The framework explicitly permits and encourages following an important off-charter lead, and mature programmes track roughly how much of a session went to each, since a consistently high on-opportunity share can signal that the charters are missing where the real risk lives.
Ten to fifteen minutes at the end. The tester captures the session's findings in a structured form, recording what was explored, what was found, what was deferred, and what should be explored next. The debrief is the value-extraction step, since a session debriefed produces an artefact that survives the session and informs future work, whereas a session not debriefed produces value only for the tester who ran it and only until they forget.
The Bach framework offers a memory aid for the debrief conversation in the acronym PROOF, standing for Past, meaning what happened during the session, Results, meaning what was achieved, Obstacles, meaning what got in the way of good testing, Outlook, meaning what still needs to be done, and Feelings, meaning how the tester feels about the state of the area.
The five prompts turn a vague "how did it go" into a structured handover that a test manager can act on, and they capture the softer signal, the tester's unease about an area, that often points at the next charter worth writing.
The debrief produces a session report, sometimes called a session sheet, which is the durable record of the chartered session and the thing that makes the work accountable. A useful report captures the charter itself, the start time and duration, the resources used, a running log of what was tested, the bugs and risks found, the split between on-charter and on-opportunity time, and any follow-up charters the session suggested.
The report matters for a reason that goes back to the original problem SBTM was built to solve.
Before the session report, a test manager asking an exploratory tester what they had done received an answer like "I looked around and found a few things," which was impossible to plan around or report upward.
The session report replaced that with a consistent artefact that could be parsed, aggregated, and turned into metrics, such as sessions completed per area, time split across testing, bug investigation, and setup, and coverage of the areas the team most cared about.
The report is what let exploratory testing sit alongside scripted testing in a managed programme rather than being treated as unaccountable.
A charter written for one release is often worth running again, and treating charters as reusable artefacts rather than disposable notes is where a team's exploratory practice compounds over time.
A charter that surveyed a payment flow before a release can be re-run after the next release with fresh data to catch regressions, a bug-hunting charter that confirmed a defect can be re-run to confirm the fix and guard against its return, and a feature charter can graduate into a regression charter once the feature is established.
Maintaining a library of charters, tagged by area, type, and risk level, gives a team a backlog it can size, prioritise, and assign in the same way it manages any other work.
Prioritising that backlog follows the same logic as risk-based testing generally. The charters worth running first are those targeting the areas where a failure would hurt most, meaning customer-critical journeys, recently changed code, regulated features, and areas with a history of defects or support complaints.
A team that maintains and prioritises a charter library gets cumulative institutional learning from its exploration, whereas a team that writes a charter, runs it once, and discards it loses that learning every time.
Agile development and continuous delivery have not retired the test charter, they have refined how charters are scheduled and integrated, and in modern agile teams charters typically appear at three points in the cycle.
During the sprint, alongside feature development, a feature charter is queued for exploratory testing once a working version is available, and the session runs within the sprint, surfacing issues the automated acceptance tests would miss and feeding them back before the feature is closed.
After major changes or releases, a regression charter targets the most likely-affected areas, complementing the automated regression suite by catching the unknown-unknowns it cannot anticipate.
And periodically, against high-value areas, some teams maintain a rolling exploratory programme of a session per week against the most business-critical areas regardless of recent change, which catches drift, hidden interactions, and slowly accumulating issues that scheduled testing misses.
In continuous delivery environments the charter integrates naturally with frequent deployments, because it does not require a release boundary, only a meaningful area to explore and a time-box to do it in.
Teams shipping multiple times a day still schedule charters at meaningful intervals, often tied to higher-stakes deployments or to changes in customer-critical journeys.
The agile testing quadrants framing applies cleanly here, since Q3, the business-facing quadrant that critiques the product, is the home of exploratory testing in the Marick model, and charters are the operational expression of Q3. Teams that over-index on the automated Q1 and Q2 quadrants often find themselves with strong unit and acceptance coverage but a thin Q3 layer, which the charter discipline is exactly what rebuilds.
AI-assisted development has made chartered exploration more important, not less, and the value concentrates in Q3 for three reasons.
AI now generates unit tests and acceptance tests at scale, so the Q1 and Q2 work that once occupied testers is increasingly machine-handled, leaving the exploratory work that human judgement cannot yet replace. AI-coded software also contains more unknowns to discover, since assistants write behaviour no one consciously designed, and exploration is the most reliable way to find those surprises before customers do. And the trust contract lives in the journeys rather than the units, so chartered exploration of customer-critical workflows catches behaviour drift that automation alone misses.
The practical pattern follows directly. Behaviour-led, self-healing automation carries the regression weight, while exploratory charters target where human judgement matters most, namely new features, major changes, and customer-critical flows under unusual conditions.
Automation handles what it does best, exploration handles what only humans do well, and reducing the regression burden frees exploratory time for where it pays off most.
Virtuoso QA does not write charters, since charter design is human judgement about where to look, but it changes the economics that decide how much charter time a team can afford. When behaviour-led, composable, self-healing tests carry the regression and journey-verification load, the hours a team would otherwise spend maintaining brittle scripts are freed for the exploratory sessions that find what automation cannot.
Tests are authored in plain English against the behaviour a workflow is meant to exhibit, they run across the cross-browser grid, and self-healing keeps them valid as the interface changes, so the regression layer stays green with far less human upkeep.
The effect is that the chartered session, the most valuable and least automatable form of testing, gets more of the team's attention rather than less, which is exactly where that attention belongs in an AI-coded estate. The platform handles the verification that repeats, and the tester handles the inquiry that does not.
Six recurring mistakes account for most of the failed exploratory sessions seen in practice.
"Explore the application" is not a charter, and the session produces unfocused notes and no findings, so narrow the target before the session begins.
A charter that prescribes specific steps is a test case in disguise, and the session loses the discovery value exploratory testing exists to produce, so leave the how to the tester and specify only the what, the with, and the to-discover.
"Look for bugs" is the most common failure mode, since the tester finds the obvious issues, misses the subtle ones, and reports a forgettable list, whereas specific information goals produce specific findings.
A session without an explicit end drifts, the tester loses focus, and the findings get diluted, so even a short time-box beats an open-ended session.
A session without a debrief is one whose value evaporates with the tester's memory, and even ten minutes of structured capture preserves the findings in a form that lasts.
A useful charter may be worth running again, against a different release, with different data, by a different tester, and teams that maintain a library get cumulative value while teams that discard each charter lose the institutional learning.
Try Virtuoso QA in Action
See how Virtuoso QA transforms plain English into fully executable tests within seconds.
