Back to List

The Benefits of Pair Testing

Blayne Roselle Blayne Roselle  |  
Mar 02, 2017
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.


Love our Blogs?

Sign up to get notified of new Skyline posts.


Blog post currently doesn't have any comments.
 Security code

Related Content

Blog Article
Microsoft Build 2017 Day 3 Recap
Brandon MartinezBrandon Martinez  |  
May 13, 2017
Day three of Microsoft Build 2017 did not have a keynote, but that doesn’t mean it ends without content to fill the day. Today will be focused on sessions, “The Hub”, and catching some of the Channel 9 Live production happening right here at the conference. Here’s a...
Blog Article
Microsoft Build 2017 Day 2 Recap
Brandon MartinezBrandon Martinez  |  
May 12, 2017
Another beautiful day in Seattle, and another amazing day at Build 2017! Today started off with another fantastic keynote followed by a wide array of awesome sessions. Here’s my recap of today’s events. Keynote Today’s keynote was heavily focused at improvements and...
Blog Article
Microsoft Build 2017 Day 1 Recap
Brandon MartinezBrandon Martinez  |  
May 11, 2017
I’m very excited to be here in Seattle, Washington to attend the Microsoft Build 2017 conference! It’s an honor to be amongst the geekiest of the geeks in the Microsoft community and to be able to absorb a ton of knowledge over the next few days. I’ll be posting daily recaps of...
Blog Article
A Noob’s Journey into Unity
Nathan FellomNathan Fellom  |  
Apr 12, 2017
My first meaningful exposure to Unity came during my senior year of college, after I was asked if I wanted to figure out something fun to do with an Oculus Rift that our Computer Science department had acquired. With absolutely no previous experience in game development, let alone VR development,...
Blog Article
You down with MVP? – Yeah, you know me
Blayne RoselleBlayne Roselle  |  
Apr 07, 2017
Minimum Viable Product (MVP) As defined by Techopedia, MVP is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters.  The final, complete set of features is only designed and developed after considering feedback from the...