다음을 통해 공유

the touring test

  • 아티클

(I couldn’t resist the play on Alan Turing’s famous test when naming this testing metaphor.)

When I think of software, I naturally think of it in testing terms. In my mind software is made up of components which are defined by structural boundaries (code files/assemblies) where multiple components communicate through some defined interface, a set of features that define the functionality for each component, and capabilities that produce behavior that the user desires. It’s extremely useful to me to think about it this way because I can now more purposefully explore my application.

For example, I can choose a set of capabilities to test as an ensemble or focus on a single one. I can purposefully explore the capabilities of many features or a single feature. I can exercise capabilities that cross component boundaries or choose to stay within a component. I can use my component/feature/capability map to guide my testing and ensure that I cover the interesting combinations to the extent possible.

I call these tests tours and think in terms of a tourism metaphor when I test software. Ideas from tourism fit well into testing. If you think about a big, complicated tourist destination like New York or London you realize that wandering aimlessly around its streets is a pretty lousy way to tour. If you understand a little bit about its districts and destinations (components and features) you have a better feel for how to get around. If you go further and use published guidebooks, consult locals and read tourist maps you’ll discover the best places to go and things to do (capabilities) a lot faster. Travelers want to get the most out of their brief vacation time and as testers we can learn from them.

At Microsoft a group of us test folk from around the division and around the company are experimenting with tour-guided testing. We have the Supermodel Tour in which all we do is window shop … look at the interface and find superficial (no intended disrespect to any actual supermodel who might be reading this blog) bugs. We have the Money Tour where we watch salespeople demo the product and create variations of those demos as test cases. We have the Intellectual Tour where we ask the software hard questions. We have the Garbage Collector’s Tour, the Competitor’s Tour, the Museum Tour, the After Hours Tour and a host more that we are experimenting with. All of these tours represent specific, focused testing advice that guides the tester through paths of the software. The tours help a tester think through inputs, data and environment settings that satisfy the goals of the tour. It's a more methodical and purposeful way to test.

We created the tours as exploratory test guidance and even more as a way of partitioning test concerns. Each tour is guidance about a very specific type of capability. Add all the tours together and they collectively should encompass most all interesting scenarios, but there is more to them that that. They can also be associated with the component/feature/capability map to help testers associate a tour with a specific capability. Want to test the interface between a database component and the application? Run the FedEx Tour. Want to test legacy code? Run the Museum Tourand the Prior Version Tour. Want to test how two features interact? Run the Guidebook Tour between them. The touring tests take the discussion of how to test up to a higher level. Instead of talking about specific test cases, they guide us toward talking about test concepts because each tour embodies testing advice for a very specific capability. Such higher level concepts have been missing from our testing vocabulary for far too long.

Tours also take the discussion of bugs to a higher level. Want to find UI bugs? Run the Supermodel Tour. Want to find stress bugs? Run the Saboteur (get it?) and the TOGOF Tour. Want to find timing bugs? Run the Rained Out Tour.

Want to learn more about the details of these tours? Stay tuned to this site, I am going to start running a tour-of-the-month post to explain these concepts in more detail. Perhaps your own team will join us and pass the touring test!

Comments

  • Anonymous
    February 12, 2009
    PingBack from http://blog.a-foton.ru/index.php/2009/02/12/the-touring-test/

  • Anonymous
    February 12, 2009
    The comment has been removed

  • Anonymous
    February 12, 2009
    The comment has been removed

  • Anonymous
    February 13, 2009
    I want to be a voracious traveller (there are so many territories in my product). Please make it tour of the day :).

  • Anonymous
    February 16, 2009
    The comment has been removed

  • Anonymous
    March 09, 2009
    Very helpful...I am searching for new techniques of testing as i am bored with traditional Manual Testing. But i dont want to use Automation though. These techniques will be good.

  • Anonymous
    June 09, 2009
    Is that an obscure AoE reference in there?

  • Anonymous
    February 13, 2011
    This Blog is one of the best top 100 software testing blogs by this article: www.testingminded.com/.../top-100-software-testing-blogs.html but for me, it's just the best! continue with good work dude! see you!

If you plan to go in Cameroon, please visit: <a href="offres-d-emploi-au-cameroun.blogspot.com/">Offres d'emploi au Cameroun</a>