What is a tour in exploratory testing, and how do a feature tour and a data tour differ?

## Why tours exist Unscripted work has one predictable failure: attention collapses. Left to itself, a tester circles the screens they already understand, in the order the product suggests, and the parts reached only through an unusual path never get opened. A tour is the cheap fix. You choose one dimension of the product, hold it fixed as the organising principle, and sweep across everything else. The lens supplies the next move when curiosity does not. A tour is an idea generator, not a case list. Nothing about it is written down in advance beyond the lens itself, and the point is that walking the lens produces questions you can then chase. ## The product-elements lenses The common set of lenses is the product-elements heuristic used in exploratory practice — structure, function, data, interfaces, platform, operations and time. Each is a different way to enumerate the product: - **Structure** — what the thing is made of: files, modules, services, screens, stored objects. - **Function** — what it does: every capability, including the ones with no menu entry. - **Data** — what it operates on: inputs, outputs, stored records, sizes, lifetimes, cardinality. - **Interfaces** — where it meets other things: user interfaces, programmatic ones, imports and exports. - **Platform** — what it depends on: operating environment, devices, locales, clocks, third-party services. - **Operations** — how it is actually used: who uses it, in what sequences, under what load, with what shortcuts. - **Time** — how behaviour changes with ordering, concurrency, duration, expiry and scheduling. A tour is one pass with one of those held fixed. They are not exclusive, and a good session often chains them: the function tour reveals a capability, the data tour of that capability's key field reveals an inconsistency, the time tour of the same field reveals what happens when two edits race. ## Feature tour versus data tour, concretely Take a grant-application review queue. A **feature tour** is a walk over every capability: assign a reviewer, score, request more information, defer, withdraw, reassign, export a decision pack, bulk-approve. The output is a map — what exists, what it claims, what is reachable only from an unusual place. Its typical finding is a capability that is missing, unreachable, or does not do what its label says. Its typical blind spot is depth: you have visited everything once and understood nothing deeply. A **data tour** takes one value — say the application's status — and follows it everywhere it is created, changed, read, shown, exported and destroyed. Status is set on submission, changed by six actions, shown in the queue list, in the detail view, in a reviewer's dashboard count, in an export, and in an audit record. The tour asks at every stop whether the rules match. That is where you find that a partial-failure rollback during a bulk action leaves 11 of 37 applications displaying as withdrawn in the list while the detail view still says pending, and the dashboard count agrees with neither. No feature tour finds that, because each feature works. ## Consistency questions as the steering wheel What turns a tour from sightseeing into testing is the question you carry while walking it. The most productive family is consistency: does this behave like the rest of the product, like the part of the product it most resembles, like it did before this change, and like its own claims? Each mismatch is a next move rather than a verdict — a place where two things disagree is worth a test, whether or not the disagreement turns out to be a defect. Deciding which side is wrong is a separate judgement and needs a reference to compare against; the tour's job is to find the disagreement and hand you somewhere to point the next test. Other steering questions travel well: what would make this expensive to get wrong, what happens at the edges of this value's range, what does the product do when this step is interrupted, and what is the second-most-likely thing a user does here. ## Where tours mislead Breadth is seductive. A tester who runs tours all week produces a wide, shallow pass and a long list of cosmetic notes, because every lens rewards moving on. The corrective is to let a strong signal break the tour: when something looks wrong, abandon the sweep, dig until you understand it, and resume afterwards — or spawn a separate mission for it. Tours are also weak where risk is concentrated. If one calculation carries the money, touring seven lenses across the whole product is a poor use of the afternoon compared with attacking that calculation. Use a tour when you do not yet know where the risk lives; use risk directly when you do. ## Answering this in an interview Define a tour as a themed sweep with one lens fixed, name three or four lenses, then contrast feature and data with a concrete example of a bug each one finds and the other misses. If asked which you would run first on an unfamiliar product, say the function tour to build a map, then pick the next lens by what looked riskiest — that answer shows the tours are serving your judgement rather than replacing it.