Basic Exploratory
Explore with a purpose. Not random clicking—structured wandering. Learn how to find bugs that no script would ever catch.
1 The Hook — Why This Matters
In 2023, a Queenstown accommodation site received complaints that searching for Wānaka (with macron) returned different results than Wanaka (without). A scripted test checked that search "worked" by typing "Wanaka" and confirming results appeared. It passed every time.
An exploratory tester, curious about how the search handled special characters, typed the same query with the macron. Different results. The database used two different indexes. No script caught it because no script asked the question.
Exploratory testing finds the gaps between what you planned to test and what actually matters to users.
2 The Rule — The One-Sentence Version
Explore with a purpose. Not random clicking—structured wandering.
Exploratory testing is not "just clicking around." It is simultaneous learning, test design, and test execution. You explore with a mission, take notes, and follow your curiosity within boundaries. The goal is discovery, not chaos.
3 The Analogy — Think Of It Like...
Exploring a new city with a checklist.
You visit the market, try local food, and find the old cathedral. You are not wandering aimlessly—you have a charter. But within that charter, you follow your nose. You notice a side street, peek down it, and find a hidden courtyard. That is exploratory testing: structured enough to be useful, free enough to find surprises.
4 Watch Me Do It — Step by Step
Here is a real NZ example: testing an accommodation booking site. Follow these steps every time you run an exploratory session.
Scenario: You are testing a site where users search for holiday homes, filter by price, and sort by rating.
- Write a charter State what you are exploring and why. Example: "Explore the search and filter features to discover inconsistencies between filtered results and sorted results."
- Set a timer for 60 minutes Time-boxing prevents rabbit holes. When the timer ends, stop. You can always schedule another session.
- Follow a tour Pick a theme and stick to it. The "money tour" follows every path that involves payment. The "data tour" fills every field with edge-case data. The "back button tour" hits back at every step. The "cancel tour" tries to abandon every process.
- Take notes continuously Write down what you did, what you saw, and what surprised you. A single note like "price filter resets when sorting" is worth more than a vague memory.
- Report bugs with evidence Every bug gets a title, steps, expected result, actual result, and a screenshot. If you cannot reproduce it, note that too. Unreproducible bugs are still signals.
| Time | Action | Observation |
|---|---|---|
| 0:05 | Search "Wānaka" (with macron) | 12 results |
| 0:07 | Search "Wanaka" (no macron) | 8 results — different set! |
| 0:15 | Set price filter $100–$200 | 6 results |
| 0:16 | Sort by rating | Filter resets, shows all prices |
| 0:30 | Cancel booking at payment step | No confirmation; user unsure |
Three bugs in 30 minutes. None were in the test plan. The scripted tests checked that search worked and filtering worked—but not that they worked together.
Scenario 2: Exploratory testing on a complex booking flow.
A travel booking app has multiple pages: search, filter, select rooms, add extras (insurance, parking), enter payment. A tester follows the "cancellation tour" to discover what happens if the user abandons at each step.
| Page | Action | Expected | Actual / Issue |
|---|---|---|---|
| Search | Click back at search results | Return to previous search | Works as expected |
| Filter | Apply filters, then click back | Filters preserved or cleared cleanly | Filters partially preserved, UI confused |
| Room select | Add room to cart, click back | Room stays in cart or is cleared | Room added; no visual indication |
| Extras | Add insurance, cancel checkout | Charges not applied | Insurance charged even after cancel |
One critical issue: insurance charged after cancellation. This bug would never appear in a straight-path script. Only exploration of the cancellation flow revealed it.
5 When to Use It / When NOT to Use It
✅ Do it when...
- You have limited or no test documentation
- You want to learn a new feature quickly
- You suspect integration issues between features
- You need to evaluate build quality fast
- You want to find gaps in existing test coverage
❌ Skip it when...
- You need to verify a specific regression fix
- Compliance requires documented, repeatable tests
- You are testing safety-critical or medical software
- You have no time to take notes or report findings
Before you apply this technique, ask:
- Is your app complex enough to warrant exploration (not trivial single-page forms)?
- Do you have at least 60 minutes uninterrupted to run a focused session?
- Can you document findings in real-time without losing focus?
- Are there integration points between features that might hide bugs?
6 Common Mistakes — Don't Do This
🚫 Random clicking
I used to think: Exploratory testing means clicking everywhere with no plan.
Actually: Random clicking finds noise, not signal. A charter gives you focus. Without one, you will spend an hour on low-value areas and miss the bugs that matter.
🚫 No documentation
I used to think: I will remember the bugs I found.
Actually: You will not. A bug you cannot reproduce is a bug you cannot fix. Notes are the output of exploratory testing. If you do not write them down, the session was a waste of time.
🚫 Viewing it as "lesser" work
I used to think: Real testers write scripts. Exploratory is for beginners.
Actually: Some of the most critical bugs are found only through exploration. Scripts verify what you already know. Exploration discovers what you do not. Both are essential.
🚫 Exploring without a plan or charter
I used to think: Exploratory means I can wander anywhere with no focus.
Actually: Unfocused exploration wastes time and produces noise. A charter (even one sentence) gives you direction. Without it, you might spend an hour on the login page while missing critical payment bugs. Write your charter before you start.
When this technique fails
Exploratory testing fails when you explore an unstable or incomplete build. If core features are broken, you cannot explore reliably; you will find noise instead of signal. Wait until the build is stable enough to navigate. Also fails when your app is too simple (single page, no flows, no edge cases); use scripted testing instead. Exploration shines on complex, integrated systems.
7 Now You Try — Interview Warm-Up
Scenario: You have 60 minutes to explore a new food delivery app. Write a one-sentence charter and pick one tour to follow.
Write your charter before revealing a suggested answer.
Suggested charter and tour:
| Item | Answer |
|---|---|
| Charter | "Explore the checkout flow to discover errors in address validation, payment handling, and order confirmation." |
| Tour chosen | The "money tour"—follow every path that involves payment or cost |
| What to watch for | Discounts applied incorrectly, GST missing, confirmation emails delayed |
Tip: Your charter might differ. The key is: one sentence, one focus, one hour. A good charter is narrow enough to finish and broad enough to find surprises.
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. What is the difference between a test script and exploratory testing?
A script tells you exactly what to do before you start. Exploratory testing designs and executes tests simultaneously while you learn. Scripts verify known requirements. Exploration discovers unknown risks.
Q2. Why is time-boxing important in exploratory testing?
It prevents rabbit holes. Without a timer, you can spend two hours on one obscure edge case while missing critical paths. A 60-minute charter forces you to cover ground and report what you found.
Q3. What is a "tour" in exploratory testing?
A theme that guides your exploration. The "money tour" follows every payment path. The "data tour" fills every field with edge cases. Tours give structure to wandering so you do not randomly click.