Bug clustering is one of 7 main testing principles and it’s not just a theoretic term as it seems. Most testers who have real experience working on the projects will confirm this statement.
Yes, when you study some of the projects for the first time, they seem to have nothing to do with clustering since the defects are present in different parts of the project (development, management, testing, etc.) But, actually, it’s an exception.
Let’s analyze the term “bug clustering” more thoroughly.
Bug clustering is the main principle that says that 80 % of all defects of a product are in 20 % of its modules.
This principle is based on an empirical regularity named after Vilfredo Pareto, a famous economist, and sociologist. It says that “roughly 80% of the effects come from 20% of the causes and the rest 20 % – from 80% of the causes.”
It doesn’t mean that according to this rule, you should test a product randomly, searching for the Grail which includes all those cherished 80 % of defects which will help you to become a first-class tester and to improve the quality of the project. You shouldn’t reinvent the wheel.
As you can see, the Pareto principle has its drawbacks. Let’s talk about them:
- In the first meaning (not taking into account 80 and 20 percent), this rule is only an investigation when the events develop in such a way that we receive the results after executing numerous various factors, and value of every such a factor is often different;
- From a mathematical point of view, the numbers stated in the principle are not absolutely correct:
- When we work on a project, in reality, distribution of importance of factors can be different and we can’t be absolutely sure that it will equal 20 and 80 %;
- We can be absolutely sure that certain data of distribution can be changed even during the analyses of equal values. For this, we need just to change the rules of data grouping, chosen randomly.
Thus, all projects are different: some of them are more influenced by the Pareto principle and some are less. For example, a project that has many parts and half of them are outdated, and another half is constantly being developed, will clearly show the execution of the bug clustering principle. And vice versa: a project with a minimum number of modules won’t show an evident bug clustering.
And here a question arises: “So why should we be familiar with this principle?” The answer is simple -“time is money “: since the main software resources have restrictions and limitations. It’s impossible to cover everything with tests. Therefore, it’s important to be able to efficiently and rapidly find the bugs and issues on time.
Let’s imagine that you have no time to create test cases and a team works on a simple checklist. And here the Pareto principle works.
We can say for sure that after we have found a first defect, a first issue which interferes with receiving a necessary result, we should continue searching in the same direction. But this doesn’t mean that we should focus all our team’s attention only on the part of the product where the first inconsistency has been found. We shouldn’t forget about the weak spots of this principle which were mentioned above.
The Pareto Principle
According to experienced QA consultants, we can make a conclusion that by having a qualitative technical assignment, properly stated requirements, communicative developers and also understanding the nature of a product and having previous experience in this field, we can improve the efficiency of this principle.
Therefore, the bug clustering principle supplies well the main ideas of an Agile team, gives a possibility to simplify a task, make work absolutely efficient and facilitate the process of the project completion.
One of the interesting peculiarities of the bug clustering principle is the possibility to analyze the information according to the results received after testing. This allows finding the weakest spots of a product and analyze them one more time.
For example, if one of the components in all sprints creates numerous defects or there are few of them but they are constantly appearing, we should think about the fact whether we should implement it in such a way. This can be possible due to the conflict between the created and new modules, adding new developers to the project and therefore, a mismatch between the old and new code.
The Pareto principle states that we may try to solve the problem in a different way: perhaps, we should study and change a technical assignment. Or maybe, it’s better to write a new module that will work properly with the present one than to use an old module.
After analyzing this situation, it seems that it has nothing to do with QA. But it’s not so easy as it seems. After we stop supporting an old module, it’s easier, faster and more efficient to solve the task than to test it. Therefore, the Pareto principle helps to improve the quality of the developed product, and a QA team, in its turn, can dedicate more time to improving the other functionalities.
According to the statistic data received by an independent consulting company focused on studies in the IT field, 45 % of the program’s functionalities are never used by the users, 19 % of them are rarely used, 16 % – occasionally and only 20 % – are frequently or constantly used. According to these numbers, we can suggest that by paying more attention to the 20 % which are used the most frequently, we can receive a better result than by using another principle.
Basic laws of testing can firstly seem useless in real life. Only while analyzing every stage of a work process, everything is analyzed as a whole and this may help us to conclude that the laws of testing hide in simple things which aren’t seemed to be connected in any way but actually, they complement the overall picture.
We shouldn’t forget about them but it’s also incorrect to focus exclusively on them on our first workday. The more experience you have, the easier is the implementation of these laws, and sometimes you will use them automatically not even thinking about them.
Leave A Comment