“Pair programming” is a practice that came from Extreme Programming (XP) with the idea that two developers working...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
together would be more productive than each working apart. The idea has expanded to include pairing two testers or testers with developers. What about pairing programmers with non-programmers? What benefits can come from that? I explored this question and others with Lanette Creamer. Creamer will be presenting “Pairing programmers with non-programmers,” and “Agile testing games” at STP Con the week of October 24th in Dallas, Texas.
SSQ: Pair programming originally started as a technique for two programmers with the same skill sets to work together so they could review and test one another’s code. Some use it as a technique for test driven development and trade off with one developer writing the unit tests which drive the design of the code and the other writing the code to get the tests to pass. Are you suggesting pairing programmers with manual testers?
Lanette Creamer: Do any two people really have the SAME skill set? I’ve never worked with two developers who were exactly the same even in how they think about software design, let alone in their skill set. For that reasons, at STPCon 2010 in the spring, I gave a presentation called, “Pairing Testers with Developers.” This talk is the follow-up to that talk. I’m targeting it for testers, but I’ve discovered since then that there is a communication gap between product owners, testers and developers. The main gap is between programmers and non-programmers, not just between testers and developers. The communication is such a challenge that often developers may feel it is impossible or pointless to try. For that reason, the important technical details are only communicated among developers, which leads to a great deal of wrong assumptions, expensive requirements misses, and less efficient test planning.
I am suggesting that there are some things we can do to start experimenting with communication barriers between those who program all day and those who do not primarily program all day.
SSQ: Do you think that testers would benefit from knowing how to code? Would part of the purpose of pairing them with programmers be so that they might learn to code or at least be familiar with reading code and learning to white-box test?
Creamer: I think that anyone can benefit from knowing how to code, but it is far less important that testers know how to code than that they know how to test. What I am suggesting is that everyone who is involved in software development share knowledge and vocabulary of programming basics to some level. The level I’ve been trying for so far is to the level of pseudo code. I get frustrated when “coding” is oversimplified. On one end, we have a novice who’s written a few scripts, and on the other end, we have a person writing assembly language, and yet another person who is writing complex object oriented code in an entirely different language. You can argue that they all can code, but none of them share much common knowledge. However, there are some basics that apply to ALL programming, and YES, we all need to understand programming concepts enough to get a code walkthrough at a handoff, and to get past the intimidation of seeing code on a screen and assuming we don’t know what it is.
I’m not saying everyone needs to write code all day, but the amount of time and effort involved in being able to follow along in code and understand is a totally different level than being able to proficiently create and maintain that code. It is sort of silly to me how confusing this topic has become because of terrible hiring practices and bad test managers, who are mostly former developers or development managers who don’t understand testing. They try to apply the same brain-dead tactics that have failed over and over for people before them, and then they blame testers when the bad idea they have fails.
Should everyone write white-box tests? No. If you want to more easily find a job, yes. But that doesn’t make it right or even a valid “should.” When it makes sense on the project, and the tester has the skills and time to do so, sure!
SSQ: Pair programming typically involves two people sharing one computer. Are you suggesting this when pairing programmers and non-programmers? When the non-programmer is “driving” are they manually testing, rather than coding?
Creamer: Oh dear. I was using the term “pairing” in possibly too loose of a way. I do not mean pair programming with someone that doesn’t program. That would not be as effective. Instead, consider this somewhere in between the way that we normally interact between programmers and non-programmers, which is keeping things at a higher level, and instead purposely going in to more technical depth with non-programmers for a limited set of tasks. This pairing is NOT meant to create code. Instead it is meant to increase understanding of the code for the non-programmers. As the non-programmers understand what the code IS and IS NOT doing, they can have a discussion with the programmer. The person who wrote the code can then alter the code in real time, if they uncover new information due to input from non-programmers.
SSQ: Do you believe that pairing teams must physically be in the same location sharing the same computer, or can it be effective when they are pairing remotely? Any technologies or tools you would suggest?
Creamer: I often use Skype to collaborate in real-time. I share my screen to demonstrate bugs, ask questions, and even to simultaneously create presentation submissions with a co-presenter! For those who wonder if that works, please note that the presentation was accepted.
SSQ: Who do you think would most benefit from this presentation and why?
Creamer: People who are black-box testers, or Agile testers who have not paired with developers. Anyone who is struggling with requirements, communication and getting the technical data and user experience understood across the team. Teams that are using other development methodologies other than Agile also can adapt these ideas to any place in their process where testers and product owners need a clear understanding of the code, or where collaboration could be stronger.
For more from Lanette Creamer, read Agile testing games at STPCon with Lanette Creamer.
Lanette Creamer is an independent software testing consultant and coach from Seattle, WA. Known in the blogging community as TestyRedhead, her blog can be found at http://blog.testyredhead.com/. Her presentations are known for being candid, including cat photos, and being focused on the human side of software testing. Recently focused on Agile testing and pairing with developers, in the past her papers and presentations have focused on combining automated checks with exploratory charters, and group collaborative testing techniques.