TESTING

Intro: Objectives of Test Plan

The following is a test plan for UDDERS 1.0. It's objective is to produce a final product which is error free and meets all of the customer's requirements. It will also provide a timeline for indivdual unit testing and system integration so as to keep the project on schedule.

Testing Schedule

All group members except for the programming team are scheduled to test some part of the system. Each individual will test one form, system integration testing will be performed in small teams. A full test of the system will be done upon completion and will be performed by all group members.

Unit Testing:
Plane Module

Security Module
Security Information - Donna Edwards - Mar. 3/97

Plane Information - Kobe Davis - Mar.5/97
Add Plane - Kobe Davis - Mar. 5/97
Edit/Delete - Lorin Mcaffrey - Mar. 5/97
List Planes - Lorin Mcaffrey - Mar. 5/97
Seating - Kory Schnellback- Mar. 5/97

Flights Module
Flight Information - Blake Kanewischer - Mar. 7/97
Add Location - Blake Kanewischer - Mar. 7/97
Edit/Delete Location - Yee Tse - Mar. 7/97
List Locations - Yee Tse - Mar. 7/97
Add Route - Blake Kanewischer - Mar. 7/97
Edit Route - Yee Tse- Mar. 7/97
List Routes - Yee Tse - Mar. 7/97
Add Flight - Yee Tse - Mar. 7/97
Edit Flight - Andy Mclaughlin - Mar. 7/97
List Fight - Andy Mclaughlin - Mar. 7/97

Passenger Module
Passenger Info - Erik Yuzwa - Mar. 9/97
Book Passenger - Alex Phan - Mar. 9/97
Modify passenger - Alex Phan - Mar. 9/97
Print Boarding Pass - Erik Yuzwa - Mar. 9/97
List Passenger - Alex Phan - Mar. 9/97
Issue Refund - Alex Phan - Mar. 9/97
Passenger List - Alex Phan - Mar. 9/97

Reports Module
Report Information - Donna Edwards - Mar. 11/97

Integration Testing
Security Module
intgrate all forms/functions - Mar. 4/97 - Donna Edwards
Plane Module
integrate all forms - Mar. 6/97 - Kobe, Lorin, Kory

Flights Module
integrate all forms - Mar. 8/97 - Blake, Yee, Andy

Passenger Module
integrate all forms - Mar. 10/97 - Tue, Alex, Kory

Report Module
integrate all forms - Mar. 12/97 - Donna Edwards
System Integration
integrate all modules - Mar. 13-14/97 - all group members

*all dates subject to change

Monitoring and Reporting

Individual tests will be carried out by group members by the above dates. Test coordinators Kobe Davis and Andy Mclaughlin will ensure that all test are carried out by the date indicated and any errors reported on. Indiviual testers will fill out the following form for each form/module tested. Only errors found will be reported. Reports will be submitted to the test coordinators to be conveyed to the programming team. Errors will be corrected by the programming team and then retested by the corresponding tester.

Test Report Form
Tester Name:
Form/Module Tested:
------------------
Test performed: (description of exact test and circumstances)
Error: (detailed description of error)

...

Test performed:
Error:
------------------

Unit Testing

Unit testing involves checking that each form performs the functions it was deisgned for in the proper manner. Tests have been designed with a clear 'walkthrough' description to test normal, boundary and abnormal inputs. Each test has a date to be performed (subject to change) and person responsible for the testing.

Security Form Testing
Add User / Edit User / List Users
Overall testing objective
To ensure that users can be added to the system and their security levels modified.
Personnel responsible for testing: Donna Edwards
Date to be completed: Mar. 3/97

TEST 1

Objective
Ensure that a user can be added to the system.
Logic
This form should be able to add users to the system.
Inputs
From the Security Form select 'Add User', and add a new user to the system. User login, id, etc.
i) Enter a user already known to be in the system.
ii) Enter a new user to the system.
Expected outputs
i) Error, system should report the duplicate records and not enter the new user.
ii) New user should be added to the system. Should be able to view new user with list users button.

TEST 2

Objective
Ensure that a current user can be deleted or his/her information be changed.
Logic
This form should be able to edit/delete users.
Inputs From the security form select 'Edit/Delete User', and enter a user.
i) Enter a user already known to be in the system, and modify the user's name, security level.
ii) Enter a user unknown to the system.
Outputs
i) User's info should be updated.
ii) Error, user not found.

TEST 2

Objective
Ensure that all users of system are listed with correct information.
Logic
This form should be able to list users of the system. Inputs i) From the security form select 'List Users'.
ii) Repeat tests 1 & 2 and use 'List Users'.
Outputs
All users of the system should be output.

List Planes Form Testing

Overall testing objective
This test will only ensure that all planes on record are listed correctly
Personnel responsible for testing:Lorin Mcaffrey
Date to be completed:March 5/97

TEST 1

Objective
Only to ensure that all planes on record are listed correctly
Logic
Inputs
none
Expected outputs
The system should list all planes that the tester has entered into the system using the Add Plane form, and display the associated information correctly

Add Plane Form Testing

Seating

Overall testing objective
To ensure that the system will add planes to the database in a manner consistent with the design specs
Personnel responsible for testing: Kobe Davis
Date to be completed: March 5/97

TEST 1

Objective
Test the form for correct response to data entered in the Plane Number and Plane Type fields
Logic
This form should check for planes which are already in the system
Inputs
Enter a Plane Number which already exists in the system
Expected outputs
The system should inform the user that the number is in use, and that he or she should either delete the plane currently using the number, or choose a new number

TEST 2

Objective
To test the form's capacity for detecting Plane Types which are inconsistent with Seating configurations selected in the Seating Form
Logic
The system should cross-reference Plane Types with known Seating Capacities and Seating configurations.
Inputs
Enter a plane type which the system is aware of, then attempt to enter seating capacities which are too large and too small
Enter a plane type which is known to the system, then enter the Seating form and attempt to enter a seating configuration which is otherwise incompatible with that plane type.
Enter a correct Plane Type/Seating Configuration/Seating Capacity combination
Expected outputs
If the Information is incorrect, the System should inform the user in either case that the Plane Type is incompatible with either the Seating Configuration or the Seating Capacity
Otherwise, the tester should see that the system has succesfully registered and accepted the given information

TEST 3

Objective
To check that the system is correctly referencing Location data
Logic
The system should access the chosen location in the Location database to ensure that the user has entered this info correctly
Inputs
Enter a correct location manually
Enter a correct location from the list box
Enter a location which is not known to the system
Expected outputs
In both cases of correct input, the system should accept the data. It should appear in the input area of the list box. Otherwise, the system should inform the user that the data is invalid, and should not accept the given data

TEST 4

Objective
To ensure that the system will remind a user to save any changes, but that it will give the user the choice to abort
Logic
If the user has entered data, choosing OK or Cancel should generate confirmation messages and trigger completeness tests
Inputs
Enter correct data in all fields, press Cancel
Enter correct data in all fields, precc OK
Enter incomplete data, press Cancel
Enter incomplete data, press OK
Expected outputs
If the data is complete, pressing OK should ask the user whether the information is correct and whether the data should be entered into the database. Pressing Cancel should cause the system to confirm the cancellation
If the data is incomplete, pressing OK should cause the system to generate a message specifying which fields still need to be entered to succesfully enter the record. Pressing Cancel should cause the system to confirm the cancellation

Edit/Delete Plane Form Testing

Seating

Overall testing objective
To ensure that planes can be edited/deleted properly within the system
Personnel responsible for testing:Lorin Mcaffrey
Date to be completed:March 5/97

TEST 1

Objective
To ensure that a plane can be successfully deleted
Logic
A plane should be able to be deleted
Inputs
Enter a valid Plane Number, press DELETE
Enter an invalid Plane Number, press DELETE
Expected outputs
If the Plane number is valid, the record should be removed from the system. If the number is incorrect, the user should be informed that there is no such plane

TEST 2

Objective
To ensure that the system will succesfully edit existing planes
Logic
A plane should be able to be edited Inputs
Enter a valid Plane Number, change the Seating capacity (acceptable number)
Enter an invalid Plane Number, change the Seating Capacity Enter various valid/invalid Seating Configurations, Locations etc
Expected outputs
If the Plane Number is valid, the system should allow the user to enter valid changes to the system, then ask the user to confirm the changes before writing to the database.
If the Plane number is invalid, the user should be informed that he/she cannot change or delete an invalid Plane Number

TEST 3

Objective
To check that the user can OK (accept) or Cancel (reject) any changes made
Logic
Inputs
Enter valid, complete data, press OK
Enter valid, complete data, press Cancel
Enter invalid or complete data, press OK
Expected outputs
If the data is valid and complete and the user presses OK, the system should confirm that the user wants to accept the changes/deletion. If the data is incomplete or invalid, the system should generate an error message to that effect
If the user presses Cancel, the system should remind the user thath the information has not been saved and confirm the cancellation

Seating Form Testing

Overall testing objective
To test that seating configurations as entered in this form handled acceptably, and to ensure that security concerns are addressed
Personnel responsible for testing: Kory Schnellback
Date to be completed: March 5/97

TEST 1

Objective
To ensure that the system will check for correct Plane Numbers
Logic
The system should make sure that Seating Configurations are not being changed for planes which are not defined in the system
Inputs
Enter a plane number which exists
Enter a plane number which is unknown to the system
Expected outputs
If the plane number is not in use, the system should inform the user and disallow the action. If the Plane Number is acceptable, the system should accept the data

TEST 2

Objective
To ensure that the system functions correctly when accepting data for Plane Type and Seating Capacity
Logic
The system should check the entered Plane Type against the Plane Capacity
Inputs
Enter Plane Type, then enter a correct (acceptable within particular limits) Seating Capacity
Enter Plane Type, then enter a Seating capacity which is beyond the payload capacity specified by the manufacturer
Enter a Seating Capacity, then enter a Plane Type which is consistent with that Seating Capacity
Enter a Seating Capacity, then enter a Plane Type which is not consistent with that seating capacity
Expected outputs
If the Plane Type and Seating Capacity are consistent, the system should accept the data and allow the user to either press OK, or configure the seats
If the Plane Type and Seating Capacity are inconsistent, the system should generate an error message and not allow the user to continue the operation

TEST 3

Objective
To check the system's seat assignment box in this form
Logic
The system should not allow the user to enter a Seat Type for a seat which is outside the range of the Seating Capacity
Inputs
Enter a Seat Number which is within the range of the Seating Capacity
Enter a Seat Number which is outside of the range of the Seating Capacity
Expected outputs
If the Seat Number is correct, the system should accept the data. otherwise, it should inform the user that he/she will have to reenter the Seat Number

TEST 4

Objective
To ensure that the system will confirm any changes or lack of changes with the user
Logic
Inputs
Enter complete data, press OK
Enter complete data, press X (close)
Enter incomplete data, press OK
Enter incomplete data, press X (close)
Expected outputs
If the data is complete, the system should confirm the changes with the user before writing them to the database when the user presses OK. If the user presses X (close), the system should remind the user that the data was not saved
If the data is incomplete and the user presses OK, the system should inform him/her that more information is needed. If the user presses X (close), the user should be reminded that the information has not been saved

List Locations Form Testing
Overall testing objective
This test will only ensure that all locations on record are listed correctly
Personnel responsible for testing:Yee Tse
Date to be completed:March 7/97

TEST 1

Objective
Only to ensure that all loactions on record are listed correctly
Logic
Inputs
none
Expected outputs
The system should list all locations that the tester has entered into the system using the Add Locations form, and display the associated information correctly

SECURITY TESTING

Objective
To ensure that security requirements are being upheld by the system.
Inputs
Attempt to access this form while logged in variously as a System Admin, Location Admin, Flight Admin and Booking Agent
Expected outputs
Systems Admins, Location Admins, and Flight Admins should be able to access this form without problems. Booking Agents are not permitted

Add Locations Form Testing
Overall testing objective
To ensure that the system will add locations to the database in a manner consistent with the design specs
Personnel responsible for testing: Blake Kanewischer
Date to be completed: March 7/97

TEST 1

Objective
Test the form for correct response to data entered in the Location Number and Location Type fields
Logic
This form should check for locations which are already in the system
Inputs
Enter a Location Number which already exists in the system
Expected outputs
The system should inform the user that the number is in use, and that he or she should either delete the location currently using the number, or choose a new number

TEST 2

Objective
To check that the system is correctly referencing Location data
Logic
The system should access the chosen location in the Location database to ensure that the user has entered this info correctly
Inputs
Enter a correct location manually
Enter a correct location from the list box
Enter a location which is not known to the system
Expected outputs
In both cases of correct input, the system should accept the data. It should appear in the input area of the list box. Otherwise, the system should inform the user that the data is invalid, and should not accept the given data

Edit/Delete Location Form Testing
Overall testing objective
To ensure that locations can be edited/deleted properly within the system
Personnel responsible for testing:Yee Tse
Date to be completed:March 5/97

TEST 1

Objective
To ensure that a location can be successfully deleted
Logic
A location should be able to be deleted
Inputs
Enter a valid Location Number, press DELETE
Enter an invalid Location Number, press DELETE
Expected outputs
If the Location number is valid, the record should be removed from the system. If the number is incorrect, the user should be informed that there is no such location

TEST 2

Objective
To ensure that the system will succesfully edit existing locations
Logic
A location should be able to be edited Inputs
Enter a valid Location Number
Enter an invalid Location Number
Expected outputs
If the Location Number is valid, the system should allow the user to enter valid changes to the system, then ask the user to confirm the changes before writing to the database.
If the Location number is invalid, the user should be informed that he/she cannot change or delete an invalid Location Number

Add Route Form Testing
Overall testing objective
To ensure that the system will edit or delete routes from the database in a manner consistent with the design specifications
Personnel responsible for testing: Blake Kanewsicher
Date to be completed: Mar. 7/97

TEST 1

Objective
Test the form for correct response when trying to edit the fields in the form
Flight number, departure location, time and arrival time
Logic
This form should check for correct syntax when changing the flight information
Inputs
Enter a departure time that is not valid.
Expected outputs
Form should come back with a dialog box saying this departure time is non-existant, and not allow the user to save this route until a valid departure time is entered.

Edit/Delete Route Form Testing
Overall testing objective
To ensure that the system will edit or delete routes from the database in a manner consistent with the design specifications
Personnel responsible for testing:
Date to be completed:

TEST 1

Objective
Test the form for correct response when trying to edit the fields in the form
Flight number, departure location, time and arrival time
Logic
This form should check for correct syntax when changing the flight information
Inputs
Enter a departure time that is not valid.
Expected outputs
Form should come back with a dialog box saying this departure time is non-existant, and not allow the user to save this route until a valid departure time is entered.

List Routes Form Testing
Overall testing objective
To ensure that the system will list routes from the database in a manner consistent with the design specifications
Personnel responsible for testing: Yee Tse
Date to be completed: Mar. 7/97

TEST 1

Objective
If a filter of a route is entered and the search failed, a error message should appear.
Logic
This form should check to make sure that it returns an error message if a route spec is not found.
Inputs
Enter a non-existent route.
Expected outputs
Form should come back with a dialog box saying UDDERS is not able to find the route requested.

Add Flight Form Testing
Overall testing objective
To ensure that the system will add flights to the database in a manner consistent with the design specifications
Personnel responsible for testing: Yee Tse
Date to be completed: Mar. 7/97

TEST 1

Objective
To test the form when a field is left blank.
Logic
This form should check to make sure all fields are filled in, and display an error message if one is left blank.
Inputs
Leave a field blank.
Expected outputs
Form should come back with a dialog box saying UDDERS is not able to add this flight because the ___ field is not filled in. Then the form will return to the editing part

TEST 2

Objective
To test the form when data is out of range for the field.
Logic
The form should check before saving the flight, that the field data is within specified ranges.
Inputs
Enter a departure date that is not within bounds.
Expected outputs
Form should come back with a dialog box saying UDDERS is not able to add this flight because the value ___ because the value ___ is not within range for the field ___.

List Flights Form Testing
Overall testing objective
To ensure that the system will list flights from the database in a manner consistent with the design specifications
Personnel responsible for testing: Andy Mclaughlin
Date to be completed: Mar. 7/97

TEST 1

Objective
If a filter of a flight is entered and the search failed, a error message should appear.
Logic
This form should check to make sure that it returns an error message if a flight spec is not found.
Inputs
Enter a non-existent flight.
Expected outputs
Form should come back with a dialog box saying UDDERS is not able to find the flight requested.

Book Passenger Form Testing

Overall testing objective
To ensure that the system will add passengers to the database in a manner consistent with the design specifications
Personnel responsible for testing: Alex Phan
Date to be completed: Mar. 9/97

TEST 1

Objective
To test the form when a field is left blank.
Logic
This form should check to make sure all fields are filled in, and display an error message if one is left blank.
Inputs
Leave a field blank.
Expected outputs
Form should come back with a dialog box saying UDDERS is not able to book this passenger because the ___ field is not filled in. Then the form will return to the editing part

TEST 2

Objective
To test the form when data is out of range for the field.
Logic
The form should check before saving the passenger, that the field data is within specified ranges.
Inputs
Enter a field that is not within bounds.
Expected outputs
Form should come back with a dialog box saying UDDERS is not able to add this passenger because the value ___ because the value ___ is not within range for the field ___.

Edit Passenger Form Testing

Overall testing objective
To ensure that the system will edit passengers from the database in a manner consistent with the design specifications
Personnel responsible for testing: Alex Phan
Date to be completed: Mar. 9/97

TEST 1

Objective
Test the form for correct response when a non-existant ticket number is entered
Logic
This form should generate a error message when a non-existant ticket number is entered.
Inputs
Enter a passenger that is not valid.
Expected outputs
Form should come back with a dialog box saying this passenger is non-existant, and not allow the user to try again.

TEST 2

Objective
Test the form for correct response when a user tries to delete a passenger that is already booked on a flight.
And that passenger has NOT obtained ticket insurance.
Logic
This form should generate a error message when a user tries to delete a passenger without insurance.
That passenger cannot obtain a refund.
Inputs
Bring up a passenger who does not have ticket insurance and try to delete them.
Expected outputs
Form should come back with a dialog box saying this passenger does not have ticket insurance.

Passenger List Form Testing
Overall testing objective
This test will only ensure that all passengers for a selected flight are listed correctly.
Personnel responsible for testing:Yee Tse
Date to be completed:March 7/97

TEST 1

Objective
Only to ensure that all passengers on record for a particular flight are listed correctly
Logic
Inputs
none
Expected outputs
The system should list all passengers that the tester has entered into the system for that flight correctly, and display the associated information correctly

Reports Form Testing

Overall testing objective
To ensure that reports are properly generated by the system
Personnel responsible for testing: Donna Edwards
Date to be completed: Mar. 11/97

TEST 1

Objective
To ensure that a revenue report is corectly generated.
Logic
Pressing the Revenue Report button should generate a revenue report with the correct information.
Inputs
Enter a year,month,day and repeat the test selecting first a yearly summary, then monthly summary and finally a summary for specific day.
Expected outputs
A report of the correct form with correct info should be generated for each selection.

TEST 2

Objective
To ensure that a refunds report is corectly generated.
Logic
Pressing the Refunds Report button should generate a refund report with the correct information.
Inputs
Select the Reports button. Enter a year,month,day and repeat the test selecting first a yearly summary, then monthly summary and finally a summary for specific day.
Expected outputs
The form should bring up a dialogue box. A report of the correct form with correct info should be generated for each selection.

Integration Testing

This stage ensures that all forms tested individually in the previous section can be combined without error into the system. Each form has been tested indivually, and will now be connected to the 'system' and tested to ensure that it can call all forms it needs to correctly and is called correctly by other forms. Forms will be connected from the top-down in a tree fasion, (ie. a branch consisting of the Seaating and Add Planes will be coupled and connected to the PLanes Menu and then the Main Menu) checking to see that all functions work correctly. The order for integration and testing is as follows:

Seating Module Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Kobe Davis, Kory Schnellback, Lorin Mcaffrey
To be performed by date: March 6/97
Procedure
Form Seating is linked to Form Add Plane
Success
Does Seating connect and share data correctly with Add Plane?
Does Seating access all necessary tables/information correctly?

Add Plane Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Kobe Davis, Kory Schnellback, Lorin Mcaffrey
To be performed by date: March 6/97
Procedure
Form Add Plane is linked to module Plane Info
Success
Does Add Plane connect and share data correctly with Plane Info?
Does Add Plane access all necessary tables/information correctly?

Edit Plane Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Kobe Davis, Kory Schnellback, Lorin Mcaffrey
To be performed by date: March 6/97
Procedure
Form Edit Plane is linked to module Plane Info
Success
Does Edit Plane connect and share data correctly with Plane Info?
Does Edit Plane access all necessary tables/information correctly?

List Planes Form Integration Testing>
(first link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Kobe Davis, Kory Schnellback, Lorin Mcaffrey
To be performed by date: March 6/97
Procedure
Form List Planes is linked to Edit/Delete Plane
Success
Does List Planes connect and share data correctly with Edit/Delte Plane?
Does List Planes access all necessary tables/information correctly?

List Planes Form Integration Testing
(second link) Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Kobe Davis, Kory Schnellback, Lorin Mcaffrey
To be performed by date: March 6/97
Procedure
Form List Planes is linked to module Plane Info
Success
Does List Planes connect and share data correctly with Plane Info?
Does List Planes access all necessary tables/information correctly?

Plane Information Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Kobe Davis, Kory Schnellback, Lorin Mcaffrey
To be performed by date: March 6/97
Procedure
Module Plane Information is linked to module Main Information
Success
Does Plane Information connect and share data correctly with Main Information?
Does Plane Information access all necessary tables/information correctly?

Add Location Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form Add Location is linked to module Flight Info
Success
Does Add Location connect and share data correctly with Flight Info?
Does Add Location access all necessary tables/information correctly?

Edit/Delete Location Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form Edit/Delete Location is linked to module Flight Information
Success
Does Edit/Delete Location connect and share data correctly with Flight Information?
Does Edit/Delete Location access all necessary tables/information correctly?

List Locations Form Integration Testing
(first link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form List Locations is linked to module Edit/Delete Location
Success
Does List Locations connect and share data correctly with Edit?Delete Location?
Does List Locations access all necessary tables/information correctly?

List Locations Form Integration Testing
(second link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form List Locations is linked to module Flight Info
Success
Does List Locations connect and share data correctly with Flight Info?
Does List Locations access all necessary tables/information correctly?

Add Route Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form Add Route is linked to module Flight Info
Success
Does Add Route connect and share data correctly with Flight Info?
Does Add Route access all necessary tables/information correctly?

Edit/Delete Route Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form Edit/Delete Route is linked to module Flight Information
Success
Does Edit/Delete Route connect and share data correctly with Flight Information?
Does Edit/Delete Route access all necessary tables/information correctly?

List Routes Form Integration Testing
(first link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form List Routes is linked to module Edit Routes
Success
Does List Routes connect and share data correctly with Edit Routes?
Does List Routes access all necessary tables/information correctly?

List Routes Form Integration Testing
(second link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form List Routes is linked to module Flight Info
Success
Does List Routes connect and share data correctly with Flight Info?
Does List Routes access all necessary tables/information correctly?

Add Flight Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form Add Flight is linked to module Flight Info
Success
Does Add Flight connect and share data correctly with Flight Info?
Does Add Flight access all necessary tables/information correctly?

Edit/Delete Flight Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form Edit/Delete Flight is linked to module Flight Info
Success
Does Edit/Delete Flight connect and share data correctly with Flight Info?
Does Edit/Delete Flight access all necessary tables/information correctly?

List Flights Form Integration Testing
(first link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form List Flights is linked to module Edit/Delete Flight
Success
Does List Flights connect and share data correctly with Edit/Delete Flight?
Does List Flights access all necessary tables/information correctly?

List Flights Form Integration Testing
(second link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Form List Flights is linked to module Flight Information
Success
Does List Flights connect and share data correctly with Flight Information?
Does List Flights access all necessary tables/information correctly?

Flights Information Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Blake Kanewischer, Yee Tse, Andy McLaughlin
To be performed by date: March 8/97
Procedure
Flight Info Form is linked to module Main Information
Success
Does Flight Info connect and share data correctly with Main Menu?
Does Flight Info access all necessary tables/information correctly?

List Flights Form Integration Testing
(third link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Erik Yuzwa, Alex Phan, Kory Schnellback
To be performed by date: March 10/97
Procedure
Form List Flights is linked to module Book Passenger
Success
Does List Flights connect and share data correctly with Book Passenger?
Does List Flights access all necessary tables/information correctly?

Book Passenger Module Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Erik Yuzwa, Alex Phan, Kory Schnellback
To be performed by date: March 10/97
Procedure
Module Book Passenger is linked to module Passenger Info
Success
Does Book Passenger connect and share data correctly with Passenger Info?
Does Book Passenger access all necessary tables/information correctly?

Print Boarding Pass Module Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Erik Yuzwa, Alex Phan, Kory Schnellback
To be performed by date: March 10/97
Procedure
Module Print Boarding Pass is linked to module Passenger Info
Success
Does Print Boarding Pass connect and share data correctly with Passenger Info?
Does Print Boarding Pass access all necessary tables/information correctly?

List Passengers Integration Testing
(second link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Tue, Alex & Kory
To be performed by date: Mar. 10/97
Procedure
Form List Passengers is linked to form Edit Booking
Success
Does List Passengers connect and share data correctly with Edit Booking?
Does List Passengers access all necessary tables/information correctly?

Edit Booking Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Tue, Alex & Kory
To be performed by date: Mar. 10/97
Procedure
Form Edit Booking is linked to form Passenger Info
Success
Does Edit Booking connect and share data correctly with Passenger Info?
Does Edit Booking access all necessary tables/information correctly?

Issue Refund Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Tue, Alex & Kory
To be performed by date: Mar. 10/97
Procedure
Form Issue Refund is linked to form Passenger Info
Success
Does Issue Refund connect and share data correctly with Passenger Info?
Does Issue Refund access all necessary tables/information correctly?

List Passengers Integration Testing
(third link)
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Tue, Alex & Kory
To be performed by date: Mar. 10/97
Procedure
Form List Passengers is linked to form Passenger Info
Success
Does List Passengers connect and share data correctly with Passenger Info?
Does List Passengers access all necessary tables/information correctly?

Flight List Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Tue, Alex & Kory
To be performed by date: Mar. 10/97
Procedure
Form Flight List is linked to form Passenger Info
Success
Does Flight List connect and share data correctly with Passenger Info?
Does FlightList access all necessary tables/information correctly?

Passenger Information Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Tue,Alex,Kory
To be performed by date: Mar. 10/97
Procedure
Fight Passenger Information is linked to Main Menu
Success
Does Passenger Information connect and share data correctly with Main Menu?
Does Passenger Information access all necessary tables/information correctly?

Report Module Integration Testing Revenue Report / Refund Report
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Donna Edwards
To be performed by date: Mar. 12/97
Procedure
Report Form is linked to Main Menu
Success
Does Report Form connect and share data correctly with Main Menu?
Does Report Form access all necessary tables/information correctly?

Revenue Report Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Donna Edwards
To be performed by date: Mar. 12/97
Procedure
Form Revenue Report Form is linked to form Reports
Success
Does Revenue Report Form connect and share data correctly with Reports?
Does Revnue Report Form access all necessary tables/information correctly?

Refund Report Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Donna Edwards
To be performed by date: Mar. 12/97
Procedure
Form Refund Report Form is linked to form Reports
Success
Does Refund Report Form connect and share data correctly with Reports?
Does Refund Report Form access all necessary tables/information correctly?

Add User Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Donna Edwards
To be performed by date: Mar. 4/97
Procedure
Add User form is linked to form Security
Success
Does Add User Form connect and share data correctly with Security?
Does Add User Form access all necessary tables/information correctly?

Modify User Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Donna Edwards
To be performed by date: Mar. 4/97
Procedure
Modify User form is linked to form Security
Success
Does Modify User Form connect and share data correctly with Security?
Does Modify User Form access all necessary tables/information correctly?

List Users Form Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Donna Edwards
To be performed by date: Mar. 4/97
Procedure
List Users form is linked to form Security
Success
Does List Users Form connect and share data correctly with Security?
Does List Users Form access all necessary tables/information correctly?

Security Module Integration Testing
Objective
To ensure that the module is properly 'integrated' with the system - i.e. calls the correct modules, and is called by the correct modules
Personnel responsible for test: Donna Edwards
To be performed by date: Mar. 4/97
Procedure
Security form is linked to Main Menu
Success
Does Security Form connect and share data correctly with Main Menu?
Does Security Form access all necessary tables/information correctly?

Functional Testing

This stage will be concerned with ensuring that UDDERS 1.0 meets the functional requirements of our customer Dairy-Air. A complete runthrough of the UDDERS 1.0 system will be performed which tests all major functions and their coordination. All specified functions will be tested by the entire UDDERS design group. A testing 'walkthrough/runthrough' will be followed that includes:
Adding/Editing/Lsting planes
Ading/Editing/Listing locations
Adding/Editing/Listing routes (between locations)
Adding/Editing/Listing flights (using routes and planes)
Booking/Editing passengers (on flights)
Issuing Boarding Passes (to the passengers)
'Overbooking a plane' and issuing refunds
Printing and reviewing of each report and list
Security Testing

The reporting procedures will continue to be followed.

Performance Evaluation

To evaluate the performance of UDDERS, Mootronix will bring in a number of independant testers. These 'testers' will be booking agents and airport employees who will be given a script of functions to perform. Afterwards they will be asked to evaluate UDDERS on a number of aspects including usability, friendliness, speed. This will also be UDDERS first test under a large 'load', which will allow us to evaluate it's reliablilit and robustness.

Acceptance Test

At this time UDDERS 1.0 will be demonstrated for our customer Dairy-Air and evaluated against it's inital design specifications.