Pair testing can help you speed up your test assignment and provide more quality to your test results. But who can do pair testing, and when should they do it? And what kind of pair testing is best for your situation?

This article gives you more information about how you should conduct pair testing in order to maximize its benefits.

Who Can Do Pair Testing

Pair testing with a developer or with another tester happens quite often, but note that these are not the only disciplines that can do it.

A documentation writer can approach the tester to get information on what will be in the next release of the application. The tester will then guide the documentation writer through the new features and provide the needed documentation for the next release.

A customer can come up with an issue that needs to be investigated. Together with the customer, the tester will replay the error scenario to see what is going on.

And a business analyst or a solution designer can pay the tester a visit just to go through the feature. While doing some checks at a certain moment, they may raise the question, “What happens if you do this?” Some serious exploratory test starts here, and the tester may find some bugs.

I’ve even heard about a well-known tester who had to take his son with him on an emergency assignment in another part of the country. While his son was sitting next to him, he asked his son to take over the keyboard and help with the testing work. The kid found some cool bugs.

I do pair testing with all the members of my Scrum team—with the developers on investigating bugs, with the solution designer to check out some behaviors of the feature, with the business analyst to show how the new feature is working, and with the visual designer to see how the user interfaces look in relation to what we expected.

You can do pair testing with almost everybody. Once I was discussing a situation with my delivery manager about an issue within the application. I too saw this problem, but I could not get a grip on it. While evaluating the situation and doing some pair testing with the delivery manager, it came to me: A feature I was working on seemed to interfere, under certain conditions, in that part of the application. This turned out to be a showstopper, and an immediate fix was needed for a back-end system to solve that problem. I eventually may have worked out the problem on my own, but pairing helped us find it faster.

When to Do Pair Testing

I often have short pair test sessions with the members of my Scrum team. These happen throughout the software development lifecycle, either in one sprint or several sprints.

You also can use pair testing as a learning opportunity, such as bringing a new colleague or a junior tester up to speed on the application by doing some testing together. 

Support for or from other roles can end in a pair testing session, too. You may ask a designer some questions about how a feature will work while you are going through some documentation, and before you know it, you’re working together at a whiteboard, discussing various scenarios related to the feature. From another point of view, the business analyst may come to you to ask how exactly the feature is working, and you end up doing a pair testing session to see if the feature can be enhanced.

Pair testing also can be done when a problem needs to be investigated. You can go to another team member (either a tester or someone else) for advice, or you may be asked by a customer support agent to look into a customer problem.

These are all great opportunities for pair testing, but it also can happen without your even noticing it.

I do some pair testing on a regular basis with my business analyst. Together we test some feature tags to see if the analytics are working, and I execute the test while the business analyst checks the data.

How to Do Pair Testing

Pair testing can happen spontaneously, even by accident, or you can take a predefined approach. Therefore I make a distinction between two types of pair testing: active pair testing and implicit pair testing.

In active pair testing, you define the preparation up front for the test work you’ll do. You make time for it as you plan it and as you execute your test ideas. You’ll sit together for an agreed-upon time period and do some exploration. Everything is predefined, and both parties are actively making an effort to pair test.

Then there are the situations when pair testing just happens.

While investigating a problem, you get stuck and ask a coworker for some help. While you’re working together and coming up with new things to test, working with different test data, you come find the cause of the problem. That was some unplanned pair testing.

Then your colleague from operations comes to your desk to ask how the new flow of a certain feature is going to work. While you explain this to him, he starts to ask questions. You can answer most of them, but then he asks about a situation that didn’t occur to you. Huh? That is a bug. Thanks for doing some testing with me.

As you are preparing for a business trip or a holiday break, you go to a colleague to explain what has been done and what is still left to do. When you come back from the trip, you go to this colleague and she tells you what has been covered and what she found. Even this is pairing.

Looking at these situations, you can see that pair testing just happened. You walked over to a person or somebody comes to your desk, and before you know it, you have done some pair testing together. I call this implicit pair testing.

If you want to actively start doing some pair testing, the best thing to do is team up with a colleague you trust who buys into the concept. Together you can determine the focus and scope of the pair testing session.

Plan the work for your pair testing up front. Set up the environment where you can test together without any problems—this means a desk, tools to work with the application, and a time window where you can work together, uninterrupted. You can do this with manager approval, or just take the initiative on your own. Evaluate the outcome and present it to your stakeholders.

Pair Testing versus Pair Programming

If a developer is asking to look into a feature and see how it works, you can end up in a session where some code is rewritten or even new code is created. In this situation you are pair programming. The outcome of the pair session is new or changed code, and the developer is the person in control.

When you ask a developer to look into an issue you have encountered in his code, you’re determining together if this is just a test error or a real problem. In this situation you are pair testing. The outcome of the pair session is information about whether the issue is a bug, and the tester is the person in control.

When you and a developer are doing automation together, one moment you are pair testing and the next moment you are pair programming. Sometimes you may not even notice the change.

I work with my developers on a regular basis. Together we write code to support our testing, such as unit tests, UI tests, end-to-end, and regression tests. We both execute these tests to see if they work. The tests I created for automation are code-reviewed by the developers to see if improvements are needed, and sometimes we refactor them directly when we have our pair session.

The Results of Pair Testing

To make pair testing a success, you have to deliver some tangible result. There can be several outputs:

• Test documentation: While you are doing test preparation, you’ll generate some documentation. The two main documents that will come out of this are a test plan and a set of test ideas to support your execution.
• Defect reports: While investigating an issue with a developer or a customer, you may realize that it’s a bug that’s causing a real problem. The defect report you write will get it solved.
• Session reports: When executing tests as a pair, one is driving and the other is taking notes. It’s a good idea to write down these notes in such a way that the information is transferable to other team members or stakeholders.
• Shared knowledge: While shared knowledge is not recognized as tangible output, I think it’s important to mention it as an outcome. Pairing means there are two experts on the subject who worked together on a test, so you eliminate the situation of a single point of failure, providing more confidence in your tests.
• Information for stakeholders: Information can be the test plan you have written, the tests you did based on your test ideas, or everything documented in your session reports. Information can also be the bugs you found, reported, and retested. All this information is valuable to stakeholders because it advises them about how to proceed.
• Tests being automated: A test created and automated together with your developer will be added to the regression test suite. These new tests will relieve you form the repetitive regression test work and make it possible to focus on real problems.

In my day-to-day work, I do pair testing with colleagues from my Scrum team on a regular basis. Some sessions are short, minutes to an hour, and some are longer, up to a day. Sometimes it is planned, and sometimes it’s spontaneous.

Pair testing works best in an environment where there is room for exploration, thinking, and being creative. You don’t need to predefine test scripts. You don’t need a UI as a starting point to test. All you need are two people who think critically—a creative person and a disruptive person. After all, two heads are better than one.