Exploratory Testing: How It Finds Bugs That Scripts Miss

Exploratory testing is testing where the tester designs and runs tests at the same time, using what each result teaches them to choose the next test. It finds bugs scripts miss because scripts only check what someone predicted. Run well, it is not random clicking: each session has a written charter, a time box of 60 to 90 minutes, notes and a debrief.

If you would rather have exploratory sessions run on your product by an outside team, see how RAITHub would test this below.

What is exploratory testing?

The ISTQB glossary defines it as an experience-based approach in which the tester spontaneously designs and executes tests based on their knowledge, prior exploration of the test object and heuristics. In plain terms: the tester learns the product while testing it, and the learning steers the testing.

Compare it with scripted testing, where someone writes the steps and expected result in advance and a tester (or a machine) follows them. Scripted tests confirm known behaviour. Exploratory tests search for unknown behaviour: the combination nobody wrote down, the state the developer did not imagine, the error message that leaks a stack trace.

Why does exploratory testing find bugs that scripts miss?

Because a script can only fail on the assertion someone wrote. A person notices everything else on the screen.

• Scripts follow the happy path the author imagined. Real users double-click, go back, open two tabs and paste emoji into number fields.
• Scripts check one thing. A test that asserts "order created" passes while the confirmation email shows the wrong currency.
• Scripts do not adapt. When a tester sees something odd, they dig. A script moves on.
• Scripts age. They test last quarter's risks. A tester exploring a new feature tests this week's.

None of this argues against automation. It argues for using people where people are strong; manual vs automated testing covers the split.

How do you run an exploratory testing session?

The common structure is session-based test management, developed by Jonathan and James Bach and described in their Session-Based Test Management paper. It makes exploration accountable without scripting it.

1. Write a charter. One sentence of mission. Elisabeth Hendrickson's Explore It! popularised the template: explore a target, with resources, to discover information.
2. Time-box it. 60 to 90 minutes of uninterrupted testing. Shorter and the tester never gets deep; longer and attention fades.
3. Take notes as you go. What you tried, what you saw, questions, and bugs. Screen recording helps.
4. File bugs properly. Steps, expected, actual, evidence; the bug report template has the format.
5. Debrief. Ten minutes with a lead or developer: what was covered, what was found, what new charters it suggests.

A copyable session sheet:

CHARTER
Explore: checkout with a discount code
With: two browser tabs, an expired code, a code for another region
To discover: whether totals, tax and the order record always agree

SESSION
Tester: [name]    Date: [date]    Build: [version or commit]
Time box: 90 min  Actual: [min]   Testing / bug filing / setup: [% / % / %]

NOTES
- [what you tried and what happened]

BUGS FILED
- [ticket id] [one-line summary]

ISSUES AND QUESTIONS
- [anything blocking, unclear or worth a new charter]

Which heuristics do exploratory testers use?

Heuristics are rules of thumb that suggest where bugs hide. A few that pay off on almost every web product:

Heuristic	What you try	Typical bug it finds
Boundaries	Zero, one, the maximum, one over the maximum, empty, very long	Off-by-one limits, truncated names, crashes on empty lists
Interruptions	Back button, refresh mid-payment, close the tab, lose the network	Double charges, half-saved records, stuck spinners
Concurrency	Same record in two tabs or two users at once	Lost updates, stock sold twice
Roles and ownership	Change an ID in the URL; act as a lower role	Users reading other users' data
Data variety	Accents, right-to-left text, emoji, time zones, currencies	Broken sorting, wrong dates, mangled names
State and history	New account, old account, cancelled plan, expired trial	Empty-state crashes, features that unlock wrongly
Follow the data	Create it, then find it in emails, exports, reports and the admin panel	Totals that disagree between screens

The roles row deserves extra time on any multi-tenant product. Changing an ID and seeing whose data comes back is cheap to try and expensive to miss; for a deeper web security pass, see the OWASP Top 10 testing checklist.

When should you use exploratory testing?

• Before a new feature ships, once it is stable enough to use but before anyone writes regression scripts for it.
• After a large refactor, when the code changed but the behaviour should not have.
• Before launch, alongside the pre-launch QA checklist.
• When bugs keep reaching production despite green CI, which means the scripts are testing the wrong things.
• When there is no documentation. Exploration is how a tester learns what the product actually does.

What are the limits of exploratory testing?

• It does not repeat. A session is not a regression suite. Anything worth checking on every release should become an automated test; regression testing after every deploy covers that half.
• It depends on the tester. Skill and product knowledge drive results, which is why charters and debriefs matter.
• Coverage is harder to prove. Session sheets and charters are the evidence; without them, "we tested it" means little.
• It is not a security assessment. A tester changing IDs finds real access bugs, but that is not a penetration test.

Buy, build or hire?

Option	What you get	Choose this when	Watch out for
A tool or SaaS testing platform	Session recorders, note-taking and test management tools	Your team already explores and needs to capture evidence	Tools record sessions; they do not decide where to look
Freelancers or crowdtesting	Many testers exploring at once, often across devices and countries	You want breadth fast, for example before a launch	Quality varies; crowd testers rarely know your domain or your earlier bugs
An in-house QA hire	A tester who builds deep product knowledge over months	You ship often and can keep one person focused on quality	In-house testers get pulled into regression runs and lose exploration time
A managed QAaaS team	Chartered sessions planned against your risks, with reports and debriefs	You want exploration done regularly without hiring	Ask to see session sheets and sample bug reports first

Why RAITHub for exploratory testing?

• Exploration next to automation. Exploratory testing is part of RAITHub's QA as a service, so a bug found in a session can become an automated regression test instead of a note.
• Testers who know how web apps break. RAITHub builds multi-tenant platforms, so sessions aim at the places those systems fail: permissions, money and data that must agree across screens.
• Evidence you keep. Charters, session sheets and bug reports are delivered to you.

There is no published exploratory-testing case study yet, so judge it on a one-off audit's report.

When you don't need us

• Your team has a curious tester with time. Give them the charter template and protect their sessions.
• The product is tiny. A founder exploring for an afternoon with the heuristics table may be enough.

How RAITHub would test this

• Scope: a risk map of your product; a set of written charters aimed at the riskiest areas; time-boxed sessions with notes; reproducible bug reports in your tracker; a debrief with your developers.
• How you buy it: as a fixed-price one-off audit (for example before launch), as part of a monthly QA plan, or through a dedicated QA team that RAITHub manages and bills monthly. No staff augmentation.
• Timeline: the number of sessions and the dates are fixed in the written quote.
• What you receive: charters, session sheets, bug reports, and a list of checks worth automating, with an NDA as standard. See the manual and exploratory testing service.
• Next step: a free 15-minute audit call, then a fixed written quote.

For a one-off pass, choose a QA audit on the contact form.

Last reviewed: 7 October 2026.

Frequently asked questions

Is exploratory testing the same as ad hoc testing?

No. Ad hoc testing has no plan or record. Exploratory testing has a written charter, a time box, notes and a debrief, so you can see what was covered and what was found.

How long should an exploratory testing session be?

60 to 90 minutes of uninterrupted testing is the common range in session-based test management. Shorter sessions rarely get deep; longer ones lose focus.

Can exploratory testing be automated?

Not the exploring itself, because it depends on a person reacting to what they see. What it discovers can be: once a session finds a bug, write an automated test so it cannot return unnoticed.

What is a test charter?

A one-sentence mission for a session: what to explore, with which resources, to discover what information. It focuses the tester without scripting their steps.

Who should do exploratory testing?

Someone who knows how software tends to fail and has time to learn your product. Developers, product managers and support staff can contribute sessions, but a skilled tester usually finds more per hour.

Does RAITHub offer exploratory testing on its own?

Yes, as a fixed-price one-off audit, or as part of a monthly QA plan or a RAITHub-managed dedicated QA team.