Testing Documentation Plan – An indispensable Control Tool in Software Testing Effort
Most critical aspect of proper control over the testing activity is testing documentation. The development life cycle is often characterized by the documents produced during each phase of work. In the same manner, the software testing life cycle may be defined, and controlled, by the documents produced during each of the testing activities.
Structured test documentation has been largely neglected in majority of the organizations. In some organizations, the documentation exists, but it remains haphazard and is generally left to the discretion of the practitioner. However recently the concept of writing a test plan has become common practice that is being regarded as a routine project deliverable. In the times to come, the organizations are getting wiser & wiser and are going to adopt standards for test documentation and will insist that all projects follow them. The fact remains that – without proper test documentation, effective management of the testing activity is difficult.
Sample Testing Documentation Plan:
Typical sample document plan defines a software testing life cycle that begins with a Master Test Plan coordinating all of the testing activity. Design testing and validation are formally reported, and unit test plans are specified for program testing. Integration, systems, and acceptance test plans are individually documented. Cases are specified by test case specifications and test procedures. Tests conducted are logged in a test log and any problems found are captured in the trouble report. Finally, a formal test certification is required before operational use and six months after implementation test effectiveness is evaluated.
The sample plan contains columns for recording the names of those who are responsible for preparing and approving each document and the time the document must be completed. It provides a quick overview of the entire testing process in the organization.
As regards specific documents that need be created during the testing life cycle, every organization remains the best judge to decide on its own. The decisions are generally based upon variables like the nature of the applications, the size and scope of the projects, and compatibility with current project methodologies.
However typical details of a sample test document plan are tabulated below.
ANSI Standard Software Test Documentation:
The IEEE Computer Society Software Engineering Standards Committee has addressed the area of software testing documentation and produced a set of standards that has been adopted by the American National Standards Institute (ANSI).
The ANSI standard defines following eight basic test documents.
Sr | Document Name | Contents |
1 | Test Plan | Defines the approach and plan for the testing work |
2 | Test Design Specification | Refines the test approach and identifies tests |
3 | Test Case Specification | Specifies a test case identified by a test design specification |
4 | Test Procedures Specification | Details the steps to carry out a set of test cases |
5 | Test Item Transmittal | Identifies test items being transmitted for testing |
6 | Test Log | Records the testing performed |
7 | Test Incident Report | Documents problems or discrepancies requiring investigation |
8 | Test Summary Report | Summarizes the testing results associated with one or more test design specifications |
The first four documents define the software testing to be performed in increasing levels of detail. The last three record the software testing results. The standard specifies the form and content for each of the eight documents. The standard does not define the specific documents that must be used. As long as the format for any document selected is adhered to, the organization may state that it is following the standard.
The Sample Software Testing Documentation Plan and the ANSI standard are two examples of integrated sets of testing documents. Variants or extensions may easily be created. A number of organizations have adopted special forms for use in documenting parts of the software testing activity. Organizations involved in setting up their own test documentation plans generally try to obtain samples from as many other companies as possible. The forms may often be used without change or with some minor modification.
Conclusion:
1) It is important to define which documents will be required and to establish a routine so that the documents “control” the workflow.
2) Minimally there must be a test plan, a test design, a record of test results, and a record of problems or discrepancies. These documents establish the test work that is supposed to be done; record the testing that is actually done; and captures any problems discovered so that they are sure to be corrected.
3) Test progress can be easily tracked, at least roughly, with the help of these documents.
4) We can easily examine the test plan or the record of the testing performed to determine why certain problems were missed; evaluate the costs of the testing performed; and compare and measure testing effectiveness.
5) Finally one must say that these documents provide us an effective control over our entire software testing effort.
Many More Articles on Test Planning & Management
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.