Exploratory Testing

What it is and what it isn’t

Every tester explores a little. The difference is whether you do it deliberately. Here’s how three common ways of testing compare:

	Scripted testing	Exploratory testing	Ad-hoc testingAd hoc testingInformal testing with no plan or documentation, trying things to see what breaks.Open in glossary →
Plan	Written test casesTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary →	A charter and a time box	None
Design	Before running	While running	Not really
Notes	Pass/fail per case	Coverage, bugs, questions, ideas	Rarely
Best at	Repeatable checks, known rules	Finding the unknown	A quick look

When exploratory testing shines

• New features before anyone has written test cases, like the brand-new ParkEasy payment flow.
• Unclear or missing requirements, when you learn the product by using it (see Testing Without Documentation).
• Risky areas like payments, sign-in and data that users can lose.
• After a big change, to find side effects that the regressionRegression testingRe-running tests to check that new changes didn't break things that used to work.Open in glossary → cases don’t look for.
• When the test cases all pass but something still feels off. Scripts only find what someone thought of in advance.

It’s less suitable as your only approach for rules that must be re-checked identically on every release (like “an account locks after 5 failed sign-ins”), for compliance evidence, or for things a machine checks better (thousands of users at once).

Charters

A test charterTest charterThe goal and scope of an exploratory testing session, written before it starts.Open in glossary → is the mission for one session. It keeps you focused without telling you every step. The most widely used template comes from Elisabeth Hendrickson’s book Explore It!:

Explore <target> with <resources> to discover <information>.

Part	Question	Example
Target	Where will you explore?	the parking payment flow
Resources	With what tools, data, conditions or heuristics?	boundary durations and repeated taps
Information	What do you want to learn?	how ParkEasy handles money

A good charter is big enough for a whole session and small enough to finish. If you’re done in 10 minutes, it was too narrow. If you’d need a week, split it. Try building a few:

Charter builder

Combine the three parts and see how strong your charter is.

Target (where?)the whole food delivery appthe checkout tip selectorthe order tracking screenthe Submit button color

Resources (how?)a slow 3G connection and airplane modeboundary amounts (0, 0.01, very large) and quick repeated tapsa phoneinterruptions: calls, lock screen, app switching

Information (what for?)bugswhether totals and tips stay correcthow the status updates recover after losing signalif it works

Explore the checkout tip selector with a slow 3G connection and airplane mode to discover how the status updates recover after losing signal.

• Target: A clear, small area you can cover well in one session.
• Resources: Concrete conditions that change behavior. They tell you what to vary.
• Information: Specific information the team needs.

Strong charter: focused, with a clear way to explore and a clear goal.

Session-based test management

Exploration is easy to start and hard to account for. “I tested for three days” tells your lead nothing. Session-based test management (SBTM), created by Jonathan and James Bach, fixes that by cutting exploration into measurable chunks.

The debrief: PROOF

A classic debrief checklist from SBTM is PROOF:

Letter	Ask yourself	ParkEasy example
Past	What happened during the session?	Explored payment with all durations and repeated taps
Results	What did I find?	3 bugs: €0 parking, double charge on double tap, Back after paying shows Pay again
Obstacles	What got in the way?	Wallet ran empty, needed a reset
Outlook	What still needs doing?	Payment with no network; zones with a 2-hour maximum
Feelings	How do I feel about this area?	Nervous about payments; would not ship Monday as is

“Feelings” may sound soft, but a tester’s gut feeling about risk is real information. Say it, and back it with what you saw.

Heuristics and tours

A heuristic is a rule of thumb: a quick way to come up with ideas that are often useful but not guaranteed. Experienced testers carry dozens in their head. Here are the ones beginners get the most out of.

SFDIPOT: a map of what to look at

Part of James Bach’s Heuristic Test Strategy Model, often remembered as “San Francisco Depot”. Each letter is a different angle on the same app:

Letter	Look at	ParkEasy idea
Structure	What it’s made of	App, wallet service, map, push notifications
Function	What it does	Start, extend and stop parking
Data	What it processes	Zone codes, plates, durations, money
Interfaces	How it connects	Payment API, the OS share sheet, other apps
Platform	What it depends on	iOS and Android versions, location services
Operations	How people really use it	In the rain, one-handed, in a hurry
Time	When things happen	Session expires at midnight, time zonesTime zoneThe local time of a region. Bugs appear when apps mix up the user's time zone with the server's.Open in glossary →, slow networks

Quick heuristics and tours

A tour is a themed walk through the app, popularised by James Whittaker. Each one gives your session a theme:

Heuristic or tour	What you do
CRUD	Create, Read, Update, Delete every kind of data. Then read it again from other screens.
Goldilocks	Too small, too big, just right: 0, 1, the max, max + 1, empty, 500 characters, emoji. Classic boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary → and edge casesEdge caseAn unusual situation at the extreme of what the software should handle.Open in glossary →.
Interruptions	Calls, notifications, lock screen, rotationOrientationWhether the device is held upright (portrait) or sideways (landscape).Open in glossary →, app switching, low battery mode. See interruptionInterruptionAnything that takes the user away from the app mid-task: a call, an alarm, a notification, low battery.Open in glossary → and Interruptions.
Back button tour	Press Back (system and in-app) on every screen, especially after saving, paying or deleting.
Money tour	Follow the features customers pay for or that sell the app. Bugs there cost the most.
Empty and full	Every screen with no data (empty stateEmpty stateThe screen a user sees when there is no content yet, like an empty cart or no search results.Open in glossary →) and with lots of data.
Double tap	Tap important buttons twice, fast. Looks for a double submitDouble submitA bug where an action runs twice because the user tapped or clicked twice quickly.Open in glossary →.
Long text	Long names, long translations, large system font. Watch for truncationTruncationText that gets cut off because it doesn't fit its space.Open in glossary → and overflow.
Network	Airplane mode, slow 3G, switching Wi-Fi to mobile data mid-action. See Network Conditions.

You don’t need all of them in one session. Pick two or three that match your charter. Experienced testers combine heuristics with error guessingError guessingChoosing tests based on experience of typical mistakes developers make.Open in glossary →: “This kind of feature usually breaks here.”

Taking notes

Notes turn an exploration into evidence. Keep them short, timestamped and in four buckets:

• Tested: what you covered and how (“Duration: 0, 15, 60, 240, tapped + at 240”).
• Bugs: what went wrong, enough to reproduce later.
• Questions: things you’re unsure are bugs (“Should Back after paying go to Sessions?”).
• Ideas: things to try in a future session (“Payment with no network”).

SESSION: ParkEasy payment, 90 min, Thu 10:00
CHARTER: Explore the parking payment flow with boundary durations and
         repeated taps to discover how ParkEasy handles money.

10:04 TESTED  Duration stepper: 15 min up to 4 h, + disabled at 4 h. OK.
10:09 BUG     - goes down to 0 min, Continue works, "Pay €0.00" accepted.
10:15 QUESTION Is 4 h the maximum in every zone, or does it depend on the sign?
10:21 BUG     Double tap on Pay: wallet −€6.00, two identical sessions.
10:33 IDEA    Next session: pay in airplane mode, kill app during "Paying…".
10:40 TESTED  Back from Confirm returns to the form, values kept. OK.
10:41 BUG     Back after "You're parked" shows Pay again. Paid twice.

Pairing

Exploring in pairs often finds more than two people alone. One person drives (uses the device), the other navigates (watches, takes notes, suggests “now try rotating”). Swap every 20 minutes or so.

• Tester + tester: great for learning heuristics from each other.
• Tester + developer: the developer sees how real users break things and often knows exactly where the weak spots are.
• Tester + product owner or designer: quick answers to “Is this a bug or intended?”

How exploratory fits with scripted testing

They’re partners, not rivals. Scripted tests protect what you already know; exploration discovers what you don’t.

Many teams run their scripted checks first (a quick smoke testSmoke testingA quick check of the most important features to decide if a build is stable enough to test further.Open in glossary → to make sure the build is alive) and spend the rest of the time on charters.

Reporting what you found

Your lead doesn’t want a diary. They want to decide something. A good session report answers:

• What did you cover, and what didn’t you? (Coverage is as important as bugs.)
• What did you find? Bugs with links to their reports, sorted by importance.
• What questions need answers? Who should answer them?
• What’s your recommendation? “I’d ship” or “I wouldn’t ship Monday, because…”
• What’s next? Follow-up charters for the gaps.

Common mistakes