Ieee software testing documentation

Christy Bahn. A set of basic test documents that are associated with the dynamic aspects of software testing that is, the execution of procedures and code is described. The purpose, outline, and content of each basic document are defined. Although the documents described in the standard focus on dynamic testing, several of them may be applicable to other testing activities.

Documentation on electronic media as well as paper is covered. The standard does not call for specific testing methodologies, approaches, techniques, facilities, or tools, and does not specify the documentation of their use. It also does not imply or impose specific methodologies for documentation control, configuration management, or quality assurance.

The purpose, outline, and content of each basic document are defined. Although the documents described in the standard focus on dynamic testing, several of them may be applicable to other testing activities.

Documentation on electronic media as well as paper is covered. The standard does not call for specific testing methodologies, approaches, techniques, facilities, or tools, and does not specify the documentation of their use. It also does not imply or impose specific methodologies for documentation control, configuration management, or quality assurance.

Scope: This standard describes a set of basic test documents which are associated with the dynamic aspects of software testing that is, the execution of procedures and code. The standard defines the purpose, outline, and content of each basic document. While the documents described in the standard focus on dynamic testing, several of them may be applicable to other testing activities for example, the test plan and test incident report may be used for design and code reviews.

If there is a discrepancy than one or more Test Incident Reports are raised or updated, and their identities recorded on the Test Log. The Test Log is important as it allows progress of the testing to be checked, as well as providing valuable information for finding out what caused an incident. If an incident is a coding fault, the fault may have occurred not in the Test Case that failed but in one that was run previously. Thus the sequence of the tests enables the fault to be found.

This document is deliberately named as an incident report, and not a fault report. The reason is that a discrepancy between expected and actual results can occur for a number of reasons other than a fault in the system. These include the expected results being wrong, the test being run wrongly, or inconsistency in the requirements meaning that more than one interpretation could be made.

The report consists of all details of the incident such as actual and expected results, when it failed, and any supporting evidence that will help in its resolution. The report will also include, if possible, an assessment of the impact upon testing of an incident.

A failed test may raise more than one incident, and at the same time an incident may occur in more than one test failure. Taking the Billing project example, if both test cases completely failed than three Test Incident Reports would be raised:. It is important to separate incidents by the features being tested so as to get a good idea of the quality of the system, and allow progress in fixing faults to be checked.

A useful derivative document from the Test Incident Report is a Test Incident Log to summarise the incidents and the status.

Eventually testing will be completed according the criteria specified in the Test Plan. This is when the success or failure of the system is decided based on the results. The Test Summary records this information. The Test Summary brings together all pertinent information about the testing, including an assessment about how well the testing has been done, the number of incidents raised and outstanding, and crucially an assessment about the quality of the system.

Also recorded for use in future project planning is details of what was done, and how long it took. This document is important in deciding whether the quality of the system is good enough to allow it to proceed to another stage.

The standard is generic to cover all types of testing. As a result it allows the documents to be tailored to each situation. This means using the basic structure as given, but other documents can be added to it, sections can be added to each document, and further descriptions can be written.

In addition some content can be referenced in another document. By using the standard means that anybody joining a project will know what documents are being used, and for what purpose, allowing them to become productive faster.