Short answer
Exploratory testing is testing where the tester designs, runs and learns from tests at the same time, instead of following a script written in advance. It is guided by a short mission called a charter and run in timeboxed sessions. It finds the defects nobody thought to write a test case for.
Scripted tests are good at confirming what you expected. They are poor at finding what you did not expect, because a script only looks where its author looked. Exploratory testing covers that gap: a skilled tester works through the product with a goal, notices something odd, follows it, and turns what they learn into the next test.
This guide covers what exploratory testing is, how it differs from scripted and ad hoc testing, how to run a session from charter to debrief, a worked example, and when it is the wrong tool.
What is exploratory testing?
Exploratory testing is an approach to software testing in which learning about the product, designing tests and running them happen together. The tester uses each result to decide what to try next. It is structured by a charter, a timebox and written notes, which is what separates it from simply clicking around.
The term was coined by Cem Kaner in the 1980s, and the idea was later developed by testers such as James Bach, who described it as simultaneous learning, test design and test execution. The important word is simultaneous. In scripted testing those three happen at different times, often by different people. In exploratory testing they happen in one head, minute by minute.
It is not the opposite of planning. A good exploratory session has a clear goal and a fixed length, and it produces a record. What it does not have is a list of steps decided in advance.
Exploratory testing vs scripted testing
Most teams need both. The question is which one fits the risk in front of you.
| Scripted testing | Exploratory testing | |
|---|---|---|
| Test design | Written before execution | Done during execution |
| Guided by | Test cases with expected results | A charter: a target, resources and a goal |
| Good at | Confirming known requirements, repeatable checks, regression | Finding unexpected behaviour, usability problems, gaps in requirements |
| Weak at | Anything its author did not think of | Proving the same thing was checked the same way twice |
| Can be automated | Yes, and stable scripts should be | No, but tools can record and support it |
| Depends on | The quality of the test cases | The skill and product knowledge of the tester |
| Output | Pass or fail per case | Session notes, defects, questions and new test ideas |
A useful way to think about it: scripted tests check, exploratory testing investigates. A failing check tells you something you already knew to look for is broken. An exploratory session tells you what you should have been looking for.
Types of exploratory testing
- Freestyle exploratory testing. No formal charter, just a tester and a product area. Useful for a first look at something new, and the closest form to ad hoc testing. Write notes anyway.
- Scenario-based exploratory testing. The tester starts from a realistic user scenario, such as a returning customer reordering from history, and explores the variations around it.
- Strategy-based exploratory testing. The tester applies known techniques on purpose: boundary values, equivalence classes, error guessing, state changes, interrupted flows.
- Session-based exploratory testing. The structured form, developed by Jonathan and James Bach as session-based test management. Each session has a charter, a fixed timebox, notes and a debrief, which makes the work plannable and reportable.
- Pair exploratory testing. Two people at one screen, often a tester and a developer or product owner. One drives, the other watches and asks questions. It spreads product knowledge fast.
How to run an exploratory testing session
Session-based testing is the version worth learning first, because it answers the question managers ask about exploratory work: what did we actually cover?
- Write a charter. One or two sentences that name the target, the resources and what you are trying to find out. A common template, from Elisabeth Hendrickson's book Explore It!, is "Explore target with resources to discover information."
- Set a timebox. Sessions of 60 to 90 minutes are typical. Long enough to get deep, short enough to stay focused. Turn off notifications.
- Prepare data and access. Test accounts in different states, sample files, a second browser or device. Missing data is the most common reason a session stalls.
- Explore and take notes as you go. Record what you tried, what you saw, what surprised you and what you skipped. Notes written afterwards lose the details that matter.
- Log defects with evidence. Steps to reproduce, the actual and expected result, a screenshot or recording. A bug found in exploration still needs to be reproducible by someone else.
- Debrief. Ten minutes with the lead or the team: what was covered, what was found, what is left, and which new charters the session suggests. This is where exploration feeds the next round of testing.
An exploratory testing example
A team has just shipped discount codes in an online shop. The scripted cases confirm that a valid code reduces the total. Here is one exploratory session on the same feature.
Charter: Explore the discount code field at checkout with expired, stacked, mistyped and edge-value codes to discover pricing errors and confusing messages. Timebox: 75 minutes.
The tester starts with the obvious variations: a code in lower case, a code with a trailing space pasted from an email, an expired code. The trailing space is rejected with "invalid code", which is a usability defect, since customers copy codes from emails all the time. Then they apply a code, remove the only item from the cart and add a cheaper one. The discount stays at the old amount and the total goes below zero on the summary screen. That is the session's main finding, and no scripted case covered it, because nobody had pictured the cart changing after a code was applied.
Following that thread, the tester tries the same thing on mobile, then with the browser back button after applying a code. The back button case works, and so does mobile. The notes record all three, including the ones that passed, because "checked and fine" is coverage too.
At the debrief, the negative total becomes a high-priority defect, the trailing space becomes a small fix, and two new scripted regression cases are written so these paths are checked on every release from now on. One new charter is added: explore discount codes combined with gift cards.
Exploratory testing techniques and heuristics
Experienced testers do not explore at random. They carry a set of prompts that point them at the places software tends to break.
| Prompt | What to try |
|---|---|
| Boundaries and limits | Zero, one, the maximum, one over the maximum, empty fields, very long text |
| Interruptions | Refresh, back button, closing the tab mid-flow, losing the network, a session timing out |
| State and order | Steps in an unexpected order, repeating an action, changing something after a later step has used it, as in the example above |
| Data variations | Special characters, other languages, pasted input with hidden whitespace, duplicate records |
| Roles and permissions | The same screen as a new user, an admin, a user whose access was just removed |
Published heuristics such as James Bach's SFDPOT mnemonic (structure, function, data, platform, operations, time) package the same idea into a checklist you can run through when you run out of ideas.
Exploratory testing vs ad hoc testing
Both are unscripted, which is why they get confused. Ad hoc testing is informal and usually unrecorded: someone tries a few things to see what breaks. Exploratory testing has a goal, a timebox and notes, and its results feed back into planning. If nobody can say afterwards what was covered, it was ad hoc testing, however skilled the tester was.
When exploratory testing is the right tool, and when it is not
It earns its place when requirements are thin or changing, when a feature is new and nobody yet knows how it fails, when you need fast feedback on a build before scripts exist, and for usability and workflow problems that no assertion describes. It is also the best way for a new tester to learn a product.
It is the wrong tool when you need proof that a fixed list of requirements was checked, as in regulated projects where an auditor wants traceable cases, and for checks that must run identically on every build. Those belong in scripted and automated regression testing. The two work best together: exploration finds the problems, and the important ones become scripted checks so they stay fixed.
How we run exploratory testing at BetterQA
Exploratory testing is part of our manual testing services, and it is where we want our engineers' time to go: our own tools take the repetitive work, so people can spend it on exploration, edge cases and quality strategy. It runs next to the scripted and automated suites, not instead of them. Bugs are logged in BugBoard, our own test management tool, and an engineer checks every finding before it reaches your Jira. Exploratory testing depends on people who know how software breaks, which is the point of an independent team: we only test, we never build, so our engineers do not share the developers' assumptions about how the product is used. If you want that alongside your own developers, see QA outsourcing.
Exploratory testing FAQ
A tester is given 60 minutes to explore a new file upload feature to find out how it handles unusual files. They try an empty file, a huge file, a file with the wrong extension, two uploads at once and cancelling halfway. They discover that a cancelled upload still appears in the list as complete, a defect no scripted case covered.
Regression testing repeats known tests to confirm that existing features still work after a change. Exploratory testing looks for problems nobody has written a test for yet. Regression is repeatable and usually automated; exploration is investigative and done by people. Good exploratory findings often become new regression cases.
Both are unscripted. Ad hoc testing is informal and usually leaves no record. Exploratory testing is structured by a charter and a timebox, and the tester takes notes and reports what was covered. Exploratory testing is ad hoc testing with a goal and a paper trail.
Functional testing is about what is being tested: whether the software does what its requirements say. Exploratory testing is about how the testing is done: without a script, designing tests as you go. You can test functionality in an exploratory way, and most exploratory sessions do.
Mostly, yes. The thinking cannot be automated, because the tester decides each next step from what they just saw. Tools help around it: recording sessions, generating test data, capturing screenshots and logs, and turning a useful path into an automated check afterwards.
Session-based test management, where the practice comes from, treats about 90 minutes as a normal session, 60 as short and 120 as long. Shorter sessions rarely get past the obvious; longer ones lose focus. Keep the charter narrow enough to fit the timebox.
A short statement of the mission for one session: what to explore, with what resources, and what you want to learn. For example: explore the password reset flow with expired and reused links to discover security and messaging problems. It keeps the session focused without dictating steps.
Need help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
