"Why would you need a tester today? When you truly learn to master Test Driven Development their should be no need for a tester. You have a test for everything and you even got it covered in your continuous integration that will alert you if someone checks in something that breaks existing behavior. Shipping software now days is a breeze compared to some years ago when you had those testers nagging you about small details that where totally irrelevant for the end product. Not only that, they didn't understand the process around coding at all and how hard it is to develop perfect code. Well, at least we are there now. The perfect code has arrived with TDD! Yeah!"

Something like the above was stated by a senior consultant that I met some weeks ago. I added some extra stuff to emphasize my point, but the overall meaning did not change. He where convinced that today there is no need for testers.

I think that TDD has made the job easier for testers, allowing us developers to produce better code quality. However, TDD don't test much of what a traditional tester would test. TDD is not something that a tester would think of to begin with. Maybe that's why Dan North came around with the concept of BDD (Behavior Driven Development), replacing test with behavior. Behavior is a much better description of what we're trying to accomplish (from a testers perspective), though BDD is not necessarily a replacement of TDD, but more a response to TDD. TDD really don't have anything to do with testing as a tester sees it. BDD however focuses more on the business aspect of what your trying to solve. It "forces" you to look at things from the outside and in.

Another aspect that TDD does not cover is of course the look and feel of the application that only a human can tell is right, wrong or bad. Much of the functional logic is also impossible to test with TDD. There are other tools one can use for that, but not TDD. I think that this kind of thinking really puts TDD into a bad light. I'm pretty confident that TDD was never intended to replace testers.

Talking about automating tests and the like. Automation is often done by developers or testers with developer skills. Automation is a tool for the testers to make their job easier, not a replacement. Code help testers automate stuff that they do time and time over. The good thing about automation is that testers can focus on other things than the manual tests which is now automated. Not all tests can be automated and not all tests will add value if automated. Some you will just spend to much time maintaining and is just not worth the effort of automating. Testers needs to be careful with how they approach test automation and the tools used in the process.

We now also see that tester more often make use of dynamic languages as their preferred language. Why? Because you can achieve more with less code. Also dynamic languages (as they are today) is often in beta, and developers have a hard time convincing their boss (and even themselves) to put it into production code. But it's easier to except using beta stuff for code that is not going to production.

In all fairness there is one situation where I see little or even no need for a tester. That is on very small scale projects where the product is very simple or where it's an API or service of some sort. You can probably manage without a tester for some time on these types of projects, but at some stage I believe you would need more than just TDD.

Instead of fighting this battle with the tester, we should help the testers more by utilizing our knowledge helping them to be more effective. Include your testers into your team instead of handing over functionality to be tested, and get it back when it does not work. Include the testers in the planning.

I recommend reading an interview with Jonathan Kohl by J. Bruce Daley about test automation. And you should of course check out Jonathan's blog as well as Bruce's.