ADS+ - An Ambulance Dispatch System
Test Plan
CS 6354 – Advanced Software Engineering, Section 581
Summer 2007
The Fantastic 9
Arturo Saracho / / 11120701Denis Stetsenko / / 10829000
Sarthak Dudhara / / 11138921
Abdullah Azzouni / / 11152135
Russell Smith / / 11126187
Anitha John / / 10480080
Abhishek Goyal / / 11139363
Nate Gardner / / 10080880
Sheetal Umeshkumar / / 11108292
Table of Contents
2. Audience 3
3. Introduction 3
4. Relationship to other documents: 3
5. System overview: 4
6. Features to be tested/not to be tested: 4
7. Pass/Fail criteria: 4
8. Approach: 4
9. Suspension and resumption: 5
10. Testing materials (hardware/software requirements): 5
10.1. Hardware 5
10.2. Software 5
10.3. Automation Tools 6
11. Test Cases 6
11.1. Logon 6
11.2. Extract Logs 8
11.3. DisplayReports 10
11.4. LocateNearestAvailableHospital 11
11.5. PlacePhoneCall 13
11.6. TraceByAddress 14
11.7. TraceByArea 16
11.8. GatherInformation 18
11.9. OpenCase 19
11.10. LocateCaseSite 21
11.11. ModifyCase 22
11.12. TrackCase 24
11.13. PickupCase 25
11.14. DeliverCase 27
11.15. CloseCase 29
11.16. CreateUser 30
11.17. ModifyUser 31
11.18. DeleteUser 33
11.19. CreateAmbulance 34
11.20. DispatchNearestAmbulance 36
11.21. ModifyAmbulance 38
11.22. TrackAmbulance 40
11.23. DeleteAmbulance 41
12. Testing Schedule 43
12.1. Staffing and training needs 43
12.2. Schedule 43
12.3. Testing Risk and Contingency Plan 43
1. Purpose
This test plan document describes the objectives, scope, approach and focus of the testing of the ADS system. This document begins with an overview of the Ambulance Dispatcher System. It then lists the high level features to be tested as part of the testing cycle. The document also lists the application features that will not be tested. It further delves into the details of the hardware, software and environmental needs for carrying out an efficient and smooth testing. It then discusses the high level testing schedule and the resource responsible for testing each of the features. It then briefly describes the pass/fail criteria and risks associated with the testing. The document ends with a detailed description of the test case that will be executed as part of the testing.
2. Audience
This test plan document has been written for the following audience
1. Project Manager
2. Test Manager
3. Business Analyst
4. Development Team
5. Test Team
6. Onsite coordinators
3. Introduction
The software will be tested and determined to be ready for delivery and of accepted quality based on the results of the functional testing. In brief the tests have to satisfy all of the customer’s and internal requirements by successfully passing all test cases.
The functional testing verifies conformance to the customer requirements and it verifies as well that not unexpected behavior outside the requirements is present.
4. Relationship to other documents:
Therequirements specificationpresents the requirements from the customer, as well as internal requirements. The requirements arenumberedto provide for an easy way to trace the test cases to each requirement. Each of the requirements corresponds to one or more use cases in the analysis documentation (RAD). As well, the object design document and the design document provide more information about how the implementation of the functionality is done which serves to better understand how to perform the white box testing.
5. System overview:
The system iscomposed of several independent components that execute some of the functionality and togetherform a 911 emergency dispatch system.
The sequence of events is as follows:
· A person will call 911 and the operator/dispatcher that answers the call gets the details about location from the person.
· Dispatcher also needs to ask how many people are injured, in case many ambulances are needed.
· The dispatcher enters the location information on the system.
· A Timer is started counting down from 11 minutes.
· The system locates the nearest three ambulances and their availability, if no ambulance is available it will locate the next three nearest from the initial three and check availability, this will be repeated until one that is available is found.
· When an available ambulance is found, location details will be sent to the unit and will be instructed to go to location for pickup.
· The system will monitor ambulance's and person's locations for tracking purposes.
· When the ambulance reaches the destination the system will wait for confirmation from the ambulance that the objective has been reached.
· If Timer reaches zero and no ambulance was found available, an exception message will be generated and given to the dispatcher.
6. Features to be tested/not to be tested:
Testing will be done to the system in order to satisfy all requirements, this means, all functionality as specified in the class diagrams and sequence diagrams has to be verified. Verification of this will assure that the design is working as expected by the developers, and will verify as well that the requirements have been satisfied.
7. Pass/Fail criteria:
A test case will be determined to have been successfully executed and passed if and only if all conditions stated are satisfied. All inputs have to be exercised, environment has to be setup, and outputs must be read and verified as having the expected values. Else, the test case is declared failed.
8. Approach:
The functional testing will be doneby unit testing the independent modules making sure the test case is passed and all corresponding requirements are satisfied. After completion of the unit tests and making sure all successfully pass, integration will be done and validation of the integrated code will take place; this will be done by considering the whole software as one unit with several inputs and outputs.
9. Suspension and resumption:
Unit testing can be suspended if necessary by making sure all corresponding test cases that have been initiated are finished and a pass/fail result is given. All remaining not initiated test cases will then be executed when testing is resumed. Testing can be suspended in the event of the need to make a modification to a software module which does not affect the structure of the use case. In the event that we need to make a change that requires changes in the inputs and outputs of test cases (involving then also changes to design), the approach will be to set a version of the software and continue the testing per the design and software up to this version. The necessary changes to the code, design and test cases will then be done in a new version which will have to be fully tested again.
10. Testing materials (hardware/software requirements):
The test environment will be formed of:
10.1. Hardware
Name / Qty Required / Qty AvailableMachines with Windows 2003, 256 MB RAM / 9 / 9
Test Server to Deploy the Application for Testing
Machines with Windows 2003, 2 GB RAM / 1 / 1
Database Server
Machines with Windows 2003, 1 GB RAM / 1 / 1
10.2. Software
Name / Copies Required / Copies AvailableBrowser – IE 6.0 / 9 / 9
BEA Web logic 8.1 SP6 License / 1 / 1
Oracle 9i / 1 / 1
10.3. Automation Tools
Name / Copies Required / Copies AvailableMercury Test Director (Defect Tracking) / 5 Licenses (2 for testing team and 3 for development team) / 5
Win runner 7.6 / 2 Licenses / 2
11. Test Cases
In this section we list the test cases that are used during testing.
11.1. Logon
Purpose:
The purpose of this test case is to testthe functionality of the Loginsystem for adherence tothe requirements.
Audience:
The audience for this test case is the customer and project team.
Test Case Specification Identifier:
TC_Logon
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 - unable to log in with correct username and invalid password
Valid User Password - unable to login with invalid username and correct password
Invalid User Login - unable to login with invalid username and invalid password
Invalid Username length - unable to login, gives message to user about invalid username length
Invalid Password length - unable to login, gives message to user about invalid password length
Input Specifications:
Dispatcher/Manager/AdministratorIdentification Numberof length5 numeric
Password of length 8 alpha-numeric characters
Output Specifications:
Upon valid login, user will be sent the Main system HTML/JSP screen
Upon invalid login, messages boxes with appropriate messages denoting the reason(s) for invalid login
Environmental Needs:
MySQL Database connection to a MySQL database with a table set up for users with users already entered
ADS System running with network connections to the MYSQL database
Special Procedure Requirements:
ADS System must be running
Inter-case Dependencies:
None
11.2. Extract Logs
Purpose:
The purpose of this test case is to testthe functionality of theLogsystem for adherence tothe requirements.
Audience:
The audience for this test case is the customer and project team.
Test Case Specification Identifier:
TC_Log
Test Items:
Components under Test:
ADS_Controller class/object
Log class/object
Database class/object
Report class/object
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:
MySQL Database connection to a MySQL database with a table set up to handle the backup and recovery of log files
ADS System running with network connections to the MYSQL database
Special Procedure Requirements:
None
Intercase Dependencies:
None
11.3. DisplayReports
Purpose:
The purpose of this test case is to testthe functionality of theReport system for adherence tothe requirements.
Audience:
The audience for this test case is the customer and project team.
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
Gathering data from the log file(s)
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 ina form usable by the customer
Environmental Needs:
MySQL Database connection to a MySQL database with a table set up to handle the backup and recovery of log files
ADS System running with network connections to the MYSQL database
Special Procedure Requirements:
None
Intercase Dependencies:
None
11.4. LocateNearestAvailableHospital
Purpose:
The purpose of this test case is to testthe functionality of theLocating the nearest hospital to the accident location inadherence tothe requirements.
Audience:
The audience for this test case is the customer and project team.
Test Case Specification Identifier:
TC_LocateNearestHospital
Test Items:
Components under Test:
ADS_Controller class/object
Database class/object
Hospital Sub-system
Features Being Exercised:
Locate Nearest Hospital
Input Specifications:
List of available hospitals loaded from the database
Accident location
Output Specifications:
The Hospital Identification Number of the nearest hospital to the accident location
Environmental Needs:
MySQL Database connection to a MySQL database with a table set up with a full list of hospitals for the area
ADS System running with network connections to the MYSQL database
Special Procedure Requirements:
None
Intercase Dependencies:
This test case is dependent upon:
Phone call must be placed: TC_PlacePhoneCall
The accident information must be gathered first: TC_GatherInformation
A Case must have already been opened: TC_OpenCase
User must be logged in: TC_Logon
11.5. PlacePhoneCall
Purpose:
The purpose of this test case is to testthe functionality of the use case PlacePhoneCall for adherence tothe requirements.
Audience:
The audience for this test case is the customer and project team.
Test Case Specification Identifier:
TC_PlacePhoneCall
Test Items:
Components under Test:
HTML/JSP Emergency Screen
ADS_Controller class/object
User - Dispatcher
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:
Dispatcher captures important information and tells the caller help is on the way.
Environmental Needs:
MySQL Database connection to a MySQL database with a table set up for users with users already entered
ADS System running with network connections to the MYSQL database
Special Procedure Requirements:
Tests related to the phone system cannot actually be done due to limited resources (no actual systems to test with)
Intercase Dependencies:
None
11.6. TraceByAddress
Purpose:
The purpose of this test case is to testthe functionality of the use case TraceByAddress for adherence tothe requirements.
Audience:
The audience for this test case is the customer and project team.
Test Case Specification Identifier:
TC_TraceByAddress
Test Items:
Components under Test:
HTML/JSP Emergency Screen
ADS_Controller class/object
User - Dispatcher
Database class/object
Features Being Exercised:
Accept phone call
Identifies incident address
Log call details
Captures required details in the system
Input Specifications:
Caller calls 911 asking for medical help
Incident address is traceable