Testers and developers are often in disagreement about the severity of a defect. When there's a disagreement, who gets final say?
Definitions of severity and priority are often the subject of great debate in development and test organizations. Some groups use a combination of both to help determine the priority of what should be fixed before a release goes live.
For example, some groups define severity based on how important the fix is for the customer. Priority is a combination of severity and how easy the fix is to code. A Priority 1 defect would be one that is the most important to the customer and easiest to fix. Priority 4 would be those that are the least important to the customer and hardest to fix. Categorizing in this way would help the team decide which defects should be fixed first.
Other groups don't use either Severity or Priority, but simply discuss each defect and decide whether or not it will be fixed. In a Scrum environment they might put the defect into the backlog and then the product owner, with input from the team, would prioritize it with the other items in the backlog.
It would be nice if there were crystal clear definitions of Severity and Priority so that everyone was always on the same page. Often, however, there are borderline cases, and it's often a judgment call. The real question that needs to be answered is whether a defect is going to be fixed and if so, in which release. Factors that should be considered include importance of the fix to the customer, the time and complexity of fixing the bug as well as the time it will take to test the fix. If the developer and the tester can agree that the fix will be complete before go-live, it shouldn't really matter whether the defect is classified as a Severity 2 or a Severity 3, though they may need to communicate their scheduling needs in order to accommodate the release. However, when there is disagreement about whether or not the defect should be fixed before released, the product owner should be consulted and ultimately make the decision.
Dig Deeper on Topics Archive
Related Q&A from Yvette Francino
Agile mobile development can be made easier by using a little-known methodology, called Mobile-D. Expert Yvette Francino takes us inside this process. Continue Reading
It may be challenging to make sure everyone's voice is heard in collaborative meetings, but a good facilitator can ensure this happens. Continue Reading
Agile methodologies stress the benefits of collaboration, working with cross-functional teams to encourage communication between business owners and ... Continue Reading