FOR0383 Software Quality Assurance Lecture 30 Testing with Use Cases Register for Courses Student Course Catalog System 4/13/2009 Dr Andy Brooks 1
Source Article Generating Test Cases From Use Cases by Jim Heumann Rational edge e-zine for the rational community, June, 2001 Rational Software 2001 http://www.ibm.com/developerworks/rational/library/content/rationaledge/jun01/ge neratingtestcasesfromusecasesjune01.pdf Use cases are developed early in the project lifecycle. Test cases can be written before any code is written. 4/13/2009 Dr Andy Brooks 2
What is a Use Case? According to the Rational Unified Process, a Use Case fully describes a sequence of actions performed by a system to provide an observable result of value to a person or another system using the product under development. Use cases tell the customer what to expect, the developer what to code, the technical writer what to document, and the tester what to test. 4/13/2009 Dr Andy Brooks 3
Figure 1: Use Case Diagram for a University Course Registration System Register for Courses Student Course Catalog System Select Courses to Teach Close Registration Professor Registrar The ovals are Use Cases. The stick figures are human or other system actors. The lines represent (directed) communication. 4/13/2009 Dr Andy Brooks 4
It is a significant step to identify use cases and actors, but now there is more to be done. Each use case also requires a significant amount of text to describe it. This text is usually formatted in sections, as shown in Table 1. 4/13/2009 Dr Andy Brooks 5
Table 1: Format for a Use-Case Textual Description Use Case Section Name Brief Description Flow of events Special Requirements Preconditions Postconditions Description An appropriate name. A brief description of the Use Case. A description of what the system does, not how the system does it. The description must be understandable by the customer. Non-functional requirements that need to be addressed during design and implementation. Constraints that apply at the time the Use Case starts. Constraints that apply at the time the Use Case ends. The most important part is flow of events (basic flow and alternative flow). 4/13/2009 Dr Andy Brooks 6
Figure 2: Basic Flow of Events and Alternate Flows of Events for a Use Case Rational Software 2001 Basic flow should be considered as what normally happens. Sometimes alternative flows return to the basic flow and sometimes they end the Use Case. 4/13/2009 Dr Andy Brooks 7
Use Case: Register for Courses, Basic Flow Rational Software 2001 1. Logon This use case starts when a Student accesses the Wylie University Web site. The system asks for, and the Student enters, the student ID and password. 2. Select Create a Schedule The system displays the functions available to the student. The student selects "Create a Schedule." 3. Obtain Course Information The system retrieves a list of available course offerings from the Course Catalog System and displays the list to the Student. 4/13/2009 Dr Andy Brooks 8
Use Case: Register for Courses, Basic Flow Rational Software 2001 4. Select Courses The Student selects four primary course offerings and two alternate course offerings from the list of available course offerings. 5. Submit Schedule The student indicates that the schedule is complete. For each selected course offering on the schedule, the system verifies that the Student has the necessary prerequisites. 6. Display Completed Schedule The system displays the schedule containing the selected course offerings for the Student and the confirmation number for the schedule. 4/13/2009 Dr Andy Brooks 9
Use Case: Register for Courses, Alternative Flows Rational Software 2001 1. Unidentified Student In Step 1 of the Basic Flow, Logon, if the system determines that the student ID and/or password is not valid, an error message is displayed. 2. Quit The Course Registration System allows the student to quit at any time during the use case. The Student may choose to save a partial schedule before quitting. All courses that are not marked as "enrolled in" are marked as "selected" in the schedule. The schedule is saved in the system. The use case ends. 4/13/2009 Dr Andy Brooks 10
Use Case: Register for Courses, Alternative Flows Rational Software 2001 3. Unfulfilled Prerequisites, Course Full, or Schedule Conflicts In Step 5 of the Basic Flow, Submit Schedule, if the system determines that prerequisites for a selected course are not satisfied, that the course is full, or that there are schedule conflicts, the system will not enroll the student in the course. A message is displayed that the student can select a different course. The use case continues at Step 4, Select Courses, in the basic flow. 4. Course Catalog System Unavailable In Step 3 of the Basic Flow, Obtain Course Information, if the system is down, a message is displayed and the use case ends. 5. Course Registration Closed If, when the use case starts, it is determined that registration has been closed, a message is displayed, and the use case ends. 4/13/2009 Dr Andy Brooks 11
Textual descriptions of flows Each step should be numbered. A step should indicate what the actor does and what the system does in response. Alternative flows always specify where they start in the basic flow and where they go when they end. 4/13/2009 Dr Andy Brooks 12
Use-Case Scenarios A scenario is a path through a Use-Case. Following the basic flow is one of many possible scenarios. Scenarios are used for creating test cases. Table 2 lists all the possible scenarios for the diagram shown in Figure 2. Note: In creating a list of all the possible scenarios, the loop of Alternative Flow 3 is either not taken or taken only once. zero times and one time around the loop 4/13/2009 Dr Andy Brooks 13
Table 2: Scenarios for the Use Case shown in Figure 2 Rational Software 2001 Scenario 1 Basic Flow Scenario 2 Basic Flow Alternative Flow 1 Scenario 3 Basic Flow Alternative Flow 1 Alternative Flow 2 Scenario 4 Basic Flow Alternative Flow 3 Scenario 5 Basic Flow Alternative Flow 3 Alternative Flow 1 Scenario 6 Basic Flow Alternative Flow 3 Alternative Flow 1 Alternative Flow 2 Scenario 7 Basic Flow Alternative Flow 4 Scenario 8 Basic Flow Alternative Flow 3 Alternative Flow 4 4/13/2009 Dr Andy Brooks 14
Table 3: Partial Scenario Matrix for the Register for Courses Use Case Rational Software 2001 Scenario Name Starting Flow Alternate S1 Successful registration Basic Flow S2 Unidentified student Basic Flow A1 S3 User quits Basic Flow A2 S4 Course Catalog System unavailable Basic Flow A4 S5 Registration Closed Basic Flow A5 S6 Cannot enroll Basic Flow A3 There should be at least one test case for each scenario. Additional test cases may be required for a scenario like A3 where cannot enroll can be as a result of either unfulfilled prerequisites, a course being full, or a conflict in the schedule. Additional test cases may be required for a scenario to test boundary values. 4/13/2009 Dr Andy Brooks 15
Test Case ID RC1 Table 4: Test Case Matrix for the Register for Courses Use Case Rational Software 2001 Scenario/ Condition S1 successful registration RC2 S2 unidentified student RC3 RC4 S3 valid user quits S4 course registration system unavailable Student ID Password Courses selected Prerequisties fulfilled Course Open Schedule Open Expected Result V V V V V V Schedule and confirmation number displayed I N/A N/A N/A N/A N/A Error message: back to login screen V V N/A N/A N/A N/A Login screen appears V V N/A N/A N/A N/A Error message: back to step 2 V means valid, I means invalid, and N/A means that it is not necessary to supply a data value in this case. 4/13/2009 Dr Andy Brooks 16
Table 4: Test Case Matrix for the Register for Courses Use Case Rational Software 2001 Test Case ID Scenario/ Condition RC5 S5 registration closed RC6 RC7 RC8 S6 cannot enroll, course full S6 cannot enroll, prerequisite not fulfilled S6 cannot enroll, schedule conflict Student ID Password Courses selected Prerequisties fulfilled Course Open Schedule Open Expected Result V V N/A N/A N/A N/A Error message: back to step 2 V V V V I V Error message: back to step 3 V V V I V V Error message: back to step 4 V V V V V I Error message: back to step 4 4/13/2009 Dr Andy Brooks 17
A review (inspection) of Table 4 Test case matrices such as Table 4 should be reviewed for accuracy and completeness. Identify redundant or missing test cases. Outwith successful flow, a row should normally contain at least one I, indicating an invalid condition being tested. For example, RC3, RC4, and RC5 have the same combination of Vs and N/As: Conditions concerned with Course Registration System unavailable and Registration Closed are missing. When a test case matrix is approved, actual data values can then be specified for each test case. 4/13/2009 Dr Andy Brooks 18
Table 5: Test Case Matrix with Data Values Rational Software 2001 4/13/2009 Dr Andy Brooks 19
Generating Test Cases from Use Cases - summary - Identifying all the scenarios in a Use Case is like identifying all the paths in a graph. The loop problem in graph-based testing is solved by looping zero times or one time only. Scenario matrices need to be reviewed for accuracy and completeness before actual data values are chosen for each test case. Perhaps the greatest benefit in trying to write test cases from Use Cases is identifying how to improve the Use Cases. 4/13/2009 Dr Andy Brooks 20