Ruthless and thorough QA is a good thing, but has nothing to do with TDD. TDD should in theory help prevent the developer from ever hearing from the Black Team to begin with. If the Black Team found the bug, the dev's TDD fu wasn't strong enough.
As much as I appreciate your praise of TDD here, there are large categories of defects that TDD does nothing to prevent. TDD only helps programmers write the code they intended to write. It doesn't protect against programmer misunderstandings.
As a result, well-TDD'd code may still have defects that involve:
- the programmers misunderstood what needed to be built ("requirements" defect)
- the programmers interfaced with an external system that behaves differently than they thought
- the programmers used a third-party library or framework incorrectly
- there is a systemic error in the programmers' approach to the problem (e.g., not knowing about SQL injection attacks)
As I say in my "Let's Play TDD" series (http://jamesshore.com/Blog/Lets-Play/), TDD does a great job of helping a programmer write the code she intended to write. But it can't check the programmer's fundamental assumptions, so it's still important to check those assumptions using other techniques.
Agree with all of this, and I've made the same arguments myself. That's one reason code coverage metrics are of limited use -- they can't measure the quality of the tests.
I wasn't intending to diminish the role of QA (essential) or assert that TDD cures all (doesn't), just that The Black Team weren't doing TDD.
OR in an agile/integrated testing environment, the Black Team would be working with the dev to help develop unit tests and/or find the bug before it was delivered.
