What is pair testing? It’s exactly what it sounds like — two people on the same machine, trying to complete a test together.

On today’s show, Katrina Clokie shares with us all the benefits her organization has enjoyed since starting pair testing, as well as how it’s helping to change culture through testing. If your Agile sprint teams are struggling with testing, you won’t want to miss this episode.

About Katrina Clokie

Katrina Clokie serves a team of more than 30 testers as a Testing Coach in Wellington, New Zealand. She is an active contributor to the international testing community as the editor of Testing Trapeze magazine, a mentor with Speak Easy, a co-founder of her local testing MeetUp WeTest Workshops, an international conference speaker, frequent blogger and tweeter.

Quotes & Insights from this Test Talk

• Pair testing is exactly what it sounds like, it’s two people on the same machine, trying to complete a testing test together. The difference for me between two people working together and two people pairing is that paring, you are both active on the problem at the same time. It’s not like asking someone over to help you do something. It’s like saying, “Okay, I have this task, will you come and sit with me the whole way through this? We can take turns at being the person driving this activity. I want your ideas. We can do this whole thing together.”
• It’s about cross-pollination of skills, but it’s actually cross-pollination between our testers. The 30 testers that I work with are spread across 18 different agile teams. Those 18 teams are working with maybe five or six different products. Even though the testers are all in the same department, a tester in one team has quite a different experience from someone in another team, like they’re working on different platforms, different approaches, different tools.2
• One person comes out of their team and into another team and that team effectively has two testers for an hour, but then the flip side is that that person from that team would then go back with the other tester and that other team would have two testers for an hour. There’s not really a change in resourcing or an impact to the project, it’s just like shuffling a person across and then shuffling the other person across. That was my pitch on explaining it to managers that these people are still actively working on their projects, we’re just moving in a person to essentially help them and learn from for an hour and then vice versa. That wasn’t a particularly difficult sell in the end.
• I think the biggest success stories have probably been in tooling. When I say tools, I’m not talking about automation specific tools — I’m talking about things like Chrome extensions or screenshot tools, where people use them without thinking and someone new will come along and say, “Whoa, what did you just do, how did you do that so fast, like what is that thing?” A lot of those sort of tools have cross-pollinated across the teams through this and really helped to make our testing a bit more efficient. Yeah, I think with the benefits have been around getting a broader scope of thinking for people, giving them some confidence that their approach is aligned with the approaches of other teams and exposing them to new ideas about tools.
• I hadn’t really thought about transformation in that way before like it was a really, I had always thought, “Just stop doing it that way and do it this way,” like how hard can it be, somewhat flippantly. When I started thinking about it as a cultural shift, I think it gives me more empathy for what those people might be going through when you say, “Now is the time to transform the way you work,” that’s not just a challenge to your role. It’s a challenge to their identity and the way that I enjoy interacting with people as well I think.
• I think the biggest difference I see between testers and the results that they achieve is based on how many conversations they have with the people around them. Even if you’re the most awesomest tester ever, if you’re not talking to your developers and your product owners and your business analysts about what they’re doing and why, your testing is less effective because you haven’t taken input about what other people have already tested, why the thing was designed the way it was, how the customers are expecting this thing to behave, what information from testing will be valuable? Without having those conversations, you increase the risk that you will end up delivering stuff from testing that people find irrelevant.

[tweet_box design=”default”]Biggest diff @katrina_tester sees between #testers & results achieved is based on how many conversations they have http://testtalks.com/111 [/tweet_box]

Connect with Katrina Clokie

• Twitter: @katrina_tester
• Blog: Katrina the Tester

May I Ask You For a Favor?

Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.

Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.

Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!