Exploratory Testing
Every technique covered so far in this track — equivalence partitioning, boundary value analysis, regression suites — is scripted: you decide what to test before you touch the app, write it down, and then execute it. Exploratory testing flips that order. You learn the app, design the next thing to try, and execute it, all in the same moment — using your own curiosity and domain knowledge to go places a written test case never would have thought to go.
What Is Exploratory Testing?
Exploratory testing is simultaneous learning, test design, and test execution. There's no predefined script — instead, a tester picks a charter (a rough goal, like "explore the Add Recipe form for anything that breaks it"), sets a time box, and then actively investigates: trying an input, seeing what happens, and letting the result of that action suggest the next thing worth trying. It's driven by tester intuition, curiosity, and knowledge of how real users and real bugs tend to behave — things a test case written weeks earlier, by someone who hasn't seen this exact build, simply wouldn't anticipate.
Scripted Testing vs Exploratory Testing
| Aspect | Scripted Testing | Exploratory Testing |
|---|---|---|
| Test design | Done in advance, written down as steps | Done on the fly, guided by what you just observed |
| Repeatability | Highly repeatable — same steps every time | Low — each session takes a different path |
| Coverage | Covers exactly what was planned, no more | Can surface issues no one thought to plan for |
| Best for | Regression suites, compliance, well-understood features | New features, unclear requirements, hunting for the unexpected |
| Depends on | How thorough the original test design was | The individual tester's skill, curiosity, and domain knowledge |
Worked Example: A 20-Minute Session on RecipeBox's Add Recipe Screen
Charter: "Explore the Add Recipe screen for 20 minutes, looking for anything that breaks the form, corrupts data, or behaves inconsistently." No fixed steps — just the goal and the time box.
| What the tester tries | Why a curious tester would think of this | What it might surface |
|---|---|---|
| Rapidly double- and triple-clicking "Save" right after filling the form | Real users tap impatiently, especially on a slow connection. A written test case rarely says "click Save exactly twice within 200ms." | The recipe gets saved twice as a duplicate entry, because Save wasn't disabled after the first tap. |
| Filling in half the form, then switching to another app (e.g. answering a text message) and coming back | Mobile users get interrupted constantly — the app can be backgrounded mid-task at any time. | RecipeBox loses the in-progress form data on resume, forcing the user to start the recipe over. |
| Pasting an extremely long string (several thousand characters) into the ingredients field | Copy-pasting a whole recipe from a website or note app is a very plausible real behavior, not an edge case a spec would call out. | The UI overflows, or the app becomes sluggish/unresponsive rendering the oversized text block. |
| Typing an emoji (e.g. 🍕) into the recipe title field | Testers with an eye for internationalization and encoding know emoji and non-ASCII characters expose storage/encoding bugs that plain-English test data never would. | The title saves correctly in the list but renders as broken characters (mojibake) when the recipe is reopened for editing. |
Notice that none of these four ideas came from a written test case — they came from the tester thinking like a real, slightly careless, slightly impatient user, and reacting to each result by immediately trying the next suspicious thing. That back-and-forth of "try something, see what happens, let that suggest the next try" is the core loop of exploratory testing.
Session-Based Test Management
Because exploratory testing has no fixed script, teams still need a way to make it accountable and repeatable as a process, even if the exact steps aren't repeatable. Session-Based Test Management (SBTM) does this by wrapping each exploratory effort into a session: a time-boxed block (commonly 60-90 minutes) with a written charter, and a short session report afterward listing what was covered, bugs found, and any questions raised. It gives management the same kind of visibility scripted test cases give — "here's what was tested and for how long" — without forcing exploration into a rigid script that would defeat its purpose.
When to Use Exploratory Testing
- Right after a brand-new feature ships, before enough is known about it to write good scripted test cases.
- When requirements are vague or the spec doesn't cover every scenario (very common in real projects).
- To supplement scripted regression testing — running both catches more than either alone.
- When time is short before a release and you need maximum bug-finding value per hour spent.