For some odd reason it appears that some proponents of TDD think there is no longer a need for a decent QA team. Indeed, some of the biggest names in the tech world today (think Facebook or BaseCamp) didn’t have QA teams for several years.

TDD is a great concept insofar as it goes. Unit testing provides a great way to document what discrete portions of your code should do and gives a way to ensure they keep behaving as expected during refactoring.

What TDD does NOT do is validate that a given program behaves like the end user expects. That’s what Integration Testing and QA are for.

I can certainly remember QA experiences that were adversarial where the QA and development teams seemed to be in an “us vs them” battle, but my general experience has proven otherwise. Most QA teams I’ve worked with, especially those teams highly connected to the end user’s experience and needs provide an irreplaceable feedback loop between the end user and the development team.

Please do NOT take code to production that hasn’t been thoroughly QA’d. Oh, what about that urgent bug fix that the customer HAS to have in their hands tomorrow? Let’s just push that into production as soon as it is fixed, right? Wrong. If your QA team doesn’t have time to look at it then the user can’t have it. Seriously.