Testing in a Pair Programming Environment
I took a new contract at the beginning of the year to work with a team that does pair programming for most of their code changes. A pair starts by reviewing a new change with the tester they will be working with and the product owner. During that meeting, everyone asks questions to make sure they understand what the need is and what they are supposed to be creating. After that, the pair works on a feature until it is ready to ship.
There are no phases. I have heard people refer to adding a tester to this mix like adding a third person to a handshake. In my experience, this is a little more like a dance.
I work remotely, so each day I get with my pair and we fire up a video chat program and a tool called tmate that allows the three of us to all type in the same Vim session. Sometimes, we start by listing the tasks that need to be done to complete a change. If the thing we are working on is small, we just get started.
This is a test-first environment, so the first thing we do is build a small test that will fail because the new code isn’t there yet. The developers iterate back and forth between tests and code. This is a combination stratetgy of code design and testing.
So, what do I do while they are writing code? Sometimes I act as a sort of navigator, asking questions about what a bit of code does and whether or not that is the right thing. Sometimes I coach on test design and strategy to help get useful automation built at the right layer of the product. Sometimes I spend my time building Cucumber tests that will eventually run against the browser. I always offer testing feedback and quality questions as we move from programmatic testing to building new production code to seeing how the product behaves in the browser.
Pair programming and a well-designed automation strategy mean that when the programmers think they are done, the quality is usually pretty good. When they put in a pull request for their change, we spend a little time exploring the change from a user’s perspective in the browser. Sometimes we find new and interesting problems, and sometimes everything seems good enough. After exploring in the browser, we do a demo for the product manager to get last-minute feedback, merge into master where the entire automation suite runs, and then ship to production.
Pairing—and, in this case, tripling—is not an act of embedding an extra person in a process that was designed for fewer people. I think of it more like a folk dance where people are in a circle. Each person in the circle can contribute to what is happening because the people to their left and right are skilled dancers. Doing this requires an implicit understanding of power exchange, acknowledging your team’s needs, and being aware that each person has a skill set that contributes to the work in a special way.
