FCC CUTS VIDS - the eleven tours in full

Michael Kelly's touring heuristic, published 20 September 2005 on michaeldkelly.com (opens in new window).

Each tour below quotes Kelly's own one-line description verbatim. The prompts and worked example under each are elaboration for this catalog, not Kelly's text.

Running example throughout: a self-serve expense-reporting web app the tester has never opened before.

FCC - the product shape

F - Feature tour

"Move through the application and get familiar with all the controls and features you come across."

Prompts

• What is on every screen reachable without special permissions?
• Which controls are visible but disabled, and under what condition do they enable?
• What exists in menus that has no obvious entry point in the UI?

Worked example. Clicking every nav item surfaces a "Recurring expenses" screen that appears in no onboarding material. Nobody on the team mentions it. That absence is the finding.

C - Complexity tour

"Find the five most complex things about the application."

Prompts

• Which screen has the most fields, states, or conditional logic?
• Where does the product ask the user to make the hardest decision?
• What would be hardest to explain to a new colleague?

Worked example. The five: multi-currency conversion, approval-chain routing, receipt OCR, the mileage calculator, and per-country tax rules. Complexity concentrates risk, so this list is usually the first draft of a charter backlog.

C - Claims tour

"Find all the information in the product that tells you what the product does."

Prompts

• What do the marketing pages, in-product tooltips, help centre, and release notes promise?
• Where do two of those sources disagree?
• What does the product claim about limits, formats, or timing?

Worked example. The pricing page says receipts are processed "instantly"; the in-app tooltip says "within a few minutes". Both are claims, and they conflict. That conflict is testable, and it is also material for hiccupps-f-heuristic, where Claims is one of the oracles.

CUTS - the usage shape

C - Configuration tour

"Attempt to find all the ways you can change settings in the product in a way that the application retains those settings."

Prompts

• What is settable per user, per team, and per organisation?
• Which settings survive logout, and which silently reset?
• What is configurable only by an administrator or only by support?

Worked example. The default currency is settable per user, but resets to the org default after a session expires. Persistence is the part of the tour that matters: a setting that does not stick is a different product than the one the settings screen advertises.

U - User tour

"Imagine five users for the product and the information they would want from the product or the major features they would be interested in."

Prompts

• Who are five distinct people who touch this, and what does each want from it?
• Which of them never log in but are affected by it anyway?
• Whose needs conflict?

Worked example. A field engineer filing from a phone, a manager approving in bulk, a finance analyst exporting for reconciliation, an auditor reading historical records, and an admin configuring policy. The analyst and the auditor want opposite things from data retention.

Run this tour before the Scenario tour, which depends on its output.

T - Testability tour

"Find all the features you can use as testability features and/or identify tools you have available that you can use to help in your testing."

Prompts

• What logs, debug views, health endpoints, or admin panels exist?
• Can state be set up directly, or only through the UI?
• What is available for generating or resetting data?

Worked example. An admin "impersonate user" action removes the need to hold five sets of credentials, and a CSV import can seed a hundred expenses in one step. Both cut session setup time, which is the constraint session-based-test-management-reference cares about.

S - Scenario tour

"Imagine five realistic scenarios for how the users identified in the user tour would use this product."

Prompts

• What does each persona from the User tour do end to end, on a normal day?
• Which scenario crosses the most features?
• What does the unhappy version of each scenario look like?

Worked example. The field engineer photographs a receipt in a basement with no signal, files it later, and the manager approves it from an email link while travelling. That scenario crosses offline capture, sync, deep linking, and approval - four areas one tour surfaced together.

VIDS - the data and system shape

V - Variability tour

"Look for things you can change in the application - and then you try to change them."

Prompts

• Which fields accept free input, and what do they accept?
• What can be reordered, renamed, deleted, or bulk-edited?
• What changes state as a side effect of changing something else?

Worked example. An expense category can be renamed after reports referencing it are submitted. Whether historical reports show the old or new name is a real question the tour raises but does not answer.

Note the overlap with sfdpot-exploratory-heuristic: variability is about finding what can change, SFDPOT is about systematically varying it once found.

I - Interoperability tour

"What does this application interact with?"

Prompts

• What does it authenticate against, import from, export to, or notify?
• Which integrations are optional, and what breaks when one is off?
• What talks to it that the team does not own?

Worked example. Single sign-on, a corporate card feed, an accounting export, and an email notification service. The card feed is the one nobody on the team controls, which makes it the first candidate for contract-level attention.

D - Data tour

"Identify the major data elements of the application."

Prompts

• What are the main entities, and how do they relate?
• Which fields are required, unique, or bounded?
• What data outlives the user who created it?

Worked example. Expense, Report, Approval, Policy, User. An Approval references a User who may later be deactivated, which raises the question of what an audit view shows for a departed employee.

S - Structure tour

"Find everything you can about what comprises the physical product (code, interfaces, hardware, files, etc...)."

Prompts

• What are the deployable pieces, and where do they run?
• What file formats, APIs, and storage does it own?
• What is the client, and what is the server?

Worked example. A React front end, a REST API, a background OCR worker, object storage for receipt images, and a nightly export job. The worker and the export job have no UI, so nothing in the Feature tour would have found them.

Turning a tour into a charter

A tour produces questions; a charter answers one. When a tour surfaces something worth pursuing, hand it to session-based-test-management-reference with a stated mission and a time box. The Complexity and Claims tours tend to generate the most charter-worthy material, because both surface places where the product's stated behaviour and its actual behaviour can diverge.