I would be interested in learning how different organizations (or defect tracking systems)approach the problem of distinguishing between software defects ("bugs")and the manifestations of those defects (observed failures.
For a long time we made no pratical distinction between the two in our proprietary defect tracking system. However, circumstances change.
Testers tend to be more interested in documenting the failure with respect to where it is observed and where the fix may be verified. Developers naturally are more interested in associating the actual defect with the unit or program it occurs in.
The problem is administrative as much as anything. I would be interested in the perspectives of those who have negotiated this issue before or who have a broader experience of defect tracking systems.
A few questions and ideas come to mind as I consider this one.
Are the testers performing black box or functional testing only? If they are, then it would be reasonable to say that they cannot identify where the actual bug "lives" in the code. While they may be able to make some educated guesses, pin-pointing it is not a fair expectation.
If the testers are performing gray box or white box testing, then they may well be able to identify the "exact" location of the bug.
The shops in which I have worked have all handled it the same. The testers report the bug INCLUDING the steps necessary to duplicate the problem. (It is understood that not all problems are always "re-createable".) The developers then use that information to determine the location of the bug.
It is my experience that most developers do not want QA types mucking about in "their" code. That same experience also sees QA types not wanting to muck about in the code either - unless it is testing designed to be at the code level.
If the shop is one that practices "throw it over the wall", then both QA and the developers tend to operate in a vacuum. Expertise in writting AND reading becomes very necessary to (dys)function like that. Collaboration where each side is able to interact with the other directly provides for better communications.
Finally, I tend to see things from a people point of view even though I am one of those "geeks" who does computer stuff for a living. Even in shops where there was a wall, I went through, around, over, or under it to increase the efficiency in communication. Be warned, that can get someone into a whole lot of trouble.
Most of the times its only the Organizations who are on the look out for these data.Since it helps them a lot in "Defect Prevention.".
The Bug Tracking Systems can only help us take some reports from them based on the columns that you are utilizing in ur tool. The Actual analysis has to be done by the Big People. It would defenitely help in finding out the most problem prone area and also the areas which can potentially have inductive effects(side effects), when a bug is fixed. And also it helps the organization find out the who has more bugs assigned.Offcourse it can't be decided just becoz one developer has more bugs he is inefficient. It all depends on How critical/difficult the task on hand.
One thing that can really help in "Bug Prevention" is to have Bug Pattern and Bug Variance Reports.
[i]Work Like u don't need Money...Love like u have never been Hurt...Dance Like Nobody is Watching...Sing Like Nobody is Listening...Live like its Heaven on Earth!