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 6

This is a series of posts on how to use a defect database as part of a development process. A defect database is an integral part of how a team works, but there can be a lot of complications over the usage of a defect database unless all the processes are well defined. When teams are under stress (and software development schedules typically leave teams in some sort of stress), there can be a lot of stresses in the team, especially between the development and the testing team over the treatment of defects. When there are well defined processes on the movement of defects, the creation of defects, and other such parts of the defect life cycle, the scope for such disagreements is significantly reduced. Importantly, a defect database is not just meant to capture defects, but it is equally important to mine the database and generate reports for the team. In the previous post (Using a common defect database and defining some common rules – Part 5), I talked about setting some caps on the number of defects that could be held by a particular developer’ this ensures that the changes in the product caused by the fixing of such defects is done early, and also ensures that too many defects do not get piled upon a particular developer. In this post, I will talk about some reports and information that can be generated from the defect database.
It’s not only about the total count of defects, but also about the age of open defects. Bug ageing is an important factor that needs to be evaluated as part of the overall processes regarding defects. Consider that a defect has been open for a long time. When this happens, it becomes difficult for the tester to remember all the details about the defect that was logged by the same tester; the situation in terms of the product may have changed significantly after more changes in the code (the defect having been filed a long time back) and hence the defect not being found now, or being found in a changed state; the defect having got fixed as part of another defect leaving the earlier defect in a uncertain situation. In fact, I have seen that in many cases, when a defect has been open for a long time, the defect is eventually closed by the team since it is no longer present in the original form in which it was filed.
It is also bad for morale within the testing team, since it means that even though the testing team has been finding defects, there is no guarantee that the defects that they found are getting fixed within a reasonable period of time (this period of time is a subjective parameter and needs to be defined by every team). So what needs to be done ? Well, as a part of defect life cycle processes, there should be timelines fixed within which a defect should be resolved (fixed / closed / deferred). This ensures that all defects are closed within a reasonable period of time, and eventually works out better for the team (although I have seen that many developers are resistant to such an idea initially and it takes time for them to be comfortable). The monitoring of whether this process is working or not can be done by reports taken from the defect database.

Read more about the processes involved with a defect database (Using a common bug database and defining some common rules – Part 7)

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>