How to Write Test Cases

Many testers / Quality Assurance engineers have issues when dealing with test cases. How much information is enough? What are the necessary steps to create detailed test cases?

We recommend the following 4-step process for generating test cases from a fully detailed use case:

  1. For each use case, generate a full set of use-case scenarios.
  2. For each scenario, identify at least one test case
  3. For each test case, identify the conditions that will make it “execute.”
  4. For each test case, identify the data values with which to test.


Step 1: Identify the Use-Case Scenarios

The flow chart of events presents the use-case scenarios.


The Scenario Matrix table presents eight possible scenarios for the sample use case. Note that the use case we’ve described is not an overly complex one, and yet a significant number of scenarios may result. As the use cases grow more complex, more and more scenarios will result. In many situations, you will need to devise a testing strategy that recognizes that it is impractical to test all possible scenarios but still assures that adequate testing is achieved.

Scenario Matrix Table

Scenario Number Originating Flow Alternate Flow Next Alternate Next Alternate
1 Basic flow
2 Basic flow Alternate Flow 1
3 Basic flow Alternate Flow 1 Alternate Flow 2
4 Basic flow Alternate Flow 3
5 Basic flow Alternate Flow 3 Alternate Flow 1
6 Basic flow Alternate Flow 3 Alternate Flow 1 Alternate Flow 2
7 Basic flow Alternate Flow 4
8 Basic flow Alternate Flow 3 Alternate Flow 4

In addition, you should be aware that not all scenarios might be described in the original use case and that this scenario discovery process might need to be conducted interactively with the development team as well. There are two reasons for this.

  1. The use cases developed for implementation are not 100 percent exhaustive and are written at a level of detail that may be insufficient for testing.
  2. The test team’s review process will create new discoveries and additional scenarios that may result from executing the use case.


Step 2: Identify the Test Cases

The test case should contain the parameters of the test to be conducted, including the conditions of the test and the expected results. One common format, used only to learn how to design test cases, illustrated below, is to use a matrix in which each row represents a specific test case and the columns represent scenarios, conditions, data values, and expected and actual results.

Matrix for Testing Specific Scenarios Table

Test Case ID Scenario / Condition Data Value 1 Data Value 2 Data Value N Expected Result Actual Result
1 Scenario 1
2 Scenario 2
3 Scenario 2

Note in table above that more than one test case can result from a specific scenario (see test case IDs 2 and 3, both for scenario 2). Typically, this arises because of various logical constructs identified in a single step in a use case. For example, consider the following step in a use case:
The homeowner enters the desired lighting sequence for each day of the week up to a maximum of seven different daily settings. The system confirms acceptance of each daily entry with a beep.
This single step in the use case will produce two test cases from this step as shown in the table below:

Two Test Cases for One Scenario

Test Case ID Scenario / Condition Description Expected Result
1 Scenario 6 Less than seven sequences entered Sequence saved; System beeps
2 Scenario 6 Attempt to enter an eighth sequence Error?


Step 3: Identify the Test Conditions

The next step is to identify the specific conditions in the test case that would cause it to execute. In other words, what conditions cause a user to execute a specific event or sequence of events within a use case? During this process, the tester searches the use-case steps for the various data conditions, branches, and so on that would cause a specific test case to occur. For each such condition identified, the tester enters a new column in the matrix, representing the specific condition identified. In this initial pass, it is adequate to simply identify that a condition exists, create the column entry, and then indicate which of the three states that could occur for that condition (valid, invalid, or not applicable) is appropriate.

  1. Valid (V) indicates a condition that must be true for the basic flow to execute.
  2. Invalid (I) indicates a condition that will invoke the alternate flow, causing a specific scenario to occur.
  3. Not applicable (N/A) indicates that an identified condition is not applicable to that specific test case ID.


Step 4: Add Data Values to Complete the Test Case

We’ve made good progress. We have now identified all the conditions that need to be tested to test a specific use case fully. We’re not quite done, however—without real data, test cases are merely descriptions of conditions, scenarios, and paths without concrete values to identify them succinctly. Without such data, it’s not possible to execute the test case and determine the results. In many cases, the use cases themselves will not directly identify these data values, and you will have to look to supplementary specifications to find performance specs, valid data ranges for input forms and interface protocols, and so on. However, this is not a new problem to the tester; just use your normal techniques for finding the data ranges.

This is also the time to make sure that test cases address any special requirements defined for the use case. These include such things as minimum / maximum performance, sometimes combined with minimum / maximum loads, or data volumes expected during the execution of the use cases.

Once you have identified the data ranges, you can finalize the test matrix with those values. Then you are ready to execute the test cases.

3 thoughts on “How to Write Test Cases

  1. This is a nice overview, of how to derive test cases.

    I do not really like the Scenario Matrix Table.
    It is not a matrix, it is a tree of paths.
    To derive the possible paths systematically, you walk through the UI of your application and list at each input, what different choices you want to take. Choices are different input values or different sequence of input values, which have relevance to the path through your UI (i.e. press the accept or cancel button). For each choice you have to follow the different branches.
    To limit the paths you define a pruning strategy, like not taking different sequences of giving input values into account, or disregarding further branches once leaving the happy path.
    This defines your strategy to path coverage.
    In addition you have then to define a strategy for data coverage,
    which defines, for which input elements you want to have which business relevant cases and which corner cases. To fulfill the data coverage,
    you might need to repeat paths defined above.
    The complexity in path and data coverage is, that they are neither independent from each other nor fully dependant. A mathematical model is to consider them as two dimensions, which are not orthogonal.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>