Extreme Programming gave us pair programming, a practice that is incredibly successful, wonderful beneficial … and hard to adapt culturally. Instead, people say they “pair when it makes sense”, which is code for “every now and again over a lunch hour”.

The main objection to pair programming is efficiency — it feels like two people doing the same job. If the pairs were split, development would be twice as fast! I can’t agree with that logic, but that is not today’s post.

Instead, today’s post is about effective pair programming when half the pair is a tester.

That’s can be scary, but with a little effort, testers can be incredibly helpful in pairing. Here are some ideas.

Pair Programming – Tester’s Perspective

A few years ago I tried to pair up with a programmer on a new prototype of a system. The prototype was programmed in python, which I did not know. We shared a windows screen. The programmer bounced back and forth between his text editor and the browser, saying “woot” occasionally. I could not track what he was doing. Eventually he would pause so I could test the new feature – things wouldn’t work, and he would either say “that isn’t implemented yet” or “of course, this is just a prototype.”

You can tick off the mistakes above, but I think the largest one was a lack of communication. I was embarrassed to ask what the programmer was doing, to explain his thinking process. And he was moving too fast for me to use the guidelines I’ll describe below.

He was probably trying to impress me.

Getting Ready for Pair Programming As a Tester

The tester is the junior member of the team. As such, they can slow things down to improve quality – but there needs to be a baseline of skill. Here’s a dozen skills to learn before sitting in the pairing seat. Some of them are easy; some require a book. Testers who are already proficient in the basics of programming – variables, for loops, and so on – will find that in a few weekends they can add incredible power to a programmer/tester pair team.

Learn the basics of the production programming language. If the language is Erlang, Haskell, or LISP, this could be a real challenge. Most mainstream languages like C#, Java and Ruby are approachable by anyone with fundamentals. Don’t just read a book; implement the bowling kata and the roman numeral kata. If you have time, implement Conway’s Game Of Life.

Learn the front-end if you need to. Frameworks change every day, but HTML, Javascript, and CSS are the basic building blocks of the front-end web. If you’ll be pairing to do full-stack work, build a modern website.

Read Refactoring by Martin Fowler, and Clean Code By Robert C. Martin. Our goal here is not to be programmers. Instead, we have a secret goal: To figure out enough to know when code is going wrong. We’ll learn about ugly code and how to point it out when the programmer is writing, along with a little bit about test driven development. After reading the books, go look at the katas you wrote, see how terrible they are, and redo them. For a slim, sweet primer on these same concepts in Ruby, consider the poodr book – Practical Object Oriented Design In Ruby.

Lunch Hour Pair With a Programmer. At this point you are not contributing, just learning. Yes, listen as the programmer explains what they are doing – but also look for code smells you know by now. Methods with too many parameters, methods that are too long, cut/pasted code on both sides of an if statement, nested ifs and loops that go too deep, code complex enough to need a comment, and overly tight coupling. If the company is a TDD shop, notice when a programmer is writing code that does not satisfy a test. If you reach this stage, you can materially add value to a pair – a lot of it – simply by being the code conscience!

Read about Design Patterns, or better yet, the original book. The original design patterns book can be a bit … dense. So search around; there dozens, if not hundreds of books on design patterns, some more introductory, some for specific languages. The point is to recognize when, say, you might want to use several different sets of rules. The simplest way to do that is a single large function that takes in a ‘type’ and has a bunch of if statements. The more testable, easier to read, and easier to extend way is to use a Strategy pattern. For a brief introduction, consider my article Why Design Patterns Still Matter for InformIT.

What To Do With It

By the end of this quick guide you know more about the structure of good code than the typical programmer does. So go ahead and pair program, watching the form at least as much as the substance. Yes, it will be good to study the substance, to figure out what the next test should be. During coding, those niggling questions “wait, which test are we satisfying?”, or “this function seems to be getting long – what if we extract method on everything inside the for loop?” will help make better code.

Of course, when the code is in a certain state and ready to be tested, the tester will really need to show their skills. That is a different post, or many different posts. Some of the best testing will happen as the code is written. Finding an internationalization bug may make the tester look smart, but asking “should we have a test for international characters?” during the Test Driven Development loop will save time and possibly prevent similar mistakes in the future.

Which could be a problem, as the code will get better before first release, so the testers will need to step up their game.

But that’s okay. This entire post is about stepping up your game.

Last But not Least

My worst day of pair programming ever happened when I just hadn’t had enough sleep the night before. My head hurt. I had a chance to impress the customer, and instead mumbled my way through; I’m not sure if I touched the keyboard. That was … not the way to make a good impression.

So get a good night’s sleep. Take a long weekend and off caffeine if you can.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

There was an error processing your information. Please try again later.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

About This Blog

From the Cloud to Virtualization, Software As a Service to Web Services, ideas seem to be everywhere all the time. Somewhere, somehow, someone needs to separate the wheat from the chaff. We’ve asked Matt Heusser to provide his insight and commentary on the prevailing issues for IT staff today.