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 1

Once a team is involved in the development process, one of the most critical aspects of the entire process is that of handling the bug/defect flow. In simple terms, the flow is something like this
– A defect is found by somebody who is doing the testing,
– The defect is then logged along with a severity / priority attached to the bug,
– It is then assigned to somebody in the team who has to take a look at the defect,
– There are timelines assigned for this defect (these are mostly done at severity priority level),
– If there are certain important aspects of the defect which lead to a prioritization then those are also captured (for example, a defect in a certain could be very important for the purpose of an interim release of the software and that means that such a defect needs to be fixed earlier to other defects),
– The developer works with the testers to figure out the conditions in which this bug was found and if there is more such information required,
– The developer fixes the bug and marks it to the testers for them to verify the fix (and ensures that the defect is available in the next code drop that the testing team gets (or they get an updated installer),
– If the tester determines that the bug has indeed been fixed, then the status of the bug is changed to mark that it is indeed fixed (although if it is a critical bug, it could be marked further to ensure that the bug is re-tested near the release date of the application). If the bug has not been fixed completely, then the bug status is reverted along with comments to let the developer know that the bug needs to be fixed. It is also possible that the defect may be have been fixed partially, in which case the status will be marked as the same, and then either the tester or a bug review committee will determine whether the amount of fix is enough and the bug can be closed, or whether the bug needs to be sent back for fixing
– As the cycle progresses and the end point of the product comes closer, bugs that are relatively less important would be identified through a set of filters and then it can be determined about whether some of those bugs can be closed (or marked to be fixed in the next version of the software), or whether some of those still need to be fixed in the remaining time (typically, it is always such that some of the bugs need to be fixed in the given time frame, while the less important bugs can be marked for the next version of the product and closed). This decision is not an easy one though, since bugs can still impact users, and that makes the task of deferring a bug not an easy one.

Now, a lot of the process defined above works well when there is a standard bug database that can be accessed by the stakeholder of the defect life cycle and whether everybody agrees with the rules defining the movement of bugs and their status in the bug database. And that is the main topic for the next post in this series (Defining processes for using a defect database – Part 2)

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>