Pairing For Learning – Across the Team

I’ve written a lot about pairing over the years, most recently about strong-style pairing with others on my team. Pairing is an excellent way to transfer skills, it offers a lot of advantages for overcoming cognitive biases when testing, and it’s just plain fun.

For most of the 4.5 years I’ve been on my current team, I haven’t been able to pair with developers as much as I would like. For one thing, the developers pair with each other 100% of the time. Also, I suspect that the dev managers worried that testers will slow their developers down even if they’re soloing because the pod is odd that day.

Fortunately, the development managers also understand the value of exploratory testing, and want developers to improve their ET skills. I’ve written about ways we have helped non-testing team members learn exploratory testing skills. The workshops and other efforts helped, but developers felt they needed to learn more. Our team is moving towards continuous delivery, and the managers feel that developers need to step up their exploratory testing at the story level to mitigate the risk of bad issues getting out in production. Our team embarked on an experiment: each tester should pair with a developer at least one day a week.

Experiment underway

Squeal! I get to pair not only with other testers, product managers and designers, but also with developers. Our team is divided into several vertical “pods”, and as we are so few testers, each of us has to help on two or more pods. I was pleasantly surprised that “my” pods embraced this experiment from the start. It also happened that for various reasons, my pods were “odd”, there was one developer each day who would have to solo. Instead of solo-ing, they paired with me! Not only were they ok with this, they were actually eager to do it. One day recently, two pods were vying to have me pair with a dev!

The main intent of the experiment was to help devs learn how to write exploratory testing charters and execute exploratory testing. In practice, this has meant everything from writing charters, doing ET charters, and simply working on stories.

Doing exploratory testing activities together has the expected benefits. The devs learn good techniques for writing charters (we use Elisabeth Hendrickson’s template from her book Explore It! ), useful exploring resources such as personas and heuristics, the importance of reporting what testing they did and what they learned. I think that we testers help the devs think beyond the happy path.

Pairing on “production code” too!

I’ve found pairing on story work surprisingly valuable. For one thing, I have new insight into what the developers’ job is like – it’s not easy! I get to watch them test-drive their code (they do offer to let me drive, but they are so freaking fast in their IDEs, I don’t know all those shortcuts! But I will work up the nerve eventually!) and they explain their thought process as they go. I’m learning a lot about our app’s architecture and reasons behind behavior I observe in testing, such as performance issues. As they write unit tests, I might suggest another test case, and hear “Oh, good, I didn’t think of that!” Or I might ask why a particular test is using double negatives (one of my pet peeves), and that turns out to be a helpful suggestion.

My patient teammates transfer lots of their skills to me. I’ve learned some new git parameters, I’ve learned a lot about using browser dev tools to debug CSS and other valuable activities, I’ve learned a little about BEM. I’m being exposed to lots of new things that help me understand our coding standards and process better, which I think will help me do a better job of testing.

Our app is mostly Rails and JS, but the team is also starting to code some pages in Elm. Pairing with a dev writing Elm code was rather mind-bending. Elm code prevents runtime exceptions by detecting issues during compilation and giving friendly hints on how to correct them.

We are fortunate that our developers pair at least 7 hours a day. We have pair workstations, each fitted out with an iMac, a 27″ Thunderbolt monitor, with mirrored displays, two keyboards and two mice. People move around every day, so if they have their own favorite keyboard and/or mouse they just carry it with them. This makes pairing comfortable – no craning your neck to see what the other person is doing, no weird personal space issues. If your work area doesn’t have comfortable pair workstations, see if you can set up at least one pairing area that pairs can use.

Good for what ails you

I’ve always been a fan of pairing, though I also am subject to the same impediments I hear other people cite. “We have too much work to do, we should divide and conquer”. “I will slow that person down too much because she’ll have to explain everything to me.” “My true nature of being an imposter will be exposed.” When I can overcome those excuses, I find pairing powerful for so many purposes.

Are you a tester on a team where the programmers are using poor coding practices and throwing code over the wall, expecting you to find all the bugs? Find the friendliest programmer, work up your courage, and go ask her if she will pair with you for an hour to test a feature, or write automated tests. Whatever success that brings, keep building on it. You will start building relationships that will let you get your whole delivery team engaged in solving testing problems.

If, like me, you find it hard to stop the merry-go-round of daily routine and make time to pair, put it on the calendar. Pick one day a week to pair with a tester, coder, designer, PO, BA, whomever. Once when another tester and I were finding it hard to make time for pairing, we added a daily one-hour meeting to our calendars and stuck to it as much as possible (I blogged about that experience too). I’ve also paired with total strangers who volunteered to pair with me via Twitter, with terrific results!

Take a baby step, pair with someone for an hour today. At the end of your hour, do a mini-retrospective together to discuss the benefits and disadvantages you experienced. Keep iterating and see if the benefits outweigh the downsides. (When I really do pair – I find no downsides). It’s a great way to learn!