Listen to this post
In many large organizations there is a kind of wall between development and testing. Developers do their work and “throw it over the wall” to be tested. This can create negative attitudes on both sides.
Developers see testers either as a source of no information (“it works? Yeah we knew that”) or bad news (“there are bugs to find and fix, ugh”). Testers are adversaries to overcome before developers can be said to have succeeded.
Testers see developers as a source of hard work, and code that must be wrestled with. Often testing lags hopelessly behind development and because of this testers see developers as a source of a never-ending avalanche of work.
When these organization adopt TDD, this unhealthy adversarial relationship tends to fade away. Developers who write tests are far more understanding of what drives testers, and they personally experience the value of tests. Testers see developers as a source of the low-level unit tests that they can inherit, and thus no longer have to write. This frees them up to do the more interesting testing that often gets cut due to time constraints.
TDD makes developers and testers into valued colleagues, and so improves the health of the culture. This contributes to improved products and less waste.