Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Learn how to identify & evaluate Parameter candidates in your systems under test and how to optimally include them in your Test Case Designer models.

When testes struggle to use TCD, the most common reason is identifying what factors & ideas should be included in the “Parameters” screen. To help address this challenge, this article describes several categories of variables that are often useful to include in software tests.

At the risk of stating the obvious, you’ll need to use your judgment here; not all of these categories will be necessary (or even useful!) to include in all of your sets of tests.

In this article you'll learn how to identify & evaluate Parameter candidates in your systems under test and how to optimally include them in your Test Case Designer models.


Table of Contents

An overview of variation ideas

...

For example, User Variations that may be considered in end-to-end tests of https://www.expedia.com/Flights, might include:

  • User type: normal user (without prior account), normal user (with established account), call center agent
  • User persona: power user, clueless newbie user, typical user
  • Account characteristics: Gold Frequent Flier, Silver Frequent Flier, Bronze Frequent Flier, not a Frequent Flier


Other related ideas:

  • User navigates primarily using: keyboard (hot-keys wherever possible), keyboard (no hot-keys), mouse
  • User rapidly clicks multiple times on submit buttons and next buttons: no, yes, no (Note: double-weighting ‘no’ will make it appear twice as often as ‘yes’)
  • User enters information from top of screen to bottom of screen: always, usually, never
  • User enters all required information the first time they submit information: always, usually, never


Usage Variations

Usage Variations relate to what different features of a system people might use, as well as how they might use those features, and the different types of data that might be used in different scenarios.

...

  • Date format: mm/dd/yy, dd/mm/yy, mm/dd/yyy, dd/mm/yyyy
  • Number of passengers: 1, 2-4, more than 4
  • Special characters included in customer name?: no, yes, no (Note: recall double-weighting)


Tips

“Hendrickson Variables”

“Hendrickson Variables” offer a great checklist to tick through as you think about possible variables to add.

Elisabeth Hendrickson published “Explore It!” in 2013. In our opinion, it is one of the best software testing books ever written. We highly recommend it to new and experienced software testers alike without reservations. Chapter 4, titled “Finding Interesting Things to Vary,” is particularly outstanding. The chapter does a superb job of articulating not only what kinds of variables you can change from test to test but also why it is such a good idea to vary them. These “Hendrickson Variables” come from Chapter 4 of “Explore It!”

Hendrickson lays-out her list of Interesting Things to Vary as follows:

  • Countable Things

...

  • Relative Positioning

...

  • Files and Storage

...

  • Formats

...

  • Size

...

  • Geographic Locations

...

  • Depth

...

  • Timing, Frequency, and Duration

...

  • Input and Navigation

...


"Rule of thumb" based on likelihood of relevance and effort

A “rule of thumb” to guide you as you decide what things should be included and excluded in the Parameters screen:

Deciding whether to include a specific test idea often comes down to a judgment call by the test designer using TCD.

...

Including test ideas using the Value Expansion feature allows for quick testing without wasting time (over testing).An example: imagine



Info
titleExample
Imagine that you’re testing a new feature of a financial transaction application. It will be used for foreign or domestic transactions. Setting up the testing environment for each foreign transaction requires dramatically more time than for domestic transactions. If you were to include “Type of Transaction” as a Parameter and use “Domestic” and “International” as the 2 Values for that Parameter, approximately 50% of your tests would be international transactions which would each require a great deal of extra setup time.



In such situations, you might instead consider using “Type of Transaction” as a Value and then adding “Domestic, International, Domestic, Domestic, Domestic, Domestic, Domestic” as sub-values when you create your Value Expansion. Using this test design technique would result in at least one “International” transaction (for coverage of this potentially important scenario) but you would avoid spending too much time “over-testing” the idea.

...