What is Exploratory Testing? A Practical Guide

Your test scripts pass. Your automation suite shows green. But users still report bugs that nobody caught. Why? Because scripted tests only find what they're designed to find. Exploratory testing finds the rest.

This guide covers how to conduct exploratory testing effectively, when to use it, and how to structure sessions that consistently uncover issues scripted testing misses.

Quick Answer: Exploratory Testing at a Glance

Aspect	Details
What	Simultaneous test design and execution where testers explore the application using their skills, intuition, and domain knowledge
When	After scripted tests pass, during early development, when learning new systems, for risk areas
Key Deliverables	Session notes, bug reports, test ideas, coverage maps, risk assessments
Who	Experienced testers, developers during pairing, product owners reviewing features
Best For	Complex user interactions, edge cases, usability issues, integration points

What is Exploratory Testing?

Exploratory testing is a software testing approach where test design and test execution happen at the same time. Instead of following pre-written scripts, testers actively explore the application, learning how it behaves and designing tests based on what they discover.

James Bach, who formalized the concept, defines it as: "Simultaneous learning, test design, and test execution."

The tester uses their knowledge of the application, understanding of user behavior, and technical expertise to guide their testing. They make decisions in real-time about what to test next based on what they observe.

Key Point: Exploratory testing is not random testing. It is skilled, focused investigation guided by the tester's expertise and structured by session goals.

The Three Core Elements

Exploratory testing involves three activities happening together:

Learning - Understanding how the application works, what it should do, and where risks might exist

Test Design - Creating test ideas based on current observations and accumulated knowledge

Test Execution - Running tests and observing results, which feeds back into learning

These activities form a feedback loop. Each test execution reveals new information that shapes the next test decision.

Exploratory Testing vs Scripted Testing

Understanding the differences helps you choose the right approach for each situation.

Aspect	Exploratory Testing	Scripted Testing
Test Design	During execution	Before execution
Flexibility	High - adapts to findings	Low - follows predetermined steps
Documentation	Session notes, findings	Detailed test cases
Repeatability	Lower - each session unique	High - same steps each time
Skill Required	High testing expertise	Can follow written instructions
Coverage	Risk-based, discovery-driven	Requirement-based, planned
Speed of Feedback	Immediate	After full execution

Neither approach is superior. They serve different purposes:

Scripted testing works best for:

• Regression testing known functionality
• Compliance requirements needing documented steps
• Tests that must run identically each time
• Training new testers on system behavior

Exploratory testing works best for:

• Finding unexpected issues
• Testing complex user workflows
• Evaluating usability and user experience
• Investigating risk areas
• Learning new systems

Most effective testing strategies combine both approaches.

When to Use Exploratory Testing

Exploratory testing provides the most value in specific situations.

During Early Development

When features are new and requirements are still evolving, exploratory testing helps:

• Find fundamental design issues early
• Provide rapid feedback to developers
• Identify edge cases before they become entrenched
• Understand actual behavior versus intended behavior

After Scripted Tests Pass

Green test suites do not mean the software works correctly. They mean the specific scenarios tested work correctly. Exploratory testing fills gaps:

• Finding issues in untested scenarios
• Discovering unexpected interactions between features
• Identifying usability problems tests cannot catch
• Validating that fixes actually solve the problem

For Complex User Interactions

Some behaviors are difficult to script:

• Multi-step workflows with branching paths
• Data entry with many validation rules
• Features depending on external systems
• Performance under realistic usage patterns

When Learning a New System

Before writing test cases, testers need to understand the application:

• How features connect to each other
• Where complexity exists
• What users actually do versus what documentation says
• System boundaries and integration points

For Risk Assessment

Before a release, exploratory testing can target high-risk areas:

• Recently changed code
• Features with history of defects
• Complex business logic
• Third-party integrations

Practical Tip: Schedule exploratory testing sessions after your automation suite runs. The automation handles regression; exploration handles discovery.

Session-Based Test Management

Session-Based Test Management (SBTM) provides structure to exploratory testing without removing its flexibility. Developed by Jonathan Bach and James Bach, SBTM divides testing into time-boxed sessions with defined focus areas.

Anatomy of a Test Session

A session includes:

Charter - What you will explore and why

Time Box - Fixed duration, typically 60-120 minutes

Session Notes - Running record of activities, findings, and ideas

Debrief - Post-session discussion of findings and next steps

Why Time Boxing Matters

Fixed-duration sessions serve several purposes:

• Maintains focus and intensity
• Provides natural checkpoints for progress
• Makes testing measurable and plannable
• Prevents fatigue from degrading test quality

A 90-minute session provides enough time for meaningful exploration without mental exhaustion.

Session Metrics

SBTM introduces simple metrics for tracking testing effort:

Session Setup - Time preparing environment, data, and tools

Charter Execution - Time spent on the chartered mission

Bug Investigation - Time spent confirming and documenting defects

Opportunity Testing - Time exploring areas outside the charter

These metrics help teams understand where testing time goes and adjust accordingly.

Writing Effective Test Charters

A charter guides exploration without constraining it. Good charters answer three questions:

The Three-Part Charter Format

Explore - What area or feature to investigate

With - What resources, techniques, or data to use

To Discover - What information or issues you seek

Example charters:

Explore the checkout flow with items in multiple shipping categories to discover how shipping calculations handle split shipments.

Explore the search function with special characters and long strings to discover input validation and error handling behavior.

Explore the notification system with a user who has multiple devices to discover sync behavior and delivery timing.

Charter Scope

Charters should be:

• Specific enough to provide direction
• Broad enough to allow discovery
• Achievable within the time box

A charter that is too narrow feels like scripted testing. A charter that is too broad leads to unfocused wandering.

Common Mistake: Writing charters that are actually test cases. "Explore login with invalid password to verify error message appears" is a test case, not a charter for exploration.

Adjusting Mid-Session

Charters are not rigid constraints. If you discover something important outside your charter, you have options:

• Note it for a future session
• Spend limited time investigating (opportunity testing)
• End early and start a new session with a revised charter

Document why you diverged. This information helps with planning future sessions.

Exploration Techniques That Work

Effective exploratory testing uses specific techniques to maximize discovery.

Tours

James Whittaker introduced the concept of "software tours" - structured approaches to exploring an application:

Feature Tour - Systematically visit every feature in the application

Complexity Tour - Focus on the most complex functions and interactions

Claims Tour - Test every claim made in documentation or marketing

Configuration Tour - Explore different settings, preferences, and configurations

User Tour - Follow paths actual users take based on user research or logs

Boundary Tour - Find and test all system boundaries and limits

Heuristics

Heuristics are thinking tools that help identify test ideas:

CRUD - Test Create, Read, Update, Delete operations for all data

SFDPOT - Structure, Function, Data, Platform, Operations, Time (San Francisco Depot)

Goldilocks - Test with too little, just right, and too much

Follow the Data - Track data through its entire lifecycle

Zero, One, Many - Test with none, one, and multiple instances

State Transitions

Explore how the system handles state changes:

• Valid transitions (logged out to logged in)
• Invalid transitions (what happens if you try to skip steps?)
• Interrupted transitions (what if the connection drops mid-process?)
• Rapid transitions (click submit multiple times quickly)

Input Variations

Test inputs beyond happy path:

• Empty inputs
• Maximum length inputs
• Special characters
• Unicode and emoji
• Copy-pasted content
• Input from external sources

Environment Variations

Change the context:

• Different browsers or devices
• Various network conditions
• Different time zones and locales
• Low memory or CPU conditions
• Concurrent users

Documenting Your Findings

Good documentation makes exploratory testing valuable beyond the session.

Session Notes

During the session, capture:

• What you tested and how
• What you observed
• Questions that arose
• Ideas for future testing
• Bugs found (briefly - detailed reports come later)
• Areas not covered

Session notes do not need to be formal. They need to be useful.

Bug Reports

When you find defects, document them thoroughly:

• Clear title describing the issue
• Steps to reproduce
• Expected versus actual behavior
• Environment details
• Screenshots or videos
• Severity assessment

Better bug reports lead to faster fixes.

Coverage Notes

Track what you explored:

• Features or areas tested
• Techniques used
• Risk areas covered
• Gaps remaining

This helps with planning future sessions and demonstrating thoroughness.

Test Ideas

Exploration generates ideas faster than you can execute them:

• Capture test ideas as they occur
• Note the reasoning behind each idea
• Prioritize for future sessions or automation candidates

Best Practice: Many testers use lightweight tools during sessions - a text file, sticky notes, or dedicated session management software. The tool matters less than consistent capture.

Common Challenges and Solutions

Challenge: "Management Wants Test Cases"

Some organizations struggle with testing that does not produce detailed test cases.

Solution: Produce different artifacts. Session reports, coverage maps, bug reports, and risk assessments demonstrate thoroughness. Explain that the goal is finding problems, not generating documents.

Challenge: "How Do We Know It's Thorough?"

Without predetermined steps, coverage seems unmeasurable.

Solution: Track coverage by feature area, risk category, or user story. Session debriefs should explicitly address what was covered and what remains. Coverage is documented differently, not absent.

Challenge: "Results Vary by Tester"

Different testers exploring the same area find different things.

Solution: This is a feature, not a bug. Different perspectives find different issues. Rotate testers across areas. Use pair testing for critical functionality. Compare findings across sessions.

Challenge: "We Cannot Reproduce What We Found"

Quick notes during exploration may not capture reproduction steps.

Solution: When you find something significant, pause and document it immediately. Reproduce it before continuing. Screen recording tools capture your exact path.

Challenge: "It Takes Too Long"

Time-boxed sessions help, but testing still takes time.

Solution: Target exploration at high-risk areas. Use scripted automation for regression so exploration focuses on new territory. Integrate exploration into development sprints rather than treating it as a separate phase.

Real-World Example: Testing a Mobile Banking App

Here is how exploratory testing works in practice.

The Context

A team is developing a mobile banking application. The latest release adds a feature for scheduling recurring bill payments. Scripted tests cover the basic functionality: creating, editing, and canceling scheduled payments.

Session 1: Understanding the Feature

Charter: Explore the recurring payment setup flow with various payment frequencies to discover how the system handles scheduling edge cases.

Duration: 90 minutes

Findings:

• Setting a payment for the 31st of each month shows confusing behavior in February
• Changing the start date after setting a frequency resets the entire schedule without warning
• No indication of which payments have actually been submitted versus scheduled
• Timezone appears to use server time, not user's local time

Bugs Filed: 2 (date handling confusion, timezone issue)

Test Ideas Generated:

• Test payment scheduling around daylight saving time transitions
• Test what happens when a recurring payment fails
• Explore notification behavior for scheduled payments

Session 2: Integration Points

Charter: Explore interactions between recurring payments and account balance/overdraft features to discover how the system handles insufficient funds scenarios.

Duration: 90 minutes

Findings:

• Scheduled payment proceeds even with insufficient balance (overdraft used without explicit consent)
• No pre-payment balance check or warning
• Failed payment creates no user notification
• Retry behavior unclear - does it try again? When?

Bugs Filed: 3 (unauthorized overdraft, missing notifications, unclear retry logic)

Test Ideas Generated:

• Test interaction with spending limits feature
• Explore behavior when account is closed
• Test multiple scheduled payments on same day

Session 3: User Experience

Charter: Explore the payment history and management interface with multiple scheduled payments to discover usability issues.

Duration: 60 minutes

Findings:

• With more than 20 scheduled payments, list becomes unusable (no search, no filter)
• Edit button not visible without scrolling on smaller screens
• Delete confirmation too easy to dismiss accidentally
• No way to duplicate an existing scheduled payment

Bugs Filed: 1 (accessibility - delete confirmation)

Test Ideas Generated:

• Test with assistive technologies
• Explore offline behavior
• Test with slow network conditions

Session Outcomes

Three 90-minute sessions (plus one 60-minute follow-up) uncovered:

• 6 bugs that scripted tests missed
• Multiple UX improvements for the product backlog
• Ideas for 15 additional test scenarios

The scripted tests validated that the feature works as designed. Exploration revealed that the design had gaps.

Tools That Support Exploratory Testing

Session Management

Rapid Reporter - Free tool for session-based testing notes

TestBuddy - Browser extension for capturing notes and screenshots

Notion/Confluence - General-purpose tools adapted for session tracking

Screen Capture

Loom - Quick video recording with automatic sharing

OBS Studio - Full-featured recording for complex scenarios

Built-in OS Tools - Windows Game Bar, macOS Screen Recording

Note Taking

Plain Text Files - Simple, portable, searchable

Mind Mapping Tools - Visual representation of explored areas (XMind, Miro)

Session Sheets - Spreadsheet templates for structured capture

Bug Reporting

Jira, Azure DevOps, GitHub Issues - Standard defect tracking

BugMagnet - Browser extension for generating test data

Practical Tip: Start with tools you already have. The best tool is the one you will actually use. Fancy tools often add friction that slows testing.

Measuring Exploratory Testing Effectiveness

Useful Metrics

Session Count - How much exploratory testing occurred

Bug Discovery Rate - Bugs found per session or per hour

Bug Severity Distribution - Are exploration-found bugs critical or minor?

Coverage by Risk Area - Are high-risk areas getting attention?

Test Ideas Generated - Is exploration feeding the testing backlog?

Metrics to Use Carefully

Bugs Found (Absolute Number) - More bugs is not always better. A mature product may have fewer bugs to find.

Time Spent - Hours spent exploring means nothing without context about what was accomplished.

What the Metrics Tell You

Track metrics over time to identify patterns:

• Is bug discovery rate declining? Maybe exploration is complete or needs fresh perspectives.
• Are critical bugs appearing late? Maybe exploration should start earlier.
• Are certain areas generating more finds? Consider more focused sessions there.

Warning: Do not use metrics to compare testers. Individual session productivity varies based on the area explored, tester familiarity, and simple luck. Compare sessions to historical averages, not to each other.

Integrating with Agile Development

Exploratory testing fits naturally with agile development practices.

In Sprint Ceremonies

Sprint Planning - Identify areas that need exploration based on new features and risk

Daily Standups - Share significant findings; mention blocked exploration

Sprint Review - Demonstrate discovered issues; show coverage achieved

Retrospective - Discuss what worked and what to adjust

Parallel with Development

Do not wait until "testing phase." Explore as features are built:

• Explore early builds to catch design issues
• Work with developers to understand implementation
• Provide immediate feedback while context is fresh

With User Stories

For each story, consider:

• What aspects need scripted regression tests?
• What aspects benefit from exploration?
• What risks require targeted investigation?

Continuous Exploration

Integrate exploration throughout:

• Developers explore their own changes before code review
• Testers explore as features become available
• The whole team explores before major releases

Building Exploratory Testing Skills

Effective exploration requires specific skills that improve with practice.

Technical Understanding

Know how software works:

• Common bug patterns and where they occur
• How different components interact
• What happens when things fail
• Performance implications of design choices

Domain Knowledge

Understand the business:

• What users actually do with the software
• Why features exist and what problems they solve
• Where mistakes cause the most harm
• Industry regulations and requirements

Critical Thinking

Question everything:

• Does this make sense from a user perspective?
• What assumptions did developers make?
• What could go wrong that nobody considered?
• Why does this work? (Understanding success helps find failure)

Communication

Findings only matter if shared effectively:

• Clear bug reports that developers can act on
• Concise session summaries for stakeholders
• Honest assessment of what was and was not covered

Practice Opportunities

Weekend Testing - Online community sessions exploring donated applications

Bug Bash Events - Time-boxed team exploration of upcoming releases

Pair Testing - Work with another tester to learn their approach

Deliberate Practice - Pick an application and explore systematically

Conclusion

Exploratory testing is skilled investigation, not random clicking. It finds issues that scripted tests miss because it adapts to what it discovers rather than following predetermined paths.

Effective exploratory testing requires:

• Clear charters that guide without constraining
• Time-boxed sessions that maintain focus
• Good documentation of findings and coverage
• Integration with existing testing approaches

The goal is not to replace scripted testing. The goal is to find the bugs that scripts will never catch - the edge cases, the usability issues, the unexpected interactions that only emerge when a skilled tester asks "what happens if..."

Start small. Run a single focused session on your highest-risk feature. Document what you find. Adjust your approach based on results. Build exploration into your regular testing practice.

Your automation verifies what you expect. Exploration discovers what you did not.

Continue Reading

Frequently Asked Questions (FAQs) / People Also Ask (PAA)