SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 5 of 5
  1. #1
    Junior Member
    Join Date
    Apr 2003
    Location
    Baton Rouge, LA, USA
    Posts
    1
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Tracking defects vs. failures

    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.

    Thanks
    PaulM

  2. #2
    Senior Member
    Join Date
    Mar 2003
    Location
    Elkhart, IN, USA
    Posts
    264
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Tracking defects vs. failures

    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.
    Michael L. Hovan
    mrschovan@verizon.net

  3. #3
    Member
    Join Date
    Apr 2003
    Location
    London
    Posts
    96
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Tracking defects vs. failures

    Hello Mr.Paul,

    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.
    FC
    [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!
    </i]

  4. #4
    Junior Member
    Join Date
    Jan 2004
    Location
    China
    Posts
    5
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Tracking defects vs. failures

    Hi,RKSharma

    What do you mean by "Bug Pattern"? Can you give me some example? Thank you.

  5. #5
    Member
    Join Date
    Apr 2003
    Location
    London
    Posts
    96
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Tracking defects vs. failures

    Bug Pattern:
    Bug patterns are error-prone coding practices that arise from the use of erroneous design patterns, misunderstanding of language semantics, or simple and common mistakes.

    Take a Look at the following PDF, it explains in detail about the Bug Pattern.

    http://www.cs.umd.edu/~pugh/java/bug...dbugsPaper.pdf
    FC
    [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!
    </i]

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 10.00%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 08:05 AM.

Copyright BetaSoft Inc.