Exploratory Testing

What it is

Exploratory testing is simultaneous learning, test design and execution. Instead of following a predefined script, the tester designs and runs tests as understanding grows, following curiosity and risk rather than a checklist. It explores where scripted tests cannot: the unexpected, the ambiguous, the integration seam nobody specified.

1
  charter ──► session (time-boxed) ──► notes / debrief
2
     │              │                        │
3
     └ a mission     └ explore + learn + test └ findings → new tests or bug reports

The disciplined form is Session-Based Test Management (SBTM): each session is time-boxed (typically 60-120 minutes), driven by a written charter (a one-line mission), and produces a debrief and notes. Heuristics give the exploration structure — for example SFDIPOT (Structure, Function, Data, Interfaces, Platform, Operations, Time) or the quality criteria CRUSSPIC STMPL.

When to use it / when to avoid it

Use it for

New or poorly specified features where scripted tests would miss things
Investigating a suspicious bug where the cause is unknown
Complementing automation — humans explore, machines repeat
Finding the risks that requirement documents never mentioned

Avoid it when

The check is stable and repeatable → automate it instead
You need an auditable pass/fail record for a release → use acceptance testing
You need to prove nothing else broke → use regression testing

Frameworks & tools

Tool	Ecosystem	Notes
Session sheets / SBTM	Process	Charter, time-box, debrief; the core discipline
Rapid Reporter	Multi	Timed-session note-taking tool for explorers
Exploratory Testing Chrome Extension	Browser	Tracks actions and captures screenshots during a session
Charters / mind maps	Process	Structure areas and risks before exploring
Heuristics (SFDIPOT, FEW HICCUPPS)	Process	Mnemonics that make exploration systematic
Playwright / Cypress	Multi	Capture a found path as an automated check
DevTools	Browser	Inspect network, console and layout live while exploring
Bug trackers (Jira, GitHub Issues)	Multi	Turn findings into tracked, reproducible reports

Quick setup

1
# Chrome extension for session capture, plus a scripted repro after you find a bug
2
npm install -D @playwright/test
3
npx playwright codegen https://staging.example.com

1
# Turn a found path into a repeatable check once exploration ends
2
pip install pytest playwright
3
playwright codegen https://staging.example.com

1
# Rapid Reporter is a standalone tool; use Go for any harness you build
2
go test ./exploratory/... -run TestFuzz

1
<!-- Jira/Xray integration lives in your tracker; SBTM sheets are the workflow -->
2
<dependency>
3
  <groupId>io.github.bonigarcia</groupId>
4
  <artifactId>webdrivermanager</artifactId>
5
  <version>5.9.2</version>
6
  <scope>test</scope>
7
</dependency>

1
# Session sheets + a tracker is the core; automate repros with Playwright .NET
2
dotnet add package Microsoft.Playwright.NUnit

Example

1
Charter:   Explore coupon redemption at checkout to find pricing errors.
2
Areas:     discount stacking, expired codes, currency rounding, partial refunds
3
Duration:  90 minutes
4
Heuristics: SFDIPOT (Data, Time), FEW HICCUPPS (Consistency, Claims)
5
Learnings: -
6
Bugs:      -

1
import { test, expect } from '@playwright/test';
2

3
test('explored: stacking two coupons double-applies the discount', async ({ page }) => {
4
  await page.goto('/checkout');
5
  await page.getByLabel('Coupon').fill('SAVE10');
6
  await page.getByRole('button', { name: 'Apply' }).click();
7
  await page.getByLabel('Coupon').fill('SAVE10');
8
  await page.getByRole('button', { name: 'Apply' }).click();
9

10
  await expect(page.getByTestId('order-total')).toHaveText('$90.00');
11
});

1
def test_stacking_coupons_does_not_double_apply(page):
2
    page.goto("/checkout")
3
    page.get_by_label("Coupon").fill("SAVE10")
4
    page.get_by_role("button", name="Apply").click()
5
    page.get_by_label("Coupon").fill("SAVE10")
6
    page.get_by_role("button", name="Apply").click()
7
    assert page.get_by_test_id("order-total").inner_text() == "$90.00"

1
func TestStackingCouponsDoesNotDoubleApply(t *testing.T) {
2
  if err := page.Goto("/checkout"); err != nil {
3
    t.Fatal(err)
4
  }
5
  applyCoupon(t, page, "SAVE10")
6
  applyCoupon(t, page, "SAVE10")
7
  if got := totalText(t, page); got != "$90.00" {
8
    t.Fatalf("mong doi $90.00, nhan %s", got)
9
  }
10
}

1
@Test
2
void stackingCouponsDoesNotDoubleApply() {
3
    driver.get(baseUrl + "/checkout");
4
    applyCoupon(driver, "SAVE10");
5
    applyCoupon(driver, "SAVE10");
6
    assertEquals("$90.00", totalText(driver));
7
}

1
[Test]
2
public async Task StackingCouponsDoesNotDoubleApply()
3
{
4
    await Page.GotoAsync("/checkout");
5
    await ApplyCouponAsync("SAVE10");
6
    await ApplyCouponAsync("SAVE10");
7
    Assert.That(await TotalTextAsync(), Is.EqualTo("$90.00"));
8
}

Anti-patterns & best practices

Always charter the session. A mission keeps exploration focused and reportable.
Time-box it. Fixed sessions prevent unbounded wandering and make effort measurable.
Take notes as you go. Undocumented exploration is lost knowledge; notes become tests and bugs.
Use heuristics for coverage. SFDIPOT and FEW HICCUPPS turn curiosity into structure.
Convert findings into automation. Once a bug is understood, capture a repeatable check.
Debrief every session. Review learnings, bugs and new charters; exploration should compound.