Go to the previous, next section.

Test Plan

@everyheading @thischapter @|@| Test Plan @thispage @everyfooting Author: rootd // Editor: ensley // Texinfo: rootd @| @| 3 December 1994

The following chapters constitute the test plan for the archie project. Testing is critically important to the archie project because our competing product (the Bunyip archie server) has a history of several years of reliable deployment. If our server is installed as a replacement for the Bunyip server at a "well-known" archie site, and then suffers repeated failure, our server may never get a second chance for acceptance.

General Testing Strategy

The tests of the archie system will be conducted in the following phases:

Each of the modules has its own chapter later in this manual with a detailed description of its test plan. The integration tests have not yet been fully determined--for now we just have a brief description in this section. The module interface compatibility checklist also does not have its own chapter in this revision.

Module Interface Compatibility Checklist

Not precisely a test, the module interface compatibility checklist is a series of questions about each module interface. This checklist is simply to affirm that the modules interface in the way they were designed. Module interface compatibility testing is based on page 639 of Roger Pressman's Software Engineering: A Practitioner's Approach (3rd ed).

Module Test

Each module needs to be tested individually to make certain that it performs its function. We have a separate chapter for each module.

Partial Integration Test

This is where we test the telnet interface, queuer, and searcher. This is the first test where our archie system actually has reasonable functionality.

Full Integration Test

This is where we see if our archie server works with requests being made by multiple interface types.

Full Integration Stress Test

After all bugs found in the full integration test are fixed, the development team will write scripts which request X archie searches per minute (where X is a variable that can be increased during run time). X will be gradually increased until the system fails. The type of failure will be determined (were users notified when their archie search could not be completed?).

Single Site Alpha-Test

This is where we install a fully functional server and make certain that it can function while updating the database. We announce the server so that users other than those in our development team can perform archie searches.

Multi Site Alpha-test

This is where we test the ability of the next generation client to load balance between servers.

Beta Test

Finally, we attempt to have someone other than ourselves install and maintain the archie server using only our distribution tarfile and documentation. Every question that the remote site asks should be considered for integration into our final documentation document.

Who will perform the testing?

The interface compatibility checklist and module test will be performed by the coder responsible for each module, and then will be double-checked by someone not working on that module.

The partial and full integration testing will be performed separately by the designer and producer.

The existence of a alpha-test servers will be announced to the local community so local users can perform archie searches on the local server. Memebers of the team (except the director and producer) will also request archie searches to increase the usage on our server. Meanwhile, the director and producer will test to determine if searches that occur during database updates cause erroneous search results.

The beta testing will be performed by some other organization with as little assistance as possible (the point is to see if our server can be installed and operated only by using our documentation).

Go to the previous, next section.