13 responses

  1. QAInsights
    May 21, 2013

    Pair test programming may not work, if developers and testers are in different geographic zone ):

    BTW, nice points. Thanks!

  2. AA
    May 21, 2013

    Nobody likes being told what they did wrong – this is the fundamental
    quarrel between developers and testers. I’ve found that simply pointing
    that out makes a difference.

    One thing I’ve done with good
    results is put developers in charge of triaging defects, and I rotate
    that role. It may sound subversive, but no developer wants to be
    “shamed” in front of a peer, nor do they want to accept or subject a
    peer to additional work. Accountability and visibility are powerful
    allies to quality.

    As you note above, unit testing is a big help
    because it creates a cleaner handshake between development and test. The
    easier (read: more automated) UT is for developers, the easier it is to
    sell to them. Otherwise, you risk having it look like development

    Sometimes its a good idea to rename UT to something
    without the word “test” in it so you don’t get the “we develop/they
    test” debate. Something like “Build Verification” works, as the
    perception is that is more of a development than test-centric task and
    therefore rightly falls under the domain of development.

    Agile has gone a long way to improving both the developers’ and testers’
    perceptions of the other. Collaboration & communication, as noted
    above, make more productive teams that produce higher quality code.

    Great article!


    • Ole Lensmar
      May 22, 2013

      Thanks for sharing your ideas – great feedback for all of us!

      I agree; at heart testing is often perceived as “criticism” – which is far off the point. Especially junior developers can have a hard time accepting that errors/bugs are just part of the process – both at code, design, UI and product levels – and as such testing/qa is a natural part of crafting the final product. Agile certainly makes this easier as it promotes communication/collaboration between disciplines – but at heart this is perhaps more a “people-issue” than anything else.


  3. Foobar
    May 21, 2013

    If tester had any talent, they would be developers.

    • snicklefritz
      May 22, 2013

      Automated testing IS development.

      • lolzzyingaround
        August 30, 2013

        Foobar is a developer and snicklefritz is a tester

      • lolzzyingaround
        August 30, 2013

        I’m a developer, and I really don’t understand what the hell testers think of developers. oh.. come on, do u think I don’t know the color of the icon..seriously..

  4. del Norte
    May 21, 2013

    My first experience with pair programming was actually as the programmer of a programmer / tester pair. We were working in cobol, which involves lots a manual testing due to its lack of robust automated testing techniques. I was the developer on a very hot project that involved a great deal of business complexity. My partner had started his career as a user of the host application, for which I had primary architectural responsibility, then “graduated” to domain expert, then to QA specialist, and was just ready to join our programming staff. His first programming assignment would be to take over maintenance and enhancement responsibility for this very complex module after he and I had developed it together.

    This experience completely changed the way that I developed software. It was amazing how much I learned about how to test software from working with someone who was a real pro. I ended up with such respect for the QA specialty. It turned out that I was also in the midst of a “graduation” of my own, to a language (java) which does provide robust support for automated testing. So I got to bring with me all of the vicarious testing experience that I had obtained from my partner as I began to write my own tests.

    One of the things that I learned is that programmers are often really bad testers. In particular, we tend to do what I’d call “theory based testing”. We come up with a theory about how a class of problems can be solved, base a number of implementations on this theory, then test ONE of the implementations to prove that our theory is correct. What I learned from my test partner is that most of my bugs were actually of a more mundane type. Cut-and-paste errors (lots of cutting and pasting in cobol!), typos, brain-farts of one sort or the other. Sample-testing one of ten implementations doesn’t cut it with that sort of errors — you need to exhaustively test every gd implementation instead, or the bug will be in the one that you skip. Luckily, with automated testing, this is easier to do.

    The most important outcome from this exercise, however, was the change that this made in my coding style. In this project, I knew that the code that I was writing, of necessity dealing with a very complex domain, had to be understandable to a junior programmer. This was where I really came to understand that the main purpose of a program is NOT to tell the computer what to do, but rather to tell other humans what the computer is doing, in a way that makes even hard things understandable.

    One thing that I would recommend to anyone who tries programmer/tester pairing is to make sure that you both actually review the code that is being written. The tester may not be have the skills to parse the syntax, but the code should be written in a way that still makes the process that it is using to address the problem apparent. Talking through this process with a skeptic whose training is to find corner cases and other process errors is extremely valuable. Of course, this runs completely counter to the idea of “black box” testing that seems so prevalent in many QA cultures. At the same time, if the pair understands the concept of API / implementation separation and builds a test plan that reflects the API instead of the implementation, the fact that there may be some knowledge leakage about the implementation back to the tester is not as large of a problem as the black box testing advocates might imply.

    • Ole Lensmar
      May 22, 2013

      wow – that’s awesome feedback and input to those of us trying to get testers and developers close to each-other, thanks so much for sharing.

  5. Liemur Ltd
    June 17, 2013

    Testers job is to tell developers what they did wrong, it can never work out.

    • volothamp
      November 22, 2013

      Upvoted, but may I suggest an improvement?

      The tester job is to tell developers what it is wrong in that moment.

      I’m convinced that the tester should never report directly to a developer, but more in a global pool of common problems. How can a developer know if it was developer A or B or even the DBA C that broke the system?

      All test issues should be reported without addressing a specific developer, there is no way that he knows or doesn’t now what the problem is and how to fix it, so why bother and trying to guess, exacerbating the conflict between the two teams?

Leave a Reply




Back to top
mobile desktop