Unit tests are to testing…

Developing good software at a large scale requires the collaboration of several disciplines, that are not, contrary to your boss’ opinion, interchangeable. You need developers, of course, but you also need designers, PMs, QA, writers, usability people, localization, pointy-haired bosses, etc. There has been a tendency in some companies, however, to try to get developers to do more and more beyond coding, or even to magically transform test engineers into developers.

First, there was the TDD, and "TDD but" movements. That was a noble idea: you think your code works? How do you even know it does? What evidence do you have to back that up? That developers should take responsibility for unit testing, and accompany all commits with tests that prove their code works on the most basic level seems like a good idea. At least, it did at the time.

There is a whole lot more to testing than unit testing, however. Integration testing, for instance, can’t be easily done with routine commits, because they require a global perspective on the application, and can only be done when code is ready to be integrated into an actual application.

There is also the problem that the developer who worked on a bit of code may be the least qualified to test it. He’s the most biased person about his code. Scientific medicine has double-blind testing protocols. In software, we have no such thing, but a good tester is one who makes no a priori assumptions about the code, and that’s not something the dev can do reliably.

In summary, developers are not the best testers. As for the silly idea that any great QA person can become a great developer, I don’t even... It’s a gross misunderstanding of both disciplines.

In a similar move, it seems like the documentation writer specialty has all but disappeared. Take this random MSDN topic: http://msdn.microsoft.com/en-us/library/dd493110(v=vs.118).aspx. There is zero information in there. You don’t know why this is useful, there is no code sample, no context, just a lazy and uninformative description of what the code technically does, but nothing about what it functionally achieves.

Compare this with this topic from 2000: http://msdn.microsoft.com/en-us/library/ms972337.aspx. That is very helpful, and a tech writer has clearly spent a lot of time writing it. Nowadays, it seems like the documentation is just what a bot could extract from what little XML doc comments the developers put in their code, and a few top-level articles. I suppose in a world of mediocrity where most projects don’t even have that, it can look passable. While an open source project can get away with it, relying as it is on the good will of its contributors, a major software company that really wants adoption has got to do better.

Doc comments are to documentation what unit testing is to testing: necessary, but a far cry from being sufficient.

Even great developers are not necessarily good testers, or good technical writers. Those are different professions, and software companies ought to understand it and maintain the corresponding disciplines active, in order to ensure the quality and competitiveness of their products.