Testing Plan/Procedures

A testing plan is a document that really needs to be tailored individually to the system or subsystem being tested. The plan should be quite detailed and should be the guide for use by all parties doing the testing.

The testing plan should include:

A tentative go live date
A list of functions and procedures to be testing
A list of who is responsible for testing each function and procedure
A set of break points or checkpoints where testing progress can be determined
A schedule of when the testing system will be available for users
A schedule of when during the day or week testing is to be done
A detailed outline of what functions and procedures will be tested, including dates for this happening
A schedule of which batch testing jobs need to be run, the order in which they need to be run, and a schedule of when they need to be run
A detail list of parameters to be used for testing batch jobs
A schedule of when test reports will be reviewed and by whom
A schedule for feedback from test reports

This should be compiled by the Testing Leader with input from the testing committee.

Some guidelines for the above:

Completeness: While detail is necessary and appropriate, total detail is not needed. If a procedure is mentioned for testing, unless it is a new procedure, details of how to test the procedure are not necessary. However, each procedure that needs to be tested needs to be mentioned.
Timliness: Often it is better to specify a range of time for testing procedures rather than a specific time. Normal work schedules must be accommodated. However, sometimes it is necessary to specify times specifically for the testing to be done. When several procedures interact and are interdependent or dependent, more specific times become necessary.
Interrelated Procedures: Most systems and subsystems have interrelated procedures. When this is the case, the testing plan needs to provide for a means of the individuals testing the procedures to coordinate the data (as appropriate).
Problems: When problems occur, the testing coordinator needs to notify appropriate individuals. This also means that testing schedules may have to be altered, and the testing system may not be available as planned. Extra time needs to be built into testing schedules to accommodate these kinds of problems.
Checkpoints: Checkpoints should be chosen at naturally occurring breaks in the testing schedule. Most testing plans have several logical units. Checkpoints may be scheduled at the end of a logical unit. If this is not the situation, schedule checkpoints to minimize disruption in the testing schedule.
Coordination: Emphasis should be placed on how to test procedures. Random entry of data makes it difficult to anticipate results from various reports. Careful selection of test data makes if much easier to follow up in checking various reports which may rely on the data.

OIT Applications Support

Last Modified: