- Pairing: Tester and Tester
- Pairing: Tester and Developer
- Pairing: Virtual Team Testers
- Pairing: Tester and Other Team Members
- Summary
- Other Articles on Test Pairing
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Pairing: Tester and Developer
On several fortunate occasions, I’ve worked with developers who have a keen interest in knowing what I test and how I test. I’ve had the chance to pull up a chair and pair together. In each of these situations, I gained the opportunity to learn more about how code design and implementation at a low level—meaning, distinctly and specifically how the code was built. In some cases, that knowledge changed the course and direction of my testing. By pairing up together, even if the occasions to pair were only singular events over months of working together, I learned more about the code, more about where the risks remained, and what risks the developers saw. In turn, developers I’ve worked with have had a chance to see a product through the eyes of a tester and to learn about different ways to test.
I’ve noticed that without fail every time I’ve had the chance to pair with a developer, the developer gains respect for testing and the work that I do. At best—and I’ve had this situation occur multiple times on different projects—testing needs become better recognized and shared as opposed to testing being viewed as something that occurs post-development. I’ve had developers tell me they will add an automated unit test as a result of realizing what testing I was executing. I’ve had developers pull up the code and review branching and conditions with me as we discuss risk.
In a nonintrusive style, I’ve been able to use test sessions with developers to teach developers about testing. It used to amaze me that I would meet developers who would know so little about testing given their background, but it doesn’t surprise me anymore. Just because our professions have a close kinship doesn’t mean that each of us knows about the other’s craft. I’ve learned a lot about coding and database modeling.
Learning goes both ways. This was one advantage Jonathan Kohl highlighted in an article he wrote in 2004 called “Pair Testing, How I Brought Developers into the Test Lab.”
I also listen for information that doesn’t always get told directly—things like where in the program developers have some uncertainty or what areas of a program took longer than expected, speculating that these are likely good spots for me to focus on first even if product risks would dictate a different direction. There are different types of risks, and a programmer’s uncertainty is one.
One of the most pragmatic aspects of pairing with a developer that I enjoy is being able to build models or tables together to better illustrate possible outcomes of code conditions. Those experiences of quick model building have stayed with me as I’ve gone on for years building models in my notebooks during my more typical solo test sessions. Every time I have a chance to see code, a program, a risk, or a problem tackled by someone else’s approach, I gain another way to approach issues or to draw out test combinations.
I’ve also found another unexpected benefit of pairing with developers, and that is the ability to more rapidly discuss what testing has been covered and what testing has discovered. After pairing together, developers have a sense of the types of conditions and tests I’m hunting down so they’re less surprised by reported defects—giving me a head nod in the hallway after defects get filed because now we have a faster way of communicating as our work continues. With my work on virtual teams, instant messenger sessions together usually reduce the number of questions on a defect report.