Pair Testing

July 12, 2008 — agile, blog, testing

Introduction
This is an article about pair testing, maybe I going to create a presentation based on this articile. If you have any comments or remarks please let me know. Please also take a look at the sources at the end of the article, I have used their knowledge and opinions to form my own opinion and view on pair testing.

At our development department we use Scrum as a development framework. Scrum is an agile framework. Exploratory Testing (ET) and Pair Programming (PP) are often used in Agile environments. If you combine those techniques it results into Pair Testing (PT).

In this article I would like to explain to you what Pair Testing is. The article is intended for people who would like to start with Pair Testing or who are just interested in Pair Testing.

What is Pair Testing
Pair Testing is testing of software by two team members sitting behind one machine. One team member is in control of the mouse and keyboard, the other one is making notes, discussing the test scenarios and asking questions. One of the two should be a tester and the other one could be a developer or business analyst.

PT is not intended to execute formal test cases, PT uses Exploratory Testing. I will not cover ET in depth in this article. ET is an informal test technique and requires extensive test experience and/or good knowledge of the software under test (SUT). When you pair a developer or business analyst and a tester, you have test knowledge and knowledge of SUT.

Pair Programming is a common practice in Extreme Programming. Pair Programming is experienced as a good approach for programming software. Pair Testing is a similar technique for testing software.

If you use PT, both team members should be equal. It should not be that the senior team member is using the junior team member as a scribe. The team members should work together and actively contribute to the PT session.

Why use Pair Testing
Pair Testing has some clear advantages above normal ET. The advantages are:

1. Developer or business analysts approach the software from a different view. They think in good paths, for example “I have to create an address and edit the fields.” The testers will also look at the exceptions, for example “What happens when I create an address and press cancel instead of save…”
2. When PT is executed with a business analyst their will be automatically knowledge sharing between the business analyst and tester. The business analyst will share his knowledge of the application of business with the testers during the session.
3. If a new project is started with new team members who are new to agile development their will be often a barrier between testers and developers. By using PT the team members will work closely together and get to know each other better.
4. Working in Pairs keeps you sharp, you can not doze off. You will keep each other sharp.
5. If you find problems and decide to register them in a bug registration system, the problem is automatically reviewed. You work in pairs, so the data you entered is immediately reviewed by the other one.
6. As a tester you will encounter mysterious bugs that seem to occur at random. In a PT session with a developer you could find a pattern and thereby the cause of the bug. The developer will probably see the link between the problems because he has knowledge of the software framework.
7. The last reason to use PT is maybe the most important one: It is fun, working together with team members is fun.

When not use Pair Testing
If you don’t have set up the right conditions for PT you should not start using it. However, there are some circumstances that you could better not use PT even if the right conditions are set.

Do not use Pair Testing when:

1. All executed test should be automated. The result of PT is findings and no test cases. You can not use the output of a PT session directly for test automation. This problem also occurs when you use ET as a single tester.
2. Team members can not work together. If you have two team members who can not work together because their characters clash you should not use PT. The team members must be able to communicate well and work together without quarrels.
3. If you are only going to execute structured test cases. It does not add any value execute the test cases together. This kind of tasks can be done by one team member alone.
4. The SUT does not allow PT. Imagine a batch operation that runs for one hour and the result is comparing output data with an excel sheet. This kind of work can also be done by a team member alone.

Set up a Pair Testing environment
To allow good PT you need to set up a good environment.

1. The team members should work voluntarily together. It will not work to force cooperation so a Test manager, Scrum Master, Test lead, etc. you should create an atmosphere that team members are willing to work together.
2. A room or desk where the team members can work undisturbed. Two team members working together should not imply twice as much disruption ;). So for example switch of mobile phones and close the email application.
3. The workplace should support two people sitting behind one desk. You can not ask people to work together if there is no room behind the desk for two chairs.

Prepare Pair Testing Session
It is necessary to do preparation before the PT session starts. Most of the preparation is because you use ET, for more details Google “ET”.

1. Create an ET Charter
2. Define the focus and scope of the test.
3. Describe the targets for the test.
4. Agree together how much time you are going to test, it should be time boxed. Normally you have a session of 60 till 90 minutes. Do not forget to plan a break!
5. Plan the meeting in for example Outlook.

Executing Pair Testing Session
During the session the team members decide which test paths and how deeply the test will be. This should be of course in line with the targets, focus and scope of the tests described in the ET Charter.

One team member (the Driver) should be in control of the keyboard and mouse. The second team member thinks out-loud, asks questions, makes notes on paper and gets the coffee.

A PT session lasts for about 60 till 90 minutes, and don’t forget the break.

Finishing Pair Testing
After the PT session the findings will be added to the bug registration system, if necessary and not yet done. The ET Charter will be updated, which test targets are tested, which problems were found and other remarks if necessary.

A part of the ET Charter is also a short evaluation of the PT session, what went well and things that could be improved next time.

If during the PT session new test targets were found, a new PT session should be planned. The pair could even already create a new ET Charter for that session.

Conclusion
Is Pair Testing rocket science? No, it is a combination of working together and testing. However, it has a lot advantages above “single” testing. There will be knowledge sharing (about testing and the SUT), train new team members, break down barriers between team members and most important it is fun!

Be aware that you not always could and should use Pair Testing, use it when possible and use it wisely.

Sources

• Pair Testing: How I Brought Developers into the Test Lab – Jonathan Kohl – Better Software January 2004
• Exploratory Testing in Pairs – Cem Kaner/James Bach – StarWest 2001
• Pair Testing version 0.3 draft – Brian Marick – 2001
• Exploring Exploratory Testing – Andy Tinkham/Cem Kaner – StarEast 2003