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.

Related Content

Blog Article
The Many Powers of Redux Dev Tools
Jeremiah BillmannJeremiah Billmann  |  
Oct 12, 2017
This blog post is loosely based on a talk, “A Time Traveling Tale of Immutability and the Many Powers of Redux”, that I gave at That Conference this year.Redux is a predictable state container for JavaScript applications. “Predictable” being the key word here as Redux also...
Blog Article
How to Build Mobile Navigation for Desktop with only HTML and CSS
Melanie LenaghanMelanie Lenaghan  |  
Oct 10, 2017
Desktop website navigation comes in a variety of flavors, but you typically see it as a list of labels positioned horizontally across the top of the screen with sub labels that drop down on hover or click.    This type of navigation is what people are familiar and comfortable with...
Blog Article
"Hey Google, How Do I Create Actions for the Home?"
Michael FazioMichael Fazio  |  
Oct 05, 2017
Welcome to the Google Home! Google released the Home late in 2016 to choruses of "Isn't that the same as the Echo?" and "Wait, is that an air freshener?" Yet, when people finally got their hands on it, they quickly realized how many features it has and what they could do...
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...