Properly Testing Your Code?

lowlytester asks: "I work for an organization that does testing at various stages from unit testing (not XP style) to various kinds of integration tests. With all this one would expect that defect in code would be close to zero. Yet the number of defects reported is so large that I wonder how much testing is too much? What is the best way to get the biggest bang for your testing buck?" Sometimes it's not the what, it's the how, and in situations like this, I wonder if the testing procedure itself may be part of the problem. When testing code, what procedures work best for you, and do you feel that excessive testing hurts the development process at all?

Comments

Use large scale Beta testing

[z_gringo]

Microsoft's massive use of Beta Testers in the user community was at the time called the largest beta test in History. They had thousands of people working for free, for quite some time.

Perhaps this model should be more widely adopted....

especially considering that the result was an effeciently designed product which was practically bug free....

Oh, wait, maybe it didn't work out EXACTLY that way..

Some defects are inevitable

[_zaphod(work)]

*Unless* you never stop testing your program.

Define acceptence criteria for the program eg: must process square widgets sucessfully, and test, using every valid and invalid situation you can think of (does it reject triangles correctly?) until you meet *all* those criteria.

There's always going to be issues, you just need to be sure that the cost of resolving those issues will be within acceptable tolerances.

Of course, making sure your system is designed and specified properly in the first place will eliminate most defects and (IMHO) make the ones that show up just all that much easier to fix.

btw: http://www.fastcompany.com/online/06/writestuff.ht ml is a great article on how they test the software that goes into the Space Shuttle.