Page 214 - DCAP405_SOFTWARE_ENGINEERING

Unit 12: Testing Tactics

situations must be tested. If we consider all possible valid combinations of equivalence classes, Notes
then it results in a large number of test cases, many of which may not uncover any undiscovered
errors.
This technique helps in selecting, in a systematic approach, a high-yield set of test cases. It is also
useful in pointing out incompleteness and ambiguities in the specifications. The following steps
are used to derive test cases:
1. The causes and effects are identified. A cause is a distinct input condition and effects are
output conditions or a system transformation. These are identified by reading the
specification and identifying the words or phrases that describe causes and effects. Each
cause and effect is assigned a unique number.
2. The semantic content of specification is studied and transformed into a Boolean graph
linking the causes and effects. This is the cause effect graph.

3. The graph is annotated with constraints describing combinations of causes and/or effects
that are impossible because of syntactic or environmental constraints.
4. By methodically tracing state conditions in the graph, the graph is converted into a limited
entry decision table. Each column in the graph represents a test case.
The columns in the decision table are converted into test cases. The basic notation for the graph
is shown in Figure 12.7.
Figure 12.7: Basic Cause Effect Graph Symbols

Think of each node as having values either 0 or 1, where 0 represents the ‘absent state’ and 1
represents the ‘present state’. The identity function states that if c is 1, e is 1; else e1 is 0. The NOT
1 1
function states that if c is 1, e is 0 and vice versa. The OR function states that if c or c or c is 1,
1 1 1 2 3
e is 1 else e is 0. The AND function states that if both c and c are 1, e is 1 else e is 0. The AND
1 1 1 2 1 1
and OR functions can have any number of inputs.
The black-box approach is a testing method in which test data are derived from the specified
functional requirements without regard to the final program structure. It is also termed data-
driven, input/output driven or requirements-based testing. Because only the functionality of
the software module is of concern, black-box testing also mainly refers to functional testing —
a testing method emphasized on executing the functions and examination of their input and
output data. The tester treats the software under test as a black box — only the inputs, outputs
and specification are visible, and the functionality is determined by observing the outputs to
corresponding inputs. In testing, various inputs are exercised and the outputs are compared
against specification to validate the correctness. All test cases are derived from the specification.

LOVELY PROFESSIONAL UNIVERSITY 207