Pareto Principle, originally described by Vilfredo Pareto and later formalized by Joseph Juran. In software testing this principle here is just a rule of thumb, but an important one.
80% of errors being concentrated in 20% of the developed product functionality. So errors in the software (modules, functional business processes, etc.) are distributed unevenly.
the percentages could be anything like 70/30 or 90/10, the reality is that most things are caused by a few underlying factors.
Not only, it relates to a finding a sufficient number of test cases that is enough to examine functionality of application or smart test case selection.
But For QA in software testing company, 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:
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.