The Standard for Software Test Documentation describes a set of basic documents for use in planning, controlling and monitoring the process of dynamic testing central to software validation. The Standard is generally applicable, and may be used even for small projects. The emphasis is on the purpose of the documents, rather than on their size. The purposes of a Test Plan are: to prescribe the scope, approach, resources, and schedule of testing activities; and to identify the items to be tested, the features to be tested, the testing tasks to be performed, the personel responsible for each task, andd the risks associated with this plan. A typical Table of Contents for a Test Plan is as follows: Identification and Purpose Introduction Test Items Features to be Tested Features not to be Tested Approach Item Pass/Fail Criteria Suspension Criteria and Resumption Requirements Test Deliverables Testing Tasks Environmental Needs Responsibilities Staffing and Training Needs Schedule Risks and Contingencies Approvals Test Design Specification The purpose of the Test Design Specification is to specify the requirements of the test approach and to identify the features to be tested by this design, and its associated tests. It would be possible for there to be several different test designs involved in testing a single software product. A Test Design Specification should contain the following elements: Identification and Purpose Features to be Tested Approach Refinements Test Identification Feature pass/fail criteria Test Case Specification The purpose of the Test Case Specification is to define a test case identified by a Test Design Specification. There will normally be several test cases (and specifications) associated with each test design. A Test Case Specification can be expressed very briefly, and it may be possible - for some designs - to document several test cases on a single page. Each Test Case Specification should have the following elements: Identification Test Items Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Test Procedure Specification The purpose of the Test Procedure Specification is to specify the steps for executing a set of test cases, or more generally, the steps used to analyse a software item in order to evaluate a set of features. A Test Procedure Specification may include descriptions of how to establish specific environmental requirements for a set of test cases - e.g. loading a specific test data base. A Test Procedure Specification should have the following elements: Identification Purpose Special Requirements Procedure Steps Test Item Transmittal Report The purpose of a Test Item Transmittal Report is to identify the test items being transmitted for testing. This report basically serves the purpose of a "cover sheet" confirming that the item to be tested is ready for testing, and documents the handover from programmer to the testing team. The Transmittal Report should have the following elements: Identification Transmitted Items Location Status Approvals Test Log The purpose of the Test Log is to provide a chronological record of relevant details about the execution of tests. A Test Log is usually in the form of a diary or log book, with columns recording the following elements: Identification Description Activity and Event Entries Test Incident Report The purpose of a Test Incident Report is to document any event that occurs during the testing process which requires investigation. The Problem Reporting procedure defined in the Quality Plan should document the manner in which any Test Incident Reports are to be treated. Each Incident Report should contain the following elements: Identification Summary Incident Description Inputs Expected Results Actual Reports Anomalies Date and Time Procedure Step Environment Attempts to Repeat Tester(s) Observer(s) Impact Test Summary Report The purpose of the Test Summary Report is to summarise the results of the designated testing activities and to provide evaluations based on these results. The Summary Report should provide advice on the release readiness of the product, and should document any known anomalies or shortcomings in the product. It should contain the following elements: Identification Summary Variances Comprehensive Assessment Summary of Results Evaluation Summary of Activities Approvals The Test Summary Report will be part of the overall Verification and Validation Summary for the Project. Original Author: Terry Rout Redesigned: 12 October, 1996 by Tracey Osborne Last Updated: 27 January, 1998 by Jo Orr Send comments, errors and suggestions to Terry Rout , T.Rout@cit.guredu.au