I truly believe that the Pareto principle exists with 80% of our problems come from 20% of the solution.
Steve Ballmer in an e-mail on Microsoft’s Trustworthy Computing initiative wrote “About 20 percent of the bugs causes 80 percent of all errors, and–this is stunning to me–1 percent of bugs caused half of all errors.”
The hard part is to figure out which 20% has the defects and while I have not figured that out, using a risk based approach and pairwise testing has given me good results.
I do find the Pareto principle invaluable when looking at the outputs from testing to ensure that the best outcomes are achieved. This involves looking at;
- Classes of errors. Take some time to categorise your defects by root cause, not impacts. If you are seeing a prevalence of one type of behaviour in one area, chances are that you will see it in others. 20% of your root causes, will close out 80% of your defects.
- If you are performing UAT with large user pools, fix the defects that are most raised, it is the quickest way to change the perception around quality as well as giving the UAT group a belief that their concerns are being addressed.
- Identify the root cause worse 20% of behaviours that impact on the financial, operational or reputational position of an organisation – get these resolved.
- 80% of your users are going to use 20% of the features, think about this for load and automated testing.
The Pareto principle is also a great lens to use during project initiation. When reviewing requirements and designs it is worth asking what 20% of functions the 80% use and of the remaining features, what can be removed – if you can get the scope right at the start and not have to code and test a feature, you are winning in the time stakes from the very start.