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 – Part 2

In the previous post (Bug ageing and software projects), I talked about the concept of bug ageing and why it is important. In this post, I will continue on that topic and write more about this area.
One of the biggest problems with bug ageing is that the more time there is between when a bug gets filed and when it finally gets seen, the sequence of steps gets lost. I have seen people insisting that if you document all the steps that you take while filing a bug, you will be able to reproduce the bug. Hogwash. This may not work in every scenario. For example, when somebody is writing the steps for a complicated crasher bug that happens once in a while, there are a number of factors at work that could have caused the crash in the application. It is only the perfect person who is able to reproduce all the twists and turns that they took which caused the crash. Suppose you have an application that allows you to add text, images and sounds while creating a greeting card, a crash that I have seen came during a specific situation when a sound was added, then a video, then text, then the sound was changed, and the text was modified. Now, when you increase the number of steps, it is going to be harder to reproduce such a crash, especially when you are called upon to do so many weeks later. As a result, we set the condition that all crashes need to be looked at within 48 hours of the crash being reported, so that we don’t lose it. The tendency is simple to let the crash go out, since it came in a complicated scenario; but guess what, with so many people coming online to express their opinions, things get very complicated. For a crash, which seemed a low scenario, we had a user lose around 1 hour of effort, and the amount of feedback in user forums was incredible to see; and we use that scenario as an education to people about how not to let such significant items such as crashes go by.
The other major problem with taking time to resolve a bug is due to environmental factors. Suppose a crash is reported, and part of the problem is the interaction of some components on the machine of the tester with some components inside the application. Over a period of time, with system updates, other applications getting modified, or other environmental conditions, this crash or bug is not longer visible. The developer does not have a reproducible scenario, but has to fix and resolve issues. In this case, most of the time, eventually the bug is let go as not reproducible, and we end up with a possible user crash scenario that we could have fixed, but were not able to find because the base environmental factors changed in the meantime. All of these end up with some costs that we have to pay later.

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>