CSSE 6354 Advanced Software Engineering (Summer 2007)

Document Sample
CSSE 6354 Advanced Software Engineering (Summer 2007) Powered By Docstoc
					 CS/SE 6354 Advanced Software Engineering (Summer 2009)

             Ambulance Dispatch System
       Test Plan & Test Specification Document
                               Submitted to:
                           Dr. Lawrence Chung
                            Associate Professor
                      Department of Computer Science
                      The University of Texas at Dallas



                               Submitted by:
                            Team:    6-SIGMA
       Team Members:
               Lakshmi Manjula Ramanujam (rlmanjula@student.utdallas.edu)
               Pranav Parikh (prp061000@utdallas.edu)
               Saudamini Sathe (saudamini.sathe@student.utdallas.edu)
               Sindhura Vallabhaneni(sxv069100@utdallas.edu)
               Soumya Sriram Lakshmi(sxl062000@utdallas.edu)
               Tejaswi Billa Koti(tejaswi.billakoti@student.utdallas.edu)



       Team URL: http://www.utdallas.edu/~sxl062000/index.html




       Version: 1.0                                Date: 07/28/2009

TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                Page 1 of 42
                                      TABLE OF CONTENTS
1. Introduction……………………………………………………………………………….3
   1.1 Team Interaction .......................................................................................................... 4
   1.2 Test Objective .............................................................................................................. 4
   1.3 Process Overview......................................................................................................... 4
2. Relationship to other documents ........................................................................................ 6
   2.1 Connection with Requirements Analysis Document .............................................. 6
   2.2 Connection with System Design Document............................................................ 7
   2.3 Connection with Object Design Document ............................................................. 7
3. System overview ............................................................................................................ 7
   3.1 Features to be tested ................................................................................................ 8
   3.2 Features not to be tested .......................................................................................... 8
4. Pass/Fail criteria ............................................................................................................. 9
5. Approach ........................................................................................................................ 9
6. Testing Process ............................................................................................................. 10
   6.1 Unit Testing ........................................................................................................... 10
      6.1.1   White Box Testing ......................................................................................... 10
      6.1.2   Black Box Testing.......................................................................................... 11
   6.2 Integration Testing ................................................................................................ 11
      6.2.1   Incremental Testing ....................................................................................... 11
   6.3 System Testing ...................................................................................................... 14
      6.3.1   Performance testing ....................................................................................... 14
7. Suspension and resumption.......................................................................................... 15
8. Testing materials (hardware/software requirements)................................................... 15
9. Testing schedule............................................................................................................. 19
10. Test Cases ...................................................................................................................... 20
   10.1.    Login .................................................................................................................. 21
   10.2.    Extract Logs ....................................................................................................... 22
   10.3.    DisplayReports .................................................................................................. 23
   10.4.    LocateNearestAvailableHospital ....................................................................... 24
   10.5.    Call..................................................................................................................... 25
   10.6.    TraceCallerByPhoneAddress............................................................................. 26
   10.7.    OpenCase ........................................................................................................... 27
   10.8.    LocateCaseSite .................................................................................................. 30
   10.9.    ModifyCase ....................................................................................................... 31
   10.10. TrackCase .......................................................................................................... 32
   10.11. CloseCase .......................................................................................................... 33
   10.12. CreateUser ......................................................................................................... 34
   10.13. CreateAmbulance .............................................................................................. 36
   10.14. DispatchNearestAmbulance .............................................................................. 38
   10.15. TrackAmbulance ............................................................................................... 39
   10.16. DeleteAmbulance .............................................................................................. 40
11. References……………………………………………………………………………...41
 TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                                                                Page 2 of 42
1. Introduction

This document is a high-level overview defining our testing strategy for the Ambulance
Dispatch System. Its objective is to communicate project-wide quality standards and
procedures. It portrays a snapshot of the project as of the end of the planning phase. This
document will address the different standards that will apply to the unit, integration and
system testing of the specified application. We will utilize testing criteria under the white
box, black box, and system-testing paradigm. This paradigm will include, but is not
limited to, the testing criteria, methods, and test cases of the overall design. Throughout the
testing process we will be applying the Model driven testing strategy.
This is the Master Test Plan for the Ambulance Dispatch System.

   1. Report Incident
   2. Recommend Hospital
   3. Recommend Ambulance
   4. Inquire Status

The primary focus of this plan is to ensure that the new Ambulance Dispatch System
provides the desired level of information and details to meet patient’s needs while allowing
for improvements to dispatch ambulances within the time constraints.
The estimated time line for this project is very aggressive (eight (8) weeks), as such, and
delays in the development process or in the installation and verification of the application
could have significant effects on the test plan. The acceptance testing is expected to take 2
days from the date of application delivery from system test and is to be done in parallel
with the current application process.




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                              Page 3 of 42
     1.1   Team Interaction

           The following describes the level of team interaction necessary to have a
           successful product.

          The Test Team will work closely with the Development Team to achieve a
           high quality design and user interface specifications based on requirements.
           The Test Team is responsible for visualizing test cases and raising quality
           issues and concerns during meetings to address issues early enough in the
           development cycle.
          The Test Team will work closely with Development Team to determine
           whether or not all the functionalities in the application meet standards for
           completeness.
          Since the application interacts with a back-end system component, the Test
           Team will need to include a plan for integration testing. Integration testing
           must be executed successfully prior to system testing.


     1.2   Test Objective
           The objective our test plan is to find and report as many bugs as possible to
           improve the integrity of our program. Although exhaustive testing is not
           possible, we will exercise a broad range of tests to achieve our goal. The
           application will only be used as a demonstration tool, but we would like to
           ensure that it could be run from a variety of platforms with little impact on
           performance or usability.

     1.3 Process Overview
           The following represents the overall flow of the testing process:

                                       1. Identify the requirements to be tested. All test
                                          cases shall be derived using the Models.


TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                         Page 4 of 42
                              2. Identify which particular test(s) will be used to
                                 test                         each                     module.


                              3. Review the test data and test cases to ensure
                                 that the unit has been thoroughly verified and
                                 that the test data and test cases are adequate to
                                 verify      proper           operation       of     the     unit.


                              4. Identify the expected results for each test.


                              5. Document the test case configuration, test
                                 data,            and              expected                results.


                              6. Perform                the      test(s).


                              7. Document the test data, test cases, and test
                                 configuration used during the testing process.
                              8. Successful unit testing is required before the
                                 unit        is         eligible        for          component
                                 integration/system                                        testing.


                              9. Unsuccessful testing requires a Bug Report
                                 Form to be generated. This document shall
                                 describe         the     test       case,     the     problem
                                 encountered, its possible cause, and the
                                 sequence of events that led to the problem. It
                                 shall be used as a basis for later technical
                                 analysis.



TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                             Page 5 of 42
                                       10. Test    documents     and    reports      shall   be
                                           submitted. Any specifications to be reviewed,
                                           revised,   or   updated     shall    be     handled
                                           immediately.

  a. Organize Project involves creating a System Test Plan, Schedule & Test
     Approach, and assigning responsibilities.
  b. Design/Build System Test involves identifying Test Cycles, Test Cases, Entrance
     & Exit Criteria, Expected Results, etc. In general, test conditions/expected results
     will be identified by the Test Team in conjunction with the Development Team.
     The Test Team will then identify Test Cases and the Data required. The Test
     conditions are derived from the Program Specifications Document.
  c. Design/Build Test Procedures includes setting up procedures such as Error
     Management systems and Status reporting.
  d. Build Test Environment includes requesting/building hardware, software and data
     set-ups.
  e. Execute System Tests – The tests identified in the Design/Build Test Procedures
     will be executed. All results will be documented and Bug Report Forms filled out
     and given to the Development Team as necessary.
  f. Signoff - Signoff happens when all pre-defined exit criteria have been achieved.


2. Relationship to other documents

     2.1 Connection with Requirements Analysis Document

          We defined the accurate problem statement and agreed on the solution domain
          for the Ambulance Dispatch System in this phase. We produced use cases,
          realized them by sequence diagrams and Analysis level class diagrams.




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                             Page 6 of 42
     2.2 Connection with System Design Document

          In this phase of the project we decomposed the system into subcomponents
          and defined how the subcomponents will interact with each other.

   2.3 Connection with Object Design Document

      From the components that were in the design phase we came up with package
      diagram in this phase. Then we refined the class diagram from Requirement
      Analysis phase. In this phase we added visibility, signature, pre-post conditions,
      and associations between the classes to the class diagram. The final class diagram
      was mapped to code.


3. System overview

     The goal of the Ambulance Dispatch System is to provide fastest ambulance service
     to the victims of any emergency incidents. To achieve this, the system is
     decomposed to many subsystems. Calling 911 and asking for the ambulance
     service would connect the caller to a dispatcher (also called dispatch controller)
     who feeds the information s/he receives from the caller into the system. The system
     would allocate and mobilize a suitable ambulance within 3 minutes, transmit details
     to the selected vehicle, and track and monitor actual performance and position. An
     exception message shall be generated if no free ambulance is available for at least
     11 minutes. The system would show the location of each patient and the nearest
     three ambulances. The system shall utilize the notion of ubiquitous computing as
     much as possible to help with human health and life, which might necessitate going
     beyond the scope of the traditional ambulance dispatch system.
     The Ambulance Dispatch System is designed to locate the available ambulances
     near the incident location and dispatch them as per the requirement. All interfaces
     are closely interlinked and with validated inputs to the system interfaces an attempt
     is made to dispatch the ambulance within 3 minutes range.
TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                          Page 7 of 42
     3.1   Features to be tested

           The following are the major functionalities of the application that need to be
           tested in the testing process.

                  Login
                  Extract Logs
                  Display Reports
                  LocateNearestAvailableHospital
                  Call
                  TracerCallerByPhoneAddress
                  OpenCase
                  LocateCaseSite
                  ModifyCase
                  TrackCase
                  CloseCase
                  CreateUser
                  CreateAmbulance
                  DeleteAmbulance
                  DispatchNearestAmbulance



     3.2   Features not to be tested

           Certain features of the system could not be tested because of
           constraints(both time and hardware), a couple of them include:
                          Call Recording
                          GPS Related Funtionality
                          Hospital Related Functionality(Updating Hospital
                           Availability)




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                         Page 8 of 42
4. Pass/Fail criteria

    The final test process will be completed once the ADS application receives a phone
    call, efficiently records the details of an emergency incident including location, finds
    the next available ambulance and dispatches the ambulance within 3 minutes.
    When the operations staff is satisfied that the data is correct and appropriate services
    are provided to incident victims then the system will be considered live.
    At this point with the current development stage we will check if all the interfaces are
    functioning properly. Later as we progress with development and add more
    functionality to the application we will grow the scope of test plan as well.


5. Approach

    Testing Process



                                 b. Design
                                System Test



     a. Organize               c. Design/Build             e. Design/Build
       Project                                               Test Proc.
                                                                                         f. Signoff
                                  Test Proc.



                                d. Organize
                                   Project



Figure 1: Test Process Flow
The diagram above outlines the Test Process approach that will be followed.


6. Testing Levels:




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                              Page 9 of 42
   The testing for the Ambulance Dispatch System will consist of Unit,
   System/Integration (combined) and Acceptance test levels. We will have one full time
   person for system/integration testing.


6.1    Unit Testing

      Unit Testing is done at the source or code level for language-specific programming
      errors such as bad syntax, logic errors, or to test particular functions or code
      modules. The unit test cases shall be designed to test the validity of the programs
      correctness.
      UNIT testing will be done by the developers and will be approved by the entire
      team. Proof of unit testing (test case list, sample output, defect information) is
      provided to the team before unit testing will be accepted and passed on for the final
      submission.


      6.1.1 White Box Testing

             In white box testing, the UI is bypassed. Inputs and outputs are tested
             directly at the code level and the results are compared against specifications.
             This form of testing ignores the function of the program under test and will
             focus only on its code and the structure of that code. Test case designers
             shall generate cases that not only cause each condition to take on all possible
             values at least once, but that cause each such condition to be executed at
             least once. To ensure this happens, we will be applying Branch Testing.
             Because the functionality of the program is relatively simple, this method
             will be feasible to apply.Each function of the ADS is executed
             independently; therefore, a program flow for each function has been derived
             from the code.




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                             Page 10 of 42
      6.1.2 Black Box Testing

            Black box testing typically involves running through every possible input to
            verify that it results in the right outputs using the software as an end-user
            would. We have decided to perform Equivalence Partitioning and Boundary
            Value Analysis testing on our application.


6.2    Integration Testing
      6.2.1 Incremental Testing

            There are two primary modules that will need to be integrated: the Graphic
            User Interface module and the back-end. The two components, once
            integrated, will form the complete Ambulance Dispatch System. The
            following describes these modules as well as the steps that will need to be
            taken to achieve complete integration. We will be employing an
            incremental testing strategy to complete the integration.

      1. Module 1-User Interface Subsystem
         o Provide user friendly interfaces to the call taker, dispatcher and supervisor
         o Provide interface to create, delete, modify and retrieve pertinent information
            to all users.
         o Provide for a login to each user to access the system depending on the role
            of the user.
         o Provide interface to run summary reports on the system persistent data in
            order to analyze the data and create historic information that can be used to
            make decisions by the system.


      2. Module 2-Access Control Subsystem
         o Provide for a role based security to the system. The roles in the system are
            Call taker, dispatcher and supervisor.

TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                           Page 11 of 42
        o Provide for a reliable verification of the user identity and giving access to
           the appropriate data depending on the role.
        o Uses and modifies the Persistent Data Subsystem to validate the user login
           information and identify the user role.
        o Modifies the Persistent Data Subsystem to store user login information and
           user details. Passwords are stored in encrypted format.


     3. Module 3-User Management Subsystem
           o Provides the administrator of the system with the ability to add new
               users and to assign roles to each user.
           o Allows for modification of the user data and saves the modification in
               the persistent storage.
           o Allows each individual user to update his/her details and sends a
               notification to the administrator for approval, before the changes are
               persisted.


     4. Module 4-Incident Report Management Subsystem
        o Manages the creation, modification, retrieval and archival of the incidence
           object.
        o This subsystem creates a new incidence object and manages the flow of the
           incident through the caller taker to the dispatcher and finally stores the
           closed incident in the persistent subsystem.
        o Modification of the incidence object is handled at every stage of the incident
           flow by this subsystem and its status is updated according to one of these
           four statues: 1. Open 2. Active 3. Inactive 4. Closed 5. Archived.
        o Responsible to maintain consistency of the incidence object, creating an
           alert for any anomaly in the object (such as no call recording associated with
           the object, status of object not changed to closed within 10 minutes from its
           creation, etc.)

TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                        Page 12 of 42
     5. Module 5-Dispatcher Subsystem
        o Responsible for deciding on the emergency level for the incidence object. It
            takes into account any historic data available to make this decision and then
            recommend an emergency level to the dispatcher.
        o Responsible for getting the traffic information from the GPS system and
            calculating the optimal route to reach the patient.
        o Handles the allocation of free driver to a free ambulance and forming an
            ambulance unit depending on the emergency level.
        o Responsible for recommending a scheme (an ambulance unit(s), shortest
            routes to take by each ambulance) to the dispatcher.
        o Responsible for sending notification to the driver and providing them with
            the chosen route.
        o Handles tracking of the deployed ambulance units with the help of the GPS
            system and handling any exceptions such as ambulance breakdown, traffic
            jam etc.
        o Responsible for interacting with the hospital system and recommending an
            available hospital along with its route to the dispatcher.
        o Also handles passing hospital information to the driver and tracking the
            busy ambulance with the help of the GPS system, and also handle any
            exception on the route of the ambulance to the hospital.
        o Responsible for updating the status of the ambulances, drivers and the
            incidence objects appropriately.


     6. Module 6-Persistent Data Subsystem
        o Responsible for storing the incidence object and persisting changes to it, if
            any.
        o Responsible for storing user information and persisting changes to it, if any.

     When the GUI is combined with the backend module, we will have complete
     Ambulance Dispatch System. To achieve complete integration of these two
TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                        Page 13 of 42
      modules, we will test each element in the GUI by replacing the stubs with the
      appropriate function from the back end. The results will be displayed within the
      GUI instead of through the Console. In testing the combined modules, we will
      follow the incremental testing method. Each stub will be replaced one at a time and
      tested. This will be done until all stubs have been replaced by the appropriate
      functions from the backend.



6.3    System Testing

       The goals of system testing are to detect faults that can only be exposed by testing
       the entire integrated system or some major part of it. Generally, system testing is
       mainly concerned with areas such as performance, security, validation, load/stress,
       and configuration sensitivity. But in our case well focus only on function
       validation and performance. And in both cases we will use the black-box method
       of testing. System/Integration testing will be performed by entire team. No
       specific test tools are available for this project. All testing is manually performed.
       Programs will enter into system/integration test after all critical defects have been
       corrected. A program may have up to two major defects as long as they do not
       impede testing of the other programs.


      6.3.1 Performance testing

             This test will be conducted to evaluate the fulfillment of a system with
             specified performance requirements. It will be done using black-box testing
             method. And this will be performed by:

                Storing the maximum data in the file and trying to insert, and observe
                 how the application will perform when it is out of boundary.
                Deleting data and check if it follows the right sorting algorithm to sort
                 the resulting data or output.
TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                            Page 14 of 42
                  Trying to store new data and check if it over writes the existing once.
                  Trying to load the data while they are already loaded



            Acceptance testing will be performed by the actual system users. Programs
            will enter into acceptance test after all critical and major defects have been
            corrected. The customer test representative will approve acceptance testing.
            A limited number of distributors will participate in the initial acceptance test
            process. Once acceptance test is complete, distributors will be added as
            their ability to generate the required data is verified.


7. Suspension and resumption

     With following interfaces implementation we decided to suspend testing activity for
     20% or more defects in Unit testing. In such situation we decide to redevelop the
     interfaces with agreed functionality. When we are back to 10% or lesser defects in
     Unit testing we resume testing process.


8. Testing materials (hardware/software requirements)

    The testing effort will require two single processor desktop PC. To properly test our
    non-functional performance requirement, it must have a minimum 1 GHz CPU and
    256 MB RAM. The machine will be using the Java Runtime Environment version
    1.6 and JBoss 4.2.3.Automation testing is done using Mercury loader for
    performance testing.
    We will document all the test results using following template while delivering the
    application.




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                            Page 15 of 42
Tested By:
Test Type
Test Case Number
Test Case Name
Test Case Description




Item(s) to be tested

1

2

Specifications
                                Expected
Input                           Output/Result




Procedural Steps

1

2

3

4

5

6

TEAM: 6-SIGMA (CS6354 SUMMER 2009)              Page 16 of 42
Following template will be used as a Test Incident Report document and all the system
defects will be tracked in this document.
Model driven approach with UML

Test Type                         Coverage Criteria               UML Diagrams


Unit Testing                      code                            Class and state diagrams


Function Testing                  Functional                      Interaction and class diagrams


System Testing                    Operational Scenarios           Use-case, activity and
                                                                  interaction diagram

Regression Testing                Functional                      Interaction and Class
                                                                  diagrams.

Solution                          Inter-system Communication      Use case and deployment
                                                                  diagrams




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                           Page 17 of 42
  ADS Software Development                                                  Problem Report #:


  Program                                             Release                             Version

  Report Type (1-6) _____              Severity (1-3) _____                Attachments (Y/N)
  1 - Coding error                     1 - Fatal                          If yes, describe:
  2 - Design issue                     2 - Serious
  3 - Suggestion                       3 - Minor
  4 - Documentation
  5 - Hardware
  6 - Query


  Problem Summary

  Can you reproduce the problem? (Y/N)

  Problem & how can it be reproduced?




  Suggested fix (optional input)




          Reported By:                                                         Date:

                       Items below are for use only by the development team

  Functional Area: ______________________                            Assigned To: ______________________

  Comments:




  Status_____                  Priority (1-5) _____
  1 - open     2 - closed

  Resolution (1-9) _____                                                    Resolution Version
  1 - Pending               4 - Deferred             7 - Withdrawn by reporter
  2 - Fixed                 5 - As designed          8 - Need more info
  3 - Irreproducible        6 - Can't be fixed       9 - Disagree with suggestion

           Resolved By:                                                        Date:

              Tested By:                                                       Date:

  Treat as Deferred (Y/N)_____



TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                                                  Page 18 of 42
9. Testing Schedule

For achieving best QA results we decided to have one (1) full time tester assigned to the
project for the system/integration and acceptance testing phases of the project. In order
to provide complete and proper testing we addressed following areas in terms of training.

  1. Team studied following reference material for understanding of the business logic
     of Ambulance Dispatch System from course website.

     Ambulance Dispatch System – Some Articles

        Dalcher--Disaster_in_London.The_LAS_case_study.pdf
        Finkelstein--A_Comedy_of_Errors--
         the_London_Ambulance_Service_case_study.pdf
        Kramer--Succeedings_of_the_8th_International.pdf
        South_West_Thames--
         Report_of_the_Inquiry_Into_The_London_Ambulance_Service.pdf




  2. The developers and testers got trained on the basic operations of the Dispatcher and
     Ambulance interfaces. Prior to final acceptance of the project the operations staff
     will also go through complete training on the ADS system’s communication
     process.
  3. After successful deployment of the system to the users the sales and administration
     staff will require training on the new screens and reports.
  4. We decided to have at least one developer and operations staff member to be
     trained on the installation and control of the PC based distributors ADS package.
     The distributors personnel will also have to be trained on the PC based package and
     its operational characteristics.



TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                          Page 19 of 42
10.   Test Cases

      In this section we list the test cases that are used during testing.


  10.1.      Login

             Purpose:
             The purpose of this test case is to test the functionality of “Login” with
             respect to the requirements.
             Test Case Specification Identifier: TC_Login

             Test Items:

                     Components under Test:
                     HTML/JSP Logon Screen
                     ADS_Controller class/object
                     User - Dispatcher/Manager/Administrator class/object
                     Database class/object


             Features Being Exercised:
                     Valid User Login - correctly logged in with correct username and
                     password
                     Valid User Name, Invalid Password - unable to log in with correct
                     username and invalid password
                     Valid User Password, Invalid User Name - unable to login with
                     invalid username and correct password
                     Invalid User Name, Invalid Password - unable to login with invalid
                     username and invalid password

             Input Specifications:
             Dispatcher/Administrator/Call-taker username.
           Dispatcher/Administrator/Call-taker password.
TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                           Page 20 of 42
          Output Specifications:
          Upon valid login, user will be directed to the main system HTML/JSP screen
          Upon invalid login (invalid username/invalid password or both), messages
          boxes with appropriate messages denoting the reason(s) for invalid error are
          displayed.

          Environmental Needs:
          System is connected to the database. Database has a stored table of usernames
          and their corresponding passwords.

          Special Procedure Requirements:
          ADS System must be running

          Inter-case Dependencies:
          None



  10.2.     Extract Logs

            Purpose:
            The purpose of this test case is to test the functionality of the Log system
            with respect to the System requirements. Log logs all the opened and closed
            cases.
            Test Case Specification Identifier: TC_Log

            Test Items:

                       Components under Test:
                       ADS_Controller class/object
                       Log class/object
                       Database class/object
                       Report class/object


TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                          Page 21 of 42
          Features Being Exercised:
                  Open Log File
                  Write to log file
                  Close log file
                  Retrieve all entries
                  Find an entry
                  Backup log file to database

          Input Specifications:
          Full Path and Filename of the ADS system log
          Log entry date, time and description of entry
          Search criteria, date, time, date and time, partial or full description

          Output Specifications:
          When log file is opened the log file is opened for editing
          Entry written to log will be in the log file
          When log file is closed, the file is closed and saved
          A report of all entries from the log file will be displayed to the user
          A report with the single entry searched for will be displayed to the user
          Entire log file saved to the database

          Environmental Needs:
          System is connected to the database. Checkpoints are established so that
          backup recovery is always possible in case of recovery.

          Special Procedure Requirements:
           None

          Intercase Dependencies:
           None




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                          Page 22 of 42
  10.3.   DisplayReports

          Purpose:
          The purpose of this test case is to test the functionality of
          the DisplayReports with respect to System requirements.


          Test Case Specification Identifier: TC_Reports



          Test Items:

                  Components under Test:
                  ADS_Controller class/object
                  Report class/object
                  Database class/object
                  Log class/object

          Features Being Exercised:
          Report Generation
          Gathering data from the database

          Input Specifications:
          Full Path and Filename of the ADS system log
          Log entry date, time and description of entry
          Search criteria, date, time, date and time, partial or full description
          Search criteria for database data to be used on reports

          Output Specifications:
          A report displaying the associated information in a form usable by the
          customer




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                          Page 23 of 42
          Environmental Needs:
                     The System and database will be used to test the functionality.
                     System needs to be connected to the database.

          Special Procedure Requirements:
          None

          Intercase Dependencies:
          None



  10.4.   LocateNearestAvailableHospital

          Purpose:
          The purpose of this test case is to test the functionality of Locating the
          nearest hospital to the accident location.

          Test Case Specification Identifier:
          TC_LocateNearestAvailableHospital

          Test Items:

                 Components under Test:
                 ADS_Controller class/object
                 Database class/object
                 Hospital Sub-system

          Features Being Exercised:
          Locate Nearest Hospital

          Input Specifications:
          Accident location




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                         Page 24 of 42
          Output Specifications:
          The Hospital Identification Number of the nearest hospital to the accident
          location

          Environmental Needs:
          Hospital list is periodically uploaded in the database. ADS system is
          connected to database.

          Special Procedure Requirements:
          None

          Intercase Dependencies:
          This test case is dependent upon:
          Phone call must be placed: TC_Call
          The accident information must be gathered.
          A Case must have already been opened: TC_OpenCase
          User must be logged in: TC_Login



  10.5.   Call

          Purpose:
          The purpose of this test case is to test the functionality of the “Call” with
          respect to the requirements.


          Test Case Specification Identifier: TC_Call

          Test Items:

             Components under Test:
             HTML/JSP Emergency Screen
             ADS_Controller class/object
             User - Dispatcher
TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                         Page 25 of 42
              Database class/object


          Features Being Exercised:
          Accept phone call
          Log call details
          Captures required details in the system

          Input Specifications:
          Caller calls 911 asking for medical help

          Output Specifications:
          Call taker captures important information and tells the caller help is on the
          way.

          Environmental Needs:
          System is connected to the database and the telephone network works
          properly.

          Special Procedure Requirements:
          Tests related to the phone system cannot actually be done due to limited
          resources (We are only dealing with a dummy)
          Intercase Dependencies:
          None



  10.6.   TraceCallerByPhoneAddress

          Purpose:
          The purpose of this test case is to test the functionality of the
          TraceCallerByPhoneAddress .
          Test Case Specification Identifier: TC_TraceCallerByAddress


TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                            Page 26 of 42
          Test Items:

                   Components under Test:
                   HTML/JSP Emergency Screen
                   ADS_Controller class/object
                   User - Dispatcher
                   Database class/object

          Features Being Exercised:
                   Accept Landline phone call
                   Identification of phone address through caller id.
                   Verification (that phone location is same as Incident Location), store
                   required details in the system

          Input Specifications:
          Caller calls 911 asking for medical help from Landline phone or phone
          enabled tracker System.
          Incident address is traceable

          Output Specifications:
          Dispatcher captures important information and tells the caller help is on the
          way.

          Environmental Needs:

          Phone network works properly. System connected to Phone network. Caller
          ID available. User enables detection of address from the landline
          phone.

          Special Procedure Requirements:
          Tests related to the phone system cannot actually be done due to limited
          resources (no actual systems to test with)


TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                        Page 27 of 42
          Intercase Dependencies:
              Inherits from PlacePhoneCall use case (TC_PlacePhoneCall)
              Phone call
              Identifies approximate incident area
              Log call details
              Captures required details in the system

              Input Specifications:
              Caller calls 911 asking for medical help
              Incident area is traceable (approximately)

              Output Specifications:
              Dispatcher captures important information and tells the caller help is on
              the way.


  10.7.   OpenCase

          Purpose:
          The purpose of this test case is to test the functionality of the OpenCase.
          This comes into picture when a caller places a call to 911 and call taker
          picks the call.


          Test case specification identifier: TC_OpenCase

          Test items:
                  Components under Test
                  ADS_Controller
                  Case_List
                  Case
                  Database



TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                        Page 28 of 42
          Input specifications:
          Caller calls 911,call taker picks call.
          Call taker Clicks on "New Emergency"
          Enters all required data for the new case emergency.
          Click the "Activate Emergency" button.

          Output specifications:
          Upon successful completion of opening a new case emergency, the new case
          will be displayed on the "Active Cases" page. The new case will be
          displayed with its assigned case identification number, along with the
          following data:
          Started: Time the new case was created
          Location: The location entered when the case was added to the ADS system
          Type: Type of emergency this case corresponds to
          Status: "Open"

          Environmental needs:
          System Connected to database. Telephone network works good, call taker or
          caller completes the call or the call gets disconnected in between in this case
          the Case is Active but incomplete.(human discretion involved in such a
          case)

          Special procedural requirements:
          There are no special procedural requirements for this test case.

          Intercase dependencies:
          Test case TC_Login must be successfully completed before this test case
          can be executed.




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                        Page 29 of 42
  10.8.   LocateCaseSite

          Purpose:
          The purpose of this test case is to test the functionality of
          the LocateCaseSite.

          Test case specification identifier: TC_LocateCaseSite

          Test items:
                  Components under test:
                       ADS_Controller
                          Map_JSP
                          Case_List
                          Case

          Input specifications:
          Login into the ADS system.
          Click on “Active Emergencies”.
          Click on the “ID” of the “Active case” that need to looked into.

          Output specifications:
          Upon successful completion of opening an active case emergency, the
          “Emergency Details” page will display the case information including the
          case emergency’s address location.

          Environmental needs:
          Gathered information should be stored in persistent storage. System
          connected to    Database.

          Special procedural requirements:
          Before executing this test case there must be at least one active case
          emergency that has previously been opened.



TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                        Page 30 of 42
          Intercase dependencies:

          The following test cases must be successfully completed before this test case
          can be executed:
          TC_Login
          TC_OpenCase



  10.9.   ModifyCase

          Purpose:
          The purpose of this test case is to test the functionality of the Modify Case
          with respect to the requirements. This is incase the caller/call
          taker/dispatcher feel that ( /adds or deletes info) from the existing case.

          Test case specification identifier: TC_ModifyCase

          Test items:

                 Components under test:
                 ADS_Controller
                 Case_List
                 Case
                 Database

          Input specifications:
          Login into the ADS system.
          Click on “Active Emergencies”.
          Click on the “ID” of the “Active case” that is to be modified.
          On the “Emergency Details” page modify the fields:
          Click on the “Save Changes” button at the bottom of the “Emergency
          Details” page.



TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                           Page 31 of 42
           Output specifications:

           Upon successful completion of modifying an active case emergency, the
           user will receive a message informing them that their modified data was
           successfully saved to the database.

           Environmental details:
           System connected to database. Changes must reflect in the Database.

           Special procedural requirements:

           Before executing this test case there must be at least one active case that has
           previously been opened.

           Intercase dependencies:

           The following test cases must be successfully completed before this test case
           can be executed:
           TC_Login
           TC_OpenCase



  10.10.   TrackCase

           Purpose:
           The purpose of this test case is to test the functionality of the TrackCase
           with respect to the requirements.

           Test case specification identifier: TC_TrackCase

           Test items:

                  Components under test:
                  Emergency_List
                  Emergency
                  Case_List

TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                         Page 32 of 42
                  Case

           Input specifications:
           Login into the ADS system.
           Click on “Active Emergencies”.

           Output specifications:

           Upon viewing the “Active Emergencies” page the system will display the
           status and ambulances assigned to each active case.

           Environmental details:
           System connected to Database.

           Special procedural requirements:
           Before executing this test case there must be at least one active case that has
           previously been opened.

           Intercase dependencies:
           The following test cases must be successfully completed before this test case
           can be executed:
           TC_Login
           TC_OpenCase



  10.11.   CloseCase

           Purpose:
           The purpose of this test case is to test the functionality of the CloseCase.
           Test case specification identifier: TC_CloseCase

           Test items:
                  Components under test:
                  ADS_Controller

TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                          Page 33 of 42
                    Case_List
                    Case
                    Database

          Input specifications:
          Login into the ADS system.
          Click on "Active Emergencies".
          Click on the "ID" of the active case that you wish to close.
          At the bottom of the "Emergency Details" page click the "Closed Case"
          button.

          Output specifications:
          Upon successful completion of closing an active case, the closed case shall
          no longer appear on the "Active Emergencies" page.

          Environmental details:
          The system and the database will be used to conduct this test.

          Special procedural requirements:
          Before executing this test case there must be at least one active case that has
          previously been opened.

          Intercase dependencies:
          The following test cases must be successfully completed before this test case
          can be executed:
          TC_Login
          TC_OpenCase




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                         Page 34 of 42
  10.12.   CreateUser

           Purpose
           The purpose of this test case is to test the use case CreateUser. It is used to
           verify that the administrator of the ADS system can create a new user in the
           system.

           Test case specification identifier: TC_CreateUser

           Test items:
           User Interface: functionality to enable administrators to enter new User
           information
           User Package: the ability to insert a new User into the system
           Main Controller Package: the ability to connect between the user interface
           and the user package

           Input specifications:
           The admin key in all the mandatory and optional user information on the
           screen.
           The admin clicks the “Add User” button.
           The admin confirms the data.

           Output specifications:
           The admin should be able to edit all the fields without any problem.
           The system should ask for confirmation before committing the data in the
           database.
           The system should update the user data in the database.
           The system should redirect the user to the create user screen.

           Environmental needs:
           None




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                          Page 35 of 42
           Special procedural requirements:
           None

           Intercase dependencies:
           N/A



  10.13.   CreateAmbulance

           Purpose

           The purpose of this test case is to test the functionality CreateAmbulance. It
           is used to verify that the ADS system can create an ambulance in the system.
           This is usually the case where an ambulance previously deleted from the
           system as malfunctioning will be brought back in after the necessary repair
           has be done on it or a new ambulance has been introduced into the system.

           Test case specification identifier: TC_CreateAmbulance

           Test items:

                  Components under test:

                  User Interface: functionality to enable users to enter new ambulance
                  information or re-enter a repaired ambulance which has been
                  previously reported as malfunctioned.
                  Ambulance Package: the ability to insert a new ambulance into the
                  system
                  Main Controller Package: the ability to connect between the user
                  interface and the ambulance package

           Input specifications:
           User clicks a button to open a Create-Ambulance screen
           User enters ambulance information: number, name, etc.


TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                        Page 36 of 42
          User enters online ID that will be used for electronic communication such as
          transfer of case information

          Output specifications:
          System displays a message that the ambulance has been created
          System provides a way to retrieve saved ambulance information at a later
          time
          Should the number provided when creating a new ambulance already exist
          in the system, a message is displayed (this way the user can differentiate that
          the ambulance is a new one or an old one which is being reintroduced as
          repaired).
          Radio system communicates with the new create ambulance
          Electronic messages are sent successfully to the ambulance
          Location-tracking system identifies the ambulance on the map

          Environmental needs:
          The ADS system software will be used to test the software part
          The radio communication system will be used to test the voice
          communication part
          The electronic communication system will be used to test the data transfer
          part
          The location-tracking system will be used to test the ambulance location-
          tracking part

          Special procedural requirements:
          All external system devices will need to be installed on the new ambulance
          when creating it in the system
          Tests related to the radio, electronic communication, and location-tracking
          systems can not actually be done due to limited resources (no actual systems
          to test with)



TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                        Page 37 of 42
           Intercase dependencies:
           N/A



  10.14.   DispatchNearestAmbulance

           Purpose
           The purpose of this test case is to test the functionality
           DipatchNearestAmbulance. It is used to verify that the system shall dispatch
           the nearest available ambulance to an emergency site.
           Test case specification identifier: TC_DispatchNearestAmbulance

           Test items:

                  Components under Test:
                  User Interface: functionality to enable displaying available
                  ambulances close to emergency sites and allowing the dispatcher
                  dispatch one or more of them
                  Ambulance Package: the ability to dispatch an ambulance to
                  emergency site

           Input specifications:
           User selects an emergency for which ambulances will be dispatched
           User clicks a button to display available ambulances close to emergency
           site
           User notifies ambulance
           User clicks a button to dispatch the ambulance
           Ambulance receives emergency information

           Output specifications:
           System displays a message that the ambulance has been dispatched
           System changes the status of the emergency

TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                       Page 38 of 42
           System changes the status of the ambulance

           Environmental needs:
           The ADS system software will be used to test the software part
           The radio communication system will be used to test the voice
           communication part
           The electronic communication system will be used to test the data transfer
           part

           Special procedural requirements:
           Tests related to the radio, and electronic communication systems can not
           actually be done due to limited resources (no actual systems to test with)

           Intercase dependencies:
           N/A



  10.15.   TrackAmbulance

           Purpose
           The purpose of this test case is to test the use case TrackAmbulance. It is
           used to verify that the ADS system tracks ambulances correctly.
           Test case specification identifier: TC_TrackAmbulance

           Test items:
                  Components under Test:
                       User Interface: functionality to enable users to display any
                          ambulance’s location
                          Ambulance Package: the ability to communicate with the
                          location-tracking system
                          Main Controller Package: the ability to connect between the
                          user interface and the ambulance package


TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                         Page 39 of 42
           Input specifications:
           User enters the ambulance number or address

           Output specifications:
           System displays a list of ambulances near a certain address or the location of
           an exact ambulance
           System displays real-time ambulance locations on a large monitor

           Environmental needs:
           The system software will be used to test the software part
           The location-tracking system will be used to test the location tracking part

           Special procedural requirements:
           Tests related to the location-tracking systems can not actually be done due
           to limited resources (no actual systems to test with)

           Intercase dependencies:
           N/A


  10.16.   DeleteAmbulance

           Purpose
           The purpose of this test case is to test the use case DeleteAmbulance. It is
           used to verify that the ADS system can delete an existing ambulance (an
           ambulance which has been reported as OUT OF SERVICE in the system).
           Test case specification identifier: TC_DeleteAmbulance

           Test items:
                  Components Under Test:
                  User Interface: functionality to enable users to delete existing
                  ambulance information
                  Ambulance Package: the ability to delete an ambulance from the
                  system

TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                         Page 40 of 42
                  Main Controller Package: the ability to connect between the user
                  interface and the ambulance package

          Input specifications:
          User clicks a button to display an existing ambulance screen
          User clicks a button to delete the ambulance
          System asks for user confirmation

          Output specifications:
          System displays a message that the ambulance has been deleted
          System keeps the actual ambulance information and only logically deletes
          the ambulance
          System logs the action
          System provides a way to retrieve ambulance information at a later time

          Environmental needs:
          The system software will be used to test the software part

          Special procedural requirements:
          Tests related to the radio, electronic communication, and location-tracking
          systems can not actually be done due to limited resources (no actual systems
          to test with)

          Intercase dependencies:
          N/A




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                       Page 41 of 42
11.   References
        o Problem Statement: http://utdallas.edu/~chung/CS6354/Project.doc

        o Object Design Template: http://wwwbruegge.informatik.tu-
          muenchen.de/twiki/bin/view/OOSE/ObjectDesignDocumentTemplate

        o Object-Oriented Software Engineering - Using UML, Patterns, and Java 2nd
          Edition

        o Composite Pattern - http://en.wikipedia.org/wiki/Composite_pattern

        o Applying UML and Patterns: An Introduction to Object-Oriented Analysis
          and
        o Design and the Unified Process, 2nd ed., C. Larmann

        o Core J2EE Patterns – Data Access Objects-
          http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.h
          tml

        o Fantastic 9 Document

        o Google.com

        o Ambulance Dispatch System – Some Articles

        o Dalcher--Disaster_in_London.The_LAS_case_study.pdf

        o Finkelstein--A_Comedy_of_Errors--
          the_London_Ambulance_Service_case_study.pdf

        o Kramer--Succeedings_of_the_8th_International.pdf

        o South_West_Thames--
          Report_of_the_Inquiry_Into_The_London_Ambulance_Service.pdf




TEAM: 6-SIGMA (CS6354 SUMMER 2009)                                     Page 42 of 42