Stats
Actions
Tags
From qa-manual-testing
Pure-reference catalog of exploratory testing tours - heuristics that frame an exploratory session around a theme. The seven canonical tours from Whittaker''''s *Exploratory Software Testing* (2009): Feature tour, Money tour, Landmark tour, Intellectual tour, Bad-data tour, Configuration tour, Garbage collector''''s tour. Each tour has a mission, a typical signal it surfaces, and an example application. Use as the heuristics menu the charter author and tester pick from when designing a session.
How this skill is triggered — by the user, by Claude, or both
Slash command
/qa-manual-testing:tour-based-explorer-promptThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A naïve exploratory session can drift - the tester clicks around
A naïve exploratory session can drift - the tester clicks around without a focusing lens. Tours solve this: 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). They've been widely cited in the testing community as the practitioner-emergent vocabulary for exploration.
This skill is a pure reference - the charter author
(exploratory-charter-author)
and the tester pick which tours to apply per session.
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.
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.
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).
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."
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).
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.
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.
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.
Per the PROOF debrief in
exploratory-charter-author
Step 5, each tour produces:
| 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). |
exploratory-charter-author - consumer of this reference.malicious-payload-bank - canonical payloads for the Bad-data tour.feature-flag-test-harness - automated complement for the Configuration tour.npx claudepluginhub testland/qa --plugin qa-manual-testingProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.