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.

Using a common bug database and defining some common rules for all stakeholders – Part 4

This is a series of posts on the bug/defect life style during project/product development. I am not getting into the theoretical diagrams and all, think of this series of posts is more related to the way that things happen on a day to day cycle during the development process. In the previous post (Using a common bug database and defining rules – Part 3), I talked about situations where the team would have a process whereby all the defects that had been created would be set to go the individual developers who own different areas of the product, or you would have a situation where all the new defects would be assigned to a specific person or a committee which would review the defects and then decide whether those need to be assigned to developers, or whether they could be set for non-fixing or fixing at a future point of time (the next release). This post will talk about some more processes that govern a bug database and the interactions between the teams during the defect life cycle.
One of the biggest problems that happens in a team, especially between the testers and the development team is over the priority in which defects need to be fixed. You would think that it would be simple, right ? Mark defects that are more critical, and fix those first ? Well, this marking as critical is where most of the troubles comes to the team. For example, a defect may not be super-severe in the sense that it does not cause the product to crash or cause any data loss, but the defect may be very important in terms of user point of view, especially when the product is being sent for pre-release to the beta users of the product. Similarly, a defect in an area of the product may impact the functioning of another area of the product and hence may be much more critical (consider an example – we had a problem in the database area where a particular column in a table was not getting inserted. Now this column was only of interest to another feature, but since the integration was broken, the defect had to be fixed as a super-critical defect since the other feature team testing was totally blocked).
Similarly, we had another problem related to a defect that was important for the ongoing localization of the product and the testing by the vendors who were doing localization. The defect was not super-critical for the feature team, but it was breaking the localization of a specific portion of the product and was costing us money in terms of vendors who had to wait for the product to be ready for testing. Such a defect would also need to be classified as super-critical.
The basic idea is that there needs to be a process and protocol to classify the schedule of defect fixing and their importance. I have seen teams start out with the basic idea that a super-critical defect is only those which cause loss of functioning, or which cause data loss. And then when they enter into the realm of where a defect that was not seemed critical where the defect was found actually should have deemed critical because of the dependencies involved in the product. If the managers of the team are ready for such a situation and have better processes of how to classify the severity of a bug in terms of fixing it, then there will be less confusion when the team actually gets into such problems. And all of this needs to be captured in the rules used in a defect database.

Read more about such processes and challenges in the next post (Using a common bug database and defining some common rules – Part 5).

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>