Who determines the appropriate severity or priority for a defect?

There are often differences of opinion on the definition of severity or priority of a defect. The bottom line is determining when and if the defect will be fixed. Factors that need to be considered are customer urgency and time required to fix and test. This strategy takes into account needs of the customer, the developer and the tester.

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 Software development lifecycle

Cloud Computing
App Architecture
ITOperations
TheServerSide.com
SearchAWS
Close