I can think of a few problems with having developers do all the testing. First of all, I completely agree that developers should have some role in the testing process. They should check each other’s work, but I’m not sure that qualifies as real testing. Here’s my thinking:

Testing is its own discipline, so by having people do both development and testing you’re losing some benefits of specialization. Developers should be involved in the testing cycles, but software testing is a profession and a specialty that has its own unique characteristics and methods.

I also think confirmation bias is a problem when people test their own stuff. Developers are too tied to their own product to see all the bugs, even when testing someone else’s code. Having someone, like a tester, who is fully divested from the underlying politics of development can really help dig out new things.

I think the thing to remember here is that separating the two groups isn’t a requirement, just a good practice. There are development groups that do their own testing just fine, either because the project is small enough or the team is structured enough to do the job well. However, I think these are the exceptions, and that most groups could benefit from having more separation.

To my approach Software Testing (and QA) is not the responsibility of the Testing/QA team ONLY. It’s something that the product guys should do (to validate requirements), the developers should do off course a lot of testing to their own code(a.k.a “unit testing”) and in the Agile way even review their team mate code. And, The testing team should be the final cycle before deploying to verify that all the prior cycles was done properly. In an ideal world (or development process) the Testing team would not find a single bug…:) but since we are all humans I think this cycle is necessary.

Roy

The one I question is separating testing from development. I think that’s what people have been doing for about 15 years, but I’m not sure it works.

Instead, I’d love to see developers become competent testers by constantly testing each other’s work. Not their own work, but each other’s within the team.

What do you think?