Pair Testing

Involves a pair of testers testing a feature or module together on the same machine. During the actual testing process, while one person tests the feature, the other one makes note of the observations as well as provides additional perspectives. The expectation is that having two people test the same feature together can help leverage their different sets of views, ideas and unique perspectives to have the feature tested better than it would have been if only one tester had tested it. Pair testing may also be used to help quickly ramp-up a new comer by pairing him with a more experienced tester.

While all this sounds pretty good, a point to be remembered is that in some circumstances it may not be possible to derive synergies from this process. Examples include, pairing testers who do not get along well, pairing a junior and senior tester when there's a fast approaching deadline to be met, etc.

This can be more related to pair programming and exploratory testing of agile software development where two team members are sitting together to test the software application. This will help both the members to learn more about the application. This will narrow down the root cause of the problem while continuous testing. Developer can find out which portion of the source code is affected by the bug. This track can help to make the solid test cases and narrowing the problem for the next time.

 

Benefits and Drawbacks

1.       The developer can learn more about the software application by exploring with the tester. The tester can learn more about the software application by exploring with the developer.

2.       Less participation is required for testing and for important bugs root cause can be analyzed very easily. The tester can very easily test the initial bug fixing status with the developer.

3.       This will make the developer to come up with great testing scenarios by their own

4.       This cannot be applicable to scripted testing where all the test cases are already written and one has to run the scripts. This will not help in the evolution of any issue and its impact.

 

Usage

1.       This is more applicable where the requirements and specifications are not very clear, the team is very new, and needs to learn the application behavior quickly.

2.       This follows the same principles of pair programming; the two team members should be in the same level.