Being one of the 7 fundamental principles of testing, bug clustering is not just a theoretical concept. Most people with experience working on real projects will agree with this statement. Of course, there are projects that, at first glance, do not seem to fall under this principle, as defects are found all over the development process, testing, organization, etc. However, this is more of an exception to the rule.
So, let's talk about such a concept as «bug clustering».
Bug clustering is a principle according to which 80% of all product bugs are contained in 20% of its components (modules).
«Bug clustering» in a natural environment
«Bug clustering» on a project
This principle is based on an empirical law named after the economist and sociologist Vilfredo Pareto, which states: «20% of the effort brings 80% of the result, and the other 80% of the effort brings only 20% of the result».
But don't take this rule as a motivation to chaotic testing in order to find the grail that contains the cherished 80% of the problems that will allow you to become known as a mega tester and make a key contribution to the project. Now, let's just quote Wikipedia to explain the disadvantages of Pareto's law:
All of the above proves the fact that all projects are different: in some cases, the impact of this law is higher and very noticeable in the sprint/iteration results, and in other cases, it is lower. For example, on a project with many modules, part of which are old while new ones are being created all the time, the principle of bug clustering is very noticeable. At the same time, a product with a minimum of interacting modules will have less significant bug clustering.
Naturally, one might ask: «Why do we need to know about this principle at all?». The answer is that time and money, as the main resources of software development, are limited or restricted. Covering all modules with tests is almost impossible, so you need to be efficient and professionally identify problems and errors within the given time.
Imagine a situation when there is no time to write high-quality test cases and the team has only a simple checklist. This is where the Pareto principle becomes effective. As soon as the first bug, the first problem, or the first discrepancy with the expected result is found, it is worth continuing to look in this direction. It can be compared to a treasure hunt, where an adventurer, like a tester, taps a stick on a surface in search of cavities behind it and then continues to move along the newly found path. But it doesn't mean that you should drop everything and concentrate as a team on the module where the first bugs were found, as there are still flaws in this rule that were mentioned above.
Based on the experience of many testers, it can be said that having quality technical specifications/requirements/friendly developers, as well as product understanding and past experience, significantly increases the effectiveness of this law.
Therefore, it perfectly fits the main ideas of the Agile team, makes the task easier, increases the speed of work on the project, and makes it more efficient.
Another interesting feature of the Defect Clusters principle For example, when one of the modules at each sprint generates the majority of bugs, or there are few bugs, but they repeatedly occur, it is a good reason to think twice whether it is worth it to keep implementing it in the current way. The reason may be due to the conflict between old and new modules, or because of new developers, and as a result, the quality of the new code is not as good as the previous one. Pareto's law allows us to look at solving the problem from a different angle: maybe we should revise technical specifications? Or maybe it is easier to stop supporting such an old module and put the effort into writing a new one that will perfectly complement the current module.
But you might ask, how is QA related to it? The fact is that getting rid of such a module will solve the problem much more efficiently and easily than testing it, which requires more and more effort from the testing team with each iteration. In this way, the Pareto principle helps to improve the product quality, and the QA team can devote more time to the rest of the functionality.
Based on statistics obtained by an independent international IT research consulting company, 45% of the program's functionality is never used by users, 19% is rarely used, 16% is sometimes used, and only 20% is used frequently or constantly. Therefore, we can assume that by focusing most of the attention on these 20% of the functions frequently used by users, it is possible to obtain more benefits than otherwise.
The fundamental principles of testing may initially seem too monolithic and inapplicable. However, it is only by analyzing the previous stage that we can piece together the mosaic, and we can say that the principles of testing are hidden in the little things, which seem unrelated at first glance, but in retrospect complement the picture they describe. You shouldn't neglect them, but you also shouldn't try to apply them on your first day of work. The more experience you have, the more often these principles are applied, and even if you don't think about using them, it becomes natural.
