The-Software-Experts




Google
 




   catch your bugs!
  Home
  Newsletter
  Forum
  Shop

  SW-Training
  - Software Design
  - Safe Coding in C
  - Software Inspection
  - Software Testing
  

  SW-Design
  - Architecture
  - Module Design
  

  Coding in C
  - Safe Coding in C
  

  Refactoring
  - Principles
  - Methods
  

  SW-Testing
  - Principles
  - Static Analysis
  - Inspections
  - Module Tests
  - Functional Tests
  - Integration Tests
  - Test Documentation
  - Links
  

  SW-Documentation
  - SGML Principles
  - Printing SGML
  - Links
  

  SW-Processes
  - Process Descriptions
  - Process Assessments
  - Self Evaluation
  - Food for Thought
  - Links
  

Safety Software
Design Training

IEC 61508 compliant
Safety Software
Design for Microcontroller

SW Document
Templates

CMMI and SPICE
compliant document
templates

SW Process
Description

CMMI Level 4 and
SPICE compliant SW
development procedure

SGML Package for
Documentation

Edit and print SGML
Documemts. Professional.
fast, easy to use.

Test Bench
for C/C++

Perl based test
environment for easy
component testing

Test Documentation

How should Test Documentation look like?

Test documentation is the vital element which raises any "try out" or "experimental" activities to the level of a proper test. Even if the way something is tested is good, it is worthless if it is not documented. How test documentation should look like is e.g. specified in the IEEE Standard 829. The IEEE standard allows scaling the set of documents by a certain degree. But basically this standard boils down to:

Test plan
The scope of the test activities, the methods and tools, the schedule and sequence of all test activities related to the SW have to be stated and defined in this plan. The test objects have to be identified as well as the attributes which have to be tested and the related end of test criteria must be fixed. Responsibilities and risks have to be identified and documented.

Test design specification
The method and approach for the tests has to be defined. In some cases it may be necessary to design a sophisticated test environment (test stubs, make files, recording facilities, etc.). All the technical details have to be specified, designed and documented.

Test case specification / Test procedure specification
In the test case specification the test object has to be identified as well as the attributes which have to be tested. It has to be made clear which steps and measures have to be applied to execute the test cases and which results are expected.

Test log / Test recording / Test reporting
The test results have to be documented and it has to be identified if the test ended with the expected results i.e. if they passed or failed. The test recording strongly depends on the test environment. In some cases this can be an automatic printout. In other cases this may be a check list which is ticked by the tester (may be even included in the test procedure / test case spec!). It may be even necessary to apply different methods within the same project, depending on the kind of test object and the kind of test employed. A preparation of the test results in a report is required. Test logs may be voluminous and have to be condensed to have their contents prepared for a quick overview and reference as well as for management or customer presentations.





Imprint