Exploratory charters

Status: described, not built.

What it would do

Take a change set and produce draft charters for exploratory sessions: one sentence each, naming a mission specific enough to focus a session and open enough to follow a thread.

From a diff touching the discount engine and the basket:

Explore the interaction between promotional codes and member tiers on the basket, with orders near the 100-euro threshold, to discover cases where the total is wrong.

Explore the basket under interruption — back button, double submit, two tabs, session expiry mid-checkout — to discover states where the discount is applied twice or lost.

Each with the reasoning attached: which files changed, what the risk model says about them, which heuristics apply, and what the existing suite already covers so the session does not repeat it.

Where its boundary is

It does not run the session. A charter is the first sentence; the value of exploratory testing comes from a human noticing something slightly odd and pulling that thread, which is the part no automation reaches by definition.

It does not judge the findings. Whether an observed behaviour is a defect, a documentation gap or intended is a judgement with context the tool does not have.

It does not replace the tester’s own charters. It drafts from what is visible — the diff, the history, the suite. The best charters come from someone’s suspicion about a part of the product, and a list generated from a diff would never have produced them.

It does not claim coverage. A generated charter list is not “the exploratory testing plan”. Treating it as one converts a discipline into a checklist, which is the specific failure mode the typology page warns about.

What it would be good at

The blank page. The hardest part of a session is the first ten minutes. A specific mission removes that, and a mediocre charter someone immediately improves is worth more than a perfect one that took twenty minutes to write.

Heuristic recall. Boundaries, interruption, identity and state, concurrency — the standard families are easy to apply and easy to forget under time pressure. A draft that has already crossed the change set with the checklist is a reliable prompt.

Not repeating the suite. Reading which cases the automated tests already cover, and steering the charter away from them, is mechanical and nobody does it.

Why it might not be worth building

Charters are cheap to write. A tester who knows the product writes one in two minutes. The tool competes against a two-minute task.

Generated charters may be generic. “Explore the checkout for defects” is worse than nothing — it produces an unfocused session and discredits the idea. The specificity is the whole value, and specificity is exactly what is hard to generate from a diff.

It could crowd out the good ones. A list on a screen has gravity. A tester working through six generated charters may not run the one they were going to write themselves — and that one was likely the best of the seven.

The honest position: this is the least valuable of the four servers, and it is listed because the boundary is worth stating. If any part of it is built, it should be the heuristic prompt — a checklist crossed with the change set — and not the sentence.