The Relationship between Testers and Programmers: An Interview with Matthew Heusser


StickyMinds technical editor Matthew Heusser is a consulting software tester and software process naturalist. In this interview, Matthew shares his thoughts on tester and programmer relationships, the impact of Acceptance Test Driven Development, and benefits of "lean coffee" gatherings.

Noel: First off, if you could introduce yourself, and maybe go into what you're going to be doing for StickyMinds and SQE—that would be great.

Matt: Thanks, Noel. For starters, I've been in technology ever since I graduated college, with a Math/CS degree, in 1997. After a couple of years of programming, I went back to school at night to get a masters degree, which is where I ran into extreme programming, agile development, and testing. During college, I wrote a couple of pieces for the school paper and published an article on, but my first real media experience was writing for StickyMinds. Likewise, my first "real" test conference presentation was at STAREAST in 2004. Fast-forward almost ten years, and I've done some more interesting stuff, teaching IS at night at Calvin College, working from home for Socialtext, and going independent and building a practice with consulting, training and writing. 

Ten years after that first presentation at STAREAST, when I had the opportunity to come back as interim editor of could I say no? So here I am.

Other interesting stuff? I am very interested in building and sharing knowledge in testing. In my spare time, I organize open-space test conferences and other events.

Noel: You and I were talking before doing this interview, and you brought up "the testing metaphor." What is that exactly?

Matt: Most folks agree that “just” development isn't enough to get to our end result, which is high-quality delivered. The question mark is how we get there. Most of us agree that some part of that is testing. The second question mark is what does testing mean?

  • Is testing evaluating the software to build confidence it is fit for use?
  • It is checking the specifications against some external standard, a 'spec'?
  • Is it trying to break the software, or looking for problems?
  • Is it reporting on the status of the software or the test project? (The "headlights" of the project?)

All of these position testing as sort of the opposite of programming. Programming is the creative process; testing is the destructive one. Testers and programmers are “enemies.” We never say it, but these ideas do influence our behavior.

Now imagine a different world, where pair programming is not two programmers, but instead a programmer and a tester. During the programming phase, the programmer is in charge, 'driving' the development. The tester needs to be technical enough to say, "Hmm...this function is getting mighty long," or, "We sure are passing in a lot of in variables here," or perhaps, "It's it about time to write a unit test." But, he doesn't have to be a production programmer.

When things switch to “test” for the story, the tester takes charge and the programmer becomes a sort of navigator or helper. Now thing about that two or three iterations in, the tester is going to have his exploratory test ideas while writing the code in the first place, so we're going to get stronger code and reduce defects, which reduces re-work. Reducing rework means we get to production faster with higher quality.

I'm not saying that example is right; it feels very code-centric to me. I'm saying I want to experiment with different ways of doing it, that we haven't figured it out yet.

User Comments

1 comment
Mukesh Sharma's picture
Mukesh Sharma

Nice read and a good way to know more about you Matt. I particularly enjoyed the piece about the lean coffee meetings!

November 15, 2013 - 1:00am

About the author

Upcoming Events

Oct 01
Oct 15
Oct 24
Nov 05