In this context, failure describes the inability of a software to carry out a function required of it. Failure occurs when the deviation is caused by the system itself during use within accepted capacity limits.

In testing, failure refers to the effects of a fault inasmuch as they become visible to the tester.

See also failure in Wikipedia.


In a testing context, a fault is an erroneous section of a program, a statement or a data definition that is at the origin of a failure.

Futher to this, a fault can also mean a situation in which, under specific conditions (e.g. high usage), program functionality is impaired or failure occurs.

Fault/defect class

This is a system for classifying faults and failures according to the impact of their consequences (i.e. impact on user).

An example of a classification point would be if the fault would prevent production or whether it can be corrected retrospectively.

Fault/defect management

The complete process of recognising, detecting, analysing and resolving faults/defects in programs and systems.

Another aspect of defect management is the documentation, categorization and identification of the results of the fault at hand.

Fault/defect masking

In one definition, this refers to a state in which one defect in a program prevents another from being detected.

Alternatively, it can mean that a defect is not detected because other faults or anomalies keep up apparently normal functionality.

Fault/defect priority

This refers to the methodology for defining the urgency in correcting defects. Points that are taken into account are:

  • fault class
  • measures required for corrective action
  • effects on the remaining development process
  • effects on the remaining test process.

Field testing

This testing approach involves releasing a preview version of a software application to a representative group of users, with the aim being to locate and document usage environments that have not yet been considered. Furthermore, the aim is to test market acceptance.

As such, field testing is very similar to beta testing.

Finite state machine

This refers to a model for testing the behaviour of a software applications; it is based on states, transitions between those states and actions.

In between states, there a transitions that are dependent on input of occurences (e.g. timed occurences) Actions can be carried out either in a state or a transition.

Cf. finite-state machine on Wikipedia.

Functional requirement

This is a requirement related to the functional behaviour of a software application or component - i.e. this is a decision as to what the application should be able to do.

Cf. functional requirements on Wikipedia.

Functional testing

An approach to testing in which the aim is to determine whether a software application fulfils the functional requirements.

The original specifications are used to produce test cases; the spec is then used to evaluate the coverage of the tests.


Functionaly refers to the capability of a software application to fulfill its functions - i.e. functionality is the description of what the system must be able to. Implementing functionality is therefore the main criteria as to whether software can be used productively.

ISO/IEC 9126 on software quality defines the following criteria:

  • Suitability
  • Accuracy
  • Interoperabiity
  • Compliance
  • Security

Functional tests

Test cases developed as part of the functional testing approach. Also known as function tests.