Writing an Exploratory Charter

Learning Objectives

By the end of this lesson you will be able to:

• Write a well-formed exploratory charter using Mission, Area, and Risk fields
• Distinguish between a too-broad and too-narrow charter
• Write a set of charters that provides systematic coverage of a complex feature

The Charter Template

A robust exploratory charter has three fields:

Mission — What is the goal of this session? What type of information do you want to produce?

• "Find bugs in the cancellation flow"
• "Understand how the system responds to concurrent operations"
• "Verify that all state transitions in the order lifecycle are correctly enforced"

Area — Where will you be testing? What is in scope?

• "The promo code input field and its interaction with cart totals"
• "All transitions from the 'In Review' state in the task lifecycle"
• "The checkout flow on mobile with cash-on-delivery payment selected"

Risk — What could go wrong? What are you most worried about?

• "Logical bugs in the AND/OR conditions of the eligibility check"
• "Silent failures when an invalid state transition is attempted"
• "Race conditions when two users submit the same promo code simultaneously"

Examples: Good vs. Problematic Charters

Too broad:

"Test the checkout feature."

Problem: No focus. A tester could spend 8 hours and never know if they covered the important risks.

Too narrow:

"Submit the form with an empty promo code field and verify the error message text exactly matches the specification."

Problem: This is a scripted test case, not a charter. It allows no discovery.

Well-formed:

Mission: Discover how the promo code system handles edge cases in eligibility logic. Area: The promo code validation on the cart page, specifically the interaction between user type, cart total, and day of week. Risk: AND/OR operator confusion in the discount conditions; new users being denied discounts they should receive; promo code silently applied when it should not be.

This charter focuses the session, leaves room for discovery, and gives the tester clear guidance on what risks to probe.

Writing a Charter Set

One charter rarely covers a complex feature. Write a set:

For a user account lifecycle:

1. Charter 1: Explore valid state transitions (normal paths) — focus on confirming correct behavior
2. Charter 2: Explore invalid state transitions — focus on rejected and silent-failure paths
3. Charter 3: Explore concurrent operations — focus on race conditions and double-submit
4. Charter 4: Explore recovery flows — focus on what happens after a failure mid-transition

Each charter is a 60–90 minute session. The set provides systematic coverage.

Charters Without a Specification

When no specification exists:

• Mission: "Understand what this feature does and document its behavior"
• Area: "The [feature name] workflow from entry to exit"
• Risk: "Unexpected error states, silent failures, inconsistent data"

Your first session is reconnaissance. Your debrief becomes the spec. Your second set of charters tests the spec you just wrote.

Pro Tip: Review your charter after the session against your debrief. If you followed the charter closely but found most bugs in an area the charter didn't mention — that's information. Your next charter for this feature should cover that area explicitly.

Summary

A charter is a precision instrument for directing exploratory energy. It's specific enough to keep you on track during a session but open enough to let you chase the interesting thing when you find it. A well-written charter set provides systematic coverage of a feature without prescribing every step — which is the exact point where scripted and exploratory testing meet.