IEEE 829 Standard for Software Test Documentation

This is an IEEE standard that specifies how software tests should be documented. Amongst others, the structure for test concepts is described, along with instructions on how to design and implement test cases and reports.

For further information, see the Wikipedia entry on IEEE 829.

Informal review

This type of review (short for "code review" in software testing) is carried out without reference to a formal, documented structure.

Cf. code review on Wikipedia.

Internal fault

This is specific type of fault.


This kind of code review is based on the visual evaluation of documents with the aim of finding defects in process - i.e. deviation from development guidelines, standards that have not been kept to, discrepencies between documentation and results.

An inspection is the most formally structured type of review and relies heavily on documented procedure.

For further information, see articles about heuristic evaluation and cognitive walkthrough on Wikipedia.


This is a tool-based aspect of software development in which extra commands are inserted into the source code of an application in order to check or record program behaviour during execution.

One example of this is a performance and memory profiling tool to gain detailed information about the running time of a certain program.

See also Wikipedia on profiling.


In software, integration is the process of combining single program sections and components into a larger system. Integration takes place using pre-defined interfaces.

Integration testing

This form of testing is used to detect faults relating to the interplay of single components that have been integrated into a complete system.

In order to be sure that the faults arise from interfaces, the individual components themselves need to have been tested successfully beforehand (see component test).

Cf. integrations test on Wikipedia.