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.
Senior engineer insight
The moment I stopped thinking of exploratory testing as "poking around" and started treating it as a discipline of asking questions the system hadn't been asked yet, my bug count per session doubled. The charter isn't bureaucracy — it's the difference between a detective with a case and a person wandering a crime scene. What changed how I think about it: realising that the bugs I found through exploration were almost always integration bugs, the kind that live in the gaps between features that each developer assumed the other had handled.
Most common mistake at Grad level: writing a charter that is so broad ("explore the whole app") that it gives no direction, then spending the full session on the first screen you click.
From the field
A team building a council rate payment portal for a mid-sized NZ council assumed their payment flow was solid — it had passed every scripted test. During a 90-minute exploratory session focused on the "cancellation tour," a tester tried paying rates, hitting browser back at the payment confirmation screen, and then navigating forward again. The portal charged the ratepayer twice and showed only one transaction in the dashboard. The team had tested the happy path end-to-end and the error path from the server side — but nobody had explored what a confused user with a slow browser connection would actually do. The fix required a backend idempotency key that had never been on anyone's radar. Lesson: the most dangerous assumptions are the ones that live between two features, not inside either one.
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.
Why teams fail here
- Writing a charter after the session ends rather than before — retrospective charters hide unfocused wandering and prevent learning from what you actually explored.
- Treating session notes as optional — without a contemporaneous record of what you did and saw, you cannot reproduce bugs, cannot write a meaningful session report, and the session's value evaporates by end of day.
- Letting the timer run indefinitely on one interesting thread — a 90-minute deep dive into one edge case is not an exploratory session, it is an investigation; finish the tour first, then schedule a focused investigation separately.
- Exploring an unstable build and reporting the resulting noise as bugs — if core navigation is broken, your session findings cannot be trusted; always verify build stability with a five-minute smoke check before committing to a charter.
Key takeaway
A charter without curiosity is just a checklist — but curiosity without a charter is just noise; exploratory testing is what happens when you bring both to the same session.
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.
Interview Questions
What NZ hiring managers ask about Basic Exploratory at the Grad level.
Q1. What is exploratory testing, and how is it different from scripted testing?
Strong answer: Exploratory testing is simultaneous learning, test design, and test execution — you explore the system as you test it, guided by curiosity and risk rather than a predetermined script. Scripted testing follows pre-written test cases step by step. Exploratory testing is better for finding unexpected bugs, unknown unknowns, and usability issues. Scripted testing is better for regression coverage and auditable evidence. Most good testing uses both: automation for regression, exploration for new features.
Q2. You have one hour to explore a new feature. What do you do first?
Strong answer: First, I establish a charter — a brief mission statement: what I'm exploring, what I'm paying attention to, and what I'm not covering in this session. Then I start with the happy path to understand how the feature is supposed to work, before moving to edge cases and error conditions. I take notes as I go: bugs, questions, observations. I save the riskiest scenarios for when I understand the feature well enough to probe them effectively. After the session, I document what I found and what was left unexplored.
Q3. How do you decide what to test when there is no test plan or specification?
Strong answer: I use heuristics to guide my exploration. I ask: who are the users and what are they trying to do? What is the most common path? What could go wrong? I explore boundaries (what happens at the minimum and maximum values?), error handling (what happens when things go wrong?), and integration points (what does this feature connect to?). For a form I have never seen before, I always test empty submission, maximum-length inputs, special characters, and what happens after a network failure mid-submission.
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.