Putting the tee BACK in tee dee dee

Christian posts about the word “tests” in test driven development. He's absolutely right: we get hung up on the word all the time.

Around here, every time we start talking about TDD, the testers get all nervous. “Does that mean you don't need QA anymore? What's my role?”

I tell them to take it easy. They have an important role to play in a team using TDD to write code, and it's a much more interesting role than in the non-TDD team

Without TDD, the job of testers is to find bugs. Find every way in which the product crashes, the screen gets all messed up, the results don't work, whatever. Find every way to break the software. We do this because our users tell us that they hate it when software breaks.

But our users also tell us that often the software doesn't quite fit their needs. That is, we've designed the wrong thing, even if we implemented it correctly. 

With TDD, the devs can know that the answer to “Did I write what I intended to write” is “yes”. QA is freed from the tedious & unimaginative role of trying to break the software, and can now step up to the role of Customer Advocate. QA can now say “the winforms designer needs to be better at roundtripping the Initialize Component code, because Elvis wants to refactor it.” or “the Dynamic Help window is useless; we should cut/enhance it before we ship,” etc.

The name TDD is pretty ingrained in our literature and language. If we're going to replace it, we need a good name. Any suggestions?