Topic: Designing Test Cases

A test case is a detailed procedure that fully tests a feature or an aspect of a feature. Whereas the test plan describes what to test, a test case describes how to perform a particular test. You need to develop a test case for each test listed in the test plan. Figure 2.10 illustrates the point at which test case design occurs in the lab development and testing process.

Figure 2.10   Designing Test Cases

A test case includes:

•	The purpose of the test.
•	Special hardware requirements, such as a modem.
•	Special software requirements, such as a tool.
•	Specific setup or configuration requirements.
•	A description of how to perform the test.
•	The expected results or success criteria for the test.

Test cases should be written by a team member who understands the function or technology being tested, and each test case should be submitted for peer review.

Organizations take a variety of approaches to documenting test cases; these range from developing detailed, recipe-like steps to writing general descriptions. In detailed test cases, the steps describe exactly how to perform the test. In descriptive test cases, the tester decides at the time of the test how to perform the test and what data to use.

Most organizations prefer detailed test cases because determining pass or fail criteria is usually easier with this type of case. In addition, detailed test cases are reproducible and are easier to automate than descriptive test cases. This is particularly important if you plan to compare the results of tests over time, such as when you are optimizing configurations. Detailed test cases are more time-consuming to develop and maintain. On the other hand, test cases that are open to interpretation are not repeatable and can require debugging, consuming time that would be better spent on testing.

Table 2.1 provides an example of the first few steps of a detailed test case.

Table 2.1   Sample Detailed Test Case

Step	Procedure	Success Criteria	Outcome
1	Log off the server, and return to the netlogon screen.	None.
2	Click the domain list to open it.	The local server name does not appear in the list.
3	Click the domain list to open it.	The root domain appears in the list.
4	Log on to the server using an account with administrative credentials.	The account logs on to the server without errors.

When planning your tests, remember that it is not feasible to test everything. Instead of trying to test every combination, prioritize your testing so that you perform the most important tests — those that focus on areas that present the greatest risk or have the greatest probability of occurring — first. For example, you might choose to test the slowest client computer, the busiest server, or the least reliable network link. Then, if time allows, you can perform lower priority tests.

Please also consider the Hexawise test case generating tool at http://www.hexawise.com/users/new.  We have a free version and a 30-second login process for full access.

Unlike most test design tools, Hexawise offers:

1) Not only pairwise (AKA 2-way) solutions, but we offer 3-way, 4-way, 5-way, and even 6-way solutions.  (In other words, you can choose the level of thoroughness you desire, and Hexawise will generate the test conditions you should execute).

2) Clear graphs showing the coverage that your test plan is generating (e.g., you will be able to tell that after test #26, for example, you have tested for a specific percentage of the total number of possible pairs of values that you have indicated you want to test for

3) Example plans that help get you started using a test design tool

4) Clear FAQ and Help sections to address any questions you might have (see http://www.hexawise.com/faq and http://www.hexawise.com/help

5) The ability to identify certain combinations of values as invalid.  (Once testers begin using test design tools, they recognize that this feature is extremely important; if Parameter values include "Annual Income" = US$5,000 and "Mortgage Type" = Jumbo, for example, but a user of a mortgage application with that income would be unable to even select the option to apply for a Jumbo mortgage, if your test design tool does not allow you to eliminate those invalid combinations automatically, you will either (a) wind up with lost coverage that you had hoped your tool would be able to deliver, (b) spend many hours trying to address this shortfall by manual adjustments to your test cases, or (c) both.

Lastly, we have an 11-slide presentation on our home page to quickly provide a little more background information about the tool and the problems it solves with screen shots.  It also contains an interesting case study of how Hexawise can help you reduce 72 billion possible test cases (that would be required -at least - to comprehensively test the "get directions" functionality of Google Maps) to only 35 test cases that achieve coverage of every single valid pair of parameter values involved.  (e.g., in those 35 test cases, every single browser type is tested together with every mode of transportation choice at least once, every single view option is tested together with every option for the zoom/in zoom/out function, etc.)

Please sign up for free access at:  http://www.hexawise.com/users/new

Thank you.