1. ## Defect clustering

hai

can any one help me with Definition of defect clustering

2. ## Re: Defect clustering

In simple terms density of bugs is called as defect clustering

3. ## Re: Defect clustering

[ QUOTE ]
In simple terms density of bugs is called as defect clustering

[/ QUOTE ]

??? I've never heard density being equated with clustering.

Density usually refers to the amount of bugs in a given amount of code. (ex/ 5 bugs per 1000 lines of code)

Clustering usually refers to the fact that bugs (defects) tend to gather in particular places within the system. (ex/ bugs might cluster in code developed by a particular developer, or might cluster in the error handling portion of a system)

Yuva - h\How did you come to define these terms as being the same?

4. ## Re: Defect clustering

I think he meant a higher density in a certain part of the code or application then compared to other parts...

5. ## Re: Defect clustering

Joe made the point clear, density has got nothing to do with clustering. Yes, yuva could have meant "higher density" but even then that is not what is "important" about clustering.

Many things in the world reflect the "principle of factor sparsity" and Software Testing is no exception. For example, in two dimensional arrays used in most programs, we find that they are sparse. Let me make it simple here- long ago, an Italian economist named Pareto highlighted that 80% of Italy's wealth was owned by 20%. From then onwards it has become a generic tool of conclusion, and was applied to many things of the world we live in.

There exists a hypothesis (with a reasonable amount of reality in it) that bugs are typically clustered in one area. Something like 80% of the defects being present in 20% of the overall codebase.

So, when you hear that an application has 1000 known bugs and look at the detail of their distribution, many of them perhaps originate from 20% of the modules therefore forming a "cluster of defects".

If you were to buy this principle, then you have to start thinking of where you can apply this- one example would be to suspend testing if you sniff a cluster (instead of finding all the rest of the defects, perhaps an upfront alert from the testers could make the developers seriously review that portion of the app again in a hope to fix the found + about_to_be_found defects). This requires speculative intelligence and is risky, though there is an engineering endorsement to the principle. Another example would be (in case where the project is over and the test summary information is available for post-mortem), one could do a thorough Root-cause-analysis on the cluster.

And so on.

-------------------------
Disclaimer: Bujji_aus, please pardon me if you were looking for just a vanilla definition and find the above answer purposeless.

6. ## Re: Defect clustering

[ QUOTE ]

Disclaimer: Bujji_aus, please pardon me if you were looking for just a vanilla definition and find the above answer purposeless.

[/ QUOTE ]

No need to excuse yourself when you give a good answer. If someone is looking for a vanilla definition of just about anything we do it'll be difficult to get across with any sort of clarity.

I actually appreciated the description. Also, thanks for dropping in the little note that it's a risky practice, because a lot of what we do is based on risk. I don't think we ever make a decision in QA that doesn't involved some amount of risk. If we test using a certain methodology, then we will neglect another, maybe better, way of doing things. A way that would expose more issues. If we try to implemnet a number of methodologies, we don't get the same depth. If we make assumptions about the stability of a product, we are setting ourselves up for failure.

All of the above involve risk, and clustering is no different. What you need to do in cases where you think you're dealing with higher levels of risk is track your efforts. Gather historical data. Make a more logical decision as to why you are doing what you're doing. It could be that investigating for a cluster of defects might be the right solution, but you will need to take that initial leap of faith in order to get to the conclusion.

As long as you can justify your reasons for doing it, then go for it. I wouldn't advise attacking an area based purely on speculation, but if you have historical information to back it up, then blast away.

7. ## Re: Defect clustering

To tip me off to bug clusters, i often look at change sets from version control systems.

because a developer saying "yeah i made a small fix in module X" could really mean "i made a one line change", or "I refactored the whole module and added 10k lines of code".

checking the number of changes in a new build can be a good indicator of areas to concentrate on and where clusters of bugs might be lurking.

8. ## Re: Defect clustering

I miss the days when I was able to check how much change was applied to the source code.....

9. ## Re: Defect clustering

[ QUOTE ]
I miss the days when I was able to check how much change was applied to the source code.....

[/ QUOTE ]

I miss the days when I was able to check how much change was applied to the source code.....and take FULL responsibility for every error in the system because I should have found the bug in the code, since I had access to it.

10. ## Re: Defect clustering

&gt;&gt;[ QUOTE ]
To tip me off to bug clusters, i often look at change sets from version control systems.

[/ QUOTE ]

I 'want to' miss the days when I will be looking at the code and making my next test steps.

IMHO, 'Changes to the Code' hinting the next test steps (and clusters etc) is a reasonable postulate in the case of atomic software utilities that are backed by one fragment of an algorithmic routine. And also in cases where we are talking about a one-man army behind a software product.

In medium-to-large applications, 'changes to the code' hinting the 'command structure of software testing' is not a wide practice and is highly debatable.

Finding Clusters in my experience was an aftereffect of Software Test cycles and that only meant some analysis of the causes.

One (good) exception to this were cases where some smart(?) Software Testers raising a flag saying that 'looks like there is a cluster of defects in this particular aspect, can you please review and let us know whether we should proceed with further tests?'.

Page 1 of 2 12 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.