Exploratory Testing

Scripted tests check what you already thought of. Exploratory testing is how you find what nobody thought of. In ISTQB terms it is an experience-based approach in which tests are designed, executed and evaluated at the same time, while the tester learns about the product. The result of each test shapes the next one.

That definition is often misread as “testing without a plan”. Done well, exploratory testing is highly structured: it has a mission, a time box, deliberate techniques, notes, and a debrief. This lesson shows how to do it that way.

Exploratory, scripted and ad hoc

	Scripted testing	Exploratory testing	Ad hoc testing
Test design	Done in advance	Done during execution, informed by results	None in particular
Guidance	Detailed steps and expected results	A charter: mission, scope, time box	None
Documentation	Test cases and results	Session notes, bugs, questions, coverage	Usually none
Repeatable?	Yes, by design	The session can be reviewed; exact steps vary	No
Strength	Consistency, regression, compliance evidence	Finding unexpected problems, learning fast	Quick, informal look

Scripted and exploratory testing are not rivals. Mature teams use scripted (often automated) checks for known, stable behaviour and exploratory sessions for new features, risky areas and anything that changed in unexpected ways.

When exploratory testing works best

• A new feature with thin or changing requirements.
• Time pressure, when there is no time to write detailed cases first.
• Complementing automation: the regression suite passes, but what has it missed?
• Learning a product quickly, for example when you join a new team.
• Investigating a reported failure that nobody can reproduce.
• Risk areas with a history of escaped defects.

It works less well where independent, repeatable evidence is required, for example some regulated contexts, unless the sessions are documented carefully.

Session-based test management

The most common way to give exploratory testing structure is session-based test management (SBTM). Work is organised into sessions:

1. Charter: what to explore and why.
2. Time box: an uninterrupted block, commonly 60 to 120 minutes.
3. Execution with notes: what you tested, what you found, questions, ideas for later.
4. Debrief: a short conversation with a lead or peer about results and next steps.

Writing a charter

A popular template from Explore It! by Elisabeth Hendrickson is:

Explore <target>
With <resources>
To discover <information>

Examples:

• Explore the discount code field at checkout with expired, malformed and very long codes to discover how validation and error handling behave.
• Explore the order history page with an account that has 500+ orders and orders in several currencies to discover performance and formatting problems.
• Explore the file upload with files of unusual types, sizes and names to discover security and robustness issues.

A good charter is focused enough to finish in one session and open enough to allow discovery. “Explore checkout” is too broad; “verify the Apply button is blue” is too narrow and is a scripted check.

Heuristics: where test ideas come from

During a session you need a steady supply of test ideas. Heuristics are rules of thumb that prompt them. Some widely used ones:

Data heuristics

Idea	Examples
Boundaries	0, 1, max, max + 1, empty, one character, very long
Wrong type	Letters in a number field, a number where a date is expected
Special characters	Quotes, apostrophes (O'Brien), emoji, right-to-left text, accented characters
Whitespace	Leading or trailing spaces, only spaces, tabs, line breaks
Injection-shaped input	<script> tags, SQL fragments, path traversal like ../../
Formats	Dates in other formats, numbers with commas as decimal separators

The Test String Generator produces many of these on demand.

Interaction and state heuristics

• Interrupt it: refresh mid-operation, press Back, close the tab, lose the network, let the session expire.
• Repeat it: double-click submit, open the same form in two tabs, replay the same request.
• Change the order: do steps out of sequence; deep-link into step three.
• Change the role: try the same action as a different user, as a logged-out user, as an admin.
• Change the environment: small screen, zoom to 200%, keyboard only, slow network, another browser.

CRUD and follow the data

Create something, then read, update and delete it, and follow the data everywhere it goes: lists, search, exports, emails, reports, APIs. Inconsistencies between places that show the same data are a rich source of bugs.

Tours

Tours, described by James Whittaker in Exploratory Software Testing, are themed paths through a product. A few examples: a money tour follows the features that sell the product, a landmark tour hops between key features in different orders, and a bad-neighbourhood tour revisits areas with many past bugs. Use them as prompts, not rules.

Taking notes

Notes turn a session from private activity into team knowledge. Keep them light but structured:

CHARTER  Explore discount codes at checkout with unusual inputs
         to discover validation and error-handling problems
TESTER   A. Tester      START 10:00   DURATION 90 min
BUILD    2026.11.3 on QA, Chrome 142

TEST NOTES
- Valid code in lower case: applied (ok)
- Code with trailing space: rejected "Invalid code" -> BUG-301
- 200-character code: request 500, generic error page -> BUG-302
- Applied code, then removed an item below min spend: code stays applied -> question Q1
- Two tabs, applied different codes: second tab silently replaces first (needs PO decision) Q2

BUGS      BUG-301, BUG-302
QUESTIONS Q1 should code be removed or warn? Q2 is one-code rule per tab or per order?
ISSUES    QA env payment sandbox slow, lost ~10 min
COVERAGE  Not tested: gift cards with codes, mobile layout

Record what you did not cover as carefully as what you did. It informs the next charter and the release risk picture.

The debrief

A 10 to 15 minute debrief after each session, often structured as PROOF:

• Past: what happened during the session?
• Results: what was achieved, which bugs and questions?
• Obstacles: what got in the way?
• Outlook: what still needs doing?
• Feelings: how does the tester feel about the area’s quality?

The debrief is where a lead decides follow-up charters, raises questions with the product owner, and spots areas that deserve automation.

Exploratory testing and automation

Exploratory testing is a human activity, but tools amplify it:

• Browser developer tools to watch network calls, console errors and storage.
• Proxies to inspect and modify requests.
• Scripts or API calls to set up complex state quickly, so the session time is spent exploring rather than clicking through setup.
• Test data generators for unusual inputs.

Findings flow the other way too: a bug found by exploration that could recur is a candidate for an automated regression test.

Practice exercise

You are given 90 minutes to explore a new “Share document via link” feature in a document editor. Users can create a link, choose “view” or “edit” permission, set an optional expiry date and revoke the link.

1. Write three charters using the explore/with/to-discover template.
2. For the first charter, list at least eight test ideas using the heuristics in this lesson.
3. Draft the coverage section of your session notes, naming two things you would deliberately leave for another session.

Show a model answer

1. Charters

• Explore link permissions with viewer, editor, owner and logged-out users to discover whether access control is enforced on every action.
• Explore link expiry with expiry dates at boundaries and in other time zones to discover when links actually stop working.
• Explore link revocation with open sessions and cached pages to discover whether revoked access is removed immediately.

2. Test ideas for the permissions charter

1. View link: try editing through the UI, and by replaying an edit API request with the view-link session.
2. Logged-out user opens a view link; then logs in as another user.
3. Change a link from edit to view while the editor has the document open.
4. Copy the link into a private window, another browser, and a mobile device.
5. Modify the link token by one character.
6. Edit user tries to change sharing settings or create new links.
7. Viewer tries download, print and copy if these are meant to be restricted.
8. Owner deletes the document; what happens for link users?
9. Same link opened in two tabs; permission changed in one.
10. Check the API response for the document does not include data the viewer should not see, such as other collaborators’ email addresses.

3. Coverage

Covered: permission enforcement via UI and API for view and edit links, logged-out access, permission change during an open session. Not covered (next sessions): expiry behaviour across time zones, and revocation with cached or offline pages. Questions for the PO: should viewers see the list of collaborators?

Key takeaways

• Exploratory testing is simultaneous learning, test design and execution, guided by a mission, not testing without a plan.
• Use session-based test management: charter, time box, notes, debrief.
• Write charters as explore target, with resources, to discover information, and derive them from risks.
• Use heuristics and tours to keep generating test ideas, and record what you did not cover.
• Exploratory and scripted or automated testing complement each other; exploration finds new problems, automation stops old ones returning.