Exploratory Testing and Charters

"Spend the afternoon testing the new search feature" is a request that reliably produces vague findings: a few clicks, an opinion, maybe one defect with no steps to reproduce. The fix is a charter — a written mission with a time-box that tells a tester exactly what to explore, how deeply, and when to stop.

A charter has one sentence of shape:

Explore <area>  with  <assets / techniques>  to  discover  <risks / information>

Concrete examples:

Explore the autocomplete dropdown with keyboard-only input to discover
accessibility and focus-order defects in the first 60 minutes of the search release.

Explore price recalculation with coupon + currency + quantity changes to discover
discrepancies between the cart summary and the order payload.

Notice what each constrains. The area prevents scope drift into "I clicked around the whole app". The technique or asset (keyboard-only, DevTools throttling, three seeded accounts) forces variation instead of repeating the same happy path you already ran in Manual Web Testing Workflow. The risk or question defines done: you can state afterward whether that risk survived, which is what makes the session reportable.

Time-boxing is the mechanism, not a suggestion. Pick 60 or 90 minutes and stop when the box ends, even mid-investigation. Two effects make this work. First, a deadline concentrates attention — without one, exploration expands to fill the day and produces diminishing returns. Second, a fixed box makes sessions schedulable and measurable: four 60-minute charters in a release week is a number you can plan and defend, whereas "we explored for a while" is not. When the timer ends, jot a one-line note on where you stopped and what you would charter next; that handoff is how a session series stays coherent across testers.

Prepare before the box starts, because setup time inside the session is exploration time wasted: seed the data (accounts, products, coupons), open the DevTools panels you will use, note the build and feature-flag state, and have the defect form ready. A tester who spends the first 15 minutes fighting a broken test environment has effectively shortened their own charter.

Depth guidance helps too. Spend roughly the first fifth of the box mapping the surface — what screens, parameters, and states exist — then commit the rest to the highest-risk branch you found. Defects cluster where state changes: applying and removing a coupon, adding and removing an item while a discount is active, switching currency with a promo applied. Those transitions are where checklists thin out and where a well-written charter sends you next.

A charter also survives contact with interruption, which is where unstructured testing falls apart. When production support pulls you away at minute 30, the written mission and your notes so far let a colleague resume: area, technique, and the branch in flight are all on the page. Teams writing charters during planning get a second benefit — the list of charters for a release is the exploratory test plan, estimable and reviewable like any other ticket, instead of an invisible activity that happens after the sprint's "real" testing.

Choosing the risk inside the mission matters as much as the mission. Ask where this feature breaks in production: state transitions (apply then remove a coupon), boundaries between services (cart writes versus pricing reads), and anything computed in more than one place (the total shown in the cart, sent in the payload, and printed on the receipt). Three charters aimed at those three shapes outperform one charter aimed at "the whole feature", because each session goes deep in one direction and still finishes with a verdict.

The charter tells you what to explore. Deciding what to try inside that scope — the systematic way to vary a feature so you do not repeat yourself — is the next section's subject.

A charter scopes the mission; it does not tell you which of the thousand possible inputs to try in the next ten minutes. That is what heuristics are for — short prompts that systematically vary one dimension at a time so you cover breadth instead of repeating your favorite path.

The best-known set for interactive software is James Bach's SFDPOT, one card per dimension:

Work the letters as prompts, not as a sequence to complete. Data is usually the fastest yield: an empty string, a single space, a 256-character paste, a right-to-left string, and a query that matches nothing will find more in ten minutes than another pass through "shoes". Operations is where interaction defects live — press Back while results load, submit twice, open two tabs and act in both, log out in tab A while tab B searches.

Pair the variation heuristic with an oracle — the rule that tells you the result is wrong. Without one you can vary inputs endlessly and still not know what "correct" means. Cheap oracles worth memorizing:

Consistency   same query twice → same results, same order (when sort is fixed)
Computation   shown total == sum of line items == payload total == receipt total
Claims        UI states 'no results under 3 chars' → 2 chars must return nothing
History       a search that previously returned results still does (no silent regression)
Reference     compare against a known-good build, a spec, or the API's raw response

A practical way to run both in a session is a coverage sketch — a small grid you fill as you go:

              desktop  tablet  throttled  offline
empty query      ✓        ✓        –         ✓
unicode          ✓        –        –         –
no results       ✓        ✓        ✓         ✓
interrupted      ✓        –        ✓         ✓

The empty cells are the point. They show what you have not tried, they make the session auditable (a reviewer can see coverage, not just conclusions), and they hand the next charter a ready-made scope. "I covered 6 of 12 cells" is evidence; "tested search thoroughly" is not.

Oracles have a second job at reporting time: the oracle you used becomes the expected-behavior line of the defect. "Computation oracle: cart shows 54.00 while the payload sends 49.00" states the rule and the violation in one sentence, so triage never has to reconstruct what wrong meant. Vague findings get rejected or bounced back for clarification; naming the oracle pre-empts the reviewer's first question — is this actually a bug?

Some dimensions need conditions you create before the box starts: an account with a session about to expire, a coupon that expires mid-test, two tabs already open, a seeded order history. Pre-seeding is the difference between spending half the charter manufacturing the condition and actually observing behavior inside it.

Interviewers frequently ask how you avoid testing the same way every time. The answer they want is mechanical: a variation heuristic for breadth, an explicit oracle for judgment, and a sketch that records both — then the discipline to write down what you found while it is fresh, which is the next section.

Exploratory testing has a reputation problem in organizations that were burned once: findings that cannot be reconstructed, no evidence the session happened, and no way to prove coverage to an auditor. Both halves of that reputation are fixable with disciplined notes and a short debrief.

Take notes during the session, not after. Keep the file open beside the browser and log as you go:

2026-10-12  10:14  build search@4f2a1c, flag search_v3 ON, desktop 1440px
10:16  Data: query 'café' returns 0, ASCII 'cafe' returns 18 — accent folding off?
10:22  Ops: Back during loading → spinner persists, second search appends results
10:31  oracle=consistency: repeat of 'red shoes' differs in order between runs
10:44  coverage: Data 4/6 · Operations 2/6 · Platform 1/4

Timestamps tie your notes to server logs and to the DevTools recording you can capture with Ctrl+Shift+R in the Network panel. Each finding needs enough to reproduce without you in the room: build and flag state, exact input, steps, observed versus expected. Ten minutes writing during the box saves an hour of reconstruction afterward — and if the defect is intermittent, the reconstruction may be impossible.

The tool matters less than the habit — plain text file, notes app, or the ticket itself — but every line must carry the state that makes it reproducible: build hash, feature flags, account, viewport. Exploration happens against a moving target; by the time your defect is picked up, two deploys may have landed and "search was broken yesterday" is unverifiable. Capture artifacts beside the text too: a screenshot showing the exact input, a HAR export when the finding is network-shaped, a 12-second screen recording for multi-step interaction defects (Command Menu → Record web performance). Attach them rather than describing them — "the spinner never ends" is arguable, a recording of it is not. And when a session finds nothing, file the report anyway: stated coverage with zero defects is evidence of quality and of work performed, which protects the team when a bug later surfaces in that exact area.

Debrief promptly, in three moves. First, state the charter and the time-box so the outcome is framed against the mission, not against "did you find bugs". Second, sort what you found into three piles: product defects (file now, with the packet), test gaps (behaviors that should be checked forever), and new risks (things you did not reach or could not verify). Third — the step most teams skip — convert: every test gap becomes a checklist line for the next release, and every repeatable finding becomes an automated regression candidate. That conversion is how exploration compounds; without it you get the same discoveries every release.

A one-paragraph session report closes the loop:

Charter: price recalculation with coupon + quantity changes, 60 min
Coverage: cart summary, order payload, receipt email (currency: USD only)
Found: 2 defects (DEF-2214 total mismatch after coupon removal; DEF-2215 payload sends old qty)
Risks remaining: multi-currency, guest cart merge → next charter's scope

That report is auditable evidence: what was explored, what was found, what was deliberately left. Feeding the "risks remaining" line straight into next session's charter is how a series of charters sweeps a feature instead of circling it — and the last thing standing between your exploration and the physical devices you still owe the release is coverage planning, covered in Cross-Browser and Device Coverage.