Exploratory testing · 9 min read

Exploratory Testing Tours: Whittaker's Six Districts

James Whittaker's book groups exploratory testing tours into six districts. This post adds its own selection rule for tours that fit one charter's mission.

Whittaker pairs UI bugs, timing bugs, stress bugs and legacy code with tours. Xray files his two stress tours in different districts: Saboteur in Seedy, TOGOF in Tourist.
Whittaker pairs UI bugs, timing bugs, stress bugs and legacy code with tours. Xray files his two stress tours in different districts: Saboteur in Seedy, TOGOF in Tourist.

This post treats an exploratory testing tour as a theme for one session: a named route through a product that hunts one kind of bug. James Whittaker's 2009 book Exploratory Software Testing sorts its tours into six districts, in this order: Business, Historical, Entertainment, Tourist, Hotel and Seedy. A charter that says "explore the new feature" names a place but no direction, so this post proposes its own rule: choose one to three tours per charter, matched to the bug classes its To discover line hunts. This post assumes you have done hands-on exploratory testing, know what a charter and a time-boxed session are, and can read a PROOF debrief in its five fields: Past, Results, Obstacles, Outlook, Feelings.

Table of contents

Tour as session theme: not Whittaker's wording

Two things here are this post's own, not Whittaker's: calling a tour a theme for one session, and the Tours (1 to 3) line on the charter card in the worked example, with the one-to-three rule behind it.

From here on, this post uses "tour" at session scale, set by the charter's To discover line, which differs from Whittaker's own uses of "tour" and "district". On 12 Feb 2009, in The Touring Test, Whittaker wrote that he calls these tests tours and thinks "in terms of a tourism metaphor". The same post describes tours as "specific, focused testing advice" and "a way of partitioning test concerns".

A 29 Dec 2009 InformIT article goes further: "A tour through the capabilities of the application represents a test case." The article also uses "district" to mean components, a different sense from the book's six. Lowercase "tourist" below means the metaphor; "the Tourist District" is one of the six.

Here a district is a metaphor label that groups tours by kind of concern, not a part of the product; Whittaker's "Want to find X bugs? Run the Y Tour" lines pair a bug class with tours, not with a district, and are not definitions. The six districts and their order come from the book's publisher page. The chapter text isn't free to read, so tour definitions here come from Whittaker's free writing (three 2009 blog posts and the InformIT article), none of which names the six districts.

Tour placement and district readings come from two summaries: an Xray guide and a 2022 ICEIS paper. The book's own tour count can't be checked from free sources (the ICEIS paper says it "considered 23 tours present in 6 districts"), so no total appears here as fact.

Business District: Money, Intellectual and Landmark

In The Touring Test, testers on the Money Tour "watch salespeople demo the product and create variations of those demos as test cases," and on the Intellectual Tour they "ask the software hard questions" (developed in a follow-up on 11 Mar 2009). On the Landmark Tour, a 6 Apr 2009 post says: "If you identify the landmark features that draw users, that's where you need to concentrate a lot of testing."

Xray, a summary, files all three tours in the Business District and describes it as the area where the work gets done.

Historical District: Museum and Prior Version

Whittaker pairs these two tours with one bug class: "Want to test legacy code? Run the Museum Tour and the Prior Version Tour." (The Touring Test). No source used here says more, so read it as the risk the tours address, not a definition. Xray files both here and describes the district as "an area with buildings of historical value."

Entertainment District: Back Alley, from secondary sources

No tour that summaries file in the Entertainment District is defined in Whittaker's free writing, so this district rests on summaries alone. Xray files Back Alley here with this secondary definition: "The Back Alley tour proposes to test the features used the least." Of the district, Xray says: "The main goal of this district is to complement other tours."

Tourist District: the Supermodel Tour

Whittaker pairs UI bugs with one tour: "Want to find UI bugs? Run the Supermodel Tour." (The Touring Test). He describes it as window shopping the interface for superficial bugs. Xray files the tour in the Tourist District and describes the district only at metaphor level: "the places in a city where tourists love to spend their time".

Hotel District: the Rained Out Tour

Whittaker pairs timing bugs with one tour: "Want to find timing bugs? Run the Rained Out Tour." (The Touring Test). Xray describes the Hotel District as "designated areas where tourists go to rest" and glosses the tour as "starting and stopping operations", a secondary gloss.

Seedy District: the Saboteur Tour

Whittaker pairs stress bugs with two tours: "Want to find stress bugs? Run the Saboteur (get it?) and the TOGOF Tour." (The Touring Test). Xray files Saboteur in the Seedy District and describes the district this way: "Every city has a place where dangerous people are."

Picking one to three exploratory testing tours for a 90min charter

The rule routes a bug class to a tour, and the district is the menu section that tour comes from. Whittaker's blog says all the tours together "collectively should encompass most all interesting scenarios" (The Touring Test); one-to-three scoping of a session in a series is the post's own rule.

Five steps from a To discover line to tours

  1. Name each bug class the charter's To discover line hunts. The risk behind it comes from the strategy layer, such as the Heuristic Test Strategy Model.
  2. Find each bug class in the table below. The row names the tour and its district.
  3. Choose one to three tours; fewer is fine. The sample report in the charter post puts 60% of a session into test design and execution, so on that sample split about 54min of 90min is touring: 27min each for two tours, 18min each for three. More tours dilute the session, by this post's own judgment from that split: the tours share one block of touring time, so each added tour shrinks every other tour's share.
  4. Name an oracle for each tour. A tour says where to go; an oracle (how you recognize a problem) decides whether a surprise is a bug.
  5. Skip districts with nothing to visit: a feature with no earlier version gives Museum and Prior Version nothing to test.

Which tour answers which bug class

The left column is this post's reading of each pairing.

The To discover line is huntingTourDistrict
Failures in the features that bring in the moneyMoneyBusiness
Behavior that breaks under hard questionsIntellectualBusiness
Failures in the features that draw usersLandmarkBusiness
Legacy codeMuseum, Prior VersionHistorical
Rarely used features (secondary definition)Back AlleyEntertainment
UI bugsSupermodelTourist
Timing bugsRained OutHotel
Stress bugsSaboteurSeedy

A bug class can cross districts: Whittaker's stress-bugs line names Saboteur and TOGOF, and Xray files TOGOF in the Tourist District, so pick by tour, not by district alone.

A worked charter: rescheduling a clinic appointment

Take a hypothetical clinic app with a new Reschedule button and no earlier reschedule flow. The bare charter says "explore the new reschedule feature". Widened, its To discover line, in the Mission below, is one information goal with two aspects, so this stays one mission and one charter.

Step 2 gives one row per aspect: "Timing bugs" points to Rained Out (Hotel) and "UI bugs" to Supermodel (Tourist), about 27min each of the 54min. Had the line named only the interrupted reschedule, one tour would have been enough. Four districts are skipped on purpose: Business (no money, landmark or hard-question failures sought), Historical (no earlier flow), Entertainment (no rarely used feature) and Seedy (stress is another mission). Omitted card parts, marked ..., include Variations to try and Seed test ideas.

Mission: Explore the reschedule dialog with one patient account
         holding two upcoming appointments to discover whether
         a rescheduled slot stays correct: in the calendar when
         interrupted (timing bugs) and on screen (UI bugs).

...

## Areas (3 to 7)
- Slot picker
- Confirm step
- Confirmation email

## Tours (1 to 3)
- Rained Out (Hotel), "Timing bugs" row: stop the reschedule at the
  confirm step
- Supermodel (Tourist), "UI bugs" row: window shop the slot labels

## Oracles to consult (2 to 4)
- The calendar and the confirmation email agree on time and clinician
- After a reschedule, the old slot is free and the new one is held

...

The Tours line extends the charter post's card and isn't Whittaker's. A tour is a theme for the session, not a target, so it stays out of the Explore line, variations and seed test ideas. Explore and With are unchanged, and a tour never replaces To discover.

Where tour findings go in the PROOF debrief

Tours add no sixth field; findings go into the five PROOF fields, and Precision in PROOF debriefs covers writing each sharply.

Past names the tours run, in order, plus any dropped. Results tags each finding with its tour and the oracle that makes it a bug. Obstacles records a tour that couldn't run. Outlook lists skips that need a later charter. Feelings says which tour's coverage the tester trusts and which they doubt. In the example, three fields look like this:

PAST
Ran Rained Out and Supermodel on the reschedule dialog, about
27min each.

RESULTS
BUG-5120 (Rained Out): stopping at the confirm step frees the old
slot but never books the new one. Oracle: the new slot must be held.
BUG-5121 (Supermodel): the slot picker truncates the clinician name.
Oracle: the confirmation email shows the full name.

OUTLOOK
Seedy tours not run: stress is a separate charter.

Who used the tour metaphor before Whittaker's catalog

Whittaker published a catalog grouped into six districts; he didn't invent touring. Michael Bolton's 2 Apr 2009 post records earlier holders of the metaphor: Cem Kaner in 1995, who noted that the user manual "takes you on a tour of the entire program"; Elisabeth Hendrickson's 2001 STAR East talk, which gave a list of test ideas using it; and James Bach's Rapid Software Testing notes, which list five tours (Bolton's earliest copy is from 2004).

Michael Kelly's Touring Heuristic of 20 Sep 2005 lists eleven tours, which Bolton refers to by the mnemonic FCC CUTS VIDS. Feature and Configuration are Kelly's, not Whittaker's. Kelly's definitions read as ways to get to know a product, where Whittaker pairs tours with kinds of bug; that contrast is this post's reading.

Bolton hedges on Whittaker's naming: for skilled exploratory testers, he writes, the touring metaphor "might be obvious enough" to have been arrived at independently. As far as the sources here show, Whittaker's own public timeline starts after Kelly's list: EuroSTAR 2008, the blog in Feb 2009, the book in Aug 2009 (the publisher's date).

Reading Whittaker's Touring Test post for yourself

Read as a menu, the six districts give a charter's To discover line a tour to match instead of a place to wander. Learn more in Whittaker's The Touring Test (12 Feb 2009).

Install the manual tester bundle.

7 plugins for manual and exploratory testing: test cases, charters, test case management, defect tracking, bug reproduction and reporting.

/plugin install qa-role-manual-tester@testland-qa