Mission Charters

## What a charter actually is A **test charter** is the written mission for one exploratory testing session. It says, in one or two sentences, *what* will be explored, *what will be used* to explore it, and *what information* the session is meant to produce. It is written before the session starts, it is visible to anyone who wants to know what testing is going on, and it is deliberately short. A charter is not a document, not a plan for a release, and not a list of steps. ## The three slots The shape most teams use comes from the session-based test-management literature: ``` Explore <target> with <resources> to discover <information>. ``` - **Target** — the area under test. It must be bounded enough that one person can hold it in their head and can afterwards say honestly which parts they touched. "The scheduler" is not a target; "slot generation for clinics whose opening hours cross midnight" is. - **Resources** — what the tester brings to bear: data sets, account types, configurations, a comparable earlier build, a specification, a diagram, a technique or heuristic, a second person. This slot is what turns two sessions on the same target into two different sessions. - **Information** — the question the session answers. Not "find bugs" in the abstract, but the risk or unknown that motivated the session: *appointments generated outside published opening hours*, *fields that silently change shape between two services*, *a role that can read another clinic's patients*. ## A worked example Weak: "Explore the appointment scheduler." Nothing there bounds the work, so two testers do two unrelated things and neither can report coverage. Chartered: "Explore overnight slot generation with clinics whose published hours cross midnight and a 17-minute slot length, to discover appointments that land outside the published hours." Target = overnight slot generation. Resources = midnight-crossing clinic records and an unusual slot length. Information = out-of-hours appointments. A tester reading it knows where to start, what to vary and what counts as a finding — and still decides every actual step themselves. ## Why "to discover" and not "to verify" The third slot states an **information goal**, not an expected result. "Verify" implies you already know what should happen and only need confirmation; that is a check, and a check that matters is better written down once and run mechanically. "Discover" licenses the tester to report anything relevant to the question, including the discovery that the question itself was wrong — for example that the published hours are ambiguous rather than that the generated slots are wrong. Framing the goal as information is also what makes a session reportable when it finds nothing: "no out-of-hours slots across eleven clinic shapes" is a result, whereas "no bugs found" is not. ## A mission, not a procedure A charter is intentionally underspecified about *how*. In exploratory work the tester designs the next test from what the last one just revealed, so fixing the steps in advance removes the very thing the session is for. The charter constrains **scope and purpose**; the tester owns **method**. That division is what lets a manager schedule and account for exploratory work without dictating it. ## The two smells **The slogan.** "Test the calendar thoroughly", "Do some exploratory testing on booking." No target boundary, no resources, no information goal. It is unfalsifiable: you can never say it is finished, and the debriefing conversation has nothing to hang on. **The disguised script.** "Open clinic admin, add a clinic with hours 22:00–06:00, save, confirm eight slots appear." Every step and the expected result are fixed, so nothing is being explored. If the steps are genuinely known and repeatable, that is a check and belongs in an automated suite; writing it as a charter buys the ceremony of exploration without the benefit. A useful test for a draft: could two capable testers run this charter and produce genuinely different, both-valid session notes? If not, it is a script. Could either of them, at the end, state what they covered and what they left? If not, it is a slogan. ## One charter, one session A charter is sized so that a single uninterrupted stretch of testing can honestly finish it. That sizing is part of writing it: if the target names two subsystems, or contains the word "and" joining unrelated areas, it is really two charters. A four-person team that charters at the right size ends each session able to say what was covered; a team that charters vaguely ends each session with sprawling notes and no coverage statement. ## What a charter is not It is not a test case (no steps, no expected result), not an acceptance criterion (it states what to investigate, not what the system must do to be shippable), and not a bug report. It is the smallest artefact that makes unscripted testing plannable, accountable and repeatable as an activity — while leaving the testing itself free.