exploratory-tours-reference
Pure-reference catalog of the seven exploratory testing tours from Whittaker's Exploratory Software Testing (2009): Feature, Money, Landmark, Intellectual, Bad-data, Configuration, and Garbage-collector's, each a themed mission with the signal it surfaces and a worked example. Use as the menu a charter author picks session themes from. Distinct from the mnemonic catalogs sfdpot-exploratory-heuristic (what to vary) and hiccupps-f-heuristic (oracles), and from session-based-test-management-reference, which manages the sessions.
Install with skills.sh (any agent)
npx skills add testland/qa --skill exploratory-tours-referenceexploratory-tours-reference
Overview
Tours keep an exploratory session focused: each tour frames the exploration around a theme that catches a specific class of bugs. The seven canonical tours come from James Whittaker's Exploratory Software Testing (2009, Addison-Wesley).
This skill is a pure reference - the charter author and the tester pick which tours to apply per session.
When to use
How to use
The seven tours
Each tour is a themed mission that catches one class of bug. Full mission, signal, worked example, and when-to-use per tour: references/tours-catalog.md.
| Tour | Mission | Signal it surfaces |
|---|---|---|
| Feature | Visit every in-scope feature at depth 1 | Does the feature exist / open / work? |
| Money | Find every place money / pricing / discount appears; verify each | Rounding, currency drift, discount-stacking, locale formatting |
| Landmark | Visit the canonical hero flows | Marquee features still work after a refactor |
| Intellectual | Explore the hardest-to-explain features | Bugs in genuinely complex business logic |
| Bad-data | Feed pathological inputs | Validation gaps, error handling, security, locale parsing |
| Configuration | Vary user / system config | Config-dependent bugs (flags, theme, locale, browser) |
| Garbage collector's | Visit every page / endpoint once | Dead links, 404s, stale routes, render issues |
Picking tours per charter
A 90-minute charter can include 1-3 tours. Pick based on the mission:
| Mission | Recommended tours |
|---|---|
| New-feature exploration | Feature tour + Money tour (if money) + Bad-data tour |
| Post-refactor regression check | Landmark tour + Garbage collector's tour |
| Bug-cluster investigation | Intellectual tour + Bad-data tour |
| Compliance / audit | Money tour + Configuration tour |
| New tester onboarding | Feature tour (alone) + reflection |
A charter with all 7 tours is too broad; the tester won't have time to apply any of them well.
Capturing tour findings
Per the PROOF debrief format, each tour produces:
Worked example - a new promo-checkout charter
Charter: "Explore the new promo-code checkout with sample carts to discover discount + input bugs."
1. Mission: new-feature exploration.
2. Pick tours (from the table): Feature + Money (money present) + Bad-data.
3. **Feature tour:** open checkout; promo field renders; apply button works. Pass.
4. **Money tour:** apply 10% off to a $24.99 cart โ expect $22.49. Then
stack two promos and check order of operations. FOUND: "STACK50"
applies after tax instead of before, reproduces 3/3.
5. **Bad-data tour:** paste a 5000-char code โ expect rejection;
`'; DROP TABLE users; --` โ expect escaping. Both handled.Result: one confirmed bug (B-001, promo applied post-tax) logged to the session sheet; Outlook recommends a follow-up Configuration-tour charter for EU-VAT carts.
Anti-patterns
Seven common ways a tour is misapplied (all-7-in-one-session, checklist rigidity, random Bad-data inputs, no rotation) and the fix for each: references/tour-anti-patterns.md.
Limitations
References
Tour anti-patterns
View source (opens in new window)Tour anti-patterns
Deep reference for exploratory-tours-reference SKILL.md. Failure modes that turn a tour from a focusing lens into wasted session time, with the fix for each.
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Picking all 7 tours for one session | Tester touches each superficially; no depth. | 1-3 tours per 90-min session. |
| Money tour without monetary fields | The tour wastes time on "verify nothing changed." | Pick tours per the feature; not all features need every tour. |
| Garbage collector's tour without a sitemap | Tester misses pages; coverage gaps invisible. | Use the team's sitemap / docs as the seed list. |
| Treating a tour as a checklist | Tour is a heuristic; rigid stepwise application defeats the exploration. | Tester adapts mid-tour as they learn (per the exploratory definition). |
| Bad-data tour with random inputs | Random isn't useful; structured pathological inputs are. | Use canonical payloads (malicious-payload-bank). |
| Intellectual tour without a domain expert pair | Tester misses the actual complexity; tour is shallow. | Pair with someone who knows the domain. |
| One tour run per release without rotation | The same tour by the same tester catches the same bugs (or none). | Rotate which tours run, which testers, what scope (Picking section). |
The seven tours in full
View source (opens in new window)The seven tours in full
Deep reference for exploratory-tours-reference SKILL.md. Consult when the compact table in the skill isn't enough and you want each tour's full mission, signal, worked example, and when-to-use guidance.
Tour 1 - Feature tour
Mission: Visit every feature in scope at depth = 1.
Signal: "Does the feature exist? Does it open without an error? Does its primary affordance work?"
Example application:
**Charter:** Explore the dashboard.
**Feature tour:**
1. Open the dashboard. Pass.
2. Click "Notifications" โ notification panel opens. Pass.
3. Click "Settings" โ settings page loads. Pass.
4. Click "Reports" โ 404. **FAIL** - investigate.When to use: New feature; post-deploy smoke; feature-coverage gap survey.
When NOT to use: Deep-dive sessions where the depth-1 sweep provides no signal.
Tour 2 - Money tour
Mission: Find every place money / pricing / currency / discount appears; verify each.
Signal: Rounding errors, currency conversion drift, discount-stacking bugs, free-shipping edge cases, locale-specific formatting (โฌ1.234,56 vs $1,234.56).
Example application:
**Charter:** Explore promo code application.
**Money tour:**
1. Apply 10% off promo to a $24.99 cart. Verify subtotal = $22.49.
2. Apply 50% off promo to a $0.01 cart. Verify subtotal = $0.01 (rounding).
3. Apply 100% off promo to a free-shipping order. Verify shipping handling.
4. Apply two stackable promos. Verify the order of operations.
5. Apply a promo + state tax. Verify tax base.When to use: Any feature touching money, pricing, billing. Critical for: Checkout, billing, subscription management.
Tour 3 - Landmark tour
Mission: Visit each "landmark" feature - the canonical user journeys / hero flows.
Signal: Whether the marquee features still work after a refactor; baseline confidence.
Example application:
**Charter:** Verify post-refactor regression risks.
**Landmark tour:**
1. Sign up new account โ confirm email โ log in. **Hero flow.**
2. Add to cart โ checkout โ confirmation. **Hero flow.**
3. Cancel subscription โ reactivate. **Hero flow.**When to use: Post-refactor verification; pre-release smoke; quarterly health check.
When NOT to use: When the team already has automated tests for hero flows (those should run first; tour confirms behavior the automation doesn't catch).
Tour 4 - Intellectual tour
Mission: Explore the hardest-to-understand parts of the product. The features that the team has trouble explaining.
Signal: Bugs in genuinely complex business logic where edge cases lurk.
Example application:
**Charter:** Explore the tax calculator's nexus rules.
**Intellectual tour:**
1. Order ships from CA to OR (no sales tax in OR). Verify tax = 0.
2. Order ships from CA to TX (Texas nexus). Verify TX tax applied.
3. Order ships from CA to NY (origin-based vs destination-based). Verify rule.
4. Order with mixed-tax-rate items. Verify per-item rate application.
5. Subscription order spanning a tax-rate change date. Verify proration.When to use: Complex business logic (tax, billing, permissioning, scheduling).
Effort: High. This tour requires the tester to understand the domain - pair with a domain-expert "guide."
Tour 5 - Bad-data tour
Mission: Feed pathological inputs and observe behavior.
Signal: Input validation bugs, error-handling gaps, security vulnerabilities, locale parsing issues.
Example application:
**Charter:** Stress-test the search input.
**Bad-data tour:**
1. Empty input. Verify behavior.
2. Single space. Verify trimming or rejection.
3. 5000-character input. Verify truncation or rejection.
4. SQL injection: `'; DROP TABLE users; --`. Verify escaping.
5. XSS: `<script>alert(1)</script>`. Verify sanitization.
6. Unicode bidi override (RLO): `โฎ`. Verify handling.
7. Right-to-left text: `ู
ุฑุญุจุง`. Verify rendering.
8. Emoji + ZWJ sequences: `๐จโ๐ฉโ๐งโ๐ฆ`. Verify counting.
9. Null byte: `foo\0bar`. Verify handling.Pair with malicious-payload-bank for the canonical payloads (OWASP Top 10 + CWE Top 25).
When to use: Any input field (search, forms, URL params, file upload).
Tour 6 - Configuration tour
Mission: Vary the user's / system's configuration; observe behavior changes.
Signal: Config-dependent bugs (feature flags off vs on, dark mode vs light, locale variations, browser variations).
Example application:
**Charter:** Verify checkout works under all account configurations.
**Configuration tour:**
1. New user, no payment method. Verify "add payment" prompt.
2. Existing user, expired card. Verify "update card" prompt.
3. EU user, GDPR consent banner active. Verify checkout flow.
4. Beta user with experiment flag `new-checkout=true`. Verify variant.
5. Admin impersonating a user. Verify behavior.When to use: Multi-tenant / multi-config products; before toggling a major feature flag.
Pair with feature-flag-test-harness for the matrix-shard approach to flag-combination testing.
Tour 7 - Garbage collector's tour
Mission: Visit every page / endpoint once. Don't deeply test; just confirm presence.
Signal: Dead links, 404s, stale routes, removed-feature breadcrumbs.
Example application:
**Charter:** Pre-release sanity check.
**Garbage collector's tour:**
1. Walk through every nav item; confirm each loads.
2. Visit every footer link; confirm each loads.
3. Visit every URL listed in the sitemap; flag 404s.
4. Visit every documentation link from the in-app help.When to use: Before a release; after a major refactor; periodic health check.
When NOT to use: Replacing automated link-checking - the garbage collector's tour is for rendering issues an automated checker can't catch.
Related skills
bug-bash-facilitator
Builds a structured bug-bash session - pre-bash kit (charter, test-data prep, environment setup, sign-up sheet), in-bash structure (role rotation across cohorts, shared backlog board, real-time triage), scoring rubric (severity weighting, novelty bonus), and a post-bash same-day wrap-up authored by the facilitator (not a standalone debrief: for post-session writeups without a live bash, use manual-test-debrief). Use when a team needs a coordinated multi-tester sweep before a release or after a major change - converts an ad-hoc "everyone test for an hour" into a recorded, comparable session with deliverables.
crusspic-stmpl-heuristic
Pure-reference catalog of James Bach's CRUSSPIC STMPL heuristic - thirteen quality criteria (quality attributes / non-functional requirements) a tester can evaluate a system against. CRUSSPIC: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility. STMPL: Supportability, Testability, Maintainability, Portability, Localizability. Use when checking a product's quality attributes or non-functional requirements, or picking which quality characteristics a test session evaluates - a checklist for judging product quality holistically; complementary to the ISO/IEC 25010 software product-quality model.
decision-table-test-design
Derives human-readable manual test cases from a business-rule spec via a decision table: identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column (each feasible column is one coverage item per ISTQB CTFL v4.0 section 4.2.3). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input.
fcc-cuts-vids-heuristic
Pure-reference catalog of Michael Kelly's FCC CUTS VIDS touring heuristic (2005): eleven tours - Feature, Complexity, Claims, Configuration, User, Testability, Scenario, Variability, Interoperability, Data, Structure - each a reconnaissance sweep that builds familiarity with an unfamiliar application. Use when onboarding onto a product or opening a first session on an unknown area, before a charter is scoped. Distinct from exploratory-tours-reference (Whittaker's seven tours, which frame a bug-hunting mission on a product the tester already knows), sfdpot-exploratory-heuristic (what to vary), hiccupps-f-heuristic (oracles), and crusspic-stmpl-heuristic (quality criteria).
hiccupps-f-heuristic
Pure-reference catalog of Michael Bolton's HICCUPPS-F oracle heuristic - the reference points a tester consults to decide 'is this a bug?': History, Image, Comparable products, Claims, Users' desires, Product (internal consistency), Purpose, Standards/statutes, plus Familiar problems. Use mid-session to test an observation against each oracle. For what to VARY use sfdpot-exploratory-heuristic, for touring an unfamiliar product use fcc-cuts-vids-heuristic, for quality criteria use crusspic-stmpl-heuristic.
manual-test-debrief
Session debrief template + tour-coverage tracker - captures the SBTM PROOF format (Past, Results, Obstacles, Outlook, Feelings) plus three-bucket time accounting (test design / setup / bug investigation), the tours applied + areas covered + areas skipped, and the per-session quality-of-attention signal. Output is the artifact a charter delivers into; the team aggregates debriefs across sessions to track what's been explored vs what's still uncharted. Use after every exploratory session - without the debrief, the session's findings disappear.
manual-test-script-author
Builds stakeholder-readable scripted manual test cases from a feature spec - emits either a step-table format (preconditions / steps / expected result / actual / pass-fail / notes) for spreadsheet review or a Gherkin Given/When/Then format for BDD-aware teams. Each script is self-contained (no implicit team knowledge), single-scenario (one happy + N edge per script), and includes the data setup the tester needs without being a developer. Use when a feature can't be (or shouldn't be) fully automated and a human tester needs an executable script - UAT, regression baselines, certification testing, exploratory follow-up scripts.
manual-testing-overview
Teaches human-driven testing end to end: when a predefined scripted test case is the right instrument versus a time-boxed exploratory session, how session-based test management works (charter with a stated mission, time box, session notes, debrief) with a worked charter and a filled-in session sheet, a decision rule for what to automate versus what to keep human, and what makes a manual bug report actionable (exact reproduction steps, observed versus expected, build and environment, evidence). Use when planning or running testing a person performs by hand, writing a charter for an exploratory session, deciding whether a check belongs in an automated suite or in a human session, or fixing bug reports that developers keep returning as not reproducible.
session-based-test-management-reference
Pure-reference catalog of Session-Based Test Management (SBTM) - the Bachs' framework for running exploratory testing as time-boxed sessions: the session (60-90 min), the charter (Explore X with Y to discover Z), the session-sheet structure, the TBS metrics, the cross-session dashboard, and the PROOF debrief. Use when authoring exploratory-testing charters, reviewing session sheets, or setting up time-boxed test sessions. Distinct from manual-test-debrief (the PROOF debrief template), exploratory-tours-reference (the session themes), and the heuristic catalog hiccupps-f-heuristic.
sfdpot-exploratory-heuristic
Pure-reference catalog of James Bach's SFDPOT heuristic - 'San Francisco Depot' - a 'you are here' framework that catalogues what a tester can vary in a system to find bugs. Six dimensions: Structure, Function, Data, Platform, Operations, Time. Use as a what-to-vary checklist during an exploratory session, complementing HICCUPPS-F (which catalogues what to compare against).
state-transition-test-design
Derives human-readable manual test cases from stateful behavior: identify states, events, transitions, and guard conditions, draw the state table including invalid (empty-cell) transitions, choose a coverage level (all states, valid transitions / 0-switch, transition pairs / 1-switch per Chow, all transitions including invalid ones), then derive one test case per coverage item as an event sequence with per-step expected states (ISTQB CTFL v4.0 section 4.2.4). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use for lifecycle entities (accounts, orders, subscriptions), workflows, and UI wizards where the response to an event depends on the current state.
test-execution-checklist
Converts a regression suite (or test plan) into an executable manual checklist for cases when automation isn't viable - a release-day smoke checklist, a post-incident verification list, or a periodic compliance check. Outputs a per-TC checkbox list with the minimal preconditions, the action, and a one-line "what to look for" - short enough to fit on one page per major flow. Use when the team needs a focused human-runnable list (not full step-tables), e.g., for production smoke after deploy or for the on-call rotation's quick verification.
uat-script-author
Emits User Acceptance Testing scripts in stakeholder-readable format - pre-conditions / business-language steps / expected business outcome / pass-fail / sign-off. Tailored for non-developer testers (end users, SMEs, solution owners) per the UAT canonical definition. Output is one TC per stakeholder-meaningful scenario with explicit sign-off, suitable for compliance / contract / audit records. Use when a release requires formal UAT before sign-off - typical for B2B contracts, regulated industries, or any delivery where the customer's acceptance is the contractual gate.