During the course of a software development project, one of the most critical workflows is the defect workflow. The software coding team releases features and code to the testing team, which tests these features against their test cases and if there are defects, these are typically logged in a defect tracking system where their progress can be monitored and they can be tracked to closure (either with the defect being closed and an upgraded feature released, or with the defect having been closed as not to be fixed or not even being a defect at all).
However, this is an area that leads to a lot of dispute. There can be significant discussions and disputes between the coding team and the testing team over what the severity and priority of a defect can mean, and from my experience, what I have seen tells me that even if one were to define a sort of standard for these terms across the organization, individual teams still need to work out their own precise definition of what these terms mean. Even more critical is the fact that individuals coders and testers also understand these terms and even though these can be subjective criteria, they also have developed a level of understanding with their counterparts in the different teams so that even though there may be some dispute over these terms when applied to a specific defect, the individuals can work it out.
Even though I stated some easy solutions in the above paras, there are many complications that come about during the course of a software development project. For example, there can be senior coders who have a lot of heft and hence can speak with a lot of authority to members of the testing team. I remember a case where a senior developer called a new tester and asked him to explain the defect he had raised - it was marked as a very high severity and the developer felt that it was a side case and should not have been marked as a very high severity. This discussion ended with a conclusion, but there have been other cases where the tester felt that they were right and resented the fact that the developer used his / her seniority to try and talk them down. These issues can become serious if they happen many times, and it may become necessary for a defect review committee or the respective team leads/ managers to resolve these kind of issues. Because human nature being what it is, there will be teams where you will have some individuals who get into these sort of disputes and they need to be resolved quickly.
For the above case, I remember one team which took a more drastic approach. They had set up an defect review committee that met once every few hours and every new defect that was created had to be reviewed by the committee before it could be taken up for any action. Without trying to criticize, it did seem odd because it meant the senior members who were part of the committee had to spend their time even on trivial defects that could be in most cased discussed and resolved between the developer and the tester.
Another problem that seemed to be happening at regular intervals was when a new member would come into the team, whether through new hiring or through a transfer from another team. People from another team could sometimes cause more challenges since they would have their own conceptions of the defect workflow and would find it hard to understand why this team may have a different version of the same. In these cases, some amount of hand holding by a more senior member of the team would really help.
These cases can go on and on, but the basic idea is that there needs to be a spirit of discussion and cooperation between team members that will help to understand these workflows and follow them in a manner that reduces disputes.
However, this is an area that leads to a lot of dispute. There can be significant discussions and disputes between the coding team and the testing team over what the severity and priority of a defect can mean, and from my experience, what I have seen tells me that even if one were to define a sort of standard for these terms across the organization, individual teams still need to work out their own precise definition of what these terms mean. Even more critical is the fact that individuals coders and testers also understand these terms and even though these can be subjective criteria, they also have developed a level of understanding with their counterparts in the different teams so that even though there may be some dispute over these terms when applied to a specific defect, the individuals can work it out.
Even though I stated some easy solutions in the above paras, there are many complications that come about during the course of a software development project. For example, there can be senior coders who have a lot of heft and hence can speak with a lot of authority to members of the testing team. I remember a case where a senior developer called a new tester and asked him to explain the defect he had raised - it was marked as a very high severity and the developer felt that it was a side case and should not have been marked as a very high severity. This discussion ended with a conclusion, but there have been other cases where the tester felt that they were right and resented the fact that the developer used his / her seniority to try and talk them down. These issues can become serious if they happen many times, and it may become necessary for a defect review committee or the respective team leads/ managers to resolve these kind of issues. Because human nature being what it is, there will be teams where you will have some individuals who get into these sort of disputes and they need to be resolved quickly.
For the above case, I remember one team which took a more drastic approach. They had set up an defect review committee that met once every few hours and every new defect that was created had to be reviewed by the committee before it could be taken up for any action. Without trying to criticize, it did seem odd because it meant the senior members who were part of the committee had to spend their time even on trivial defects that could be in most cased discussed and resolved between the developer and the tester.
Another problem that seemed to be happening at regular intervals was when a new member would come into the team, whether through new hiring or through a transfer from another team. People from another team could sometimes cause more challenges since they would have their own conceptions of the defect workflow and would find it hard to understand why this team may have a different version of the same. In these cases, some amount of hand holding by a more senior member of the team would really help.
These cases can go on and on, but the basic idea is that there needs to be a spirit of discussion and cooperation between team members that will help to understand these workflows and follow them in a manner that reduces disputes.
