The online community for software testing & quality assurance professionals
 
 
Calendar   Today's Topics
Sponsors:




Lost Password?

Home
BetaSoft
Blogs
Jobs
Training
News
Links
Downloads



Quality Engineering >> Defect Tracking

Pages: 1
jeni
Member


Reged: 12/05/01
Posts: 43
Loc: atlanta,ga,usa
Bug Tracking -- difference between Priority and Severity
      #228171 - 12/19/01 12:27 AM

I use Bugzilla. A developer and I were discussing what P1 (priority 1) bugs actually mean. He was saying it means all bugs marked P1 should be FIXED before a release. How do you guys take advantage of the Priority markings (if applicable to your bug tracking system)? I use priorities to denote IMPORTANCE of a bug. Which ones need to be looked at first, so if a developer has nothing to do he may look up all P1 bugs in the database. The priority is _relative_ to all other NEW/OUTSTANDING bugs in the database.

------------------
--


Post Extras: Print Post   Remind Me!   Notify Moderator  
jeni
Member


Reged: 12/05/01
Posts: 43
Loc: atlanta,ga,usa
Re: Bug Tracking -- difference between Priority and Severity
      #228172 - 12/19/01 12:29 AM

I guess I should be using the severity to denote which ones are most important (what should be looked at first)???

My main question is:

What do others use severity and priority for exactly?

I want to take full advantage.

------------------
--


Post Extras: Print Post   Remind Me!   Notify Moderator  
Jeff Nyman
Moderator


Reged: 12/28/99
Posts: 1875
Loc: Chicago,Illinois,USA
Re: Bug Tracking -- difference between Priority and Severity
      #228173 - 12/19/01 12:41 AM

For me:

Priority - Indicates how important it is to fix the issue and when it should be fixed.

Severity - Indicates how bad the issue is and the impact of a fix.

What I use priority for is that it will usually describe an assessment of the importance of a problem, and this assessment should be based on a business statement of what is and is not important. This statement should come in the form of a numbered rating scheme. These numbered schemes are then usually matched to phrases that indicate, at a glance, the overall priority of the issue. Priority designations are usually assigned during the requirements phase to indicate what features are possible to remove or hold off on for a given release.

As far as severity, I think the severity can be looked at in two ways. The first is looking at it as the extent of the problem. In other words: how far-reaching is this problem? A quality tester may find a particular defect, for example, and submit it for just one particular area of the software product however, when development begins to look at it they may find that it is actually a wider problem than the quality tester realized. The extent is one part of the severity but the other part is looking at how extensive a fix to the problem would be. For example, it is possible that a given fix for one defect might require re-writing a great deal of other modules, even some that are unrelated, to accommodate the fix which means there is a great chance of introducing even more defects into the system. Or it might be a fix where the solution will have an impact on the performance of the system, such as response time, because there is more logic that requires processing or it will require a code solution that is particularly CPU intensive. Severity should reflect a qualitative appraisal of the issue's extent without any discussion of how important the problem is from the business perspective.

Also, you might check out this thread. It has some information that might help you. The thread is more about some designations that people used.

[This message has been edited by JeffNyman (edited 06-20-2002).]

Post Extras: Print Post   Remind Me!   Notify Moderator  
icruiser
Moderator


Reged: 02/21/01
Posts: 343
Loc: Arlington, VA, USA
Re: Bug Tracking -- difference between Priority and Severity
      #228174 - 12/18/01 03:52 PM

I'll chime in on this one too. I recommend doing away with priority and severity and just having a "Customer Impact" field. Since it is the customer for which all software is developed, defining the impact of the ticket based on the customer is the easiest and most efficient way to categorize a ticket. It also eliminates confusion between definitions of severity levels and priority levels.

I wrote a short article arguing this point. If interested, email me and I can send it to you.

------------------

[This message has been edited by icruiser (edited 12-18-2001).]

Post Extras: Print Post   Remind Me!   Notify Moderator  
Joe Strazzere
Moderator


Reged: 05/15/00
Posts: 12344
Loc: Massachusetts, USA
Re: Bug Tracking -- difference between Priority and Severity
      #228175 - 12/19/01 05:27 AM

quote:
Originally posted by icruiser:
I'll chime in on this one too. I recommend doing away with priority and severity and just having a "Customer Impact" field. Since it is the customer for which all software is developed, defining the impact of the ticket based on the customer is the easiest and most efficient way to categorize a ticket. It also eliminates confusion between definitions of severity levels and priority levels.

I wrote a short article arguing this point. If interested, email me and I can send it to you.


If the article is short, why not just post it in this forum?

------------------
- Joe (strazzerj@aol.com)


Post Extras: Print Post   Remind Me!   Notify Moderator  
QAGirl
Veteran


Reged: 08/14/01
Posts: 2678
Loc: Atlanta, GA
Re: Bug Tracking -- difference between Priority and Severity
      #228176 - 12/19/01 05:36 AM

quote:
Originally posted by icruiser:
I'll chime in on this one too. I recommend doing away with priority and severity and just having a "Customer Impact" field. Since it is the customer for which all software is developed, defining the impact of the ticket based on the customer is the easiest and most efficient way to categorize a ticket.

I can agree with that on most issues.. but what of issues that affect internal reporting, back-up and recovery and the like? It's much more difficult to correlate these to the direct impact on the Customer.

Also, while I'm sure it would eliminate confusion on the severity/priority article, I think it would still not address the larger issue of the subjectiveness of such measurements. Granted, in many cases priority is subjective, but I'd argue that customer impact can sometimes become even more convoluted than a simple question of subjectiveness. Example: Assume you have an overall customer base of 500 customers. Of those 500, 25 are considered 'Enterprise' customers, who generate double the revenue of a single company that is not. You have three defects - one affects 90% of your customers in a manner that is very frustrating and causes corrupt data in some cases, but has a work-around (for the purposes of my argument, let's assume it's a fairly convoluted work-around). On the other hand, you also have a defect that affects your enterprise customers, who are being extremely vocal about the effects of the defect, but it does not really cause major issues in the system, and the workaround is fairly simple for the customer to implement. Finally, you have a defect that is affecting 100% of your customers, but is very easy to fix, and has no workaround.

Bug 1 is medium severity (could be fixed in about 15 man hours)

Bug 2 is high severity (could be fixed in 30 man hours)

Bug 3 is low severity (could be fixed in 2 man hours).

Your resources are very limited, so if you are to fix Bug 2, there is no chance of addressing Bug 1 or Bug 3. If you address bug 1, you might have time for Bug 3, but there's no guarantee.

What gets the higher 'customer impact' rating? Granted, I'm not necessarily saying that assigning a priority/severity system would eliminate all of the issues this scenario raised, but simply saying that I see even more problems in a customer impact rating system.

I'd agree with Joe though - let us see it!

------------------
~* Happy Holidays!! *~

[This message has been edited by QAGirl (edited 12-19-2001).]

Post Extras: Print Post   Remind Me!   Notify Moderator  
jwasik
Junior Member


Reged: 04/28/00
Posts: 19
Re: Bug Tracking -- difference between Priority and Severity
      #228177 - 12/19/01 07:42 AM

Our situation might be a little odd... but we have to hide the priority (or sometimes the severity) based upon the developers level of understanding. Most of the time they just want to know which bugs we think should be fixed and in what order. The quality team has become like micro-managers for their projects.

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
SCS
Junior Member


Reged: 08/08/01
Posts: 10
Loc: Dublin, Ireland
Re: Bug Tracking -- difference between Priority and Severity
      #228178 - 12/20/01 07:59 AM

I think your situation must be a little unique... instead of hiding the severity or the priority, why not just provide them with some basic guidelines as to what each rating means for each category. I've found that also including samples helps eg P1, S1 means a critcal fail, urgent fix required.

Sharon

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
Jeanj
Moderator


Reged: 02/25/00
Posts: 2079
Loc: Minneapolis, MN
Re: Bug Tracking -- difference between Priority and Severity
      #228179 - 12/20/01 07:06 PM

quote:
Originally posted by icruiser:
I'll chime in on this one too. I recommend doing away with priority and severity and just having a "Customer Impact" field. of severity levels and priority levels.


I too would like to see that. I have done a lot of work with end-users and tried to explain the severity/priority differences, and have gotten feedback that they want their own "levels" that could ad or detract from the weighting of severity/priority. The couple of times I've tried to do something that, it simply turned into a 3rd unit of measure for who/when/how fast defects are addressed.

I'd like to see how it might be implemented.

------------------
-- Jean


Post Extras: Print Post   Remind Me!   Notify Moderator  
Edwin Paul Christopher L
Member


Reged: 10/29/01
Posts: 61
Loc: Chennai, Tamilnadu, India
Re: Bug Tracking -- difference between Priority and Severity
      #228180 - 12/21/01 01:25 AM

Thxs JeffNyman, forur clear description about the Priority and Severity.

I am having a small doubt, could anyone tell me which level of severity classification is universely accepted.

Coz I am using IEEE standarad for Bug severity as "Critical,Major,Average,Minor, Cosmetic".

Thanx in advance,

Edwin

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
Bug Buster
Member


Reged: 12/20/01
Posts: 35
Loc: Manchester, United Kingdom
Re: Bug Tracking -- difference between Priority and Severity
      #228181 - 12/21/01 03:33 AM

I thought I'd just join in and share how we assign a severity status against defects:

The person who raises them has a choice of:

Critical - Show stopping defects, crashes, DB corruption, loss of data etc.

Important - Bugs that generates scary error messages, stops the users from being able to complete tasks, system is unusable unless restarted etc.

Necessary - Doesn't do any damage and there is a workaround, but the bug will annoy customers, make their life more difficult, generally reduce the quality of the product etc.

Nice To Have - A strange severity I admit, but we've found it useful for things like minor spelling mistakes, inconsistencies in the product, behaviour that you shouldn't really be able to do but doesn't cause any problems at all etc.

Regardless of what severity we give them though, the defects are reviewed at a weekly (which become daily near deadline time) defect meeting, where Client Managers get together with the Development Managers, the Lead Test Analyst (me) and the Lead Developer. Defects are given a priority (those that will be fixed first and must be fixed before we ship the product) in that meeting. The Lead Developer/Tester advises how long they estimate the defect will take to fix/verify and sometimes this changes the priority of defects as well.

Developers/testers can only really guess at a priority of a defect, I do admit that as your product knowledge grows it becomes more educated, but in the end it has to be a management decision.

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
SilkRunner
Junior Member


Reged: 09/25/01
Posts: 6
Re: Bug Tracking -- difference between Priority and Severity
      #228182 - 01/16/02 11:27 PM

I also used Bugzilla and we had a lot of discussions about severity and priority. Finally everybody agreed on these definitions:
PRIORITY Definition
P1 - Must be assigned to an engineer immediately. Patch fix ASAP.
P2 - Must be resolved before the next release. Fix is going to be included in the next scheduled patch.
P3 - Needs to be fixed within the next release
P4 - Needs to be fixed within the future releases
P5 - Needs to be entered into the development schedule

Severity is important, but not imply priority. If the application crashes on a report generated annualy, you might not fix the bug right away.
Very often problem with Minor or Trivial severity has to be fixed with the next patch or ASAP. Production problems usually have higher priority.

------------------


Post Extras: Print Post   Remind Me!   Notify Moderator  
DarthQA
Member


Reged: 08/08/00
Posts: 36
Loc: Miami, Fl
Re: Bug Tracking -- difference between Priority and Severity
      #228183 - 01/17/02 06:38 AM

In my case

PRIORITY is the impact on marketing ie. how will this affect what the user "sees" visually, bad spelling, poor GUI design, etc

SERVERITY is the impact on functionality ie. does the software crash, leak memory, corrupt data, etc.

The reason I did it like this was to eliminate the situations where app crashing bugs were getting fixed before, say, spelling errors. I argued that a spelling error on the splash screen deserves equal weight as a crash. No one bit on that SO...

FOR EXAMPLE
Scenario 1: the app is writing corrupt data to the database. It may receive a SEVERITY of a 5 (being the most severe because the data is corrupt) and a PRIORITY of 1 (being that a user wont really "see" it unless they dig). This gives us a BUG RATING of 6 (5+1)

Scenario 2: there is a blatent spelling error on the File Menu. It receives a SEVERITY of 1 (not a functional problem) and a PRIORITY of 5 (VERY visible to the user). This gives us a BUG RATING of 6 (1+5).

Now both bugs are equally rated and are equal on the to be fixed timeline. Now, the actual formula for calculating Bug Rating is much more complex than the above examples, but this gives the general principle.

------------------
DarthQA, CSTE
QA Lead Engineer

[This message has been edited by DarthQA (edited 01-17-2002).]

Post Extras: Print Post   Remind Me!   Notify Moderator  
Pages: 1



Extra information
0 registered and 9 anonymous users are browsing this forum.

Moderator:  AJ, Daniel_S, swt88 

Print Topic

Forum Permissions
      You cannot start new topics
      You cannot reply to topics
      HTML is disabled
      UBBCode is enabled

Rating:
Topic views: 6429

Rate this topic

Jump to

Contact Us | Privacy statement SQAForums

Powered by UBB.threads™ 6.5.5