Five Rules of a Software Defect
One of the key items for a software tester is to know when software is defective. The best definition of a defect that I have been able to find comes from Software Testing (2nd Edition)
- The software doesn’t do something that the product specification says it should do.
- The software does something that the product specification says it shouldn’t do.
- The software does something that the product specification doesn’t mention.
- The software doesn’t do something that the product specification doesn’t mention but should.
- The software is difficult to understand, hard to use, slow, or—in the software tester’s eyes—will be viewed by the end user as just plain not right.
Points 1 and 2 above are pretty clear cut. Basically, if the software acts differently than explicitly stated, it is a defect. Defects found of this type are relatively easy to report and usually are not contested by the developers or product manager.
Given that 4 of the 5 rules are related to the specification it shouldn’t surprise us that the specification is typically the number one cause of defects. Why? Because specifications are hard to write. It is difficult to capture the entire design of a feature or product without having concrete examples of what is possible. Customers’ needs can change from the time the spec is born and the time it is implemented.
If we are in a position that is more of a Quality Assurance type of role, then we should be concerned with the quality of the spec. We should take an active part in reviewing it. If we are in a position that is solely testing-based, then we must live with poor specs.
