A defect database is an integral part of a project development cycle, providing the tool where the defect life cycle plays out. It is from the defect database that the team gets a good idea of how well they are doing, whether the defects that they are getting indicate that the current quality levels of the product at this stage of the cycle are better than expected, or worse than expected. I have known teams experienced in their product development processes who get worried when they don’t see an expected number of defects during the cycle, since then they are worried about whether the testing is unveiling enough bugs, or whether something is getting missed. Because of the fact that the defect database is so important (including the processes that surround it), it is important for teams that do not have well defined processes around the defect database to spend time working through the operation of the defect database, mapping their expected defect life cycle to the way their defect database is configured, and ensuring that everyone in the team has a good understanding of these processes, in order to avoid confusion. Even when there is conflict around the interactions in a defect database, the team members should know the way that they need to proceed to resolve such defects, else such situations can become tense and also escalate to a point where managers are required to step in. In the previous post (Using a common bug database and defining some rules – Part 4), I talked about the different priorities that can define which defects need to be prioritized first and the time spent in preparing for these. In the current post, I will talk about viewing some statistics on a defect database to see whether people are getting too loaded.
When a team is heavily loaded, or they are taking on a totally new feature (versus working on modifications to an existing feature), there is a much greater chance that the number of defects that will be found will be much higher. This could be because existing features have already been tested before and hence a number of bugs would already have been shaken out, and also because the testing team would be giving a fresh look to such a feature, testing it from the ground up rather than the more limited testing done to changes in an existing feature. So, when a developer is working on a new feature, the number of defects (with different severity levels) has a chance of being higher than average.
What does this mean ? Well, this is where the concept of a cap on the number of defects per developer comes into existence. This could be an overall cap based on just the absolute number of bugs against one or more developers, or it could be based on the number of bugs of a specific severity. The logic goes that when the number of defects against a developer goes very high, then it is time for the developer to spend time to fix these defects rather than also working on their existing feature development work. When a defect is open, the defect could be such that it could be fixed and tested later without much impact; on the other hand, the defect could be such that it will force a change in the logic and hence there would be a need for such re-testing the affected area. When there are a number of such defects that are open, it leads to a situation where once the defects are fixed, there will be the need for re-testing of some of these areas. In such cases (and in many others that are not detailed here), it would be far more beneficial if these defects are fixed now rather than later.
Hence, teams need to put in place a process whereby there are rules for when the developer needs to stop further development work and start fixing of defects to bring them down to a specific level (and this can take into account the severity levels of defects with them) and then they can re-start development. This may seemingly impact the delivery of features, but it is actually a manifestation of quality first and should be implemented. To do this will need a way to abstract the number of defects per developer as well as the severity using the defect database on a regular basis.
Read more about the processes regarding defects (Bug database and defining some common rules for stakeholders – Part 6)