The key is the automation of the tests. I personally hold the belief that the logic author should also be the spec author, and it's QA's jobs to find gaps in yo

The key is the automation of the tests. I personally hold the belief that the logic author should also be the spec author, and it's QA's jobs to find gaps in your model of the world. The barrier means QA doesn't have the same model, and often lacks info that you have. That's valuable in some aspects, but it's not double-entry. (Double entry in accounting means that you always record two transactions that need to match each other, not that there's independent verification - that'd be auditing) I believe you need both double-entry and independent verification. (Of course, that depends on scope & desired quality. Your 100-line bash script that you only run to print fortunes for your friends probably needs less rigor than products that are used by billions, or that have life-or-death impact) You're right that it's not specifically TDD that enables this - but you do want automated unit tests written by the developer, whatever methodology you use. (Or at least I want them :)