Exploratory Testing

<objective> Structured exploration that finds bugs scripted tests miss. Exploratory testing is simultaneous learning, test design, and execution -- the tester adapts in real time based on what the application reveals. This skill provides the frameworks to make that exploration systematic, repeatable, and documentable. </objective>

Quick Route

Match the situation to a charter pattern and the reference section to open.

Full time splits for each row are in Session Planning by Context below.

Discovery Questions

Before designing a session, gather context. Check .agents/qa-project-context.md first -- if it exists, use it as the foundation and skip questions already answered there.

Target Area

• 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.)

Hypotheses and Suspicions

• 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?

Time and Scope

• 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?

Team Context

• 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?

Core Principles

1. Structured Freedom

Exploratory testing is not "click around and see what happens." It is guided by a charter that defines the target, resources, and information goal. Within that charter, the tester has freedom to follow leads, investigate anomalies, and change direction based on discoveries. The structure makes it repeatable; the freedom makes it effective.

2. Document As You Go

Observations not recorded are observations lost. Take notes during the session, not after. Record what you did, what you saw, and what questions arose. The session log is the deliverable -- it replaces a test script.

3. Heuristics Over Scripts

Heuristics are thinking tools that guide exploration without dictating exact steps. HICCUPS and FEW HICCUPS (below) provide systematic lenses for examining software. They help testers ask better questions and notice things they would otherwise miss.

4. Time-Boxed Sessions

Open-ended exploration suffers from diminishing returns. After 90 minutes, fatigue reduces bug-finding effectiveness. Time-box sessions to 45-90 minutes, then debrief. Short focused sessions outperform long unfocused ones.

5. Bugs Found Are the Beginning, Not the End

An exploratory session that finds a bug has only done half its job. The other half is: Could this bug have been caught by an automated test? If yes, write that test. Exploratory testing feeds the automation pipeline.

Session-Based Test Management (SBTM)

SBTM gives exploratory testing a management layer: charters define intent, sessions are the unit of work, debriefs extract learnings.

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.

Charter Template

A charter is a one-sentence mission statement following this pattern:

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

Charter quality checklist:

• 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

See references/session-templates.md for five worked charter examples (checkout, profile, search, data export, multi-user collaboration).

Session Setup, Flow, and Debrief

The full session lifecycle — pre-session setup steps, environment preparation checklist, the minute-by-minute session flow, the "when you find something interesting" loop, and the structured debrief template — lives in references/session-templates.md. Pull it up at the start of a session and keep it open.

Key timing guardrails to remember without opening the reference: orient and survey in the first 15 minutes, explore for ~40, wrap up and debrief at the end. Always debrief, even solo.

Bug Discovery Heuristics

Heuristics are mental models that guide exploration. They are not checklists to exhaustively complete -- they are lenses to look through.

HICCUPS

A mnemonic for seven oracles that reveal bugs. An oracle is a principle for recognizing problems.

FEW HICCUPS (Extended)

Adds three lenses to the base HICCUPS model:

Heuristic Test-Idea Banks

The detailed test-idea lists for boundary, state-transition, error-handling, and "what if" exploration are in references/heuristics-and-automation.md. Reach for them when you need concrete prompts:

• Boundary heuristics — numeric, string, time, and collection boundaries (zero/one/many, max±1, Unicode, DST, page-size edges).