AI-Assisted Exploratory Testing with Claude: The Co-Pilot for Test Sessions

1. What sets exploratory testing apart from scripted testing

Exploratory testing is a test method where test design, execution, and learning happen at the same time, instead of working through steps written in advance. A tester formulates a question, for example whether the discount logic stays consistent with stacked coupons, and adjusts the next action in real time based on what the application currently shows. This adaptability is the decisive difference from scripted testing, where every step is fixed in advance and deviations from the script often go unnoticed.

The value of exploratory testing lies exactly in finding things nobody explicitly anticipated. Scripted tests reliably confirm known behavior, but fundamentally only cover what was already thought of when the script was written. Exploratory testing, on the other hand, finds the surprises: a race condition on a rapid double click, an inconsistency between two languages in the same form, an unexpected side effect of a seemingly unrelated function.

This is exactly where AI-assisted exploratory testing comes in: Claude can offer suggestions for the next direction to investigate during a session, without taking over the actual discovery. The creativity and instinct stay with the human, while the AI can substantially strengthen the system used for heuristics and documentation.

2. Why Claude is a good sparring partner for exploration

A central problem in exploratory testing is so-called tunnel vision: a tester finds an interesting path and follows it deeper and deeper, while neighboring, equally relevant areas of the application go unexamined. Claude can counteract this in the moment by asking, after each block of observations, which related areas have not yet been investigated, or by suggesting a short list of alternative directions based on the session's progress so far.

A second advantage lies in knowledge of typical error types. Claude has broad knowledge of documented bug patterns from a wide range of software projects, from off-by-one errors to inconsistent error messages to race conditions in asynchronous forms. This knowledge can be pulled in deliberately during a session: instead of wondering what to look for next, the tester can ask Claude for known error patterns that fit the functionality currently under test, such as checkout flows or form validation.

The division of roles matters: Claude suggests directions and patterns, the human decides which of them actually make sense in the concrete application and follows them up with their own observational skill. This split preserves the creative substance of exploratory testing while reducing blind spots caused by tunnel vision or time pressure.

3. Preparing session-based test management with Claude

Session-based test management, SBTM for short, structures exploratory testing into clearly bounded time windows with a fixed goal, the test charter, and a defined outcome, the session report. Before starting a session, Claude works well to realistically assess scope: how many functional areas does the planned charter cover, is the planned ninety minutes sufficient, or should the charter be split in two for a more focused session?

This upfront assessment saves significant time in practice, because too broadly formulated charters regularly cause a session to skim across many areas superficially without going deep anywhere. Claude can, based on a feature description and its estimated complexity, provide a recommendation on session length and charter scope, drawn from experience-based patterns of comparable test scenarios.

# Ask Claude to assess charter scope before starting a session
claude -p "Given this charter: 'Explore the checkout flow with
combined coupon codes and gift cards.' Estimate whether 90 minutes
is realistic, or suggest splitting into narrower charters."

# Example refined output used as session input
# Charter A (45 min): Coupon code stacking rules and edge cases
# Charter B (45 min): Gift card balance interaction with coupons

4. Writing and refining a test charter with Claude

A good test charter briefly and precisely describes what should be investigated, why it matters, and what resources are available, without prescribing concrete test steps up front. The typical formula reads: "Explore <target area> with <resources> to find out <information>." A weak charter like "test the checkout" offers barely any orientation, while "explore checkout with expired discount codes combined with an active coupon to find out whether the price display stays consistent" gives a clear direction without constraining the exploration.

Claude works well for shaping a rough first draft into a more precise charter. A prompt like "improve this test charter so it names a concrete risk while staying open to exploration" often produces significantly more focused wording. Claude can also propose several alternative charters for the same feature, so a team can deliberately allocate limited time to the riskiest areas, instead of leaving the scope of exploration to chance.

5. Using Claude as a co-pilot during the test session

During the actual session, Claude Code can be kept open in parallel to manual testing in a second window, to resolve short intermediate questions: what should happen according to the specification for this edge case, which related function could be affected by this change, which comparable bugs have historically been found in this module? These intermediate questions barely interrupt the testing flow, but deliver valuable context the tester would otherwise have to research separately.

A proven pattern is briefly asking Claude, after each interesting finding, which related scenarios should still be investigated before moving on to the next topic area. This follow-up counteracts the already mentioned tunnel vision and ensures a found problem is not viewed in isolation, but examined in its full scope, for example whether a rounding error also occurs for other currencies or tax rates.

# Quick mid-session check to counteract tunnel vision
claude -p "I just found a rounding error when combining a percentage
discount with a fixed coupon in EUR. Before I move on: which related
areas of the checkout should I check next — other currencies, other
tax rates, or other discount combinations?"

# Typical Claude response used to steer the next 10 minutes of the session:
# 1. Same combination with a currency using 0 decimal places (e.g. JPY)
# 2. Same combination with a tax-inclusive price display
# 3. Three stacked discounts instead of two

6. Capturing observations in a structured way

A common problem in exploratory testing is loss of context: a tester notices something interesting, notes it briefly, and hours later can no longer reconstruct which exact steps led to the observation. Claude can act as a structuring writing assistant during the session, turning the tester's short bullet points into complete, traceable notes with context, steps, and observation.

These notes can be immediately shaped into a consistent format directly usable for the later session report or for a ticket in the bug tracking software. This eliminates the time-consuming rework at the end of a session, where raw notes must be translated into understandable sentences while details have already started to fade.

# Example: turning raw session notes into a structured observation
# using Claude as a formatting assistant during the session

raw_note = """
checkout, 2 coupons, price wrong, 3.50 off but should be 5.00
happened after adding gift card too
"""

# Prompt sent to Claude:
prompt = """
Turn this raw exploratory testing note into a structured
observation with: Context, Steps to reproduce, Expected,
Actual, Severity guess. Keep it factual, no speculation
beyond what is stated.
"""

# Resulting structured note (used verbatim in the session report):
structured_note = {
    "context": "Checkout with two stacked coupon codes plus a gift card",
    "steps": [
        "Add product worth 50.00 to cart",
        "Apply coupon A (10% off)",
        "Apply coupon B (5.00 fixed discount)",
        "Apply a gift card with sufficient balance",
    ],
    "expected": "Total discount of 10.00 (5.00 percent + 5.00 fixed)",
    "actual": "Total discount shown as 8.50",
    "severity_guess": "Medium — incorrect total, no crash",
}

7. Applying heuristics such as SFDPOT with Claude

Established test heuristics such as SFDPOT, an acronym for Structure, Function, Data, Platform, Operations, and Time, give exploratory sessions a thinking structure without losing the freedom of the method. Claude can view a feature description through these six lenses and formulate concrete questions for each, for example under Data: what happens with an extremely long product name, an empty required field, or an unusual character encoding in the form field?

This heuristic-based preparation is especially valuable for testers who have little experience with a new feature area yet. Instead of starting from zero, Claude delivers a structured starting list of questions per heuristic category, which the tester prioritizes during the session and extends with their own observations. The heuristic remains a thinking tool, not a rigid script to work through.

{
  "charter": "Explore the gift card redemption flow",
  "heuristic": "SFDPOT",
  "generated_questions": {
    "structure": ["What are the visible sub-components of the redemption form?"],
    "function": ["What happens on partial redemption of the balance?"],
    "data": [
      "Empty gift card code",
      "Gift card code with trailing whitespace",
      "Extremely long product name shown next to the balance"
    ],
    "platform": ["Does the balance display correctly on narrow viewports?"],
    "operations": ["What happens if two tabs redeem the same card simultaneously?"],
    "time": ["What happens to a card exactly at its expiry timestamp?"]
  }
}

8. From exploration to automated regression

A bug found during exploratory testing is worthless if it is not permanently monitored after the fix. Claude can help, right after a successful session, derive an automated regression test from the structured observation note that exactly maps the session's reproduction steps. This transition from spontaneous discovery to lasting safeguard is one of the biggest practical levers of AI-assisted exploratory testing.

The generated regression test should reproduce the exact combination that led to the finding, not a simplified variant. If, for example, a rounding error is found in the combination of percentage discount and coupon, the automated test must map exactly that combination, not just one of the two discounts in isolation. Claude can reliably handle this translation from free observation into a precise, repeatable test case, provided the original note was well structured.

<?php
declare(strict_types=1);

namespace Mironsoft\Pricing\Test\Regression;

use Mironsoft\Pricing\Model\PriceCalculator;
use PHPUnit\Framework\TestCase;

/**
 * Regression test derived directly from an exploratory testing session note.
 * Reproduces the exact combination that revealed the rounding bug,
 * not a simplified subset.
 */
final class StackedDiscountRoundingRegressionTest extends TestCase
{
    public function testPercentagePlusFixedCouponRoundsCorrectly(): void
    {
        // From session note: cart 50.00, 10% coupon + 5.00 fixed coupon,
        // expected total discount 10.00, actual observed was 8.50
        $calculator = new PriceCalculator();

        $result = $calculator->calculateFinalPrice(
            quantity: 1,
            unitPrice: 50.00,
            coupons: ['PERCENT10', 'FIXED5'],
        );

        $this->assertEqualsWithDelta(40.00, $result, 0.01);
    }
}

9. Limits and comparison: human, AI, and combined

Claude cannot see an application, click through it, or recognize an unexpected visual detail with a human eye, for example a slightly shifted icon that points to a deeper layout bug. This sensory component of exploratory testing remains entirely human. Likewise, prioritizing which finding is important enough to pursue further remains a decision that requires business and user context Claude does not possess.

The practical value of AI-assisted exploratory testing therefore does not come from replacement, but from complementing: Claude carries the cognitive load of structuring, documenting, and remembering heuristics, while the human supplies the creative exploration, visual perception, and business framing. Teams who deliberately design this split report cleaner session reports and a higher hit rate when prioritizing found issues.

10. Summary

AI-assisted exploratory testing with Claude combines the strengths of both sides: the creative, adaptive search for the unexpected performed by the human, and systematic support for charter formulation, heuristic application, and documentation provided by the AI. Claude helps formulate more precise test charters, counteracts tunnel vision during the session, captures observations in a structured way, and turns found issues into automated regression tests.

The limits are equally clear: visual perception, actually clicking through the application, and business prioritization remain human tasks. Anyone who respects this division of labor gains substantially more structure in exploratory testing with Claude as a co-pilot, without losing its creative substance.

11. FAQ: AI-Assisted Exploratory Testing