In the world of Agile development, many have heard of Pair Programming (two programmers working together at one workstation. One, the driver, writes code while the other, the observer, reviews each line of code – the two programmers will frequently switch roles). Similar in concept, but perhaps not as well-known is Pair Testing (two people working together to test the same feature, at the same place, and at the same time by continuously exchanging ideas. One member of the team will test the application, while the other team member observes, makes notes, and conjures new scenarios). This concept is something I have wanted to try for a while and two of my more recent projects have allowed for this to occur. Pair Testing can be done with a combination of different roles (QA/Dev, QA/BA, QA/QA). This post will focus on the QA/QA combo. Project 1 – Mobile Application With this project, the requirement was that each test case be executed against two mobile platforms (iOS and Android) before the user story could be considered done. Many of the tests could be run on devices from the comfort of my desk. However, there were test cases that required someone physically be onsite in order to perform the task at hand. To eliminate redundancy, to increase quality, and to decrease the perceived amount of time spent testing each user story, I decided to try Pair Testing with the other 2 QA Analysts working on the project. With this project, Pair Testing: Eliminated Redundancy – by not having 1 person run the exact same test case multiple times Increased Quality – by having 3 testers observing, exchanging ideas, and exploring at the same time Decreased Time (at least psychologically it felt this way) – the total hours spent testing 1 test case didn’t necessarily decrease (i.e., to execute 1 test case it may take 1 QA Analyst 90 minutes to complete – 30 minutes to test the 1st device, 30 minutes to test the 2nd device, and 30 minutes to make updates to the test case and create bugs). With 3 QA Analyst, the time spent from start-to-finish was 30 minutes (i.e., 30 minutes for Tester 1 to complete the test case on an Android device; at the same time Tester 1 is testing, Tester 2 is completing the test case on an iOS device and Tester 3 is reading the test scenario, observing, and creating bugs). However, psychologically, it just felt like it took much less time. Project 2 – Web Application Pair Testing can also be useful in bringing someone that is new to QA and/or to a project up-to-speed. With this project, someone new to the QA role was brought on to the team that didn’t have QA experience. Rather than assigning this person to begin testing a user story on their own, or having them observe me, I again decided to try Pair Testing. In this instance, the person projected the application we were testing on to a screen and I would read through the test case, observe the behavior of the application, and suggest additional scenarios. With this project, Pair Testing: Brought the QA up-to-speed quickly Provided confidence to the QA when they needed to test independently (this gave them a better understanding of the application) Allowed for me to answer questions, inform them of any nuances with the application, and provide immediate feedback Eliminated tunnel vision – by having another pair of eyes, this provided innovative ideas or methods I had not considered Created a collaborative environment to bounce ideas off of each other In conclusion, I am a proponent of Pair Testing – not only does it eliminate redundancy and increase quality, but it also helps build stronger relationships. Working closely provides opportunities to build on each other’s strengths and get to know each other personally. I intend to use Pair Testing in future projects.