Defect Tracking System – Wastage of Money & Time ???

As a QA I have been logging bugs since 5 years. But what do we do with that ? A typical flow:
If this is the only thing we need to do then why taking so much of pain to have a defect tracking system.
To log a standard bug (Standard Bug= Broken Functionality), we need to write steps to reproduce, pre-requisites (if any), expected result, actual result, priority, severity, snapshot (if any), Test environment details and finally save it. This takes around roughly 3-5 minutes to log a bug. To say truth, I have never seen any report coming out of defect tracking system which is of use in analyzing the pattern of bug or finding out any trend in them. All I have seen apart from tracking usage, is the summary of bugs with count based on Priority and Severity. Is that the only purpose of Defect Tracking System? If that is the case then why not use a Google spreadsheet rather then investing money of the company and time of QA in a bug logging system. I am sure if we mine the data which is created by bug logging system we are bound to get some real useful information on the project like quality of the code, bug density apart from Bug Convergence, bug resolution rate etc.
So I think if we are using the defect logging system just for tracking bugs and having a count of them, then I would strongly suggest to use an excel sheet. Allow a tester to test more rather than spend more time on logging.


  1. Probably you will find some answers from the following link.

  2. Dude that pdf doesn't answer that question!
    We have information but my concern is what's the use of creating such huge information which comes at the cost of "Testing Time" and no one bothers about it once the bug status is "Closed".

    Nishant Verma

  3. I recommend you try Assembla's bug tracking tool is the easiest one available and it only takes seconds (I mean it!!!) to log a bug, assign it and prioritize it. It's REALLY easy and time saving (they use a system like gmail stars) and have lots of cool features.

  4. @Anonymous Friend I am not looking for any alternative Bug Tracking Tool, I am more interested in using the data which is collected out of Defect Tracking System.

    Thanks for the tool you suggested. I will definitely have a look into it.

    Nishant Verma

  5. It'd be interesting to hear what you have to say about even tracking the severity and priority in the first place.

    My current thinking is that it seems to take up time and creates confusion about what we should actually should be fixing. It gets worse when we have a 'quality gate' of severity of bugs that we should be fixing.

    For me it seems much simpler to just state whether or not we are going to fix the bug for the next release or not. If we're not then why are we tracking it anyway? And for the bugs we care about just out them in priority order on the wall and let people pick them up.

    Do we lose anything important by taking that approach?

  6. @Mark I feel 'Severity' and 'Priority' makes sense at least to the people in Triage process (When concerned QA who has logged the bug is not around).
    But I agree with you that we need one more field should be present which says whether the bug will be fixed or not?

    We know in Triage we basically take a call on all the bugs logged and de-prioritize the one which are not to be fixed.

    So I suppose Mingle should add one more field "To be Fixed" :)



Post a Comment

Your comments will be reviewed and then published !

Popular posts from this blog

The 3 qualities that will always help you become better at almost anything…

Test Case Paths : Happy, Sad & Bad