Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. Two tours that I use together are the user tour and the scenario tour.

In the user tour you attempt to imagine five users for the product and the information they would want from the product or the major features they would be interested in. In the scenario tour try to imagine five realistic scenarios for how the users identified in the user tour would use this product.

When I’m attempting to imagine users for the product, I find it helpful to think not only about that a user will do, but what they value. I also look to see if there is real user data available in the application I’m testing. Test data is good, but real data offers a different insight into how an actual user will possibly use the system. As you’re attempting to identify your users, don’t forget about users you may not want – hackers and other malcontent, users who don’t know what to they really need to do or how to use it, users who attempt to do too much with the product at one time.

It’s helpful to think about what environments those users will operate in. What access rights they will have. And what common patterns they will follow. Once you know who the users are, think about compelling stories of how they use the product. What inputs do they have and what outputs do they care about? The scenarios you want to identify will be compelling stories of how someone who matters might do something that matters with the product.

For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)

Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. One the tours that I use is the structure tour.

In the structure tour you attempt to find everything you can about what comprises the physical product. That can include the code, hardware, multimedia files, or databases. I often look at the source and unit tests for languages I’m familiar with. I also try to get a look at the database or the schema(s) if XML is involved. When performance testing, understanding the application architecture and the hardware being used and how it’s configured are also priorities.

For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)

Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. One the tours that I use is the claims tour.

In the claims tour you attempt to find all the information in the product that tells you what the product does. This is helpful in checking for product consistency. If a product is inconsistent with claims, then it is inconsistent with explicit or implicit claims made by the product. In the claims tour, you are looking to not only identify what the claims are, but you can also attempt to identify which claims are vague, possibly incomplete, or even inconsistent.

Explicit claims can often be found in help material, marketing material, training material, tool tips, or even magazine articles (reviews of your product). An implicit claim can be found when your product has uses industry terminology, has a common look and feel, performs common and well understood functionality, or has a feature set that is could be considered to be well understood.

For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)

Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. One the tours that I use is the complexity tour.

In the complexity tour, one attempts to find the five most complex things about the product. Complexity can exist around features or data. Complex features can be the most common features in an application (the algorithm behind Google search) or they might be rarely used – hidden away waiting to cause problems (end of year processing for an accounting system).

For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)

Sometimes while I'm testing a new application, I struggle to get started. To help me focus and better understand my testing, I use application tours to support my testing. One the tours that I use is the variability tour.

In the variability tour, you simply look for things you can change in the product - and then you try to change them. Click buttons, select values, change settings, etc… The goal is to try to get a feel for how things work and what possible values might be.

For a more descriptive look at using application tours, see an article I did for Software Test and Performance a few years ago. (It starts on page 20.)