Software Testdokumentation nach den IEEE und ISO Standards

Abstract

Test documentation is needed not only to assess the extent and quality of a test but also to assess the productivity of testers and to tie the test to the software architecture. Decision makers and auditors need test documentation to decide whether to release a version or not. Maintainers need test documentation to see how changes can be tested. Testers need test documents to help them identify the causes of errors. Finally auditors require a documentation of the test to confirm that the product has been adequately tested. Test documents are prescribed by prevailing IEEE and ISO standards. Originally they were prepared by hand. Today they are most often generated automatically as a byproduct of the test automation. The demand for test documentation goes back to the early days of testing when the US military was testing the ballistic missile defense system. The tool RXVP – Research and Evaluation Package – instrumented the Fortran code to trace execution paths through the system and to measure the degree of test coverage. Branch coverage was considered at that time to be an important criteria for determining how well the software was tested [Miller, 1979]. It was also important to register the paths that were taken through the network of code modules in order to be able to reconstruct the tests. Shortly thereafter the IEEE published the Standard ANSI/IEEE-829 for Software Test Documentation. The first version appeared in 1983. It was later revised in 1998 [ANSI/IEEE, 1998]. It is interesting to note that this first general test standard was entitled test documentation and not just system testing. It emphasized what should come out of a system test – the results. Later in 1987 another corresponding standard for unit testing – ANSI/IEEE Std. 1008 – was published. That standard put much less emphasis on documentation, i.e. what should be delivered, and instead emphasized the process, i.e. how software units should be tested [ANSI/IEEE, 1993].