Exploratory Testing

What Is Exploratory Testing? #

Exploratory testing is an approach where the tester simultaneously learns about the system, designs tests, and executes them — all in one continuous, cognitive process. It was formalized by James Bach and Cem Kaner, who defined it as:

“Simultaneously learning, test design, and test execution.”

Unlike scripted testing where you write all test cases first and then execute them step by step, exploratory testing adapts in real time. What you discover in one test influences what you test next. It is test design and execution interleaved.

The Mindset #

An exploratory tester is like a detective investigating a case. You start with a hypothesis (“this login form might be vulnerable to injection”), investigate it, discover new leads (“the error message reveals the database type”), and follow them. Each finding shapes your next move.

This requires:

• Curiosity — Constantly asking “what happens if…?”
• Critical thinking — Questioning assumptions and expected behavior
• Domain knowledge — Understanding what the software should do
• Technical awareness — Knowing common failure patterns and risk areas

Exploratory Testing Process #

The cycle is continuous: execution leads to observation, observation leads to new ideas, new ideas lead to new tests. This continues until the time-box expires.

Test Charters #

A test charter is a brief mission statement that guides an exploratory session. It prevents aimless wandering while leaving room for discovery.

Charter format:

Explore [target] with [resources/techniques] to discover [information/risks]

Examples:

Explore the checkout flow with boundary values and invalid credit cards to discover payment processing failures and error handling gaps.

Explore the search functionality with special characters, long strings, and empty queries to discover input validation and crash scenarios.

Explore the user profile page with different browsers and screen sizes to discover responsive design issues and cross-browser bugs.

Charter Quality Criteria #

A good charter is:

• Focused — Narrow enough to complete in 60-90 minutes
• Testable — Defines what you are looking for
• Risk-based — Targets areas where bugs are most likely or most impactful
• Flexible — Leaves room for discovery and deviation

A bad charter is too vague (“Explore the app”) or too specific (“Click the login button and verify the text says ‘Welcome’”).

Touring Heuristics #

Touring heuristics, developed by James Whittaker in “Exploratory Software Testing” (2009), provide structured approaches for exploring software. Think of them as different “tourist guides” for the same city:

The Guidebook Tour. Follow the user manual or help documentation step by step. Do the documented features work as described? Are there features mentioned in documentation but not in the software (or vice versa)?

The Money Tour. Test the features that customers pay for — the core value proposition. For an e-commerce site: browse, search, add to cart, checkout. For a project management tool: create project, add tasks, assign team members.

The Landmark Tour. Identify the major landmarks (key screens, important features) and navigate between them in various orders. Does the system maintain state correctly? Are there shortcuts that skip important steps?

The Antisocial Tour. Do everything the application does not want you to do. Enter invalid data, skip required steps, use the back button at critical moments, interrupt operations midway.

The Rained-Out Tour. Start operations and cancel them. What happens when you cancel a file upload at 50%? Close the browser during checkout? Lose network connection during a save operation?

The Obsessive-Compulsive Tour. Do the same thing repeatedly. Submit the same form 100 times. Click the save button rapidly. Refresh the page continuously. This uncovers race conditions and resource leaks.

When to Use Exploratory Testing #

Exploratory testing is most valuable when:

• A new feature arrives with minimal or no specifications
• Time is limited and you need maximum coverage quickly
• You want to find bugs scripted tests miss — especially UX issues and edge cases
• The system is complex and you cannot predict all scenarios in advance
• After automation reveals only expected paths — exploration finds the unexpected
• Risk areas need focused investigation
• You are learning a new application or domain

Exploratory vs. Ad Hoc Testing #

This distinction is critical. Many people confuse them, but they are fundamentally different:

Exploratory testing is a professional discipline. Ad hoc testing is useful for quick checks but cannot be relied upon as a systematic testing approach.

Exercise: Write Test Charters and Conduct Exploration #

Part 1: Write Test Charters

You are testing a food delivery mobile app. Write 3 test charters for the following scenarios. Use the format: “Explore [target] with [techniques] to discover [risks].”

1. A charter for the order placement flow
2. A charter for the app’s behavior under poor network conditions
3. A charter for the restaurant search and filtering feature

Part 2: Conduct a 30-Minute Exploratory Session

Choose one of your charters and conduct a 30-minute exploratory session on any food delivery app you have access to (or a similar web application). Document your session using this template:

CHARTER: [Your charter]
DURATION: 30 minutes
TESTER: [Your name]
DATE: [Date]

AREAS EXPLORED:
- [List areas you tested]

BUGS FOUND:
- [Bug 1: Description, severity, steps to reproduce]
- [Bug 2: ...]

ISSUES/QUESTIONS:
- [Any questions or concerns that arose]

RISKS NOT COVERED:
- [Areas you did not have time to explore]

% ON CHARTER: [How much time was spent on the charter vs. following new leads]

Part 3: Reflection

After the session, answer:

1. What did you discover that you would not have found with scripted test cases?
2. How did your exploration path change based on what you found?
3. What would you explore in the next session?

CHARTER: Explore the order placement flow with boundary values
         and rapid modifications to discover calculation errors.
DURATION: 30 minutes
TESTER: Student
DATE: 2026-03-19

AREAS EXPLORED:
- Adding minimum order amount ($0.01 items)
- Adding 99 of the same item
- Rapidly adding and removing items
- Applying and removing promo codes during item changes
- Changing delivery address after order is in cart
- Switching between pickup and delivery mid-order

BUGS FOUND:
- BUG-1 (Medium): When rapidly adding and removing the same item,
  the cart count badge shows negative number (-1) momentarily.
  Steps: Add item → Remove item → Add item rapidly 5 times.
- BUG-2 (High): Applying a promo code, then removing the item
  the promo applies to, still shows the discount on the total.
  Steps: Add pizza → Apply PIZZA50 promo → Remove pizza →
  Total still shows -$5 discount on remaining items.
- BUG-3 (Low): Switching from delivery to pickup does not
  remove the delivery fee from the total until page refresh.

ISSUES/QUESTIONS:
- Is there a maximum number of items per order? No error shown at 99.
- What happens to the promo code if the restaurant closes mid-order?

RISKS NOT COVERED:
- Multi-restaurant orders (didn't have time)
- Order placement with expired payment method
- Behavior when restaurant removes a menu item while it's in your cart

% ON CHARTER: 70% on charter, 30% following the promo code bug trail

Key Takeaways #

• Exploratory testing combines learning, test design, and execution in a continuous cognitive process
• Test charters provide focus without constraining discovery
• Touring heuristics offer structured approaches for systematic exploration
• Exploratory testing is a professional discipline — not random or ad hoc
• It is most valuable for new features, risk areas, time-limited testing, and finding bugs that scripted tests miss
• Session notes and charter-based reporting make exploratory testing accountable and traceable
• The best testing strategies combine scripted testing for known scenarios with exploratory testing for the unknown