Exploratory Testing: Techniques, Charters, Session-Based Testing

Scripted cases catch what you already imagined. Exploratory testing is how skilled testers investigate under time pressure while designing the next check from the last surprise: charter a mission, time box, follow risk, take notes, and turn findings into better coverage.

This guide covers core ideas, charters, session-based test management, techniques, Agile usage, documentation templates, examples, and common mistakes. You will leave ready to run sessions that stakeholders can trust.

What Is Exploratory Testing?

Exploratory testing is an approach to testing that emphasizes learning, test design, and test execution as simultaneous activities. Instead of fully specifying every step before interacting with the product, the tester uses current information to choose the next experiment.

James Bach and Cem Kaner popularized modern exploratory practice as skilled, accountable, and teachable. The opposite of exploratory testing is not automation. The opposite is rigid script dependence that leaves no room for insight.

Core Loop

Learn the product
   -> Design a probe
      -> Execute the probe
         -> Observe the result
            -> Update your model
               -> Choose the next probe

That loop can last two minutes or two hours. Session structure keeps it from dissolving into unfocused browsing.

Exploratory Testing vs Ad Hoc Testing

Dimension	Exploratory testing	Ad hoc testing
Mission	Explicit charter	Often none
Time management	Time boxed sessions	Until someone stops
Documentation	Notes, bugs, debrief	Usually minimal
Skill model	Heuristics and risk	Personal habit
Accountability	Reportable coverage outline	Hard to review
Learning transfer	High when notes exist	Low

If your team says "we did exploratory" but nobody can say what was investigated, you probably did ad hoc testing. Rename it honestly or upgrade the practice.

Why Exploratory Testing Matters

Scripted testing is excellent for known expectations. It is weaker when:

• Requirements are incomplete.
• Users combine features in unexpected ways.
• Integrations fail in stateful sequences.
• UX confusion causes costly mistakes.
• Automation coverage is thin in a new area.
• Defects hide in transitions, not static screens.

Exploration shines at finding unknown unknowns. It also improves scripted coverage later, because discoveries become new cases.

Within the software testing life cycle, exploration often sits inside execution, but the thinking starts in requirement analysis when questions appear.

Session-Based Test Management (SBTM)

Session-based test management (SBTM), associated with Jonathan Bach and common exploratory practice, organizes exploration into focused sessions.

SBTM Building Blocks

1. Charter: the mission for the session.
2. Time box: often 45 to 120 minutes of uninterrupted work.
3. Session: the actual investigation.
4. Notes: what you did, saw, and wondered.
5. Debrief: short review with a lead or peer.
6. Reporting: bugs, risks, follow-ups, coverage summary.

Why SBTM Helps Managers and Testers

Managers get visibility without forcing every click into a test case. Testers get freedom without chaos. Debriefs transfer skill and catch tunnel vision.

Suggested Session Lengths

Context	Session length
Quick risk scan after a fix	30 to 45 minutes
Standard feature exploration	60 to 90 minutes
Deep integration investigation	90 to 120 minutes
Exhausted attention	Stop and split; tired exploration is weak

Protect the session from Slack if you can. Context switching destroys deep investigation.

Exploratory Testing Charter Examples

A charter states the purpose and scope of a session without scripting every step.

Charter Template

Explore [target]
with [resources]
to discover [information]

Strong Charter Examples

Explore password reset on web
with disposable inboxes and clock control
to discover security and usability failures around expiry and reuse

Explore checkout coupon stacking rules
with multi-item carts and expired codes
to discover incorrect totals, confusing messages, and permission leaks

Explore admin export for large tenants
with 10k record fixtures and slow network throttling
to discover timeouts, partial files, and misleading success states

Explore mobile navigation for first-time users
with a clean account and no tutorial skip
to discover onboarding dead ends and accessibility barriers

Weak Charters

Test the app

Click around checkout

Find bugs

Weak charters produce unfocused sessions and unreadable notes.

Charter Scope Controls

Good charters often include:

• In scope area.
• Out of scope boundaries.
• Priority risks.
• Data or tools available.
• Compatibility targets if relevant.

Example with boundaries:

Explore invite-to-workspace flow on web only
(out of scope: native apps, SCIM provisioning)
with two roles (admin, member)
to discover authorization gaps and expired invite behavior

How to Run an Exploratory Session Step by Step

Step 1: Pick a Risk Worth the Time

Sources of charters:

• New or changed features.
• Areas with recent production incidents.
• Complex state machines.
• Money, auth, privacy, and data integrity paths.
• Weak automation zones.
• Support ticket clusters.

Step 2: Prepare Setup Quickly

• Build and environment confirmed.
• Accounts and roles ready.
• Note file open.
• Recording tool ready if needed.
• Known issues list nearby so you do not refile noise.

Step 3: Start the Clock and State the Charter

Write the charter at the top of the notes. This keeps you honest when a distraction appears.

Step 4: Alternate Between Tours and Deep Dives

If something strange appears, decide:

• Park it as a note and continue the mission, or
• Follow it because it is on charter and high value.

Do not chase every shiny UI quirk if your charter is payment integrity.

Step 5: Capture Notes in the Moment

Use short, timestamped lines. Pretty prose can wait.

10:05 created project as admin
10:12 invited member email, token looks single use
10:18 accepted invite in second browser, role became admin unexpectedly
BUG? privilege elevation
evidence: screenshot 3, network invite accept response

Step 6: File Bugs Properly After or During Pause Points

Convert solid failures into quality defect reports. Do not leave critical issues as private scribbles. Use a strong bug report structure when you file.

Step 7: Debrief

A 10 minute debrief can ask:

• What did you cover?
• What mattered most?
• What is still risky?
• What should become scripted or automated?
• What blocked you?

Step 8: Convert Learning

• New test cases for durable risks.
• Automation candidates.
• Requirement questions for product.
• Follow-up charters.

This conversion is how exploration improves long term quality systems, including how you write test cases.

Techniques and Heuristics You Can Use While Exploring

Exploratory testing is not technique free. It uses many design ideas dynamically.

Functional Tours

• Happy path tour: can a careful user succeed?
• Backdoor tour: deep links, refreshed pages, browser back.
• CRUD tour: create, read, update, delete across states.
• Interrupt tour: cancel, retry, double submit, offline blips.

Data Tours

• Empty, one, many, max.
• Unicode, emoji, RTL text.
• Boundary values and invalid classes on the fly using BVA and EP thinking.
• Stale data and concurrent edits.

State and Workflow Tours

• Save mid wizard and resume.
• Session timeout mid operation.
• Multi-tab edits.
• Role switches.
• Feature flag flips.

Risk Heuristics (Samples)

• Follow the money: payments, refunds, credits, tax.
• Follow the user trust: auth, privacy, permissions.
• Follow the data: imports, exports, migrations, reports.
• Follow the integration: webhooks, email, third parties.
• Follow the change: files touched by the latest commit.

Compatibility and Context

• Browser differences for UI logic.
• Mobile viewport behavior.
• Slow network.
• Locale and timezone edges.

Heuristics do not guarantee bugs. They generate better probes faster.

How to Document Exploratory Testing Sessions

Documentation should be light enough to keep flow and rich enough to review.

Session Note Template

Session ID:
Tester:
Date:
Build / environment:
Charter:
Time box:
Setup / data:
Notes:
Bugs filed:
Questions / ambiguities:
Coverage outline:
Risks remaining:
Follow-ups:
Percent on charter vs opportunity / setup (optional):
Debrief with:

Coverage Outline Example

Instead of claiming "fully tested," outline:

Covered:
- Invite send as admin
- Accept as new user
- Accept as existing user
- Expired invite message
Not covered:
- SSO invited users
- Invite storm rate limits
- Mobile web
Issues:
- BUG-512 role elevation on accept

This is honest and useful.

Optional Metrics in SBTM

Some teams track rough percentages of session time:

• Charter work
• Opportunity testing (interesting side paths)
• Setup / blocked time

Do not weaponize the metrics. Use them to spot environment pain and chronic interruption.

Exploratory Testing in Agile

When to Use Exploratory Testing in Agile

Use exploration:

• Every sprint on new stories after basic checks pass.
• After major refactors even if unit tests are green.
• Before release on high risk journeys.
• After production incidents to hunt relatives of the bug.
• When requirements change mid sprint and scripts lag.

A Practical Agile Mix

Activity	Role
Unit and API automated tests	Fast feedback on known logic
UI automated smoke or critical paths	Build confidence
Scripted feature cases	Explicit acceptance coverage
Exploratory sessions	Discovery and risk hunting
Hardening exploratory day	Cross feature interactions

Exploration is not a substitute for smoke and regression discipline. It is a partner. Smoke says the build is testable. Regression protects known value. Exploration searches for what nobody fully specified.

Story Level Pattern

1. Clarify acceptance criteria.
2. Automate or script critical expected paths.
3. Run one focused exploratory charter on the story risks.
4. File bugs and questions.
5. Add regression coverage for serious finds.

Pair and Mob Exploratory Testing

Exploring in pairs can raise quality of attention.

Formats:

• Driver and navigator switch every 10 to 15 minutes.
• Developer and tester pair on a risky feature.
• Mob session for a release candidate with rotating hands.

Rules:

• One charter at a time.
• Shared notes visible.
• Bugs filed with clear owners for reproduction data.

Pairing is also a training engine for junior testers.

Worked Example: 75 Minute Session

Product area: team billing seats
Build: staging 2.4.1
Charter: Explore seat changes when members are invited, deactivated, and reactivated to discover billing miscounts and permission issues.

Timeline

0-10 min: setup accounts, open notes, confirm plan prices
10-25: add seats, invite members, observe pending vs active counts
25-40: deactivate member, check immediate billing display
40-55: reactivate, attempt over-seat invite
55-70: double tab seat update race
70-75: file bugs, summarize coverage

Findings Style

• BUG: deactivated user still counted as billable for 24 hours with no UI notice.
• QUESTION: is grace period intentional? Not in story.
• RISK: race on two admins changing seats concurrently may over-allocate.
• FOLLOW-UP charter: invoice PDF totals after mid-cycle seat changes.

This session produced product questions and durable risks, not only pass/fail marks.

Converting Exploration into Durable Assets

Discovery type	Convert into
Stable important behavior	Scripted test case
Repeatable high value check	Automated test
Ambiguous rule	Product question or requirement update
Rare severe risk	Monitoring or alert idea, plus test if feasible
Usability friction	UX issue with evidence, not always a "bug"

Exploration without conversion wastes organizational learning.

Tooling That Helps Without Taking Over

Useful support tools:

• Note apps or markdown files.
• Screen recording.
• Browser devtools.
• Proxy tools when inspecting traffic.
• Feature flag consoles.
• Test data generators.
• Simple checklists of heuristics.

Avoid tools that force every action into heavyweight script format during the session. Capture freely, structure later.

Common Mistakes in Exploratory Testing

Mistake 1: Calling Chaos Exploration

If there is no charter, no notes, and no debrief, do not brand it as exploratory testing. Call it ad hoc and improve.

Mistake 2: Exploring Instead of Smoke

On a broken build, fix the gate first. Exploration on a non-startable app wastes skilled time.

Mistake 3: Never Filing Bugs Until Days Later

Memory decays. Evidence disappears. File or at least capture reproduction the same day.

Mistake 4: Infinite Sessions Without Debrief

Long unreviewed exploration hides weak strategy and duplicates effort across testers.

Mistake 5: No Link to Risk

Exploring theme colors for two hours while payment is untested is a prioritization failure, not thoroughness.

Mistake 6: Refusing Scripts Entirely

Exploration purism leaves regression fragile. Use both.

Mistake 7: Over-Documenting to the Point of Freezing

If notes become novels mid session, you stop testing. Use short fragments, then polish defect reports.

Mistake 8: Measuring Success Only by Bug Count

A session that clarifies a dangerous ambiguity can be more valuable than three trivial UI nits.

Team Playbook You Can Adopt This Week

1. Agree on a charter template.
2. Reserve two 60 minute sessions per tester per sprint for pure exploration on risky areas.
3. Require notes stored in a shared folder or ticket.
4. Run 10 minute debriefs for new testers and high risk areas.
5. Tag filed bugs with found-by-exploratory for learning analytics.
6. Convert at least one discovery per session into a durable check when relevant.
7. Review blocked time to improve environments.
8. Teach three heuristics in your next team meeting.

More Exploratory Testing Charter Examples by Risk Type

Security Oriented

Explore role switching and direct object references in project settings
with admin and member accounts on two tenants
to discover unauthorized reads or updates across tenant boundaries

Data Integrity Oriented

Explore concurrent edits on the same task description
with two browsers and slow network throttling
to discover lost updates, confusing merge behavior, and misleading success toasts

Resilience Oriented

Explore checkout while payment sandbox is delayed or erroring
with retries, double clicks, and back button use
to discover duplicate orders, stuck spinners, and unclear recovery paths

Usability Oriented

Explore first-time report builder with no sample data
with a new account and empty tenant
to discover dead ends, jargon, and missing empty states

Rotate risk types across a sprint so exploration does not always attack the same comfortable UI surface.

Note Taking Styles You Can Steal

Timeline Style

14:01 open billing
14:04 change seats 3 -> 5
14:07 invoice preview still shows 3
BUG candidate

Mind Map Style (text)

Invites
  - send
  - resend
  - expire
  - accept existing user
  - accept new user
  - revoke
Permissions
  - member cannot invite
  - admin can
Questions
  - can owner transfer with pending invites?

Bug First Style

Capture failure seeds immediately, then fill context:

SEED: total negative after stacked coupons
need: cart data, flags, recording

Pick a style you will actually maintain under pressure.

Leading Exploratory Testing on a Team

If you lead QA, make exploration visible:

1. Publish a weekly risk theme (auth, billing, imports).
2. Assign charters, not only tickets.
3. Review two session notes in 1:1s for coaching.
4. Track how many exploratory finds become regression assets.
5. Protect calendar time; exploration dies when only "free time" is allowed.
6. Invite developers to one paired session per release on their feature.

Leaders who only measure scripted execution will get only scripted behavior from the team.

When Exploration Should Stop

Stop or pause a session when:

• The environment is too broken for learning.
• You are too tired to notice subtle signals.
• The charter is done and residual risks are listed.
• You discovered a blocker that needs a new build before more testing is valuable.
• You are repeating the same probe without a new hypothesis.

Stopping well is part of professionalism. Endless unfocused clicking is not dedication.

Practice Exercise

Choose a public web app feature, such as signup.

Write this charter:

Explore signup validation and onboarding first-run state
with disposable email and mobile viewport
to discover confusing errors, state loss, and permission mistakes

Run 45 minutes with notes. Produce:

• Coverage outline
• One bug or UX issue report
• One follow-up charter
• One regression case candidate

Then compare with a peer. Differences in risks noticed will teach more than any definition quiz.

Second drill: rewrite three weak charters from your backlog into the "Explore X with Y to discover Z" form.

For competitive reps, take a manual challenge in the QABattle arena and force yourself to write a charter before you click. Afterward, convert notes into two formal cases and one defect style writeup.

Final Practical Workflow

When you need exploratory confidence:

1. Identify the highest uncertainty or business risk.
2. Write a sharp charter with boundaries.
3. Time box the session and protect focus.
4. Prepare data and evidence tools.
5. Investigate with heuristics, not only happy paths.
6. Take timestamped notes and capture proof.
7. File high quality bugs and questions.
8. Debrief coverage and residual risk.
9. Convert durable lessons into cases or automation.
10. Schedule the next charter where risk remains.

If you remember one principle, remember this: exploratory testing is skilled investigation under a mission. Charters give direction, sessions give focus, notes give accountability, and conversion gives long term value. Do that consistently and your team will find the problems scripts were never told to look for.

Schedule your next session before you finish reading. Write one charter for your riskiest current feature, set a 60 minute timer, and take notes as if a teammate will debrief you. That single habit builds more skill than another hour of definitions.