Information Technology Reference
In-Depth Information
thought of as subsets of the states identified in the dynamic model of the object.
Each test case represents one combination of values for each domain object in the
use scenario.
As the use case test plan is written, an input data specification table captures the
information required to construct the test cases. That information includes the class
from which the domain object is instantiated, the state space of the class and
significant states (boundary values) for the objects. As the tester writes additional
test plans and encounters additional objects from the same class, the information
from one test plan can be used to facilitate the completion of the current test plan
(McGregor
1994
).
10.1.2.2 Testing Interactions
Creating use case-level test plans also facilitates the identification and investigation
of interactions,: situations in which one object affects another one or one attribute of
an object affects other attributes of the same object. Certainly many interactions are
useful and necessary. That is how objects achieve their responsibilities. However,
there are also undesirable or unintended interactions where an objects state is
affected by another object in unanticipated ways. For example, two objects might
share a component object because a pointer to the one object was inadvertently
passed to the two encapsulating objects. This phenomenon may happen instead of a
second new object being created and passed to one of them. A change made in one of
the encapsulating objects is seen by the other encapsulating object.
Even an intended interaction gone badly can cause trouble. For example, if an
error prevents the editing of a field, then it is more probable that the same, or a
related, error will prevent us from clearing that same field. This is due to the
intentional use of a single component object to handle both responsibilities.
The brute force technique for searching for unanticipated interactions is to test
all possible permutations of the equivalence classes entered in the input data
specification table. If this proves to be too much information or require too many
resources for the information gained, the tester can use all possible permutations of
successful execution but only include a single instance of error conditions and
exceptional situations. These selection criteria represent successively less thorough
coverage but also require fewer resources.
Since the tester often does not have access to the code, the identification of
interactions is partially a matter of intuition and inference. The resources required
for the permutation approach can be reduced further by making assumptions about
where interactions do not exist. That is, there is no need to consider different
combinations of object values if the value of one object does not influence the
value of another. Test cases are constructed to exercise permutations within a set
of interacting objects, but not to include other objects that we assume are inde-
pendent of the first group. Obviously this opens the door to faults not being
detected, but that is true of any strategy other than an all permutations strategy
(McGregor
1994
).
