exploratory-testing

• What feature, module, or flow is the exploration target?
• Is this a new feature (discovery mode) or existing feature (regression mode)?
• What is the most recent change to this area?
• Are there known risk areas or previous bug clusters here? (See

  risk-based-testing

  for risk data.)

• What do you think might break? (Hunches are valid starting points.)
• What did the developer say was tricky or uncertain?
• Are there areas the automated suite does not cover?
• Have users reported issues in this area before?

• How much time is available for this session? (45-90 minutes is optimal.)
• Is this a broad survey (casting a wide net) or deep dive (focused attack on one area)?
• What environments and data sets are available?
• Are there specific platforms, browsers, or device types to focus on?

• Who built the feature? (Pairing with the developer during exploration can be powerful.)
• Is there a tester who has domain expertise in this area?
• Who should receive the session report?

Canonical references:

• SBTM PDF (Jon Bach / James Bach, satisfice.com) — https://www.satisfice.com/download/session-based-test-management
• Taking Testing Seriously: The Rapid Software Testing Approach (Bach & Bolton, Wiley 2025) — current authoritative RST/SBTM book.
• HTSM v6.3 (Bach, last updated Dec 2024) — emphasizes state-based testing and boundary heuristics. Pair with HICCUPS below.

Explore [target]
  with [resources]
  to discover [information]

• Target is specific enough to guide exploration (not "explore the app")
• Resources name specific tools, data, or conditions to use
• Information goal describes what you want to learn, not what you want to prove
• A single session can reasonably cover the charter in 45-90 minutes

references/session-templates.md

references/heuristics-and-automation.md

• Boundary heuristics — numeric, string, time, and collection boundaries (zero/one/many, max±1, Unicode, DST, page-size edges).
• State transition heuristics — skipping steps, going backward, interrupting, repeating, concurrent transitions, post-error state.
• Error handling heuristics — network loss, malformed responses, rate limits, expired sessions, invalid uploads.
• "What if" scenarios — back button, duplicate tabs, ad blockers, pasted formatting, accessibility features, unfamiliar locales, hostile users.

• The feature is new and requirements are still evolving
• You are investigating a vague bug report ("sometimes it is slow")
• You want to assess the overall quality of an area (quality survey)
• The area is complex with many state combinations that are hard to script
• You need to evaluate subjective qualities (UX, intuitiveness, visual polish)
• You are trying to find bugs, not confirm behavior

• The behavior is stable and well-defined
• The test needs to run on every commit/PR (regression)
• The scenario has a clear pass/fail criterion
• The test involves data combinations that are tedious to explore manually
• You need cross-browser or cross-device coverage at scale
• You found a bug through exploration and want to prevent regression

• As an idea generator before the session. Paste the charter and ask for 10 edge cases the heuristics might miss. Pick 3 to actually try. Discard the rest — most will be generic or invented.
• As an oracle for "is this correct?" mid-session. When you find unexpected behavior, ask the agent to look up the spec / API / standard. Never trust the answer without verifying against the source it cites.
• As a fact-checker on findings, not a writer of bug reports. You write the bug; the LLM reviews for clarity. The reverse — LLM writes, you review — produces template-shaped reports that lose the specific details a human noticed.
• For coverage gap suggestions during debrief. "Given these notes, what charter should I run next?"

• Choosing what to explore. The charter must come from your understanding of risk and stakeholder concerns.
• Deciding whether something is a bug. "The model says it looks fine" is not a debrief.
• Writing the testing story. Specific, situated detail is the point of exploratory testing — generic LLM prose is the opposite.

ai-system-testing

• Embedded testers — testers fully embedded inside delivery teams, contributing to development conversations end-to-end rather than acting as a separate gate. The most common model on cross-functional teams.
• Specialist testers — deep skills in a domain (security, accessibility, performance) called in across teams.
• Coach testers — senior testers who teach craft (heuristics, charter writing, exploratory thinking) to developers and junior testers; rarely test end-to-end themselves.

• Each charter is a real charter: every session has a written

  Explore [target] with [resources] to discover [information]

  line where the target is more specific than "the app." A session with no charter line is unchartered exploration, not SBTM.
• The session log has timestamps and tags: open the log and confirm observations carry a time column and a tag (BUG, QUESTION, IDEA, RISK, NOTE). An untimed, untagged wall of prose cannot be debriefed.
• Every filed bug traces back to a charter and reproduces: for each bug ID, follow its reproduction steps in a clean environment and confirm it still happens. A bug you can't reproduce is a note, not a filed defect.
• Converted regression tests actually run red-then-green: for any exploratory finding promoted to automation, run the new test against the buggy build (

  npx playwright test path/to/spec

  should fail) and against the fix (should pass). A regression test that was never seen failing is not proven to guard the bug.
• Coverage is stated honestly: the debrief marks each charter area covered, partial, or unexplored. "100% covered" with unexplored areas listed below it is the gap to catch.

• Session charters are written for each target area, each following the "Explore [target] with [resources] to discover [information]" pattern
• All planned sessions have been executed and debriefed using the debrief template, with each charter area marked covered, partial, or unexplored
• Every bug found during sessions is logged with a reference to the originating charter and reproduction steps
• Session logs exist with time-stamped observations tagged as BUG, QUESTION, IDEA, RISK, or NOTE
• A findings summary captures total session count, bugs filed (by severity), test ideas identified, and follow-up sessions scheduled or explicitly deferred

• session-templates.md — Charter examples, environment-prep checklist, session-flow timings, debrief template, and the note-taking session-log format.
• heuristics-and-automation.md — Boundary/state/error/"what if" heuristic test-idea banks, the exploration-to-automation pipeline diagram, and a worked Playwright regression example.

• agentic-browser-testing -- The automated cousin: a browser agent explores the app from a natural-language goal with no script. Use it for unattended exploratory smoke; use exploratory-testing for human, charter-driven SBTM sessions and bug hunting.
• playwright-automation -- Where stabilized exploratory findings graduate into maintained, deterministic regression tests.
• test-planning -- Sprint test plans allocate time for exploratory sessions and reference charters.
• risk-based-testing -- Risk assessment identifies which areas deserve exploratory attention.
• test-reliability -- Flaky or unreliable areas identified through exploration feed into test reliability improvements.
• qa-metrics -- Track exploratory session counts, bug discovery rates, and charter coverage as QA metrics.
• qa-project-context -- The project context file identifies known risk areas and previous bug clusters that guide charter writing.