From Use Cases to Test Cases 1

A Tester’s Perspective  Without use cases testers will approach the system to be tested as a “black box”. “What, exactly, is this system supposed to do, and in what order is it supposed to do it?” “What are all the things that can go wrong with the system, and how is the system supposed to behave when this happens?” “How can I create and record a set of testing scenarios in which I can put this system through its paces?” “How will I know when I’ve tested the system completely and thoroughly?” “Is there anything else this system is supposed to do, or not do, that I need to know about?” 2

A Tester’s Perspective (Cont’d)  If the requirements were developed using a use case approach, the testers will have: A comprehensive set of use cases that documents an ordered sequence of events describing how the system interacts with the user and how it delivers its results to that user. A use-case model that documents all the use cases for the system, as well as how they interact and what actors drive them. Within each use case, both a basic flow of events and alternate flows that define what the system does in other situations. Descriptions of pre-conditions and post-conditions. A supplementary specification that defines the nonfunctional requirements of the system.  The use-case approach technique builds a set of assets that can directly drive the testing process. 3

Common Testing Terms  A test plan contains information about the purpose and goals of testing and identifies strategies to be used in testing.  A test case is a set of test inputs, execution conditions, and expected results developed for a particular objective (e.g., to verify compliance with a specific requirement).  A test procedure is a set of detailed instructions for the setup, execution, and evaluation of results for a given test case.  A test script is a software script that automates the execution of a test procedure (or portion of).  Test coverage defines the degree to which a given test or set of tests address all specified test cases for a given system component.  A test item is a build that is an object of testing.  Test results are a repository of data captured during the execution of a test used in analyzing test results. 4

Use Case Scenarios  A scenario, or an instance of a use case, is a use case execution wherein a specific user executes the use case in a specific way.  Each possible sequence of flows in a use case is a separate scenario. 5

Steps in Deriving Test Cases from Use Cases 1. Identify the use case scenarios. 2. For each scenario, identify one or more test cases. 3. For each test case, identify the conditions that will cause it to execute. 4. Complete the test case by adding data values. 6

Step 1: Identify the Use Case Scenarios  You can construct a matrix to construct all possible combinations of basic and alternate flows.  Be aware that it is possible that not all possible scenarios are described in the original use case.  The process is iterative and may require changes in the design and/or the requirements specification. 7

Step 2: Identify the Test Cases  For each scenario specify one or more test cases.  Each test case should include the parameters of the test to be conducted, including the conditions of the test and the expected results. 8

Step 3: Identify the Test Conditions  For each test case identify what conditions cause the execution of a specific event or sequence of events within a use case?  For each condition indicate which of the following three states would cause execution of the test case: Valid (V) indicates a condition that must be true for the basic flow to execute. Invalid (I) indicates a condition that will invoke the alternate flow, causing a specific scenario to occur. Not applicable (N/A) indicates that an identified condition is not applicable to that test case. 9

Step 4: Add Data Values to Complete the Test Case  Real data must be provided as necessary to be able to execute the test cases.  Make sure also that the test cases address any special requirements (minimum/maximum performance, loads, or data volumes) defined for the use case. 10

Managing the Test Coverage  For most applications, testing all use cases at this level of thoroughness is not practical. Consider the following guidelines for choosing use cases to test. Select the most appropriate or critical use cases for the most thorough testing. E.g., primary user interfaces, those architecturally significant or have potential for causing significant problems if incorrect. Choose each use case to test based on a balance between the cost, risk, and necessity for verification. Determine the relative importance of your use cases by using a priority algorithm specific to your context. 11

Black-Box versus White-Box Testing with Use Cases  Can use cases help with white-box testing? 12