I don’t care if it works on your machine! We are not shipping your machine!” – Vidiu Platon

I can almost see the testing manager talking (negotiating?) with the developer while going over the bug report and making this, rather exasperated, statement. Those of us who have been in software development long enough are quite likely to have encountered such intense “developer v/s tester” situations somewhere along the way. Of late the roles, or should I say battle lines, have blurred somewhat – don’t believe me? Think about how often you now come across the term Software Design Engineer in Test (SDET) – much more frequently than was the case even a couple of years ago right? In the language of car companies, the SDET is a “crossover” – someone who spans the software development and testing worlds and has bits, pieces and features of both in his job description. The SDET is a visible symbol of a discussion we are having quite often now – should developers test? Also by extension, should developers test their own code?

At one level, especially for smaller software development teams, start-ups or even larger companies where software is not the core function, the attraction of having a smaller self-contained team of developers who do their own testing and validation is obvious. Costs are contained, as is the management overhead and the demands on their, more limited, internal technical bandwidth are less onerous. At the other end of the spectrum are larger software development efforts where more development-friendly test functions like test automation demand the presence of software developers on the testing team. We have always made the case that in the case of test automation the test strategy has to be much more closely coupled with the development strategy and architecture – again a function where developers could play a key role.

That being said, I believe that testing is a specialized task in itself that needs a focused testing team to action effectively. There are some key reasons why I think developers would not be quite as well suited to the task of testing their own code.

1. Mindset:
   Most people will agree with the statement that the job of a tester is to break the software. A quality tester will try every use case and condition possible to try and make the software fail. They look for complex situations, combinations of situations, repeated applications and even heavier than expected load conditions to make the software break. In many ways, this is a completely opposite mindset to that with which the developer approaches his task – essentially the developer is always trying to make it work and that may not be the best approach for testing.
2. Starting right:
   It’s not unusual to encounter development efforts that have been built on an inaccurate understanding of the initial requirements. A developer testing the code would generally be less inclined to check if the foundation itself is incorrect. Essentially the “bug” is the place where the design started.
3. Proprietary interest
   It’s a rare developer who doesn’t get attached to his (or her) code. It’s something they have sweated over and as a result, to some extent, they would start testing from the position that the code works. This is likely to lead to short cuts, assumptions about simple or “trivial” things and a possible tendency to skip things that they “have fixed during coding”. Obviously, these are the kind of things that turn around and bite back later in the cycle.
4. Big picture view:
   Most developers will have a reasonable view of the code they are working on – that unit or that piece of the puzzle. Even if that works fine in itself no software works in isolation. A Tester will usually be able to turn a wider scope and test – look at how the code works when fully compiled? Or how it works in a simulated, or real, user environment.
5. Tricks of the trade:
   This is, of course, apparent. Testers have much more experience with the act of testing, the tools and techniques, how to log and report bugs and even common faults and the reasons why they occur. A developer would have to reinvent that particular wheel to become as efficient at the role.

So what role can developers play in the testing process? Well for starters it is apparent that they would be extremely well suited to unit testing and, at least, validation testing of their code. That apart there seems to be a good case for pairing developers and testers – the model works well in the Agile context due to the short sprints and multiple iterations. This, though, is the subject of another post. In closing let me share what Brian W. Kernighan said, “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” I’m not saying I agree – just that he’s the computer scientist, not me.