Home/ Junior/ Learning/ Exploratory Testing
Junior · Experience-Based Technique

Exploratory Testing

Simultaneous test design, execution, and learning. NOT random clicking — structured investigation guided by a charter and your growing understanding of the system.

Junior ISTQB CTFL 4.4.3 — K2 Understand ~12 min read + exercise

1 The Hook — Why This Matters

In 2019, a Wellington fintech startup launched a new payment feature after six weeks of scripted regression testing. Every test case passed. But on day two in production, a customer discovered that rapidly clicking the "Confirm Payment" button during network lag created duplicate transactions. One small business was charged four times for a single $10,000 invoice.

The scripted tests had covered the happy path, the error path, and the boundary values. But no script had said: "What happens if the user panics and mashes the button while the spinner is showing?" That bug was found in under three minutes by an exploratory tester — but only after the damage was done in production.

The lesson: scripted tests verify what you already suspect. Exploratory testing finds what you never imagined.

2 The Rule — The One-Sentence Version

Simultaneous test design, execution, and learning. NOT random clicking.

That is the entire technique. Everything else — charters, time-boxes, session reports, debriefs — exists to make this loop disciplined and repeatable. You are not following a script. You are investigating the software in real time, using each result to choose the next action.

3 The Analogy — Think Of It Like...

Analogy

A search and rescue team looking for a missing tramper in Fiordland.

They don't walk every track in alphabetical order. They start with a search plan — the charter. They check in every hour — the time-box. And they redirect teams based on what they find — the learning loop. A footprint sends one team to a river; a torn jacket sends another to a ridge. Ad-hoc searching is wandering into the bush without a map. Exploratory testing is a trained SAR operation: structured, time-bound, and documented — just without a fixed script.

4 Watch Me Do It — Step by Step

Here is a complete 60-minute exploratory session on a new NZ payment gateway, following the SBTM (Session-Based Test Management) structure.

  1. Write the charter A charter gives the session its mission. Use the formula: "Explore [TARGET] using [RESOURCES] to discover [INFORMATION]."
  2. Set the time-box Block out 60–90 minutes with no interruptions. When the timer ends, you stop, debrief, and write a new charter if needed.
  3. Explore and document in real time Design one test, execute it, learn from the result, and let that result guide the next test. Record every test, observation, and bug in the session sheet.
  4. Debrief with PROOF After the session, report using PROOF: Past (what was planned), Results (what was found), Obstacles (what blocked you), Outlook (what to test next), Feelings (was the area risky or stable?).
Payment gateway — SBTM session sheet
Element Detail
CharterExplore the checkout payment flow using NZ debit and credit cards, throttled 3G network, and rapid navigation to discover how the system handles declined cards, timeouts, and duplicate submissions
Time-box60 minutes
SetupChrome 123, DevTools Network throttling set to "Slow 3G", test cards from Stripe docs
Test 1Enter valid card 4242 4242 4242 4242, submit normally. Pass — payment succeeds, confirmation shown.
Test 2Throttle to 3G, click Confirm. Bug — spinner hangs for 45 seconds with no cancel option.
Test 3Submit then rapid Back button. Bug — double charge created on resubmission.
Test 4Card with spaces "4242 4242 4242 4242". Bug — validation rejects despite spaces being common in user input.
Test 5Refresh confirmation page. Bug — status shows "Pending" not "Paid"; customer would panic and pay again.
Bugs found4 (spinner hang, double charge on Back, spaces rejected, refresh shows Pending)
Debrief noteNavigation fragility is high. Recommend a new charter for 3D Secure and saved-card flows.
Pro tip: Notice how each test informed the next. The normal submit worked, so the tester immediately asked "what happens if the network is slow?" The spinner hang suggested timing fragility, so the tester tried a Back button. That found a double charge, suggesting navigation is fragile, so they tried a refresh. This is the exploratory loop in action.

5 The Decision Tool — When to Use It

✅ Use exploratory testing when...

  • Specs are incomplete or changing frequently
  • You need to learn the system before writing scripts
  • You suspect bugs that scripts won't find
  • Time is limited and you need maximum bug-find value per hour
  • A major refactor just landed and emergent behaviour is unknown
  • You want to evaluate user experience, not just correctness

❌ Don't use it when...

  • Regressing a stable, well-specified feature
  • Compliance testing requires documented traceability
  • Every release must run the exact same test set (automation)
  • You have no time to debrief or report findings
  • The tester has zero domain knowledge and no charter guidance
  • You need precise, repeatable coverage metrics for audit

Before you start an exploratory session, ask:

  • Do you know the system well enough to explore it meaningfully?
  • Do you have a time box, or are you exploring open-ended?
  • Can you capture findings, or is this pure ad-hoc exploration?

6 Common Mistakes — Don't Do This

🚫 Treating it as random clicking

I used to think: Exploratory testing meant clicking around until something broke.
Actually: Ad-hoc testing has no structure. Exploratory testing has a charter, a time box, and a session report. Random clicking misses critical paths and wastes time. A charter gives you a mission. Time-boxing keeps you focused. The session report proves what you did.

🚫 Skipping documentation

I used to think: I didn't need to document anything because I was "just exploring."
Actually: If you don't document it, it didn't happen. A bug found in an exploratory session but not logged is a bug that will ship. Your session notes are evidence: what you tested, what you found, what you didn't cover. Without them, you cannot debrief, reproduce, or improve.

🚫 Ignoring the time box

I used to think: The 60-90 minute time box was just a suggestion.
Actually: The time box exists because tester attention degrades after that. When you hit the limit, you stop, debrief, and write a new charter if needed. Extending the session turns focused investigation into aimless wandering. The discipline is the point.

When exploratory testing fails

Exploring without a time box (no closure) or without documenting findings (no evidence) defeats the purpose. Exploratory testing is powerful when used as a complement to systematic testing, but it cannot replace documented test plans for audit or regulatory compliance.

7 Now You Try — Write a Charter

🎯 Interactive Exercise

Scenario: You have 60 minutes to explore an NZ online booking system for a ferry service (Wellington to Picton). The system lets users select a date, choose a vehicle type, enter passenger details, and pay. You have heard rumours that the system mishandles public holiday pricing and vehicle length validation.

Your task: Using the charter formula "Explore [TARGET] using [RESOURCES] to discover [INFORMATION]," write a single-sentence charter for this session.

Model charter:

“Explore the vehicle booking and pricing flow using NZ public holiday dates, vehicle lengths at boundary values (just under and just over the standard limit), and both desktop and mobile viewports to discover whether public holiday surcharges are applied correctly and whether vehicle length validation prevents oversized vehicles from completing booking.”

A strong charter has three parts:

  • Target: The specific feature or area (not "the whole site")
  • Resources: The data, tools, or constraints you will use
  • Information goal: What you want to learn (not just "find bugs")

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you're ready to practice.

Q1. How is exploratory testing different from ad-hoc testing?

Exploratory testing is structured investigation guided by a charter, time box, and session report. Ad-hoc testing is impulsive and undocumented — you click around without a specific failure in mind. ET is simultaneous design and execution with a learning loop; ad-hoc is random interaction without discipline.

Q2. What are the three components of a well-written charter?

Target (what area you are exploring), Resources (data, tools, or approach), and Information goal (what you want to discover). The standard formula is: "Explore [TARGET] using [RESOURCES] to discover [INFORMATION]."

Q3. A junior tester says: "I found a bug in exploratory testing, but I didn't log it because I was in a session." What is wrong with this?

If it isn't logged, it doesn't exist. Session notes and bug reports are the deliverables of exploratory testing. Without documentation, the finding cannot be reproduced, fixed, or counted as coverage. Log bugs during the session, then debrief afterwards using PROOF.

9 Interview Prep — Know These Cold

These are questions Kiwi employers actually ask junior testers. Have an answer ready.

Q1. How is exploratory testing different from ad-hoc testing?

Exploratory testing is disciplined with charters, time-boxing, and debriefs. It is simultaneous test design, execution, and learning. Ad-hoc testing is impulsive and undocumented — random interaction without structure, planning, or a learning loop.

Q2. What is SBTM and why does it matter?

Session-Based Test Management structures exploratory testing into defined charters, 60–90 minute time-boxes, session sheets, and debriefs. It matters because it gives exploratory testing the accountability and traceability that managers need, without sacrificing the flexibility that makes ET effective.

Q3. When would you choose exploratory testing over scripted testing?

Choose ET when specifications are incomplete, when a major refactor has landed with unknown emergent behaviour, when you need to learn the system before writing scripts, or when you suspect bugs that predefined test cases won't catch. Use scripted testing for stable, well-specified features that require repeatability and compliance traceability.

Q4. What does PROOF stand for in a debrief?

PROOF is the debrief framework: Past (what was planned), Results (what was found), Obstacles (what blocked progress), Outlook (what to test next), and Feelings (was the area risky or stable?). It turns a session into actionable intelligence.

10 Link to Reference

Want the full theory, ISTQB syllabus mapping, and advanced SBTM templates?

→ Exploratory Testing — Full Library Reference

Includes the formal ISTQB definition, tour types (Business, Feature, Anti-, Money), and a reusable session sheet template.