This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.Find sources: "Pair testing" – news · newspapers · books · scholar · JSTOR (January 2021) (Learn how and when to remove this template message)

Pair testing is a software development technique in which two team members work together at one keyboard to test the software application. One does the testing and the other analyzes or reviews the testing. This can be done between one tester and developer or business analyst or between two testers with both participants taking turns at driving the keyboard.[1]

Description

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

Usage

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.

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

See also

References

  1. ^ Hendrickson, Elisabeth. "Paired Exploration". Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing. O'Reilly Media. ISBN 978-1-937785-02-4. One way to get everyone on the team involved in exploring is to pair them up to explore. Pairing professional testers with others is particularly effective. If a tester and a business analyst pair together, the tester is likely to learn more about the business and the expectations for the software... If a tester and a programmer pair together on exploring, the programmer is likely to gain insight about risks while the tester gains insight about the architecture.