Web Testing Exploratory Tours

This is the list of exploratory testing tours that James Whittaker (former Google QA director, working for Microsoft again currently) has in his book on exploratory testing:

The Guidebook tour

Follow the user manual’s advice just like the wary traveler, by never deviating from its lead.

The money tour

For exploratory testers finding the money features leads directly to the sales force. Sales folk spend a great deal of time giving demos of applications and are a fantastic source of  information for the Money tour. To execute the tour, simply run through the demos yourself and look for problems.

The landmark tour

Choose a set of landmarks, decide on an ordering for them,  and then explore the application going from landmark to  landmark until you’ve visited all of them in your list. Keep track  of which landmarks you’ve used and create a landmark  coverage map to track your progress.

The intellectual tour

This tour takes on the approach of asking the software hard questions. How do we make the software work as  hard as possible? Which features will stretch it to its limits? What inputs and data will cause it to perform the most  processing? Which inputs might fool its error-checking  routines? Which inputs and internal data will stress  its capability to produce any specific output?

The fedex tour

During this tour, a tester must concentrate on this data. Try to identify inputs that are stored and “follow” them  around the software.

The garbage collector's tour

This is like a methodical spot check. We can decide to spot check the interface where we go screen by screen, dialog by dialog (favoring, like the garbage collector, the shortest route), and not stopping to test in detail, but checking the obvious things.

The bad neighbourhood tour

As bugs are found and reported, we can connect certain features with bug counts 
and can track where bugs are occurring on our product. Because bugs tend to congregate, 
revisiting buggy sections of the product is a tour worth taking. Indeed, once a buggy section of 
code is identified, it is recommended to take a Garbage Collector’s tour through nearby features to verify that the fixes didn’t introduce any new bugs.

The museum tour

Software’s antiquities are legacy code. Older code files that undergo revision or that are put into a new environment tend to be failure prone. With the original developers long gone and documentation  
often poor, legacy code is hard to modify,  hard to review, and evades the unit testing  
net of developers (who usually write such  tests only for new code). During this tour,  testers should identify older code and  executable artifacts and ensure they receive a fair share of testing attention.

The back alley tour

Test the least likely features to be  used and the ones that are the least  attractive to users. If your organization  tracks feature usage, this tour will direct  you to test the ones at the bottom of   
the list. If your organization tracks code  coverage, this tour implores you to find   
ways to test the code yet to be covered.

The all nighter tour

Exploratory testers on the All-Nighter tour will keep their  application running without closing it. They will open files  and not close them. Often, they don’t even bother saving  them so as to avoid any potential resetting effect that might occur at save time. They connect to remote resources and never disconnect. And while all these resources are in constant use, they may even run tests using other tours to keep the software working and moving data around.  If they do this long enough, they may find bugs that other  testers will not find because the software is denied that clean reset that occurs when it is restarted.

The supermodel tour

During the Supermodel tour, the focus is not on functionality or real interaction. It’s only on the interface. Take the tour and watch the interface elements. Do they look good? Do they render properly, and is the performance good? As you make changes, does the GUI refresh properly? Does it do so correctly or are there unsightly artifacts left on the screen? If the software is using color in a way to convey some meaning,     
is this done consistently? Are the GUI panels internally consistent with buttons and controls where you would expect them to be? Does the interface violate any conventions or standards?

The couch potato tour

A Coach Potato tour means doing as little actual work as possible. This means accepting all default values, leaving input fields blank, filling in as little form data as possible, never clicking on an advertisement, paging through screens without clicking any buttons or entering any data, and so forth. If there is any      
choice to go one way in the application or another, the coach potato always takes the path of least resistance.

The obsessive compulsive tour

OCD testers will enter the same input over  and over. They will perform the same action  over and over. They will repeat, redo, copy,  paste, borrow, and then do all that some  more. Mostly, the name of the game is repetition. Order an item on a shopping site and then order it again to check if a multiple purchase discount applies. Enter some data on a screen, then return immediately to enter it again. These are actions developers often don’t program error cases for. They can wreak significant havoc.

More details on these tours can be found on this article from James Whittaker's blog and in his exploratory testing book.

Share this