Manual Testing
Intermediate 11 min read Manual Testing

Exploratory & Ad-hoc Testing

Scripted tests cover what you planned; exploratory testing finds what you did not. Learn the session-based approach, charter-driven testing, and how to document discovery so the insights survive the tester instead of living in someone's head.

exploratory testingad-hoc testingchartersession-based testingheuristicsdiscovery
Prerequisites: Testing Fundamentals Test Case Design Techniques
Introduction

What is this?

Exploratory testing is simultaneous learning, test design and execution — the tester designs and runs tests on the fly based on what they observe. It is not unstructured clicking: it uses charters (a mission with scope and a timebox), heuristics and careful note-taking. Ad-hoc testing is the lighter cousin: informal, quick checks without charters. Exploratory testing complements scripted suites by probing real usage, odd data and integration seams that planned cases miss.

Motivation

Why do you need it?

  • The most damaging defects are usually found in paths nobody scripted.
  • It explores real user behavior and business workflows, not just spec-conformant happy paths.
  • Session-based sessions produce structured results instead of vague 'I clicked around' notes.
  • It adapts instantly to new builds, new data or a just-discovered defect, unlike a frozen suite.
  • It is the fastest way to cover unanticipated risk areas before a release.
Think about it

Mental model

Imagine

A map is not the terrain

Think of

A scripted suite is not the app

A hiker follows a map, but a good hiker also reads the actual terrain, finds shortcuts and unexpected hazards the map missed. Exploratory testing is reading the real terrain of the application while the map (scripted tests) covers the planned routes.

Mechanics

How it works

  • Define a charter: mission, scope, data and a timebox — for example, 'Explore guest checkout with invalid payment data for 45 minutes'.
  • Use heuristics and tours (functional, user, feature, capability) to drive discovery instead of wandering.
  • Design and execute tests on the fly, following interesting observations and branching from them.
  • Document each finding as you go: what was tested, what happened, evidence, and any defect.
  • Debrief the session: share notes, cluster findings and feed the best ones back into the scripted suite.

A session-based exploratory testing loop.

Charter
Explore
Observe
Document
Debrief
Feed back
Reference

Key commands

echo 'Charter: guest checkout, edge payment data, 45 min' > session.md

Record the session charter before exploring.

curl -s -X POST https://staging.example.com/api/cart -d '{"qty": 999}' | jq '.status'

Probe an edge input the scripted suite never tried.

echo 'qty 999 -> spinner forever, no timeout' >> session.md

Document the finding with the observation as it happens.

gh issue create --title 'Emoji in city breaks PDF export' --body-file defect.md

Promote a discovery into a tracked defect immediately.

echo 'promoted to scripted: TC-201 edge qty, TC-202 unicode address' >> session.md

Feed the best discoveries back into the scripted suite.

Hands-on

Examples

A charter-driven exploratory session

A charter-driven exploratory session
# Session charter
Mission   : Find data-loss risks in guest checkout
Scope     : Cart -> checkout -> confirmation, invalid + edge payment data
Data      : empty cart, huge quantities, discount codes, emoji in address
Timebox   : 45 minutes
Tester    : QA
Result    : 2 defects found (quantity 999 freezes cart, emoji in city breaks PDF)
 
# Session notes
- Started on empty cart: "checkout" navigates to login unexpectedly
- Quantity 999: spinner spins forever, no timeout error
- Emoji in city: PDF export renders raw bytes, 500 on download
- Evidence: screencast session-3.mov + HAR per defect

The charter gives the session a mission, scope and timebox; the notes capture what was tried and what happened with evidence. Two real defects surfaced because the exploration pushed past the scripted happy path.

Real world

In production

  • Release-bound sessions run charters against the riskiest flows in addition to the full regression.
  • After any major refactor, exploratory passes find integration breaks faster than waiting for the suite.
  • New testers gain product knowledge fast by running charters with a senior tester reviewing the debrief.
  • Defects found in exploratory sessions feed regression cases, so discovery compounds over time.
Guidelines

Best practices

  • Always write a charter with a mission, scope and timebox before exploring.
  • Use tours and heuristics (inputs, boundaries, states, integrations) to stay systematic.
  • Document as you go — notes taken after the session lose detail.
  • Debrief every session and feed discoveries back into the scripted suite.
  • Run exploratory sessions on the latest build against realistic data, not demo data.
Watch out

Common mistakes

  • Treating exploratory testing as unstructured clicking without a charter.
  • Forgetting to document, so findings evaporate with the tester.
  • Exploring only happy paths and never hostile or edge inputs.
  • Keeping exploratory sessions secret from the scripted test effort instead of feeding them back.
Root cause analysis

Common issues

Error
Sessions produce nothing actionable
Root cause

No charter, so exploration drifts

Fix

Scope each session with a mission, a data list and a timebox.

Error
Findings are lost after the session
Root cause

No notes taken during exploration

Fix

Document as you go and debrief at the end of every session.

Error
Manager sees exploratory testing as 'random clicking'
Root cause

No reporting structure

Fix

Use charters, session notes and defect counts so the value is visible.

When things break

Debugging tips

  • When something looks odd, change one variable at a time to isolate what triggers it.
  • Follow error messages into adjacent flows — a broken endpoint often breaks its callers too.
  • Revisit the same area with different data (fresh, empty, huge, unicode) to widen the search.
  • Log the build and environment for every session so findings are reproducible.
Interviews

Interview checkpoint

Practice

Hands-on lab

Run a Charter-Based Exploratory Session
45 min · intermediate
In progress
Objectives
  • Write an effective session charter
  • Use heuristics and tours to drive discovery
  • Document findings with evidence as they occur
  • Debrief and feed discoveries back into the scripted suite

Run a Charter-Based Exploratory Session

45 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

What is the key differentiator of exploratory testing?

2

A charter makes exploratory testing structured and documented.

3

Your exploratory session finds an unusual but real failure. What should you do?

Quick reference

Cheat sheet

Charter and exploration kit
MissionWhat to find, in one line
ScopeFlows and features to probe
DataEdges: empty, huge, unicode, invalid
Timeboxe.g. 45 minutes
Notes + evidenceDocument as you go
Go deeper

Official documentation

James Bach — Exploratory Testing Explained
docs
Ministry of Testing — Session-Based Test Management
docs
Context-Driven Testing — Heuristics
docs