03 Nov 2026 Exploratory testing: what it finds that scripted tests miss, and how to plan it

In short: Exploratory testing means a tester designs and runs tests at the same time, learning about the software as they go. It finds problems nobody wrote a requirement for, such as confusing screens and odd combinations. Plan it with a clear goal, a time box and notes. Automation guards what you know; exploration finds what you don’t.

Every test in your automated suite was written by someone who already knew what to check. That’s its strength, and also its limit. Users don’t follow your test cases. They click back halfway through, paste odd text into a field and open two tabs at once. Exploratory testing is how a skilled person finds those problems before your users do. Done well, it’s one of the best uses of a tester’s time.

What is exploratory testing?

Exploratory testing is testing where you design the next test based on what the last one taught you. There’s no script written in advance. A tester gets a goal, such as “find out how the new refund screen handles mistakes”, and starts using the software. What they see shapes what they try next. If a field accepts a negative amount, they dig into that. If an error message is unclear, they check where else it appears. The ISTQB glossary describes it as testing where the tester designs and runs tests on the fly, based on their knowledge and what they learn. That sounds loose, but good exploratory testing has a clear structure. It differs from random clicking in the same way a doctor’s exam differs from a guess.

Scripted testing works the other way around. Someone writes the steps and the expected result first, and the test follows them. That makes scripted tests repeatable and easy to automate. It also means they only check what their author thought of.

What does exploratory testing find that scripted tests miss?

It finds the problems that sit between the requirements. A scripted test checks that a rule works as written. A person exploring notices when the rule makes no sense to a user, or when two rules clash. Those findings are often the ones that cause support calls after a release. These are typical examples.

• Confusing screens. Every field works, but a new user doesn’t know what to do next.
• Odd combinations. A discount code plus a gift card plus a cancelled item.
• Interrupted flows. The back button, a timeout or a second tab halfway through a payment.
• Rare edges. Very long names, special characters, the last day of the month. Our post on edge case testing shows how costly those can get.
• Gaps between systems. The order is saved, but the confirmation email shows the old price.

Only a person can judge some of these. Whether a screen is clear, or whether a user will manage, is a human call. That matters even more for anything with a user interface.

How do you plan exploratory testing so it isn’t just clicking around?

Give each session a goal, a fixed time and a short report. This approach is often called session-based test management, a method described by James and Jonathan Bach. The goal is written as a charter: one line that says what to explore and what to look for. The time box keeps the session focused, often 60 to 90 minutes. The notes make the work visible, so a test lead can see what was covered. These steps work in most teams.

1. Write a charter. For example: “Explore the refund flow with partial returns to find wrong amounts.”
2. Set a time box. Pick a length and stop when it ends, even mid-thought.
3. Take notes as you go. What you tried, what you found, and questions that came up.
4. Debrief for ten minutes. Share the findings with a developer or the product owner.
5. Decide what follows. A bug ticket, a new charter, or a new automated test.

Plan sessions where the risk is highest. New features, areas that changed a lot and flows that touch money or personal data are good places to start. Elisabeth Hendrickson’s book Explore It! has many practical charter ideas.

How do exploratory testing and test automation work together?

They do different jobs, and each makes the other better. Automation checks again and again that what worked yesterday still works today. That’s the job of regression testing. Exploration looks for what nobody knew to check. When a session finds a serious bug, the fix gets an automated test, so the problem can’t come back unnoticed. And when the regression set runs by itself every night, testers have time to explore instead of repeating the same checks by hand.

Our Government Operations Centre case shows this mix. The platform kept changing and had no regression tests. Use case testing and exploratory testing were used to check new functions and find unexpected behaviour. Selenium automated the regression tests for the core functions across several browsers. After each test cycle, the client got release advice.

AI doesn’t change this split. It can read a user story and draft test cases, which saves time on the scripted side. But a person still thinks for themselves about what matters, what’s missing and what feels wrong. Exploratory testing from a real user’s point of view stays human work, and so does acceptance testing by your business users. Read more in our post on AI in software testing.

Exploratory testing has limits too. You can’t repeat a session exactly, and the results depend on the skill of the tester. It’s also harder to report on than a pass rate. Charters and notes solve part of that, but not all. So don’t use it as your only safety net for what must keep working. That’s what automation is for.

What this means for your team

Most teams agree that exploratory testing is valuable. Yet it’s often the first thing to go when a release gets tight. Testers spend their days on manual regression checks, and there’s no time left to explore. Or the team has no tester at all, and developers test their own work with the steps they already had in mind.

Two things help. Automate the repeat work, so people get time back. And make sure someone on the team has the skill and the mandate to explore. Our QA & Testing Solutions add experienced testers to your team for exactly that work. They plan sessions where the risk is, report what they find in plain words, and turn the important findings into tests that keep running.

A first step for this week: pick the feature you’re least sure about. Write one charter for it, book 90 minutes, and see what you find.

Frequently asked questions

What is the difference between exploratory testing and ad hoc testing?

Ad hoc testing has no plan or record. Exploratory testing has a goal, a time box and notes, so you know what was covered and what was found. The freedom is in how the tester reaches the goal.

Can exploratory testing be automated?

No. The value comes from a person reacting to what they see. What you can automate are the checks that come out of it, so a bug you found once is guarded in every run after that.

Who should do exploratory testing?

Someone who knows how users work and how software tends to fail, usually an experienced tester. Developers and business users can join a session. Fresh eyes often spot things the builders no longer see.

How do you report on exploratory testing?

Report per session: the charter, the time spent, what was covered, the bugs found and open questions. A short overview of sessions per feature shows a test lead where the gaps still are.