Testing interactions
Printed From: One Stop Testing
Category: Software Testing @ OneStopTesting
Forum Name: Beginners @ OneStopTesting
Forum Discription: New to the Club...!!! Don't Worry, We are here for you...!!! Learn the very basics of Software Testing and other pertinent Informations.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=1542
Printed Date: 05Sep2025 at 11:21pm
Topic: Testing interactions
Posted By: Sangita
Subject: Testing interactions
Date Posted: 19Jun2007 at 9:56pm
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. Two objects might share a component object because a
pointer to the one object was inadvertently passed to the two encapsulating
objects 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 bad 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. So test cases are
constructed to exercise permutations within a set of interacting objects but
not to include other objects that we assume are independent 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.
|
|