What is defect density software testing?
Question:
Answer:
Defect Density
One of the easiest ways to judge whether a program is ready to release is to measure its defect density—the number of defects per line of code. Suppose that the first version of your product, GigaTron 1.0, consisted of 100,000 lines of code, that you detected 650 defects prior to the software’s release, and that 50 more defects were reported after the software was released. The software therefore had a lifetime defect count of 700 defects, and a defect density of 7 defects per thousand lines of code (KLOC).
Suppose that GigaTron 2.0 consisted of 50,000 additional lines of code, that you detected 400 defects prior to release, and another 75 after release. The total defect density of that release would be 475 total defects divided by 50,000 new lines of code, or 9.5 defects per KLOC.
Now suppose that you’re trying to decide whether GigaTron 3.0 is reliable enough to ship. It consists of 100,000 new lines of code, and you’ve detected 600 defects so far, or 6 defects per KLOC. Unless you have a good reason to think that your development process has improved with this project, your experience should lead you to expect between 7 and 10 defects per KLOC. The number of defects you should attempt to find will vary depending on the level of quality you’re aiming for. If you want to remove 95 percent of all defects before shipping, you would need to detect somewhere between 650 and 950 pre-release defects. This technique suggests that the product is not quite ready to ship.
The more historical project data you have, the more confident you can be in your pre-release defect density targets. If you have data from only two projects and the range is as broad as 7 to 10 defects per KLOC, that leaves a lot of wiggle room for an expert judgment about whether the third project will be more like the first or second. But if you’ve tracked defect data for 10 projects and found that their average lifetime defect rate is 7.4 defects per KLOC with a standard deviation of 0.4 defects, you have a great deal of guidance indeed.
Defect density is one of the most important factors that allow one to decide if a piece of software is ready to be released. In theory, one can find all the defects and count them, however it is impossible to find all the defects within any reasonable amount of time. Estimating defect density can become difficult for high reliability software, since the remaining defects can be extremely hard to test. Defect seeding will work only if the distribution of seeded defects is similar to the existing
More Questions & Answers...