Understanding, Designing and Testing Use Cases

Harinath V Pudipeddi [email protected] www.sqae.com Introduction Unified Modeling Language (UML) is fast gaining popularity and is being used by many organizations. Testing projects/products using the UML notation calls for Test Engineers who are well versed with UML and its structure. This paper aims at those individuals who are into testing these UML based applications. UML has been conceived by Ivar Jacobson (aka as Father of Use Cases), James Raumbaugh and Grady Booch. All the three are senior scientists for Rational Corporation. In this paper I have concentrated to explain the understanding, designing and testing of Use Cases, one of the 9 UML diagrams. The introduction section (Pages 3-5) has been taken from various books on UML which include few authored by the scientists themselves, because the concepts are important and should be understood thoroughly. Please feel free to send me your comments on this paper to [email protected].

Understanding, Designing and Testing Use Cases

What is UML? UML stands for Unified Modeling Language (UML), a well approached and planned language based on the Object Oriented concept. Without going much deep into UML and its structure, I would brief here an outline of what the UML contains. Diagrams in UML A Diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships). There are nine diagrams included in UML: 1. 2. 3. 4. 5. 6. 7. 8. 9. Class Diagram Object Diagram Use Case Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram

Class Diagrams Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves. Object Diagrams Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object diagrams contain the following elements: Objects and Links. Use Case Diagrams Use Case Diagrams describe the functionality of a system and users of the system. These diagrams contain the following elements: Actors and Use Cases. Sequence Diagrams Sequence Diagrams describe interactions among classes. These interactions are modeled as exchange of messages. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams are a type of interaction diagrams. Sequence diagrams contain the following elements: Class Roles, Lifelines, Activations and Messages. Collaboration Diagrams Collaboration Diagrams describe interactions among classes and associations. These interactions are modeled as exchanges of messages between classes through their associations. Collaboration diagrams are a type of interaction diagram. Collaboration diagrams contain the following elements: Class Roles, Association Roles, Message Roles.

Understanding, Designing and Testing Use Cases

Statechart Diagrams Statechart (or state) diagrams describe the states and responses of a class. Statechart diagrams describe the behavior of a class in response to external stimuli. These diagrams contain the following elements: States, Transitions. Activity Diagrams Activity diagrams describe the activities of a class. These diagrams are similar to statechart diagrams and use similar conventions, but activity diagrams describe the behavior of a class in response to internal processing rather than external events as in statechart diagram. Component Diagrams Component diagrams describe the organization of and dependencies among software implementation components. These diagrams contain components, which represent distributable physical units; including source code, object code, and executable code. Deployment Diagrams Deployment diagrams describe the configuration of processing resource elements and the mapping of software implementation components onto them. These diagrams contain components and nodes, which represent processing or computational resources, including computers, printers, etc. Model View of UML

Structural View Class / Object Diagrams

Implementation View Component Diagrams

Use Case Diagrams Sequence / Collaboration / Statechart / Activity Diagrams Behavioral View Deployment Diagrams Environmental View

The Use Case View of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts and testers. With the UML, the static aspects of this view are captured in use case diagrams; the dynamic aspects of this view are captured in interaction diagrams, Statechart diagrams and activity diagrams.

Understanding, Designing and Testing Use Cases

The Design View of a system encompasses the classes, interfaces and collaborations that form the vocabulary of the problem and its solution. This view primarily supports the functional requirements of the system, meaning the services that the system should provide to its end users. With UML, the static aspects of this view are captured in class diagrams and object diagrams, the dynamic aspects of this view are captured in interaction diagrams, Statechart diagrams and activity diagrams. The Process View of a system encompasses the threads and processes that form the systems concurrency and synchronization mechanisms. This view primarily addresses the performance, scalability and throughput of the system. With the UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view, but with a focus on the active classes that represent these threads and processes. The Implementation View of a system encompasses the components and files that are used to assemble and release the physical system. This view primarily addresses the configuration management of the systems releases, made up of somewhat independent components and files that can be assembled in various ways to produce a running system. With the UML, the static aspects of this view are captured in component diagrams; the dynamic aspects of this view are captured in interaction diagrams, Statechart diagrams, and activity diagrams. The Deployment View of a system encompasses the nodes that form the systems hardware topology on which the system executes. This view primarily addresses the distribution, delivery and installation of the parts that make up the physical system. With the UML, the static aspects of this view are captured in deployment diagrams; the dynamic aspects of this view are captured in interaction diagrams, Statechart diagrams, and activity diagrams.

Understanding, Designing and Testing Use Cases

Use Case Diagrams As we have discussed earlier, a Use Case view explains the behavior of the system to end users, analysts and testers. Designing a Use Case With a small example, let us see how we can design a Use Case. Suppose that we are designing an application which has the login screen functionality for authentication. The login screen is one of the most important in an application and the design for the same should be perfect. The requirements for the login functionality are like this: 1. The login screen should have User Name, Password and Connect to fields. 2. The Connect to field is not mandatory. This field helps the user to connect to a particular database. If the user needs, he can use this option or by default it should connect to the database which we have pre-defined to be default. 3. Login, Clear and Cancel buttons should be available. 4. Depending on the login name, the user should be taken to the Administrator page or the normal user page. We have our requirements clear. Now we need to approach to design use case for this. As the definition goes, a use case is used to explain the behavior of the system. The UML Specification Document, UML Notation document or the UML Schematic document does not specify that a use case should be structured in a specific way. This leads to a debate of how the use case should be structured and designed. There are many formats and ways in which a use case can be designed and used. Here, I would be depicting the usually way in which I design a use case. A typical use case contains the following information: Use Case Section Description Name An appropriate name for the Use Case. Brief Description A brief description of the use cases role and purpose. Actors Persons who are users to the functionality. Flow of Events A textual representation of what the system does with regard to the use case. Usual notation for the flow of events are: Main Flow Alternative Flow Exceptional Flow Special Requirements A textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation. Pre-Conditions A textual description that defines any constraints on the system at the time the

Understanding, Designing and Testing Use Cases

Post-Conditions

use case may start. A textual description that defines any constraints on the system at the time the use case will terminate.

After having seen what the use case should typically contain, let us write the use case for the login requirements what we have defined. Use Case Name: Login Description: This use case explains the login functionality. Actors: Administrator, User. Main Flow: Login Action 1. Actor invokes the application. 2. Actor enters User ID, Password and clicks on <Login> button. Actor enters wrong User ID, see alternative flow 1. Actor enters wrong Password, see alternative flow 2. Actor chooses to connect to different database, see alternative flow 3. Actor clicks on <Clear>, see alternative flow 4. Actor clicks on <Cancel>, see alternative flow 5. Alternate Flow 1: Actor enters wrong User ID Action Response 1. Actor enters wrong User ID and 1. Display error message Invalid User password and clicks <Login>. ID, Please try again. Alternate Flow 2: Actor enters wrong Password Action Response 1. Actor enters User ID and wrong 1. Display error message Invalid password and clicks <Login>. Password, Please try again. Response 1. Display login page with User ID, Password, Connect fields along with Login, Clear and Cancel buttons. 2. Authenticate and display the home page.

Alternate Flow 3: Actor chooses different database

Understanding, Designing and Testing Use Cases

Action 1. Actor enters User ID, Password and chooses to connect to a different database by selecting from the list.

Response 1. Connect to the mentioned database and display home page.

Alternate Flow 4: Actor clicks on <Clear> Action Response 1. Actor enters some information in the 1. Clear the contents in the fields and User ID, Password or Connect field and position the cursor in the User ID field. then clicks on <Clear> Alternate Flow 3: Actor clicks on <Cancel> Action Response 1. Actor clicks on <Cancel> button. 1. Close the login screen. Business Rules 1. When the login screen is initially displayed, the <Login> and <Clear> buttons should be disabled. 2. <Cancel> button should always be enabled. 3. When the actor enters any information in User ID, Password or selects any other database in the list in the Connect To field, then enable <Clear> button. 4. When the actor enters information in User ID and Password fields, then enable <Login> button. 5. The tabbing order should be User ID, Password, Connect To, Login, Password, Clear and Cancel buttons. The Business Rules which we have addressed towards the end of the use case are for the whole functionality of the use case. If there are any business rules for individual fields we can address them here. Let us look at another way of writing the above use case. In this format, I would be addressing the Business Rules in a third column in the use case itself. Main Flow: Login Action 1. Actor invokes the application. Response 1. Display login page with User ID, Password, Connect fields and Login, Clear and Cancel buttons. Business Rule 1. When the login screen is initially displayed, the <Login> and <Clear> buttons should be disabled. 2. <Cancel> button should always be enabled. 3. When the actor enters any information in User ID, Password or selects any other database in the list in the Connect To field, then enable <Clear> button. 4. When the actor

Understanding, Designing and Testing Use Cases

enters information in User ID and Password fields, then enable <Login> button. 5. The tabbing order should be User ID, Password, Connect To, Login, Password, Clear and Cancel buttons. 2. Actor enters User ID, Password and clicks on <Login> button. If actor enters wrong User ID, see alternative flow 1. If actor enters wrong Password, see alternative flow 2. If actor chooses to connect to different database, see alternative flow 3. If actor clicks on <Clear>, see alternative flow 4. If actor clicks on <Cancel>, see alternative flow 5. In this format, the use case might look a bit jazzy, but it is easier to read. The business rules (validation rules) for each step are addressed in the same row itself. In my opinion when you are writing functional use cases then we can use the first format and when we are writing the user interface use cases, then we can use the second format. Understanding a Use Case Understanding a use case is nothing big if you know how to read English and have a little bit of reasoning skills. Let us look at understanding the above written use case itself. The use case depicts the behavior of the system. When you are reading the above use case you read each step horizontally. Look at step 1 written in the first type of use case: 2. Authenticate and display the home page.

Understanding, Designing and Testing Use Cases

Main Flow: Login Action 1. Actor invokes the application.

Response 1. Display login page with User ID, Password, Connect fields along with Login, Clear and Cancel buttons.

Here Action, is something which is performed by the user; and Response is the application/system response to the action performed by the user. Thus, you can understand that when the actor performs an action of invoking the application, the login screen is displayed with the mentioned fields and information. In the first type of writing use case, the Business Rules have been addressed below after all the flows. In the second type of writing use case, the same Business Rules have been addressed in a third column. Business Rules are nothing but special conditions which have to be satisfied by the response of the system. Testing Use Cases Testing Use Cases calls for a through understanding the concept of use case, how to read it and how do you derive test cases from it. I will explain briefly a methodology I follow when deriving test cases and scenarios from Use Cases. For each actor involved in the use case, identify the possible sequence of interactions between the system and the actor, and select those that are likely to produce different system behaviors. For each input data coming from an actor to the use case, or output generated from the use case to an actor, identify the equivalence classes sets of values which are likely to produce equivalent behavior. Identify Test Cases based on Range Value Analysis and Error Guessing. Each test case represents one combination of values from each of the below: objects, actor interactions, input / output data. Based on the above analysis, produce a use case test table (scenario) for each use case. Select suitable combinations of the table entries to generate test case specifications. For each test table, identify the test cases (success or extension) tested. Ensure all extensions are tested at least once. Maintain a Use Case Prioritization Table for the use cases for better coverage as follows: Use Case No Use Case Risk Frequency Criticality Priority

The Risk column in the table describes the risk involved in the Use Case. The Frequency column in the table describes how frequently the Use Case occurs in the system.

Understanding, Designing and Testing Use Cases

10

The Criticality column in the table describes the importance of the Use Case in the system. The Priority column in the table describes the priority for testing by taking the priority of the use case from the developer. Some use cases might have to be tested more thoroughly based on the frequency of use, criticality and the risk factors. Test the most used parts of the program over a wider range of inputs than lesser user portions to ensure better coverage. Test more heavily those parts of the system that pose the highest risk to the project to ensure that the most harmful faults are identified as soon as possible. The most risk factors such as change in functionality, performance shortfall or change in technology should be bared in mind. Test the use cases more thoroughly, which have impact on the operation of the system. The pre-conditions have to be taken into consideration before assuming the testing of the use case. Make test cases for the failure of the pre-conditions and test for the functionality of the use case. The post-conditions speak about the reference to other use cases from the use case you are testing. Make test cases for checking if the functionality from the current use case to the use case to which the functionality should be flowing is working properly. The business rules should be incorporated and tested at the place where appropriately where they would be acting in the use case. Maintain a Test Coverage Matrix for each use case. The following format can be used:
UC No. UC Name Flow TC Nos No. of TCs Tested Status

In the above table:

The UC No. column describes the Use Case Number. The UC Name column describes the Use Case Name. The Flow column describes the flow applicable: Typical Flow, Alternate Flow 1, Alternate Flow 2, etc. The TC Nos column describes the start and end test case numbers for the flow. The No. of TCs column describes the total number of test cases written. The Tested column describes if the flow is tested or not. The Status column describes the status of the set of test cases, if they have passed or failed.

Understanding, Designing and Testing Use Cases

11

Strategy for designing the Test Cases and Test Scenarios The following steps typically speak of a strategy for designing the Test Case(s) and Test Scenario(s) from the Use Case document. Step 1: Step 2: Step 4: Step 3: Step 4: Step 5: Step 6: Step 7: Step 8: Step 9: Identify the module / class / function for which the Use Case belongs. Identify the functionality of the Use Case with respect to the overall functionality of the system. Identify the Functional Points in the Use Case and make a Functional Point Document. Identify the Actors involved in the Use Case. Identify if the Use Case Extends or Uses any other Use Case. Identify the pre-conditions. Understand the Typical Flow of the Use Case. Understand the Alternate Flow of the Use Case. Identify the Business Rules. Check for any post-conditions and special requirements.

Step 10: Document Test Cases for the Typical Flow (include any actions made in the alternate flow if applicable). Step 11: Document the Test Cases for Business Rules. Step 12: Document Test Cases for Alternate Flow. Step 13: Finally, identify the main functionality of the Use Case and document a complete positive end-to-end scenario. Make a Cross Reference Matrix with respect to each: 1. Use Case Document and Functional Point Document. 2. Functional Point Document and Test Case Document. 3. Test Case Document and Defect Report. These Cross-Reference Matrix Documents would be helpful for easily identifying and tracking out the defects and the functionality. Version Control For every Test Case Document maintain Version Control Document for tracking out the changes in the Test Case Document. The template can be made in the following way: Version Number Date Comments

Understanding, Designing and Testing Use Cases

12