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.

Setting up automated systems for reporting bugs to team members

During the course of a project, the most important phase for the development / testing team is the phase where code is written, tested, bugs found, and fixed. This is a cycle that keeps on happening, and developers / testers are fairly used to this cycle. AS a part of this cycle, there are typical limits fixed on the number of bugs that a person can have in their court, as well as the amount of time a bug can sit in someone’s court without being acted upon. Now, such information is not normally available, and needs the use of some tools to mine this information and then present it in a desired form to the team members.
In the case of our cycle, we needed a lot of information:
– Number of bugs with each developer and tester
– The priority of bugs with each developer and tester
– The amount of time bugs had been sitting with the developers and testers
There were others, but for now, let us assume that this is basic information. Some of this information is needed for the individual developers and testers so that they have a good idea of how much soup they are in, and whether they need to step up their efforts to resolve the open bugs open with them.
Then the managers of the team also need statistics about the bugs to better take decisions. Suppose, you as a manager of the team find that the number of bugs open with some team members is very high; this would take you to the conclusion that these bugs cannot be fixed in the given time available with the developer along with the development work pending. Such an analysis can lead to the decision to reduce the scope of work that is still pending in order to ensure that there is enough time to resolve the open bugs and do feature work without compromising on quality, and also without pushing the development team to breaking point.
For all this, there is the need to get such information available readily. In our case, we had a tool that could mine the defect database repository and get the relevant data as required for the different stakeholders. We had set up this tool to send the various reports by email at defined time intervals (for example, the data about overall bug statistics was generated at the end of the day so that we could get information about progress during the day while the actual bugs with the development and testing teams was reported to them in the morning so that they could have information about their bugs once they were ready to start work).
We did have some cases where individual team members ignored these emails, but for the most part, these reports were very useful and provided a big help during the time when quick decisions were required to be made. Earlier, we used to do these data analysis manually, and that took a lot of time and resulted in a higher number of errors.

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>