Often when we talk about “pairing,” we are referring to two people of the same discipline, either two programmers or two testers, working together. At the upcoming Agile Development Practices conference in Las Vegas, Dawn Cannan will be doing a session entitled, “Pair Development: How Programmers and Testers Benefit.”
SSQ contributor Chris McMahon talked to Cannan last month about her STAREAST presentation on
SSQ: By way of setting the context, what is "Pair Development" in a nutshell?
Dawn Cannan: Shannon and I chose the term "pair development" to mean something specific and particular. I have heard someone say that every team member is a "developer," because all the team members are involved in "developing the software" (to take it literally). We hear a lot in the software development world about "pair programming," and a little about "pair testing," but we think that one technique that doesn't get enough attention is pairing a tester with a programmer. As a technical tester who can read code, I've spent all of my testing career noticing that I get the most out of the times that I get to just sit with a programmer and walk through my questions and through the explanations of what the system is doing and why. I've seen first-hand that the insight I gain from doing this helps me test better, and that the programmer learns how I will test things and what I am looking for.
Even I am used to referring to the person who writes the production code as a "developer," and this semantic shift can be tricky. Shannon and I had to work pretty hard not to use the word “developer” when we mean “programmer,” but it is a distinction that makes a difference in this context.
SSQ: What are some examples of the benefits of tester/programmer pairing?
Cannan: The benefits of this paired development depend on the people and their skills, and on
other aspects of the system they are developing. Testers who have a traditional testing background
and are just learning to be more technical will learn a lot of technical details about the system.
Even a tester with technical prowess will be likely to learn things about the system they did not
previously know. For example, I have learned programming techniques that I have been able to apply
to writing automated tests during my time with people who program for a living. If the team also
pairs on testing tasks, like defining test cases, the programmer will learn earlier rather than
later what will be done to test the code. The programmer may have some insight into tests cases
that the tester hasn't thought about, and the programmer can be sure to cover the test cases before
the application ever sees a customer. But the most important outcome of paired development is a
shared language -- when
the testers and the developers are talking the same language, using the same words to describe
the same component or behavior, it prevents all kinds of wasted time.
SSQ: How much of each work day should be spent pairing like this? Are there certain activities where pairing provides more benefit and others where pairing provides less benefit?
Cannan: It's difficult to say how much of each day should be spent pairing, because there are many variables that will have an impact on how effective this technique is, and those will change over time. For example, I think a new team member may get more out of a lot of time pairing, as they learn the system and have an opportunity to ask questions along the way. I also recognize that some people have a harder time working so closely with another person for extended periods of time. I believe that the amount of time should be based on what works for both people, on that day, given their current needs.
There are tasks that I believe don't necessarily benefit from pairing. For example, if a tester and a programmer have gotten together to talk about which test cases should be covered in a set of developer-written tests (maybe unit tests, or integration tests), then it may not be productive to have the tester sit there and watch the programmer type the code that implements each of the test cases. However, I do believe that any task that involves investigating or learning is a great candidate for pairing. Determining test cases, walking through the details of a story and scoping the boundaries, and troubleshooting a bug are easy wins!
SSQ: Many teams like to switch pairs to make sure everyone on the team pairs with everyone else at some point, but some teams don't. What's your opinion on "promiscuous pairing"?
Cannan: I have been so excited to be able to participate in promiscuous pairing myself, and see a lot of great benefits from doing things that way. In my experience, the benefits of switching pairs outweighs the benefits of developing a deeper rhythm within a pair. When each person has a chance to pair with everybody else, the shared language that I described earlier spreads through the whole team. There are no little silos of pairs of people who refer to things differently than another pair. Changing pairs adds a freshness to work that we all need. Testers who work on different parts of the system at different times can also develop a deeper understanding of the impact of changes on other parts of the overall system. The only pitfall that I have seen is that between times that Tester A works on Part B of the system, Part B has been worked on and has changed, and it can be a bit confusing. Even this is alleviated if all members of the team are a part of reviewing all of the stories each sprint. Though my experience with "switching it up" is positive, I am sure that under certain conditions, it could be detrimental. So, again, and as always, do what works and is right for your pair, your team, your current process, your situation.
SSQ: Thanks Dawn! We’ll see you at Agile Development Practices West!
Dawn Cannan is the author of the blog “Confessions of a Passionate Tester.” She speaks and writes on software testing and development, test automation, and agile software development.