Note that this document describes a process rather than a product. During system development, this document and its supplements provide the information needed to do adequate testing. It lists approaches and standards to ensure that a quality product that meets the needs of the user is produced. This document is augmented by supplementary documents that list schedules, assignments and results. Some of this supplemental information need not be preserved. A record of the final result of the testing should be kept externally. For the maintenance phase, this document provides the context for regression testing when any changes are made. In this document we are trying to encompass the purpose of several IEEE standards.

[See 829-1998 IEEE Standard for Software Test Documentation, 1008-1987 (R1993) IEEE Standard for Software Unit Testing, and 1012-1998 IEEE Standard for Software Verification and Validation

Please note: The following is a careful explanation of what we feel a full test design document should look like. Contrary to what is stated below, we do not expect our students to produce a complete document. Testing is a very time-consuming task and many tests are very similar but each must be designed and performed separately. For the purpose of courses at the University of Scranton, we expect that 3.1, (3.2, if present) and 4.1 will contain at least one example of a fully described test for each major type of unit or use case realization to show the methodology of testing. This document need not contain all the tests. Provide enough information to allow a reader to understand how other tests may be set up.

The Test Design document must have the following contents (preferably with the section numbering used here):

1. Introduction

1.1. Purpose

Clearly state the purpose of this document and its intended audience.

1.2. Scope

Overview the testing process briefly. Give the major phases. Tell what will not be tested, for example, supporting software.

1.3. Glossary

Define the technical terms used in this document. Do not assume the experience or expertise of the reader.

1.4. References

List here any references to other documents cited anywhere in this document including references to related project documents, in particular the SRS and the SDD. This is usually the only Bibliography in the document.

1.5 Overview of Document

Describe the contents and organization of the rest of this document.

2. Test Plan

A test plan is a document describing the scope, approach, resources and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. (IEEE 829, p. 10) In this section, we outline the mechanics of the testing process. In the next two sections we list specific test items, the test data to be used and the results expected. Each tested item must be explicitly cross-referenced to and from the document describing it.

2.1. Schedules and Resources

Overview the testing schedule by phases and state any needed resources. This would be augmented by a specific schedule of when each designated test will be done and by whom. Record why you divided the testing work up as you did to inform maintenance developers of good practice. A specific schedule would be an accompanying document (or an appendix to this document). That separates the test design and plan needed for maintenance from the actual recording of tests.

2.2. Test Recording

Give the form to be used to record test results. It should very specifically name the item to be tested, the person who did the testing, reference the test process/data and the results expected, the date tested, and, for a failed test, the person with the responsibility to correct and retest. If possible, the form should link the tests so that a retest of one item will remind the tester to retest all items relying on that item (regression testing). The filled out forms would be kept with the specific testing schedule. Ideally, a database could be used to keep track of this testing. (See IEEE 829, Section 3, pp. 10-12.)

2.3. Test Reporting

A summary of what has been tested successfully, what has shown errors and when re-testing is expected is needed. In this section, provide a form that can be used to record this summary. The filled out summaries would be kept with the specific testing schedule described earlier. If a database were used for the test recording, this report could be produced by the database. (See IEEE 829, Section 10, pp. 15-16.)

2.4. Static Testing

Include static testing in this plan. Static testing is the formal reading of code and/or documents to find errors or omissions. Describe at what stages this will occur and the procedures to be followed.

3. Verification Testing

3.1. Unit Testing

For each unit in the SDD, there must be a test that the unit works properly. List each unit and the approach you will take to test it. The more specific this section is, the more valuable it will be to maintenance developers. (See note above.)

3.2. Integrative Testing

This section may be divided into several sections. The design of the project determines how many intermediate levels are distinct enough to rate a separate section here. Such levels are often called modules, components or sub-systems. Do not create levels to test just to make this section look impressive. (See note above.)

4. Validation Testing

4.1. System Testing

This is actually the top level of integrative testing. At this level, we validate requirements. We have fully described the needed behavior of the system in refer to the use cases in the SRS. We have then shown how our design provides realizations for these use cases in the SDD. Here we test each use case realization to make sure that it works as promised. (See note above.)

Use cases must also work in combination so we include sequences of use case tests to check on coordination. Again, give as explicit a set of tests as possible. This section may be divided into more sections if needed. (See note above.)

4.2. Acceptance and Beta Testing

List plans for acceptance testing and/or beta testing. (Exact terminology differs so be sure to define these terms in the Glossary.) This is testing with real data by the development team (acceptance testing) or the customer (beta testing). Tell how the results of such testing will be reported back and handled.

Branch to the Project Documentation Standards Homepage

Branch to Martin’s Homepage