Application variability tour in action

Reading Time: 2 minutes


My first contact with software testing was in factory and control schools of software testing. At that time I did not know that fact. In this post I will explain how I needed to make a shift from those schools, in order to deliver better software testing to my clients.

In my current software testing project, I got question: “Do you have all the requirements in order to start your testing activities?”. I said: “For start, I only need the application.”

By that I meant, I will start to explore the application based on product tours created by James Bach and expanded by Michael Kelly [source]. This paper is required reading for BBST Test Design course [source].

The main idea is that you can learn about the application by doing application tours. I will explain how variability tour helped me to identify potential problem in the application.

When you are doing application tours, from tools you only need a pen and paper. Simple as that. What counts are notes that you will put in your notebook.

Idea behind the variability tour is to find things that you can change in your product, and then try to change them. These are the moving parts of the application. And you will start to think about the application data that are part of those changes. What gets challenging here is that you realize that moving parts are connected and dependant on each other.

For better understanding this problem, see James Lyndsay’s black-box testing machines [source].

I tested a feature which purpose was to move application item through various states. This is known as State pattern [source]. Item has states and actions that are used to move item through those states.

I was doing coverage test of that feature. Create an item and move it through all available states. A variability tour. And I found an interesting feature that could be a possible issue. In every state, item had a same list of possible actions. There was a helping action, move an item to previous state. Very useful for the coverage test.

And I noticed that order of list of actions changed when item was returned to previous state from the order when item was first time in that state.

This was not the issue by itself, but by knowing that this feature exist, we could reveal some other important issue. This is example of over featuring the application. And developer did not know that this feature is implemented.

That was definitely issue for me as a tester because I needed to be extra careful to not make a mistake while I was doing coverage of item state transitions.


In my country, fresh graduates are not attracted by software testing, because they know about software testing from factory and control schools of software testing. By presenting them with application tours, maybe you will change their opinion about software testing.


Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Karlo Smid

Leave a Reply

Your email address will not be published. Required fields are marked *