Finally a subject that I can speak to with some authority. I have been doing software testing for more than 10 years.
Unit testing is definitely part of a programmer’s responsibility. There’s no better way to waste time and throw a project off schedule like when a software module crashes as soon as it is started. It’s like a home builder taking you to your lot and showing you a pile of lumber saying, “There’s your house. If there are any problems, just write up a list and I’ll get it fixed.” Where to begin?
A separate QA group is the best way to go. Maybe I’m a bit biased, but a simple 5 minute code change can involve hours of testing to make sure it didn’t break something else. It is a much better use of resources if the developer can focus just on writing the code and let the tester handle the testing.
I’ve also come to realize that a project manager, a developer, a tester, and a customer can have a lot of differing ideas on how something should function (I have never seen a spec that is foolproof). Testing his own code, a developer works under only his assumptions and may miss some other scenarios that he or the PM never thought of. Testers are taught how to work like customers and encouraged to do the most foolish things they can think of to mimic the worst case scenario the software could be subjected to. With newbie developers, it is quite easy to bring their code to its knees. Experienced developers learn to anticipate what QA will throw at their code and develop much more robust code the first time around.
[hijack] That is why it is bad to judge testers on the number of defects found. If a tester routinely works with experienced developers, then there will be a lot less defects to find. [/hijack]
Finally developers have a lot of code on their computers. That code tends to be the latest and greatest. It may not accurately reflect what a customer has on their computer or what is going into the next release. What they may have gotten to work with that new code may not work with the code the customers already have (resulting in the dreaded, “But it works on my machine,” excuse that QA engineers are all too familiar with). Thus it is best to install it and test it on a clean computer modeling the conditions that the software would be used in on a customer’s PC.
Once the we’re done with testing, the software goes into user acceptance testing where we give some of our customers the opportunity to try it out and make sure everything meets their expectations. Their goal is not to find defects and make sure the software is robust, but make sure that it meets their needs and expectations.
In all, testing can be rather fun. After all, the main goal is to break the software. What’s more fun than getting paid to break stuff. 