• Testing
• Objectives
• Methods
• Monitoring
• Test Scheduling
• Unit Test Scheduling
• Integration Test Scheduling
• Testing Report Submissions
• Report Submissions Integration Testing
• Defence of Integration Plan
• Unit Testing
• Integration Testing

Testing

7.1 Objectives:

Overall our test plan is designed to check the performance of the Newspaper Delivery System. After our conceptual design was implemented, we outlined a variety of tests suitable for our system. Our testing plans include integration testing, unit testing and the debugging of all processes, walkthroughs, and overall system performance. These tests will serve to assist our implementation team in finalizing any major or minor details that the system requires.

Back to Top

7.2 Methods:

For System Integration we have decided to use the Top Down approach by first integrating the interfaces for the subsystems followed by an incremental integration of processes for the subsystem outlined below. We decided on this method because it conforms to the general flow of how the system functions. Whereby a user is prompted from the initial interfaces right down to the specific process interfaces which will interact with the database.

Unit testing and the debugging of all process will be a large part of the performance check of the system. This type of testing will consist of focusing on each unit of the system at a time. Each individual process will be manually tested with any probable user input. This thorough analysis will give the implementation an idea of where necessary changes and improvements will be made. This will eventually help lead to the development of the final system.

A usability study on the system will be designed so to identify specific problem on the system. Direct observation methods will be employed; watching users interact with the system. Simple tasks will be performed by a user from our customer group with the guidance from our representatives. This will also act as a "tour" of our system and serves to determine how the system facilitates the needs of the customers. This system has limited functionality, but represents the conceptual model we intend to create and gives a broad view to the users of the system (alpha and beta models). Such studies are excellent at identifying overall design or interface problems.

The Overall system performance will be conducted through general scenarios which tests the system's ease of use and usability. This method is quite similar to the Walkthru, except testing will be by the implementation team and is less limited in the scope of our criterias.

It is worthwhile to note that the system was created in Microsoft(c) Access and simple logistics were applied to test this part of the system. Ensurance of the functionality of the tables, forms, and general consistency were made.

Back to Top

7.3 Monitoring:

A test coordinator will be in charge of monitoring the flow of the testing processes and keep testers in pace to meet deadlines. The test coordinator will also be in charge of collecting the relevant data from each of the testing sections and handling any retests. All the data collected will be screened, edited and interpreted and presented to the implementation team.

Back to Top

7.4 Test Scheduling:

The following is a schedule of the deadlines for our supplier group to test the particular sections of the system. The results of the sections will be given in a report documenting the problem areas. The main focus of these schedules will be limited to unit testing and integration testing.

Back to Top

Back to Top

7.5 Testing Report Submissions:

Deadlines are setup by the test coordinator in order for them to get the necessary information to the integration team in suitable time. Each of the individual test results will be submitted strictly on the dates indicated in the table below.

Back to Top

Back to Top

7.6 Defense of Integration Plan:

We selected the top down integration because all of our interfaces which conect our system together work interactively from the first interface at the top level right down to the last interface for the specific processes. You cannot access any of the bottom level interfaces without first going through the top level. Also most processes need eachother inorder to be tested effectively. This allows us to begin unit test while integration is taking place.

Back to Top

7.7 Unit Testing:

All the unit tests will be conducted by the programmers/testers according to the table above. Not all the individual units are listed above. Most of the individual units have subunits, and these will also be tested by the respective tester. These tests and the associated analyses are located in the Process Specification section.

Most processes contain subprocesses that can be organized into four major catagories.

Adding

Testing of modules which require addition to the data store will involve inputs,

• that satisfy the syntactic conditions for the record
• that don't satisfy the syntactic conditions for the record
• that satisfy the syntactic conditions but conflicts with already existing data

and addition to the data store when there are,

• no records
• 25 records
• 50 records

to ensure proper addition of records to the data store.

Deleting

Testing of modules which require deletion to the data store will involve inputs,

• that satisfy the syntactic conditions for the record
• that don't satisfy the syntactic conditions for the record
• that satisfy the syntactic conditions but conflicts with already existing data

and deletion from the data store when there are,

• no records
• 25 records
• 50 records

to ensure proper deletion of records from the data store.

Modifying

Testing of modules which require modification of the data store will involve inputs,

• that satisfy the syntactic conditions for the record
• that don't satisfy the syntactic conditions for the record
• that satisfy the syntactic conditions but conflicts with already existing data

and modification of the data store when there are,

• no records
• 25 records
• 50 records

to ensure proper modification of records from the data store.

Back to Top

7.8 Integration Testing:

The Integration Testing table above provides a list of level 3 processes that was found to be most suitable to focus integration testing upon. Once the startup menu is created the following submenus to be integrated can be called.

7.8.1 General Customer Processing

All customer functions are accessible through the "Customers" submenu selection from the startup menu. Testing must ensure that the three distinct but similar GUI's can be reached from the "Customers" interface. The similarity between interfaces requires common actions to be tested thoroughly to ensure that they maintain data consistency. When a customers is to be added, modified or deleted the integrated processes must react accordingly.

7.8.2 General Delivery Processing

Delivery functions are accessible through the "Deliveries" submenu selection from the startup menu. The "Deliveries" interface contains four distinct but similar GUIs that carrier information, route information, zone information, and district information . The creation of zones should permit the subsystem to further separate carriers from routes. Flexibility of changing a carrier without affecting the household in a zone and a household should be changed without affecting the carrier. This makes database maintenance simpler and more efficient.

7.8.3 Publication(Product) Information Processing

Operations dealing with Newspaper Information GUI belong to the product information interface. In the product information interface the user should be able to switch between the two types of product information: Newspaper information, and Magazine information. By pressing the tab labeled Magazine information, the system should switch to the magazine information GUI. The system will contain the product ID, magazine name, publisher name, frequency of issue (weekly, biweekly, monthly, bimonthly or quarterly), and retail outlet prices.

Back To Top
Back to Process Spec Menu