Exploratory Testing — Session-Based Test Management Guide

DodaTech Updated 2026-06-24 4 min read

Exploratory testing is a hands-on approach where testers actively explore an application without predefined scripts, using their domain knowledge and creativity to find defects that formal test cases miss. In this guide, you will learn session-based test management (SBTM) — a structured way to plan, execute, and document exploratory testing sessions using charters, time boxes, and debrief reports. The QA team at DodaTech uses exploratory testing for every major Doda Browser release, catching usability issues that automated regression suites never surface.

Learning Path

flowchart LR
  A[Manual Testing] --> B[Test Case Design]
  B --> C[Exploratory Testing
You are here]
  C --> D[Usability Testing]
  D --> E[Session-Based Management]
  style C fill:#f90,color:#fff

What Is Session-Based Test Management?

Session-based test management (SBTM) gives exploratory testing a structure without losing its creative freedom. Each session has three components:

Component	Description	Duration
Charter	Mission statement for the session	Defines scope
Time box	Fixed duration with no interruptions	60–120 minutes
Debrief	Review of findings and coverage	15 minutes

Writing a Charter

A good charter follows the format: Explore [target area] with [resources] to discover [information]:

Explore the user registration flow using
Chrome and Firefox to discover validation
errors, UX friction, and error handling gaps.

// Charter tracking object
const session = {
  charter: "Explore checkout with promo codes to find discount calculation errors",
  area: "Checkout & Payments",
  startTime: new Date(),
  duration: 90, // minutes
  bugs: [],
  coverage: [],
  questions: []
};

Session Report Template

After each session, document findings in a structured report:

## Session Report

**Charter:** Explore file upload with large images to find performance issues
**Tester:** Alice
**Date:** 2026-06-24
**Duration:** 90 min

### Bugs Found
1. UPLOAD-001: 50MB PNG crashes upload handler
2. UPLOAD-002: Progress bar stuck at 99% for files >10MB
3. UPLOAD-003: No error message for unsupported .webp format

### Coverage
- [x] File size validation
- [x] Format whitelist
- [x] Progress indicator
- [x] Concurrent uploads
- [ ] Drag and drop

### Issues Requiring Clarification
- What is the maximum supported file size? (checking with PM)

Tracking Coverage with a Session Matrix

Use a session matrix to track which areas have been explored across multiple sessions:

sessions = [
    {"area": "Login", "tester": "Alice", "bugs": 3, "charter": "Explore SSO login flows"},
    {"area": "Search", "tester": "Bob", "bugs": 5, "charter": "Explore search with special characters"},
    {"area": "Upload", "tester": "Alice", "bugs": 2, "charter": "Explore bulk upload performance"},
    {"area": "Login", "tester": "Bob", "bugs": 1, "charter": "Explore password reset flow"},
]

matrix = {}
for s in sessions:
    key = s["area"]
    if key not in matrix:
        matrix[key] = {"sessions": 0, "bugs": 0, "testers": set()}
    matrix[key]["sessions"] += 1
    matrix[key]["bugs"] += s["bugs"]
    matrix[key]["testers"].add(s["tester"])

for area, data in matrix.items():
    print(f"{area}: {data['sessions']} sessions, {data['bugs']} bugs, {len(data['testers'])} testers")

Expected output:

Login: 2 sessions, 4 bugs, 2 testers
Search: 1 sessions, 5 bugs, 1 testers
Upload: 1 sessions, 2 bugs, 1 testers

Heuristics for Exploratory Testing

Heuristics guide your exploration without scripting every step:

FEW HICCUPS mnemonic:
F — Functionality (does it work?)
E — Error handling (what breaks?)
W — Workflow (can I complete tasks?)
H — History (browser back/forward)
I — Input (boundary values, special chars)
C — Consistency (same behavior across areas)
C — Capacity (load, timeout, concurrent)
U — Usability (is it intuitive?)
P — Performance (is it fast enough?)
S — Security (can I bypass access controls?)

Common Mistakes in Exploratory Testing

1. No Charter

Exploring without a mission leads to shallow coverage and untestable results.

2. Unbounded Sessions

Without a time box, testers chase rabbit holes and burn out.

3. No Documentation

Verbal findings are lost. Always write a debrief report.

4. Confirmation Bias

Testing only what you expect to work. Explore error paths and edge cases.

5. Skipping Setup

Not configuring test data or environments before the session wastes time.

Practice Questions

1. What are the three components of a session-based test management session?

Charter, time box, and debrief.

2. What format should a good charter follow?

"Explore [target area] with [resources] to discover [information]."

3. Why is a time box important in exploratory testing?

It prevents unbounded exploration and ensures focused, productive sessions.

4. How is exploratory testing different from scripted testing?

Scripted testing follows predefined steps. Exploratory testing combines test design and execution in real time.

Challenge: Write charters for five exploratory testing sessions on a file-sharing application. Cover upload, download, sharing, search, and account settings. Run each session for 60 minutes and document findings.

FAQ

What is the difference between exploratory testing and ad-hoc testing?

Ad-hoc testing is unstructured random testing. Exploratory testing is intentional — it uses charters, heuristics, and debriefs to produce reproducible results.

How long should an exploratory testing session be?

60 to 90 minutes is standard. Longer sessions lose focus; shorter sessions lack depth.

Can exploratory testing be automated?

The exploration itself cannot be automated, but you can automate regression tests for bugs discovered during exploration.

What tools support session-based test management?

Spreadsheets, test management tools like TestRail, and lightweight tools like Session Tester or a simple markdown log.