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:
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:
Set up a Pair Testing environment
To allow good PT you need to set up a good environment.
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”.
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.
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.