ODC - Orthogonal Defect Classification

Function Test Triggers

There are several terms used to describe the testing of the functional aspect of a product. Depending on the size and scope of the project, any or all could be applied under the heading of function test. Unit test, for example, is an effort to validate the ability of the code written to execute successfully, independently from other influences such as interfaces with other products or functions. Function test takes a broader view, ensuring not only that the function executes successfully, but that interfaces are handled correctly, and that the function provides expected results. Component test is a term applicable to a large product which consists of multiple elements (components). This additional 'function test' ensures that all of the functions within a component perform satisfactorily, and the components of a product interface correctly with each other.

Each of these types of test effort would have a characteristic trigger signature, for example, the triggers most often associated with Unit test would be those at the simple end of the scale, while those associated with Component test would be predominantly more complex. One consideration is that, in general, the more complex the test scenario, the greater it's ability to test not only the code, but the underlying design. Whether these various approaches are appropriate in all cases, or are combined in an organization, is irrelevant to the topic at hand, however, and therefore we have chosen to combine all of these activities under one heading, 'function test'.

Test Coverage

refers to the use of an obvious test case of an external function. From a customer viewpoint, this would correspond to entering a single command, with a single set of parameter values.

Test Sequencing

is another relatively simple scenario, which examines the sequential effect of executing more than one body of code. This trigger reflects a customer scenario in which a simple series of commands is entered, such as 'create file', 'open file', 'close file'.

Test Interaction

begins to introduce more complex conditions, with multiple commands and multiple parameters interacting with each other. Customer environments in which databases are shared among multiple end users, and each command is dependent to a large degree on the successful execution, stored information, and interfaces of other functions, will often result in the surfacing of these types of faults.

Test Variation

is another trigger which requires more complex scenarios. It involves an attempt to exercise a single function in many different ways by entering a combination of parameters and values, sometimes invalid ones. These faults often show up as situations in which the customer inadvertently enters a parameter incorrectly, and instead of handling the situation and returning a meaningful message to the customer, the program abends.

Simple Path and Combination Path

are two additional triggers associated with function test which require some knowledge of how the code is designed and executed, as well as the logic flow. While this is not purely an external viewpoint, many customers apply some knowledge of these internals to the task of using the function in ways which are of particular interest to them, sometimes in an unexpected manner. The distinction between the two triggers is one of complexity: Simple path is a straightforward attempt to force specific branches to be executed, while complex path attempts to exercise these branches under varying conditions.