I had an interesting discussion with a tester the other day. I had put down a couple of beers, so had the dutch courage to let him know what i generally think about system testing. In a nutshell, I am not a fan of manual testing. Sure there is a definite need for it, but generally manual testing gets bogged down and I for one, (talking from experience - not just a random thought), think a comprehensive regime of unit testing adds infinite more value to a software project than manual testing.  The reason is a theory known as moral hazard. 

Moral hazard, as defined in the above Wikipedia link is " the prospect that a party insulated from risk may behave differently from the way it would behave if it were fully exposed to the risk". It is a theory generally used within the insurance marketplace.  The idea being that if too much protection is given to an insured party, they will behave in a manner that may give rise to them not protecting the insured assets from harm.  They are more likely to use the asset for risky purposes, to abuse it etc, asultimately they would know that in the event of the asset being destroyed, lost or broken, they would be protected by the insurance.  

From a developer/tester relationship standpoint, there is a clear moral hazard - and it's not the tester's fault. A developer who chooses not to unit test, or does a half-baked job of it, knows that the end product will still be system tested. They know that if a bug escapes out into the wild, that it would be the tester who gets it in the neck, and that they would only suffer a consequence if the bug was something deeply technical and outside of the scope or understanding of system testers.  This gives rise to questions targetted at testers such as "Why didn't you test this?", "how did this get through test??" etc.  It's almost as if the developer discards all responsibility and accountability as soon as the software moves into test. (by the way i know not all developers are like this but many, many, many of them are).  The moral hazard is clear.

If a developer is compelled to create highly effective, high coverage unit tests, then indeed they lose the moral hazard - they are responsible for their own quality. You could argue that this shifts the moral hazard onto testers, however i would argue that a well put together suite of unit tests in the order of 95% code coverage, and using proper assertions Is far less risky than allowing side effect ridden code through to test. Testers simply aren't going to catch all the sublte issues in the code, that only properly written unit tests can find. The other nice result of the above approach is that testers would then be testing functionality - not struggling through lots of minor technical bugs that would have been caught by unit tests.  This means that bugs are only likely to be found when a) there was a misinterpretation of requirements and b) the requirements were themselves incorrect.

In my experience, approaching a new project in this manner is highly effective.  Testers actually become nervous because they can't find many (or any bugs), but quickly everyone realises why this is, and testers become much happier because they can get on with their jobs and not fight against low quality, nonunit tested code. Also the final product is of vastly superior quality. 

Moral Hazard is not just an issue for insurers  - it's some thing that we as developers also produce by our choices about quality. If you don't own your own quality, you can't really expect to produce quality systems, and you can't always blame the tester if that happens.