This is a series of posts that talk about some of the processes that are required when we talk about a defect database during a software development process. During a project / product development cycle, the use of a defect database is incredibly important, and it is equally critical that there be a lot of effort spent around the processes for handling the defect life cycle. Consider how to define whether a defect should be high severity or low severity, the timeframe within which a defect should be handled, how to handle defects that are to be raised by external beta customers, etc. In the last post (Using a common defect database and defining some common rules – Part 7), I talked about some of the processes that the team should design for handling defects that would be created by external beta customers, the minimum information that is required from these customers without putting too much pressure on them for creating such defects. In this post, I will talk about some more of the processes that come into play when using a defect database.
One of the most critical issues that come into play when using a defect database includes how to ensure that all the developers and testers get information about the number of bugs that they have in their name. When I first started out as a project manager, it seemed very obvious to me that any serious developer or tester would log into the defect database and learn about the number of bugs that they hold in their name, and that they would have this information available with them almost on a regular basis. It was only later that I learnt about tunnel vision, where the developer and tester were so focused on their work that they did not really know about the number of bugs in their name. One result of this was the need for reminders to them about the defects in their name, and sometimes on an urgent basis when some of the defects that they held were critical. At the same time, this also caused irritation because many of them did not like the frequency of reminders about the defect count, and some who did look at the defects in their name complained that these kind of emails assumed that they were not looking at their emails and were offended by this implication. So, damned if you do, damned if you don’t.
This was one of the most difficult issues to resolve, and what we did was try to setup a system / application where reports were configured. We had a variety of reports that were setup, and set the configurations to be also controlled by an internal web page. At the beginning, we set a list of people for each report, and then gave them the required permissions so that each person could go and set their reports. We had some people come and remove certain reports, but a number of people were satisfied with the reports that they were getting and did not make any changes. In one case, we had a team member who removed a certain report, and was then falling behind in looking at new bugs (which was the aim of one such report which the person had removed). This allowed the manager of that team member to have a discussion with the person, since we had given them the facility of getting reports, and also about removing reports if they were able to handle their defects without the need for such a report, and the person finally went and re-instated the report.
It took some effort to get all these reports going, and there was some opposition to spending the effort to have the reports setting available on a page, but in the end, it played a vital part in ensuring that people were comfortable with such reports.
If you have had experiences similar to this one, please do provide feedback in the form of comments.
Read more in the next post in this series (Using a common bug database and defining some common rules – Part 9 – TBD)