Practical tips for pairing with a developer to test

Pairing is seen to be a popular way of working with software. The two common types of pairing are “pair programming” and “pair testing”. In both examples I think of the words “programming” and “testing” to refer to activities rather than roles. This means anyone can take part in these pairs. In my experience pair testing works well with two testers but also with a tester and a developer.

James Bach and Cem Kaner explain pair testing as:

“Pair testing is different from many other kinds of pair work because testing is an *idea generation activity* rather than a plan implementation activity. Testing is a heuristic search of an open-ended and multi- dimensional space. Pairing has the effect of forcing each tester to explain ideas and react to ideas. When one tester must phrase his thoughts to another tester, that simple process of phrasing seems to bring the ideas into better focus and naturally triggers more ideas. If faithfully performed, we believe this will result in more and better ideas that inform the tests.”[1]

Pairing with a developer to test is a great way to learn about a product, resolve bugs quickly, generate test ideas and a great opportunity to increase testability.

When originally working in cross functional agile teams I found it difficult to identify how to approach pairing with developers. All too often, developers and testers worked in silos waiting for the code to be moved to the “Ready for Testing” column on the Task board[2]. On the occasions i attempted to work more closely with developers it was hard to keep the conversation going more than a few minutes.

One “tool” I’ve found incredibly useful to aid pair testing sessions with developers is the debugger built into most development IDE’s such as Visual Studio[3] or Eclipse[4].

When coding a feature developers will use the debug capability to do just that, debug their code to check its doing what they expect and track any exceptions that may occur.

When it comes to pair testing with a developer our context will be slightly different. We are less concerned with “debugging” the code and more concerned with using the “debugger” as a tool to support testing. It is a great way to observe and control the application during testing.

The benefit of using this tool is that it facilitates the discussion between the developer and the tester. Ask the developer to “step through the code” using the debugger and explain as he goes. Don’t worry if you can’t code, the objective here, as I said earlier, is not to debug the code but to test. As the developer is talking through the code, ask questions, observe patterns within the code, and listen carefully to what he says and how he says it. As the debugger allows you to control the code it’s great for those moments when you ask the question “What If?”, “Can you show me?”, “Hold on a second.” It means as a pair you can explore those questions easily with complete control over the code going back and forth as you please. Don’t expect answers to all your questions and don’t dwell too much on a single point. Take diligent notes and return to these later in the session or in a following pair session.

Having the ability to stop at points in the code also enables the developer to point out important parts of the code. For example parts that directly relate to the Acceptance Criteria of a Story such as a calculation algorithm.

To support this conversation ask about Unit Tests that have been written to check the code. Ask the developer to step into the unit tests and explain what has and also importantly hasn’t been unit tested.

The joy of pairing also means a quick fix and retest process. It’s possible for simple bugs to be fixed there and then with more complex bugs can be recorded ready for the fix to be explored in your next pair session. Getting familiar with the debug process enables you to also debug through the code should you find any bugs. For many issues exceptions will be thrown by the application so you can point these out to the developer should you find an issue. If your comfortable with code, you could even code up a fix and review it with your developer.

Another good output from this pairing session is ideas for exploratory testing sessions. You can ask the developer areas he’s perhaps uncomfortable with and in many cases I’ve found developers more than forthcoming with that information. During your pairing its natural for there to be some areas your not entirely comfortable with and the gut instinct will kick in. As the story matures towards “Done” you may find your pairing sessions move away from the debug tool and become more exploratory in nature.

It’s important to pair throughout the story, not just at the end. Find a balance that works for your team. The developers within my current team are good because they will shout once when they need me and on the flip side are open to me approaching if I want to pair up. Alternative approaches are to schedule calendar reminders at the start/end of each day or after lunch, this might support testers in large development teams. Pairing frequently means that you will gradually take bites of the story rather than being overwhelmed at the end. Bringing questions or bugs you’ve observed in your own testing also helps kick start the next pairing session. Getting access to the application code and being able to run it locally will help you prepare for your next session. It will also help you get more familiar with the capabilities of the development IDE.

Another good benefit of pairing is testability. Explaining how you’d like to control and observe the application allows you to directly influence the design of the code. Maybe you’d like the logging to be improved, maybe a different kind of variable to be used that’s better for automated checks, or maybe you need a method to tear down data. These are examples of Intrinsic Testability and James Bach explains there are other forms of Testability[5]. In my experience many of these are emphasised through pairing:

Intrinsic Testability – “If we hadn’t agreed during our pairing to put in extra logging we may never have noticed it”

Project Related Testability – “Having the developer explain areas he wasn’t too comfortable with and couldn’t Unit Test helped us really focus our exploratory testing charters in those areas.”

Value Related Testability -“Through our pairing we have built a strong rapport and we are comfortable asking each other challenging questions or constructive feedback”

Subjective Testability – “Now I know how to run the application locally I can debug through the code and provide more technical information about where the code might be going wrong. I sometimes even feel comfortable coding a fix.”

So in summary, pairing with a developer is a really effective way of testing. Use the tools available such as the debugger as a way to facilitate the conversation between yourself and the developer. As your relationship grows you’ll find your sessions become more efficient allowing for more time to be spent on the complex and complicated areas.

[1] Exploratory Testing in Pairs – http://www.kaner.com/pdfs/exptest.pdf

[2] I’ve found that when teams have “testing” columns on task boards it encourages developers and testers to work in silos. I personally prefer To Do – In Progress – Done.

[3] Debugging in Visual Studio – http://msdn.microsoft.com/en-gb/library/sc65sadd.aspx

[4] Debugging in Eclipse – http://www.eclipse.org/jetty/documentation/current/debugging-with-eclipse.html

[5] Heuristics of Software Testability – http://www.satisfice.com/tools/testable.pdf