The Many Advantages of Pair Testing

Pair testing can be done with various disciplines within the software development lifecycle. It has many advantages, both for the quality of the product and the benefit of the testers, and it doesn’t require any special training. You only need two brains and two pairs of eyes. Would your team try pair testing?

I think pair testing is not a technique, but an approach. An approach reflects a broad vision about the best way to organize your testing, rather than specific tactics for designing individual tests.

Testing, as I see it, is: 

  • In search of quality-related information
  • Questioning the product in order to evaluate it and learn from it
  • Gathering information to make an informed decision

These are the definitions of testing I work with. Testing is all about asking questions and collecting information. By asking questions, you learn more about the application you are testing, and while learning, you create more questions to reveal more information. 

The earlier in the software development lifecycle you start testing, the more information you can collect, and the better you can design your tests. One way to start testing earlier is with two people working together on the same testing task, or pair testing.

Much like with pair programming, the biggest disadvantage is that two people are working on the same assignment. Managers will complain about that, saying they should be working on different things so that they can cover more of the application and that time and money are spent more wisely.

But are they? Working as a pair has its advantages. Let’s look at some of them and see if you can encourage your team to try pair testing.

Two Heads Are Better Than One

In pair testing, generally one person is executing the tests while the other person is making notes of what has been done and what has been observed, in order to inform the testers and the stakeholders. When needed, they can switch. What you have here is two different minds and two sets of eyes focused on the assignment. One person observes and asks, the other person thinks and responds, and both people inspire each other.

This exercise is useful to come up with test ideas. The pair can then agree on decisions and divide the work. When you work alone, you constantly switch between test execution and making notes of your observations, so working as a team will make you go faster.

Increased Coverage of Knowledge

As two people are working together on the same assignment, they will grow to the same level of knowledge about the application. That way, there is no single point of failure because the knowledge is shared.

There’s also the advantage that if one person is not able to participate, the other one can take over, and the work on the application is not interrupted.

Likewise, when emergencies occur, such as a problem in the production environment, one person can look into the problem while the other continues with the test assignment. When the problem is solved, they inform each other about what happened and continue their work as a pair. There is a quick alignment and easy knowledge transfer, and the specifics of the application are always covered.

Guided Learning

In some situations, there is a clear distinction between roles in pair testing. The pair can consist of a junior and a senior tester, with the senior tester acting as a mentor, teaching the junior. The junior executes the test as the senior observes and guides, from time to time asking clarifying questions to ensure the junior understands what they’re doing.

This also works for introducing a new colleague to the application. A new tester can be paired with a subject matter expert to observe testing, with the subject matter expert explaining how the application works and what it can do. The new colleague can ask questions and be sure they understand the product before working on their own.

I currently work on a Scrum team as the only tester. When it is my team's turn to execute the regression testing of the application, I visit my colleague testers on other teams to see if the features they worked on are part of the regression test. If so, we do some pair testing together to transfer knowledge, so I can learn how the features are supposed to work.

Better Bug Investigation

Sometimes you run into a problem that is hard to investigate. You see some weird behavior in the application under test, but you can’t figure out what is wrong. 

Help can come from another tester, a business analyst, a solution designer, or even a developer. Together you replay the error scenario and investigate the problem, then test with other input or data to see if there are more problems, which can result in a bug report. You may not have thought about it, but this is actually pair testing.

Once I was testing a feature and could not execute a request to the back-end system. I asked the tester who worked on that feature to help me. While testing, we found out that there was a serious issue with the back end. They forgot to implement an extra parameter while the front-end applicator was in a newly introduced state. By pairing, we were able to investigate and resolve the bug quicker and more thoroughly than I would have been able to by myself.

Thorough Test Preparation

Testing an application requires preparation, and working in a pair sets you up for success.

When working on test design as a pair, I recommend you read the documentation about the application separately, then have a brainstorm session together about what you read. Make a list with risks as you identify them, then create a mind map of areas to cover that are related to the identified risks. Together you can come up with questions to help you get more clarification on the risks and create test ideas to be executed to gather information.

The discussions you have will create a flow of thoughts you wouldn’t get when working alone.

A Way to Stay Focused

As a single tester, you can get easily distracted by your surroundings and lose focus from the work you’re supposed to do. When you are working as a pair, there is more focus on the assignment. If one person’s mind starts to wander, the other one will get them back on track.

Distractions also can be work-related, and when that happens, the distractions must be dealt with. Pairing can help in this situation, too. If you need to stop work in order to pay attention to an urgent problem, when you’re done and can return to the original assignment, your tester colleague can bring you up to speed with the latest activities and information.

Give Pair Testing a Try

Working as a pair does mean that there sometimes will be logistical issues. A simple example is that one person could start work early in the morning so they can leave early, but the other person may prefer working later hours.

This doesn’t have to throw off your pair testing, though. The early person can start with some preparation of the test ideas to be investigated. Then, they can work on the prepared ideas together. The late person can finish up by completing the test reports and filing the remaining bugs that have been found. No one has to be inconvenienced; it just requires some coordination.

Pair testing can be done with various disciplines within the software development lifecycle. It has many advantages, both for the quality of the product and the benefit of the testers, and it doesn’t require any special training. You only need two brains and two pairs of eyes. The rest will follow as you organize your work.

User Comments

Xander Bartels's picture

I totally agree that pair testing or pair testing/development  is very benifitial. However, It doesn't mean that it should be a complete working day, so I don't think that there are logistical issues when the ppl are part of the same (scrum / agile) team.


It is excellent way to transfer knowledge and it is benificial towards the future.

February 5, 2018 - 1:42am
Ralph Fisher's picture

Excellently argued and well written!

If I'm doing Exploratory Testing with another tester, or prgrammer, I like to time-box the activity to at most a couple of hours to avoid fatigue. What¡s your opinion Simon?

April 17, 2019 - 2:07am
Simon Schrijver's picture


Thanks for you feedback. For you Exploratory Test(ET), you need to work in session as we call that in ET. A certain amount of time where you do a deep coverage of the problem you are investigating or the test that you are executing. We call this Session Based Exploratory Testing. For more information, check out my blogs on

April 18, 2019 - 2:24pm

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.