Who determines the appropriate severity or priority for a defect?

Who determines the appropriate severity or priority for a defect?

Testers and developers are often in disagreement about the severity of a defect. When there's a disagreement, who gets final say?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

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.

This was first published in February 2010

Back to top