>> I have a doubt regarding this severity and priority. As per the Priority definition, for those bugs which need to be fixed in later releases, we should assign the low priority level.yn, I wouldn't recommend adjusting something to low that doesn't need to be there ('low' often becomes 'we'll never address these bugs at all').If you have a bug that's a medium or high - but not for the current release - then check your bug tracking software to see if you can assign a target milestone/release/version/whatever to it. It may not be a priority for *this* release, but you want to be able to mark it appropriately for future releases so it doesn't fall through the cracks.

Although looking at issue severity seems to make common sense, I've always struggled with large projects with large numbers of issues. In these sorts of systems, minor usability issues, gui issues, issues with phrasing of terms on the screen, etc., seem to get relegated to lowest priority. For the companies I've worked in that bucket might as well be labeled "will never be fixed." The resulting product, while not containing any show stoppers, has rough fit and finish. Sort of like buying a car that runs every day, but who's seats won't adjust and the doors squeek, and, and... you get the picture. Any suggestions on handling this effect?

I am a big fan of two separate ratings of bugs, and I like this approach. I implemented a similar version of this concept in a past position. When I started as manager of the test team, our biggest waste of time during stress-filled release cycles was arguing about the severity, which ranged from 1(highest severity) to 5(lowest severity). The development team endlessly attacked testers for not understanding the description of each severity level, and for good reason. A release was considered delayed if on the release date there were any severity 1 or 2 issues outstanding. Testers could not distinguish severity 2 and 3 bugs, according to development - they kept giving sev 3's a severity of 2 (and potentially delaying a release). Funny, but the assignment of other severity levels was never questioned! This was clearly a battle where the entire battlefield needed to be destroyed, so we added a column to our bug tables called Priority. The Product Manager for the release would assign the priority, which was either R(required for release) or NR(not required for release). It was the tester's job to assess the impact of the bug on the software itself, not the impact on the customer. The metric driving preparedness for release became the count of bugs with "R" priority. This allowed testers to focus on what they truly understood - how bad off is the program when the bug occurs? The argument over readiness for release changed into a judgement call by the Product Manager, who had the best insight into impact of bugs on customers (and overall accountability for the project). This also allowed us to distinguish typos that were critical (e.g., misspelled company name on a web portal's home page) and crashes that were not (e.g., reserving a particular hotel fo a particular number of guests on a specific day in time crashed the app). Our use of severity was not as good as the one Peter suggests, though - we were just giving the programmer a little more info about the nature of the bug. Peter's point is important - customer impact of a bug does not always drive priority in terms of a fix - and we did not address this in our solution. What we learned, in addition to this, was that the best person to determine customer impact might exist outside the technical team. We had much smoother releases after our change, too. Thanks for a great example of best practices in a fundamental process.

I would say if it is an established language to the developer, it is fine to adopt any system. In my practice, severity rating are formed up using 2x2 matrix of exposure and impact of an issue. Hence, the final rating, I would say already depicts the urgency of an issue. Tackling the issues by prioritising the severity level seems sound to me and less complex to the developers.

Peter, Nice article. I remember one group I worked in had only severity tags. The Priority 1 severity finally ended up with 4 or 5 additional gradations which were in effect priorities. Overly complicated and also failed to give the triage team a clear set of rules to make decisions without a lot of convolution.Your description is straightforward and easy to use!

The most important thing in assigning priorities in defect ttracking is to have clear and percise design requirements. If the requirements are not met, then I totally agree with Peter's process of assigning priorties. Sometimes, there is a total disagreement between the developer and the tester of how high the priority should be. The tester should be customer as well as company centered to ensure the highest quality possible and the best customer satification.Basil McDougald QA Analyst Hummingbird, Ltd.

I've found that it is best to assign priority to a release point which helps us measure readiness for individual releases. We use a High, Medium, Low and Defer scheme where high is the issue must be fixed for the next planned release, medium the one to follow, low before final release. Defer - don't fix unless nothing else is left.This also gives the developers a fixed point of reference for when a bug is absolutely required. It can avoid having a developer work on a lower priority issue because it's easier (it does happen).

To comment further on Jeff Patton's comment - In queuing systems, a job that stays in the system but doesn't get attention because jobs with higher priorities hog the resources 'starves'. When a job starves, its priority is automatically increased. Thus a low priority job that doesn't get attention will gradually increase in priority until it is addressed. Wouldn't the addition of a starvation mechanism in the bug tracker help to prevent low priority issues never receiving attention?