Write Test Charters That Drive Exploration

Think of a charter as a map for an explorer. It does not tell you every step to take. It gives you:

1. Where to go
2. What to look for
3. How long to explore

A charter is a focused mission: one area to explore, with one clear purpose. It is short, often a single sentence, and written before the session begins.

The three questions a charter answers

Before writing a charter, answer three questions.

1. Where will you explore?

Which part of the product are you investigating?

This is your target: a feature, workflow, integration, or system boundary. Be specific enough to focus the session, but broad enough to leave room for discovery.

2. What are you looking for?

What kind of information do you want to uncover?

Think about error handling, edge cases, security behaviour, integration failures, unexpected states, or anything else that could reveal risk.

This is often the most important part of the charter, and the part that tends to be the vaguest.

3. How long will you explore?

Every session needs a time boundary. Without one, exploration can expand indefinitely.

Three useful ranges are:

• Short - 30 to 45 minutes. Good for a focused risk or question.
• Medium - 45 to 90 minutes. Useful for exploring a feature with several risks.
• Long - 90 to 120 minutes. Use when the area genuinely needs more depth.

The goal is not to finish everything within the session. The timebox creates a boundary for focused exploration.

The syntax

A common Session-Based Test Management (SBTM) format is:

Explore {target} with {resources} to discover {information}

• Target is the feature or area you are exploring.

• Resources are the inputs, tools, data, environments, or techniques you will use.

• Information is what you want to learn or discover, rather than a result you already expect.

Examples that work:

Notice that none of these tells the tester exactly what to do. They provide direction while leaving room for investigation.

When a charter is too narrow

A charter becomes too narrow when it describes a single test scenario instead of an area worth exploring.

That is essentially a test case wearing a charter's clothing.

The question has already been decided. You are simply checking whether one specific input works.

Step back and look at the bigger question.

Maybe you really want to know:

That is a better charter. The apostrophe in a last name becomes one test idea you can investigate during the session.

When a charter is too broad

A charter is too broad when no reasonable session could explore it meaningfully.

There is no realistic stopping point. If the session ends and you say "security is done", nobody knows what that actually means.

Break the problem down.

Authentication, for example, might produce several focused charters:

• Password policies
• Session management
• Token expiry
• Account recovery
• Authentication boundaries

Each charter gives the tester a meaningful area to explore within a session. Together, they provide broader coverage.

The role of information type

The final part of the charter should make clear what kind of information you want to uncover.

Useful information types include:

• Behaviour under constraint: What happens at limits, boundaries, and extremes?
• Error handling: What happens when inputs are invalid, services are unavailable, or a flow is interrupted?
• State transitions: How does the system behave as it moves between states, including unexpected paths?
• Security posture: How does the system respond to manipulation, injection, or unauthorised access?
• Integration behaviour: What happens at the boundaries between this system and the systems it depends on?
• User experience: Can users understand the flow, recover from errors, and complete their task?

Naming the information type gives the session a clearer purpose. It also gives you something to evaluate afterward: did the session help you learn what you set out to discover?

How many charters per feature?

There is no fixed number.

A useful heuristic is:

• If you cannot identify three distinct areas of risk, you may not understand the feature well enough yet.
• If you have more than eight charters for one feature, the feature may be too large and should probably be broken down.

For a moderately complex feature, three to five charters is often a good starting point:

1. Happy paths and key workflows
2. Errors and edge conditions
3. Integration points
4. Highest-risk areas
5. Any risks discovered during exploration

Start with what you know. Add or change charters as your understanding of the feature grows.

The charter list should evolve with your learning. That is part of exploratory testing.

Who writes charters?

Anyone who understands the feature can contribute.

• Testers bring knowledge of common failure patterns and testing heuristics.
• Developers bring knowledge of implementation risks and areas they are uncertain about.
• Product managers bring the user scenarios and behaviours that matter most to the product.
• Subject matter experts bring domain knowledge that others may miss.

The strongest charters often come from collaboration.

Write them early, before testing begins. The same conversation that uncovers assumptions and risks can also produce the first set of charters.