Exploratory Testing
Charters, time-boxed sessions, test heuristics and note-taking for finding the bugs scripted tests miss.
What is exploratory testing?
Exploratory testing is simultaneous learning, test design and test execution. Instead of following a script, you explore the product, and each observation shapes the next test. It's how testers find the bugs that nobody thought to write a test case for.
It is not random clicking. Good exploratory testing is structured with charters, time-boxes and notes.
Scripted vs exploratory
| Scripted testing | Exploratory testing |
|---|---|
| Tests designed in advance | Tests designed while testing |
| Good for regression and compliance | Good for new features and finding unknown risks |
| Repeatable by anyone | Depends on tester skill and curiosity |
| Confirms known behaviour | Discovers unknown behaviour |
Strong teams use both: scripted (often automated) tests for what must keep working, exploratory sessions for what might be broken in ways nobody expected.
Session-based test management
The most common way to structure exploratory testing:
- Charter — a mission for the session.
- Time-box — usually 45–90 minutes, uninterrupted.
- Notes — what you tested, what you found, questions raised.
- Debrief — a short review with the team lead or developer.
Writing a charter
A popular template: Explore target with resources to discover information.
Explore the checkout discount field
with expired, reused and malformed codes, and two browser tabs
to discover how the total and error messages behave in edge cases.
Explore the mobile registration flow
with a slow 3G connection and the phone rotated mid-form
to discover data loss, double submissions and layout problems.
A narrow charter keeps you focused; a vague one ("test the app") produces vague results.
Heuristics: where to look for bugs
Heuristics are memory aids that suggest test ideas.
SFDIPOT (San Francisco Depot) — areas of the product to consider:
- Structure — what it's made of (pages, components, files).
- Function — what it does.
- Data — what it processes (empty, huge, special characters, different languages).
- Interfaces — how it connects (APIs, imports, exports, integrations).
- Platform — what it depends on (browsers, OS, devices, network).
- Operations — how it's used in real life (power users, first-time users, mistakes).
- Time — timing and dates (time zones, slow responses, sessions expiring, month ends).
Quick attacks to try on any form:
- Leave everything empty, then submit.
- Enter the maximum length, then one more character.
- Paste text with emojis, Urdu (اردو) and right-to-left Arabic.
- Double-click submit; press back after submitting; refresh mid-flow.
- Open the same record in two tabs and save both.
- Let the session expire, then submit.
Taking useful notes
Keep notes as you go — they become bug reports, new test cases and evidence of coverage:
Charter: Explore checkout discount field with edge-case codes (60 min)
Tester: Bilal Build: 4.2.0-rc3 Browser: Chrome 130, Firefox 131
10:05 Valid code SAVE10 → 10% off ✔
10:12 Lowercase save10 → accepted ✔ (case-insensitive, as expected)
10:18 " SAVE10 " with spaces → "Invalid code" ✘ → BUG-201 (trim input)
10:26 Applied SAVE10 in tab A, removed in tab B, paid in tab A
→ paid discounted price but order shows no code ✘ → BUG-202 (High)
10:40 Expired code → clear message ✔
10:51 QUESTION: should codes stack? Product says no; UI allows two → ask PO
Summary: 2 bugs, 1 open question. Not covered: Safari, mobile.
The "not covered" line matters — it tells the team what risk remains.
When to do exploratory testing
- As soon as a new feature is testable, before writing detailed scripts.
- After a major refactor or dependency upgrade.
- Before a release, on the riskiest areas from your risk analysis.
- When a bug is found — bugs cluster, so explore around it.
Findings from exploratory sessions should feed back into your suite: if a bug was serious, add a scripted (ideally automated) regression test so it never returns.