SYST30009

Engineering Quality Software

In-Class-Exercise-02

This assignment is worth 1% and must be completed in class before you leave in order to receive credit.

As discussed and describedin the example presented at the beginning of this class, the most important part of a use case for generating test cases is the flow of events. The two main parts of the flow of events are the basic flow of events and the alternate flows of events. From the description of the “Fill Order” use case provided below, which provides both the basic and alternate flows of events, construct the appropriate test cases using the three-step process described in class.

Step One – Generate Scenarios

Read the use case textual description provided and identify each combination of main and alternate flows –the scenarios – and create a scenario matrix.

Scenario Name / Starting Flow / Alternate

Step Two – Identify Test Cases

Once the full set of scenarios has been identified, the next step is toidentify the test cases. Do this by analyzing the scenarios andreviewing the use case textual description as well. There should be at leastone test case for each scenario, but there could probably be more and then additional test cases may be required to test all the possibilities.

The next step in fleshing out the test cases is to reread the use-casetextual description and find the conditions or data elements required toexecute the various scenarios. To clearly document the test cases, once again, a matrix format is useful,like the one below . Notice the top row. The first column contains thetest case ID, the second column has a brief description of the test case,including the scenario being tested, and all other columns except the lastone contain data elements that will be used in implementing the tests. Thelast column contains a description of the test case's expected output.

Test Case Matrix for a use case.

Column one contains the test case ID and column two a brief description of the test case and the scenario being tested. The other columns except the last one contain the data elements that will be used in implementing the tests. The last column contains a description of the test case’s expected output.

Note that in this matrix no data values are actually entered. Thecells of the table should contain a V, I, or n/a. V indicates valid, I is for invalid,and n/a means that it is not necessary to supply a data value in this case.This specific matrix is a good intermediate step; it clearly shows whatconditions are being tested for each test case. It is also very easy todetermine by looking at the Vs and Is whether you have identified asufficient number of test cases. In addition to the "happy day" scenarios inwhich everything works fine, each row in the matrix should have at leastone I indicating an invalid condition being tested.

Note: the number of columns and rows shown below are for illustration purposes.

Test Case ID / Scenario/Condition

Step Three – Identify Data Values to Test

Once all of the test cases have been identified, they should be reviewedand validated to ensure accuracy and to identify redundant or missing testcases. Then, once they are approved, the final step is to substitute actualdata values for the Is and Vs. Without test data, test cases (or testprocedures) can't be implemented or executed; they are just descriptionsof conditions, scenarios, and paths. Therefore, it is necessary to identifyactual values to be used in implementing the final tests.

Test Case ID / Scenario/Condition

In current practice, use cases are associated with the front end of thesoftware development lifecycle and test cases are typically associated withthe latter part of the lifecycle. By leveraging use cases to generate testcases, however, testing teams can get started much earlier in the lifecycle,allowing them to identify and repair defects that would be very costly tofix later, ship on time, and ensure that the system will work reliably.Using the methodology outlined above for generatingtest cases, developers can simplify the testing process, increase efficiency,and help ensure complete test coverage.

Case Study – Humber-ValleyHospital

Develop a test plan using this methodology for the following use case. Please submit the documentation in the format provided above with a suitable cover page providing your name and student ID. This is an individual effort exercise.

System: HumberValleyHospital Pharmacy Package

Use Case: Fill Order

Actor / System
  1. Pharmacist accesses the pharmacy system from the Hospital System Main Menu.
  1. The pharmacist enters a login and password
  1. The pharmacist selects “Fill Order”
  1. The pharmacist selects the first one in the queue (as a rule, they are filled on a first-in-first-out (FIFO) basis.
  1. The pharmacist dispenses the medication and calls the order complete on the system.
  1. The pharmacist attaches the label to the medication.
/ 1.1 The system prompts for a login and password.
2.1 The system validates login and password.
2.2 If valid, then the system displays the pharmacy system main menu. If not, see alternative flow 2.2.
3.1 The system displays the list of prescription orders in the queue waiting to be filled. If none exist, see alternative flow 3.1.
4.1 The system displays the prescription order details.
6.1 The system prints a label.
6.2 The system returns to the list of prescription orders.
Alternative Paths / 2.2 System displays message and returns to the prompt for a login and password.
3.1 System displays an empty queue message and returns to the pharmacy main menu.

Page 1 of 4