次の方法で共有

tour of the month: the intellectual's tour

  • [アーティクル]

As promised, here is the first tour on the tour-of-the-month parade. It's probably not the best place to start, but it's finding so many good bugs for so many testers around the company that I wanted to get it in the hands of others sooner rather than later where it might make more logistical sense.

Enjoy!

I was once on a walking tour of London in which the guide was a gentleman in his fifties who claimed at the outset to have lived in London all his life. A fellow tourist happened to be a scholar who was knowledgeable in English history and was constantly asking hard questions of the guide. He didn’t mean to be a jerk, but he was curious and that ended up being a dangerous combination … at least to the guide.

Whenever the guide would talk about some specific location on the tour whether it was Oscar Wilde’s former apartment in Chelsea, details of the great fire, or what life was like when horses were the primary mode of transportation, the scholar would second guess him or ask him some hard question that the guide struggled to answer. The poor guide had never worked so hard on any past tour. Every time he opened his mouth he knew he was going to be challenged and he knew he had to be on his toes. He wasn’t up to the task and finally admitted that he had only actually lived in London for five years and he had memorized the script of the tour. Until he met the scholar, his ruse had worked.

What a fantastic bug! I was so impressed I bought both the guide and the scholar a pint when the tour ended at a pub (a place, incidentally, where the hapless guide was infinitely more knowledgeable than the scholar).

When applied to exploratory testing, 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 ability to produce any specific output?

For folks who test word processors this tour would direct them to create the most complicated documents possible, ones full of graphics, tables, multiple columns, footnotes and so forth. For folks testing online purchasing systems, what is the hardest order we can place? Can we order two hundred items? Can we place multiple items on backorder? Can we keep changing our mind about the credit card we want to use? Can we make mistakes on every field in the data entry forms? This tour is going to be different for every application, but the idea is the same: ask your software hard questions. Just as the scholar did with the London guide, you are likely to find gaps in its logic and capabilities.

A variation of this tour is the arrogant American tour that celebrates a stereotype of my countrymen when we travel abroad. Instead of asking hard questions, we ask silly questions otherwise intended simply to annoy or impede the tour and draw attention to ourselves. We intentionally present obstacles to see how the software reacts. Instead of the most complicated word processing document, we make the most colorful, invert every other page, print only prime number pages, or place something in a location that makes little sense. On a shopping site we’ll seek out the most expensive items only to return them immediately. It doesn’t have to make sense … we do it because we can.

Comments