In March 2020, I was fortunate to go Ministry of Testing Brighton. One of my favourite talk on that day was by Lisi Hocke. Who spoke about her testing tour. Before that, I have never thought about pair testing with people. Just tend to dig in take the information in and start testing, when I have questions then I ask and boom back testing.
After the talk, I started looking into part testing and how I can utilise it to improve my test automation skills. Before digging into how I implemented this, let’s talk about pair testing first. I am sure you’ve heard of pair programming and mob programming before? This is similar to pair testing. I should probably say pair testing is the cousin of pair programming. Yope I know, I got jokes lol
Pair testing was defined on Wikipedia as a software development technique in which two team members work together on one keyboard to test the software application. One does the testing and the other analyses or reviews the testing. Remember the saying “two heads is better than one” (C.S. Lewis) .Yope in pair testing two heads might better than one as well.
Pair testing is a collaborative effort, versus a single-person testing effort. Typically one of the team member is a tester and the other is either a tester, a developer, business analyst or a product owner. But good luck with pairing with a product owner, he/she might be too busy for you.
So now that we know what pair testing is. What type or style of pair testing can we do?
Types of pair testing
There are two significant style pf pairing; one traditional and the other strong-style (Maaret Pyhäjärvi, 2018).
In traditional pairing, a second person is introduced and the work to do is split. Roles are introduced and rotated, either on task or on timer. The work is split so that whoever is on the keyboard is in control of the test session. The individual on the keyboard has the ideas, and focuses on the tactical implementation of those ideas. The other one thinks more strategic and take notes/ write down ideas. It is often suggested that the person on the keyboard should think out loud to allow others know what’s going on in the testers head. You just don’t want to sit there testing and no conversation. That might be a little bit boring for everyone; just saying.
The downside of this style is that the one without the keyboard is continuously translating what he/she is observing from the other’s testing, building assumptions. It might be difficult to actually see what’s going on, which might easily create a bit of disconcertion in the pair. This might even get worse as the watcher might end up zoning out and stop paying attention. Thus, leading to notes not matching up with the testing that was done. Then you go one and end up hating each other (joke).
In strong-style paring, we split the differently compared to traditional style. The one who is not on the keyboard is now the one with the idea. They must vocalised the idea for the one on the keyboard to action. The one on the keyboard ask for clarification when/if needed and can challenge the direction, also suggest ideas and ask questions. However, the decision is on the one without the keyboard. Notes are taken on the same computer, representing ideas and initiated by the person not on the keyboard. As these notes are typed and reviewed, they become a shared representation of the idea.
One of the advantage of this style of paring is that the one without the keyboard must vocalise all their ideas. This then creates a strong connection in the pair. Apparently speaking about what you want to happen on a keyboard is a skill of its own. Damn, who knew? In addition, it takes a bit of practice to get used to.
Now let’s discuss another form of pair testing. Mob testing
Strong-style pairing is the foundation of mob testing. In this style, we have group of people working on one task, taking turns on the computer. Ideas come from the crowd not on the computer. The aim is to get the best out of people into the work we are doing. Everyone takes turns at the keyboard, and if you someone unequal at task, this helps out navigating at an appropriate level of abstraction.
Advantages of Pair Testing
1. It helps transfer knowledge. New information, ideas, perspectives are shared and discovered.
2. It tends to promote negative testing. Like when paring with engineer, it is not common to only code for happy path. Pairing ensure more angles are covered.
3. It can save time. For example pair test session with a developer, it is very easy and quick to pair the programme under test with the developer. The developer might be able to pin point the big quicker as he/she is more familiar with the code and framework. At least I hope so, or else you are both screwed.
4. Pair testing is fun and build culture
5. It can also be used as an opportunity to train new employees
6. Finally, it can improve continuous testing within teams.
How I implemented pair testing
One of the first thing I did when I got back from Ministry of Testing Brighton was to pair with the Python Developer in my team. He worked on a withdrawal logging service that I was meant to test. However, then I was not familiar with services logs. Asked when he was free for few minutes for discussion and you know I am a very nice person, people tend to say yes to me. He came, sat with me and we went through the scenarios and boom we starting tailing the shit of the withdrawal service. Using stuffs like `tail -f`, `tail -n` and now I can say and pro in tailing stuffs.
The second time I paired was with a tester. Then, the finance payment integration tests was confusing to me. I paired with a principle tester who worked me through the framework, how the tests are called, the helpers and what some of the tests were doing. I won’t say I am pro in finance payment tests but after that I understood what was going.
I hope with this, you will go on and start pairing with developers, other testers and business analyst. Happy pair testing.