Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Bug ageing – why it is important to follow in a software project

First of all, what is bug ageing ? Well, in a very broad sense, bug ageing is the amount of time that a bug is with a certain person. A bug can follow many different paths during its history – the bug can be with a developer, pending for the bug to be fixed. The bug can be with the tester, pending some information to be provided to the developer or when the bug is marked fixed, or the bug can be with management, where they weigh the cost vs. benefits of the bug and decide on a future course of action. In a typical scenario, all these bug actions happen within a short period of time and the bug is resolved (fixed, deferred, or withdrawn) with a short period of time.
However, there are numerous cases where the bug is not fixed quickly. There can be multiple reasons for the same:
– The bug is with the developer, but the developer has a large number of bugs on their plate and hence is not able to give this specific bug the priority that it deserves
– The developer has been told to focus on a specific product area and hence is not able to focus on bugs from other areas, and hence these bugs remain unattended for some time
– The bug is marked in an area which is going to be handled at a future part of the schedule and hence the bug is marked to be fixed when attention is provided to the area further on in the schedule
– The developer wants to get the number of bugs on their plate down, and hence focuses on the bugs that are easier to fix, and tougher bugs have to wait for more time before they are given attention
– It is not easy to recreate the conditions in which the QE found the bug, and hence the developer, showing signs of inertia, is waiting and will push the bug fix when he / she had more time

Similarly, the QE could be having a number of reasons for delaying the bug fix. Some of these are:
– The QE is very busy in testing a specific area of the product, and is not able to spend time on the specific bug
– The bug may have been filed by somebody else, but is assigned to a specific QE because that is their area. As a result, the QE is not very enthused about the bug (no ownership feeling over the bug)
– The QE has a large number of bugs, and the scenario to resolve this bug means using a much older build (and installing the latest build and removing a later build takes time (with larger applications, this could mean as much as 1-2 hours just to install a build)); hence there is inertia in going ahead in recreating the bug

In all such cases, when bugs wait a large amount of time to get resolved, there is a pending time bug. One of the biggest problems in older bugs is that, when a bug would have been filed many months ago, the dev or QE lose track of the scenario in which the bug was filed (even though the steps would have been written down) and find it harder to replicate the bug as time increases.
I will write more about this case in the next post ..

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>