This title makes my eye twitch. The times when I've seen testers and TDD come into a "vs" situation, the whole thing was invariably just senselessly tragic. Th

This title makes my eye twitch. The times when I've seen testers and TDD come into a "vs" situation, the whole thing was invariably just senselessly tragic. The testers saw developers writing tests as an immediate threat, and responded to in a very self-defeating fashion. They would refuse to acknowledge the automated tests and insist on manually testing everything. Perhaps even, paradoxically enough, increasing their manual testing load by creating manual versions of as many automated tests as possible. This would, in turn, reduce the time available for digging deep and doing the kinds of testing that aren't amenable to automation (or to automating with a typical unit testing framework), while also increasing the need for painful things like code freezes. Ultimately, ironically enough, the work they were doing became increasingly redundant, and the automated testing did, in the end, turn out to be a serious threat. Not to the interesting and highly specialized work they wanted to be doing, but to the senseless busywork they unnecessarily roped themselves into. But not by necessity. It's so much nicer when QA can collaborate with and guide the developers' automated testing efforts. It's such an easy win-win situation: Developers get close guidance from software quality experts on how to ship higher-quality software, and testers get to spend less time stuck in a quagmire of tracking down and filing reports for a mess of silly little bugs that never should have made it onto their desks in the first place. Which should hopefully kick off a virtuous cycle of everyone helping everyone else be more productive and happier at work.