Most applications today have been designed to include some form of customization or extensibility including user preference settings, scripting languages or APIs for custom extensions using more traditional languages.
Software companies like Microsoft understand this, and design for a product that addresses 80 percent of the requirements, leaving the last 20% as customizations by the end user
80% of Defects are Caused by 20% of Code……
The concept here is the Pareto Principle, originally described by Vilfredo Pareto and later formalized by Joseph Juran. Of course, this is just a rule of thumb, but an important one. Whether the percentages are really 70/30 or 90/10, the reality is that most things are caused by a few underlying factors.
For software testers, knowing this fact can offer tremendous value. If a tester is simply looking at a list of 100 bugs, it may not be clear if there is any underlying meaning. But if the tester were to combine those bugs based on some kind of category, it may be possible to see that a very large number of bugs come from very few places.
Here are a few recommendations for getting the most out of this principle:
– Try to sort bugs by root cause and not by outcome. Grouping all the bugs that made the software crash isn’t that helpful. Grouping all the bugs that resulted from module XYZ is more helpful.
– Work with developers to look for innovative groupings. For example, 80% of the program’s bugs may result from calling the same underlying library. However, that may not be readily apparent from where the bugs occur within the program.
– Remember that bugs may result from flawed procedures. For example, a large number of bugs could be present because a developer is using out of date specifications.
This principle can be tremendously powerful in reducing the bug counts within a program because solving just a few things can make a program much more stable.
Software Testing Diary 