The chips are burnt on the top? [img]images/icons/smile.gif[/img]
Ok, all kidding aside, that is a very good question that Rich asks. I've been told not to "over-test" too, but no one seems to know when something is overtested. Project managers seem to be able to recognize when something has been overtested (they think!), but they aren't able to provide any up-front guidance.
On of my cohorts made a tongue-in-cheek reply that the managers actually ran with until they thought about it for a while - "We will minimize testing by checking only for the defects that are present."
Over-testing includes but is not limited to ignoring equivalence partitioning.
Over-test does not necessarily include testing every possible permutation and combination and redundancy. I've had the "over-tested" phrase tossed at me also. I didn't see it as an issue. I just looked at it as panic on the part of the messenger knowing that it was a typical panicky immeasurable statement. I simply gave the messenger an opportunity to understand equivalence partitioning. The messenger and the recipient were both satisfied.
Disclaimer: it is understood that any terminology or phrase such as "over-tested" used by someone not acquainted with testing - is an opportunity to stuff some knowledge into the black hole of ignorance.
Originally posted by Rich W.: I like it! Why bother with the code that has no defects!
<font size="2" face="Verdana, Arial, Helvetica">I do not know of any code that is defect-free.
How do you know you're done testing? Perhaps one of or a combination of these three ways:
1 - you've run all your planned tests (and they pass)
2 - you're testing but you're finding very few defects (calculate as defects found per time period, this number should increase rapidly at the start then decrease over the project life-cycle approaching but never reaching zero)
3 - your project manager says you're out of time (business reality, not necessarily bad, means mangement is taking responsibility for any remaining risk, ideally you should be helping them make this decision)
There's no zero-defect code you're likely to ever run into at least, but it's an idea you can expect to keep re-appearing through your career, refer to point 2.