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 3

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 2), I talked about whether the defect database is a web based database or a client-server database that depends on a client application running on the machine of the users; the previous post also talked about ensuring that there is a good description of what a defect is and how to decide in cases where there is a dispute of whether a particular issue is a defect or not. I will continue on this topic in more detail in this post.
I have seen 2 types of processes, something which varies between team to team, and which also varies depending on which phase of the schedule you are in. If this has lead to some confusion, let me explain further. I have seen teams where every defect coming into the system is analysed by a person or a team before they are sent for fixing, and other teams where these defects are automatically assigned to specific developers for fixing.
– Let me take the latter part first. In this case, the defect database would have a feature where the different product categories are mapped in the database and each product category is mapped to a default developer. When defects can be automatically assigned to the development team, then the benefit of this feature is that the tester searches for the product category when creating a defect, and when the defect is created, it automatically gets assigned to the relevant developer. This was a feature that was not present in the database we were using for a few years and got added a couple of years back. You would not believe that amount of time this saved us, since there were times when a developer had free time and it took time to get the assigned defect to the right developer, and with this approach, time got saved. We estimated that it saved us around 5% of time in turning around defects.
– The other approach is where bugs are reviewed by a person or by a committee and only then it is decided whether the defect is needed to be fixed or not.

Why would you take one approach or the other ?
Well, there are several reasons why a team would want to ensure that all their defects are reviewed before they are sent on for fixing:
– The logic of the application is complicated, and there is a need to ensure that a defect is monitored before (and even during and after) the fixing of the defect is done by the developer. This will ensure that the defects are monitored and any logic changes can be evaluated before the defects are actually committed into the system.
– The testers are new, or they are external (such as vendors), and they do not have the experience that testers who are experienced with the application have. As a result, defects that may be logged may already be known, or may not even be defects. It can be a severe waste of time, and yet this is a known problem when new testers are brought into the system, and really cannot be avoided. It is easier to ensure that their defects are evaluated before they are passed onto the development team, and they are given feedback about the quality of their defects.
– It also depends on the timeframe of the schedule. For example, when the product / project is near the end, the amount of risk from a wrong defect fix can be a problem. Hence, it would be a part of risk mitigation to mark all such defects for evaluation at a certain point in the schedule of the development milestones and only pass on those defects that have been marked as necessary to fix.
– When the overall number of defects being generated is low, then teams can easily take on the overhead of evaluating all incoming defects and only mark passed defects for fixing.
– Another advantage of evaluating all incoming defects is that these defects can be properly assigned milestones and priorities for fixing, depending on their severity and importance, something that is very important. You would want to segregate the more critical and important defects for early fixing rather than the non-critical defects.

More on this overall topic in the next post (Using a common defect database and defining some common rules – Part 4)

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>