This is a series of posts on the bug/defect life style during project/product development. I am not getting into the theoretical diagrams and all, think of this series of posts is more related to the way that things happen on a day to day cycle during the development process. In the previous post (Using a common bug database and defining rules – Part 3), I talked about situations where the team would have a process whereby all the defects that had been created would be set to go the individual developers who own different areas of the product, or you would have a situation where all the new defects would be assigned to a specific person or a committee which would review the defects and then decide whether those need to be assigned to developers, or whether they could be set for non-fixing or fixing at a future point of time (the next release). This post will talk about some more processes that govern a bug database and the interactions between the teams during the defect life cycle.
Similarly, we had another problem related to a defect that was important for the ongoing localization of the product and the testing by the vendors who were doing localization. The defect was not super-critical for the feature team, but it was breaking the localization of a specific portion of the product and was costing us money in terms of vendors who had to wait for the product to be ready for testing. Such a defect would also need to be classified as super-critical.
The basic idea is that there needs to be a process and protocol to classify the schedule of defect fixing and their importance. I have seen teams start out with the basic idea that a super-critical defect is only those which cause loss of functioning, or which cause data loss. And then when they enter into the realm of where a defect that was not seemed critical where the defect was found actually should have deemed critical because of the dependencies involved in the product. If the managers of the team are ready for such a situation and have better processes of how to classify the severity of a bug in terms of fixing it, then there will be less confusion when the team actually gets into such problems. And all of this needs to be captured in the rules used in a defect database.
Read more about such processes and challenges in the next post (Using a common bug database and defining some common rules – Part 5).