Topic: Testing interactions

Message


   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.

Author	Message
Sangita Groupie Joined: 27Apr2007 Online Status: Offline Posts: 53	Topic: Testing interactions 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. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Software Testing @ OneStopTesting : Beginners @ OneStopTesting