Testers and Developers, Can We Please Get Along?


A couple weeks ago I had the opportunity to attend the StarEAST conference in Orlando. As in past years, it was inspiring to see so many qualified testers and QA managers all under the same roof. Speaker sessions were relevant, humorous and interesting, and from the list of topics, it’s evident that junior and veteran testers alike have started to adopt trends like Agile testing and automation without ignoring things like exploratory testing, test management and planning.

I would even go so far as to say many attendees were far beyond learning and embracing new trends; they’re eager to roll up their sleeves and get their hands dirty with automation tools, Agile practices and cross-functional teams. Testing is definitely a practice you can thrive in.

Unfortunately, there are still some clouds on the horizon – you saw that coming, didn’t you? Jokes about “stupid developers” are still lurking in the corners, stories of “throwing things over the wall to development” continue to repeat themselves, and making fun of developer geekiness still prevails. Admittedly, I enjoyed these jokes as much as everyone else, but they always give me a bitter aftertaste; why is this barrier between testers and developers so hard to overcome?

Shouldn’t we all be on the stage together talking about real-life experiences where testers and developers helped build great products together?

Shouldn’t we be sitting together running tests and debugging code to create the most beautiful software out there?

Ultimately, if we don’t overcome this cultural divide, how will we ever expect to do “real” Agile testing with testers and developers delivering great quality to our users together?

The thing that bothers me the most is that the time for this to happen has never been better! Let me explain:

  • Testers are often using the same tools that developers are using for creating (automated) tests.
  • Test automation is being embraced more and more by testers as well as developers.
  • Both testers and developers are embracing the continued value of exploratory testing as an essential practice for testing new functionality in a product.
  • Unit testing and test coverage discussions are becoming natural ingredients in new development projects.
  • The value of Test-Driven Development and BDD is being embraced more and more by development teams, often in conjunction with Spec-by-Example.
  • Testers are becoming just as important as developers and product managers when fleshing out requirements and evaluating the complexity of new features.

And to top this all off, the whole Agile movement is leading the way! Remember, Agile is all about communication, collaboration and cross-functional teams, which is exactly what needs to be in place to overcome the “legacy” prejudices still prevailing between developers and testers.

So what can be done today?

Many of us (including me) instinctively feel that breaking cultural barriers like those described above can be extremely hard, even if there are a lot of things going for it. But I think we also all recognize the benefits at hand and the opportunity given. Many speakers at StarEAST touched upon this subject. Here are a couple of their suggestions for breaking down these walls:

  • Introduce pair test-programming; let your testers and developers sit together to develop and run tests, to discuss requirements and to assess non-functional aspects (performance, security, usability, etc.).
  • Install and learn each other’s tools; developers should have a grasp of test management tools, testers should be able to check out the source code and run automated tests. This builds mutual understanding for the complexities at hand with automation frameworks, refactoring, etc.
  • Go to hackathons together! Imagine having an expert tester on your team at the next local API hackathon; the quality of your entry will be so far ahead of the competition they won’t know what hit them (thanks to all exploratory testing being performed in parallel with creation of unit tests and automated UI scripts).
  • Treat testers and developers as one integrated team; sit together, do stuff together, incite collaboration.

Maybe I’m knocking on an open door here. Have you already torn down the wall between developers and testers in your team? Are they all joking together about sales and marketing? Share your insights or objections with us – I for one would love to hear your story!

See also:


  1. QAInsights says:

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

    BTW, nice points. Thanks!

  2. 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 says:

      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. If tester had any talent, they would be developers.

  4. del Norte says:

    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 says:

      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 says:

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

    • 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?

Speak Your Mind