Where do new exploratory test charters come from, and how do you keep a charter backlog useful?

## The backlog as the memory of exploration A **charter backlog** is the running list of missions a team has decided are worth a session but has not run yet. It is the thing that makes exploratory testing survive contact with a real schedule: without it, chartering happens fresh each morning, driven by whatever is loudest, and the areas nobody remembers stay unexplored. With it, the team can see what it intends to explore, what it has explored, and where the gaps are. ## Where charters come from Good backlogs are stocked from several sources deliberately, because each source is blind to different risks. - **Areas the team is uneasy about.** Complexity, churn, a component one person owns alone, a part everyone avoids. Unease is not evidence, but it is a reliable *pointer* to where evidence is missing. - **Recent change.** Anything that landed since the last exploration of that area, explored against how the area behaved before. - **Feature and data shape.** A workflow, or a class of data that stresses assumptions — records at boundaries, records with unusual shapes, records created by an older version of the system. - **User role.** The same area explored as each kind of user who touches it, which surfaces permission and visibility problems that a single-role pass never sees. - **Quality attributes.** The same area explored for accessibility, for error handling, for behaviour under degraded dependencies, for what it discloses when it fails. - **Field and support signal.** Clusters of reported problems, repeated support questions, and past defects, which point at areas where the team's model of the system is known to be wrong. - **Specification gaps.** Places where nobody can say what correct behaviour is. A charter aimed at producing that answer is often worth more than one aimed at finding a defect. ## Charters spawned by findings The most valuable source is the sessions themselves. A session is chartered against one question and routinely bumps into a second one, and the discipline is: **write the new charter, do not chase it now.** Chasing costs the coverage statement for the current charter and produces a set of notes about two half-explored areas. A concrete case: on a hospital appointment scheduler, a four-person team ran a session on rescheduling and hit a schema-drift mismatch — the clinic-hours payload had changed shape between two service versions, so one side read a field the other no longer sent, and appointments quietly kept the old duration. The tester recorded the finding, finished the rescheduling charter, and left the backlog two new charters: one exploring every consumer of that payload for the same drift, one exploring what the system does with records written under the older shape. Neither existed the day before; both are now higher-value than most of the 23 charters already on the list. ## Keeping it useful A backlog rots in predictable ways, and the hygiene is mostly subtraction. - **Retire stale charters.** A charter written against a design that no longer exists is noise. Anything that has sat untouched for a long time gets re-read and either rewritten or deleted. - **Deduplicate.** Two charters whose targets and information goals overlap should be merged, or the boundary between them made explicit. - **Keep them session-sized.** Backlog entries drift into headings over time; a heading must be split before it can be run. - **Record what has been run, not just what is pending.** The backlog's value is as much in the finished column — it is the only coverage record unscripted testing produces. - **Do not let it become a regression checklist.** When the same charter is re-run verbatim every release and finds nothing, its information goal has been answered; the repeatable part belongs in an automated check and the charter should be rewritten around what is still unknown. - **Keep it small enough to read.** A backlog nobody reads is not steering anything; if it has grown past what the team can review in one sitting, that is a signal to retire, not to file. ## Ordering, and where that decision lives Choosing which charter runs next is a planning conversation, not a property of the backlog, and it belongs with whoever owns release-level prioritisation. What chartering owes that conversation is a backlog whose entries are honest: each one session-sized, each one naming the information it would produce, so the cost and the payoff of running it are both legible. A backlog of vague headings cannot be prioritised by anyone, however good the prioritisation process is. ## Why interviewers ask It separates candidates who have *heard of* exploratory testing from those who have sustained it. A practice with no backlog collapses back into ad-hoc poking within a couple of releases, and the symptom is always the same: plenty of session notes, no coverage picture, and the same three comfortable areas explored over and over.