Exploratory Testing: What It Is, How to Do It and a Worked Example

Every tester has seen it happen: all the test cases pass, the release goes out, and a customer finds a serious bug within an hour by doing something nobody anticipated. Scripted tests can only check what someone thought of in advance. Exploratory testing is how you go looking for everything else.

This guide shows you how to do it with enough discipline that you can explain what you covered, what you found and what you did not get to. You will need no special tools, only a product to test, a timer and somewhere to keep notes.

What is exploratory testing?

Exploratory testing is an approach where you learn about the software, design tests and execute them at the same time. Each result shapes your next test. If a search box handles an apostrophe strangely, you do not move to the next scripted step. You follow that clue and try quotes, accents and very long input.

Cem Kaner is widely credited with coining the term in the 1980s, and James Bach and others later developed it into a practical discipline. The key idea is that the tester is an investigator using judgement, rather than someone following steps written earlier. A good session answers a question such as “what could go wrong when two people edit this invoice?”

Exploratory vs scripted testing

You need both. Scripted checks protect what already works, and our guide on how to write test cases covers that side. Exploration finds what those checks never considered. Good bugs found while exploring often become new scripted or automated checks, so the two approaches feed each other.

Exploratory vs ad hoc testing

People often use these terms as if they were the same, which is why exploratory testing sometimes gets dismissed. Ad hoc testing usually has no defined goal or record. You try things and hope. Exploratory testing has a mission, a time limit, notes and a debrief. Someone can ask what you covered, and you can answer with evidence.

When to use it

Exploratory testing pays off the most in these situations:

• A new feature has just arrived. It is the fastest way to learn how it behaves and where the risks are, before you write detailed tests.
• Requirements are thin or still changing. You can test against your understanding and raise questions early.
• Time is short before a release. A few focused sessions on the riskiest areas can tell you a lot.
• An area keeps producing bugs. Defects tend to cluster, so investigate around a recent fix.
• Usability matters. A human notices when a flow is confusing, even if it technically works.

It is a poor fit where every step must be documented for an audit or where the same large set of checks has to be repeated exactly, as in a full regression run. In those cases, use scripted tests. Your test strategy should say how much of each approach the project needs.

Write a charter

A charter is a short mission statement for one session. It keeps you focused without telling you which steps to take. A popular template comes from Elisabeth Hendrickson’s book Explore It!:

Explore   <target>
With      <resources, tools or data>
To discover <information>

Some charters we might write for an online shop:

• Explore the checkout with expired, invalid and stacked coupons to discover how totals and error messages behave.
• Explore the product search with special characters and very long input to discover how well it handles bad data.
• Explore the account page with two browsers logged in at once to discover what happens with conflicting edits.

A charter that is too broad, such as “test the website”, gives no focus. One that is too narrow, such as “check the coupon field rejects ABC”, is really just a single test case. Aim for something you can reasonably cover in about an hour.

Run timed sessions

Session-based test management, developed by Jonathan and James Bach, turns exploration into something you can plan and report on. It has a simple rhythm:

1. Pick one charter. Choose it based on risk.
2. Set a timer. 45 to 90 minutes works well, and you should avoid interruptions.
3. Test and take notes. Record what you tried, what you saw, any bugs and any questions.
4. Stay on mission. If you spot something unrelated, write it down as a new charter and return to the current one, unless it is more important.
5. Debrief. Spend ten minutes with a colleague going through what you covered, what you found and what still worries you.

Useful heuristics

A heuristic is a rule of thumb that gives you ideas when you are stuck. These are good ones to start with:

For a broader checklist, look up James Bach’s SFDPOT mnemonic: Structure, Function, Data, Platform, Operations and Time. When you are testing limits, boundary value analysis tells you precisely which values matter most.

A worked example

Here is how a 60-minute session on a coupon feature could go. This is an illustration of the process, not a report from a real product.

Charter:  Explore checkout coupons with expired, stacked and
          oddly formatted codes to discover pricing errors.
Duration: 60 minutes
Tester:   Priya
Build:    2.14.0 on staging, Chrome

Notes
10:02  SAVE10 on a 500 cart gives 450. Correct.
10:08  " save10 " with spaces is accepted. Reasonable.
10:15  Expired code shows "Invalid code". Unclear wording.  QUESTION
10:21  SAVE10 then WELCOME5: second replaces first, no warning.  QUESTION
10:30  Apply SAVE10, then remove item to empty cart. Total is -50.  BUG
10:38  Same bug with one item left at a low price: total goes negative.
10:47  Apply code in two tabs, pay in one. Code used twice.  BUG
10:58  Not covered: gift cards, currency other than INR.  NEW CHARTER

Notice how the session flowed. The negative total was not on anyone’s list. It came from wondering what happens when the cart changes after a coupon is applied, and that discovery led straight to the next test. The session ended with two bugs, two questions for the product owner and a new charter, which is a very useful hour.

Report your findings

Exploration is only valuable if other people can act on the result. At the end of a session, share a short summary of:

• Coverage: what you tested and on which build and environment.
• Bugs: filed separately, with clear steps. See how to write a bug report.
• Questions: anything where the right behaviour is unclear.
• Gaps and risks: what you did not reach, and how worried you are about it.

Then ask which findings should become permanent checks. That double-submission bug, for example, deserves a regression test once it is fixed, and our end-to-end testing best practices can help you automate it well.

Common mistakes

• Taking no notes. Without them, you cannot reproduce bugs or show what you covered.
• Having no charter. You drift towards the easy, familiar parts of the product.
• Measuring only bug counts. A session that finds nothing in a risky area is still useful information.
• Leaving it to the last day. Serious findings need time to be fixed, so explore early as well as late.
• Treating it as a job for juniors. Exploration rewards experience and product knowledge. Developers, designers and support staff also make excellent session partners.

Final thoughts

Exploratory testing takes curiosity and turns it into a repeatable practice. Try it this week: choose the riskiest feature in your current sprint, write one charter, set a timer for 60 minutes and keep notes. Debrief with a colleague afterwards. One session is usually enough to show your team why this belongs in the process.

Frequently asked questions

Keep learning