The software tester and programmer relationship

Cultivating the software tester/programmer relationship

I have a hard time getting our programmers to work closely with me. They have a low opinion of the value I can contribute to the project and have little respect for the value of testing in general. How can I get them to see that not all testers believe in just documentation and show them that I can help them write better software?

    Requires Free Membership to View

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

I have a game I play with programmers. I call it five bugs in five minutes. It's been I while since I've done it (you have to be sitting close to the people doing the programming), but I still get to play it every now and then.

The game works like this:

  1. A programmer finishes coding some testable unit of work.
  2. The programmer comes over and throws down the testing gauntlet.
  3. You go over to the programmer's desk and they launch the software you will be testing, navigating to the code that is supposedly "done," and establishes the limits to the software they are presenting you with.
  4. You accept or you decline the challenge (noting that declining lowers your project "street credit").
  5. If you accept, you test for five minutes with the programmer looking over your shoulder.
  6. Every time you find a bug, you laugh sadistically and tell the programmer the bug you found.
  7. The programmer (and this is important) confirms or denies that what you found counts as a bug.
  8. After five minutes you stop.
  9. If you find five bugs (that the programmer confirms are bugs), the programmer pays you $5 (or buys you lunch).
  10. If you fail to find five bugs (that the programmer confirms are bugs), you pay the programmer $5 (or buy him lunch).

I find that this game has the following side effects:

  • Over time, I get more free lunches then I give.
  • Over time, I develop better communication with the programmers. They become more willing to help me, and they become more interested in fixing my bugs.
  • Over time, the programmers get better at preventing the types of bugs I find -- forcing me to change my test techniques and raise the bar of my testing.
  • Over longer periods of time with the same developers, I start to give more free lunches then I get.

It allows both of us to grow in a fun little competitive way. It certainly raises my status in their community. And most important, it gets them coming to me when they finish programming something, because they know I can help them write better software.

This was first published in February 2007