Q
Problem solve Get help with specific problems with your technologies, process and projects.

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.

This was last published in February 2010

Dig Deeper on Software Project Management Process

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close