Communication avenues to pairing opportunities

Recently I reread ‘The Power Of Pairing’ by Mike Talks (TestSheepNZ), as part of a ‘blog club’ I facilitated with the Trade Me testers.

It’s about the 5^th time I've read this blog post (and it won’t be the last) as pairing is something I’m a huge fan of. I definitely exercised facilitator’s favoritism when picking this blog for blog club.

That said, traditional pairing is not something we ‘actively do’ as Testers at Trade Me. As test managers, I don’t tell testers they should be pairing. I tell them all the benefits and positive outcomes I think pairing would have, but let them decide if they’re going to give it a go.
This said, I think that a lot of the interactions we have as Testers can be looked at as being pairing.

Without putting to a ridged definition on pairing, to me you’re pairing if you’re working alongside someone else in order to create something, exchanging information and learning's. The thing being created could be a project, an artifact, or an approach. 

That exchange of information comes down to communication – and that is something we do actively encourage, facilitate, and push people to do by providing avenues for good communication.
I wanted to share my thoughts on some of these communication avenues, how they lead to pairing opportunities, and how I think it makes our testing (and development) better.

Proximity

When I started at Trade Me, you sat with your functional group; meaning all of our developers sat together, and all of our testers sat together. This was great for within-discipline communication. Practices, processes, and technical understanding was easily shared and picked up when you joined the team.
The seating arrangement encouraged communication with fellow testers. It was really easy to lean over to a tester at the desk next to and chat to them.

Most of the time you were looking for information, knowledge that tester has which you might not have. Testers would exchange information, affirm or discount assumptions, and bounce ideas around on test coverage and a test approach.
You could look at this as being a type of micro-pairing. You’re developing a test approach together, and drawing two minds onto an activity.

On the flip side, this seating arrangement did hinder the same type of casual communication with developers.
To communicate with the developer you either sent an IM or email asking for time to sit with them, or you walked over to their desk and hoped you were catching them at a good time.

This was before we adopted Agile and Scrum at Trade Me, but even then, ninety nine percent of the time you would be testing solo on a change from a particular developer. These developers are giant oracles which testers should be tapping in to, but often the effort of communication got in the way.

Developers work hard at their jobs and in my experience like to be perfectionists. If you did get a pairing session with the developers, it would often just be a walk through of code which has been written.
As Mike says in his blog “If you're sitting with someone, and one of you is controlling all the conversation for the whole session, then you are not pairing.”
Walk throughs can be great at giving a tester insight into what vulnerabilities might exist, or what type of data to focus on. They can still add value.
But, the developer will (hopefully) be confident in what they've built and won’t be naturally looking for gaps in their own knowledge.

We adopted Agile about two years ago, and with this we collocated our scrum teams (we call them ‘squads’). As you’d expect we saw a massive upswing in casual communication between testers and developers.
Because this communication avenue is now open throughout the development life cycle, there are consistent opportunities for Testers to get involved early.
I've seen this communication spawn pairing sessions between developers and programmers. While the Tester may not be able to pair-program, a session where both parties talk about what data exists, how it gets handled, and the way it could be tested counts as pairing in my book.

Developers have good feedback about the arrangement. They like having more information and perspectives on solutions. After all, their work going through test efficiently makes them look good too!

Initially testers were worried about being siloed and ‘far from’ other testers. The fear was that their easy communication avenue was being closed, and that it would be harder to learn from each other and get peer involvement.

This has happened to some degree, but not to the extremes we were worried about. We've been quite lucky with the seating arrangement. You’re never more than two or three desks away from another tester.

Interruptability

I consciously make sure I’m accepting of interruptions, and I actively encourage our testers to be the same.
No one knows everything at Trade Me and making yourself and others available for communication opportunities is really important if you want to make sure that people have the information and support they need to do a good job.

One of the biggest challenges we've faced is that new testers didn't know we were accepting of interruptions.
When you’re starting in a new role, it’s really hard to know who you can approach and who you can ask for help.
We've had made sure that when we bring a new tester on board that we have a buddy available for them to ask questions. On the first few days that buddy should block out time to be free for interruptions, making them completely interruptable.
Encouraging new starters to interrupt you also means you get a great view on how quickly they’re picking things up, and where their knowledge gaps are.

These interruptions are great leadins for the micro-pairing I talked about above.
Just like Mike says in his blog, pairing has a great benefit to junior testers: "Putting them in the driving seat gives them the opportunity to take the initiative, and to explain their approach.  It allows you the opportunity to suggest additional tests they might want to consider, or give feedback about what tests might be more important to run first."

Agile

The Agile meetings and processes we follow are shining communication avenues filled with pairing and pairing opportunities.

Backlog grooming, planning poker and daily stand ups all give people the opportunity to share their perspectives, and give testers and developers the chance to work together to deliver a solution.

In a grooming session you’re pulling upcoming work to pieces, and digging into what’s involved in delivering it.

To me, this is pairing. People are in the right mind-set to learn, and are looking to exchange information. You’re not strictly pair-programming or pair-testing – but you’re working together to shape the coding and testing that will take place.

If you’re at a scrum stand-up, each person is communicating what they've done and plan to do. This communication leads you to great pairing opportunities!

“Hey, that sounds really interesting – I know some stuff about that from last time I tested it, can we pair together when you code the changes?” or “It sounds like you know about this area, can you pair with me when I’m planning the test approach?”

Feed-in, not Feedback.

No one person knows how every part of the Trade Me site works. There are definitely SMEs in the business, but there isn't one person or document which can give you all the information you’ll ever need.

Communication is one way to overcome this knowledge gap, and as a tester the more people you communicate with, the more perspectives you’ll have, and the higher the chance you’ll achieve a quality product.

From Mike' blog“…having an extra perspective allowed the person to question or state things, to bring them to the table for discussion, and thus expand on one persons perspective.”

Getting these perspectives early means they feed-in to your testing activities.

In the last three years we've scaled heavily, increasing the number of testers at Trade Me by 400%. On top of this, some of those are geographically isolated.

Knowing the knowledge gaps, and who to communicate or pair with became harder.

We needed a quicker and more accessible way to feed-in to each others work.

Enter test run reviews. Essentially; every test run a tester creates undergoes peer review.

(Worth noting: We write test runs, which for us are a collection of test conditions, a test approach, and a risk assessment)

This sounds like a normal bureaucratic test review process, but for us it’s far from a mindless box ticking exercise.

These test run reviews are a two way discussion which happens early in the life of the testing activities. The Tester can request a review as soon as they have an approach, mind map, or set of conditions.

The reviewer will question the approach, critique the test condition coverage, and look at the risk assessment. They’ll ask why things have been included or excluded, and make suggestions using their own perspectives.

The review itself is usually an email exchange, but I encourage reviews over the phone – or even better over the shoulder.

This communication and feed-in practice is a type of pairing. It lets experienced testers bring their perspectives to the table, promotes mutual learning, and means you’re working together to produce the testing activities that will take place.

We require that at least one review takes place by another tester, but there is no limit on the number of reviews or who reviews them. We encourage testers to seek out SMEs and get their input on approach and coverage. It can be as simple as asking “we’re changing this area, can you think of anything I might not have tested?”

One thing we’re looking at changing is how we treat new testers with regards to test run reviews and pairing.

At the moment, we don’t let testers do peer reviews until they've been at the company for six months. This isn't that we don’t think they’re good testers, it’s that we don’t want to add to the ‘system shock’ that comes from starting a new job in a new environment.

We’re missing the best type of perspectives – new perspectives.

I’m looking at doing is a “paired pairing”.  If a new starter wants to do a review in their first six months – they can, just make sure you pair with someone else while they do it.

How does it make our testing better?

So, at the top of this blog I said that I’d talk about how these communication avenues, and pairing opportunities make our testing (and development better).

The best example for me is that it removes so much fear of failure, which removes a blame culture.

Knowing that you've used those communication avenues and pairing opportunities, means you have confidence in your test coverage, development approach, and final product as you go into a deploy.

If something gets missed in development or testing, it’s not one person’s fault. You look for the missed communication avenues and pairing opportunities which could have helped, or, you create new ones.

The more avenues you open up, the more that will lead to pairing, and the better informed your perspectives become.