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
andystaves
Member


Reged: 10/01/01
Posts: 71
Loc: Salisbury UK
Defect Severity definition
      #228158 - 10/03/01 12:13 AM

Now I think about it, this should probably go into the 'defect tracking' forum....

Not to worry.

At the moment I am in a position to get things done right first time. I am the first QA person my company has ever really had, and I am in the process of building a methodology to match the needs of the business.

One such process is defining the severity of a bug.

Does anyone have a system that they feel works well, and they would be willing to share?

Thanks in advance

Andy

------------------
Is it up? Is it down?


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


Reged: 08/23/01
Posts: 417
Re: Defect Severity definition
      #228159 - 10/03/01 12:27 AM

i don't think there is any system or standard to define the severity of the bugs..
you should use your own judgement, there are bugs that prevent the application for doing what is suppose to do, and there are bugs just affect the GUI design, or the are just spelling mistakes bugs..It depends on how they affect your application, and how they are important to your client.

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


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


Reged: 04/18/00
Posts: 90
Loc: oakland, md, usa
Re: Defect Severity definition
      #228160 - 10/03/01 12:41 AM

this is what we use, but I'd advise you to customize to meet your needs:
Severity 1 - Catastrophic defect that causes total failure of the software or unrecoverable data loss. There is no work around. In general, a severity 1 defect would prevent the product from being released. Example: defects that cause the system to crash, corrupt data files, or completely disrupt service.

Severity 2 - Defect results in severely impaired functionality. A work around may exist but its use is unsatisfactory. In general, you would not release the product with such a defect. Examples: with certain steps, we may generate a Windows error/message that you can click Ok on and continue with whatever you were doing with no harmful effects.

Severity 3 - Defect causes failure of non-critical aspects of the system. There is a reasonably satisfactory work around. The product may be released if the defect is documented, but the existence of the defect may cause customer dissatisfaction. Example: a non Client Financial Report is not recognizing an option correctly, but if a filter is set, the report can be generated with the proper output.

Severity 4 - Defect of minor significance. A work around exists or, if not, the impairment is slight. Generally, the product could be released and most customers would be unaware of the defect's existence or only slightly dissatisfied. Example: A button or button set is slightly off center on a data screen, or the problem is purely cosmetic and not easily recognizable.

Severity 5 - Enhancement request or design issue. These should probably be coded as Suggestions or brought to the Design Team by the originating persons DT representative.

------------------
Will Riley


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


Reged: 10/01/01
Posts: 71
Loc: Salisbury UK
Re: Defect Severity definition
      #228161 - 10/02/01 01:01 PM

Thanks Rilo, that's pretty much along the lines I was already thinking

Andy

------------------
Is it up? Is it down?


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


Reged: 02/13/01
Posts: 929
Loc: Colorado Springs, CO, USA
Re: Defect Severity definition
      #228162 - 10/02/01 01:03 PM

The severity, usually indicates the severity of the impact on the system (blue screen, error/crash, no error message but mangled data, erroneous error messages, cosmetic problems.)

However, this alone cannot be used as the priority for fixing issues - you also need to look at the impact in the real-world, the cost of fixing the bugs, the cost of a workaround and how often the bug will occur. Because of this, risk management is quite specific to each development group.

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


Reged: 12/28/99
Posts: 1875
Loc: Chicago,Illinois,USA
Re: Defect Severity definition
      #228163 - 10/02/01 01:12 PM

Without getting too much into the why's of what I do, here is a basic conceptual idea of how I define severity and priority. I did not include the usability/accessibilitly aspects in this list. (By the way, CC refers to Customer Care. Or Help Desk, if you prefer).

Priorities
Priority 1: Immediate
- Blocks further testing (QA/QT)
- Currently very visible and/or deterimental to customers (CC)
- Possibly immediately detrimental to revenue or reputation (Sales, Marketing, QA)
- Needed for time critical deadline (sale, expo, trade show, etc.) (QA, Sales, Marketing)

Priority 2: High
- must fix before next release because of:
- numerous customer complaints about the issue (CC)
- critical area of the system (Dev/QA)
- will be very visible and/or deterimental when released (QA/QT/Dev)
- does not conform to what was stated as a requirement for the release (QA)

Priority 3: Medium
- should fix if time permits; not a critical areas of the system (Dev/QA)
- some customers are impacted by it but there is a workaround (Dev/CC/QA)
- very few customer complaints logged about this issue (CC)

Priority 4: Low
- would like to fix but can be released as is; trivial, cosmetic (Dev, QA/QT, Marketing)
- few customers even notice it much less are impacted by it (i.e., not very visible or deterimental) (CC)


Severities
Severity 1: Critical
- system crash, massive performance degradation, data corruption, data loss, security violation

Severity 2: High
- operational error, data integrity, some performance degradation, loss of functionality (no workaround)

Severity 3: Medium
- same as Severity 2 except there is a workaround

Severity 4: Low
- minor problem, misspelling, UI layout, rare occurrence

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


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


Reged: 08/07/01
Posts: 234
Loc: Vancouver, BC, Canada
Re: Defect Severity definition
      #228164 - 10/02/01 01:15 PM

If you use a numbering system, you are unconsciously adding "value" to the severity. That's for priority, which should be decided by the PM and not QA.

Would suggest using descriptive terms for severity. We use such terms that describe the effects of the bug(for instance: crashes crash, cosmetic, usability, incorrect output). This also lets me get on with my work quicker rather than having to cross reference to the Severity definitions and figure out which number I need to use.

Gail

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


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


Reged: 08/14/01
Posts: 2678
Loc: Atlanta, GA
Re: Defect Severity definition
      #228165 - 10/02/01 01:15 PM

I would agree with the definitions provided, to an extent... Severity, should, as TestGeek indicated, be an indication of not only the overall system impact, such as crash versus cosmetic, etc., but is often used to help indicate the 'difficulty or time required for fix'. In many cases, I've seen priority used to indicate the 'level' of the error.

For example, a defect where a user is receiving a Java Script Error or OLE Exception when attempting to complete a given function would be Priority 1 - Showstopper, Critical, etc., but may only be Severity 3 - minor, because it's really a '3 second fix'.

The key in implementing these levels of definition in any way is to ensure that everyone understands what you're aiming for, and that all information that's needed is being 'tracked' within that indicator.

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


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


Reged: 08/07/01
Posts: 234
Loc: Vancouver, BC, Canada
Re: Defect Severity definition
      #228166 - 10/02/01 01:20 PM

quote:
Originally posted by QAGirl:
For example, a defect where a user is receiving a Java Script Error or OLE Exception when attempting to complete a given function would be Priority 1 - Showstopper, Critical, etc., but may only be Severity 3 - minor, because it's really a '3 second fix'.


Just one question about this, QAGirl. How would a tester know that it's a "3 second fix"?

Gail

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


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


Reged: 06/26/99
Posts: 1766
Loc: San Jose, CA
Re: Defect Severity definition
      #228167 - 10/02/01 01:23 PM

Actually the severity that I'm used to are as follows:
1- Crash/Hang
2- No Workaround (means that you cannot get an important feature/area because of the bug)
3- Workaround (means that you can get to the feature in a different way and continue)
4- Feature/Enhancement Request

These generally tend to be the top 4 severities in a defect tracker.

------------------
AJ Alhait
BetaSoft Inc.


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


Reged: 08/14/01
Posts: 2678
Loc: Atlanta, GA
Re: Defect Severity definition
      #228168 - 10/02/01 01:26 PM

quote:
Originally posted by Plummi:
Just one question about this, QAGirl. How would a tester know that it's a "3 second fix"?

Gail


They wouldn't. In the environments I spoke of, such things were determined in SCCB (Software Configuration Control Board) meetings where the developers estimated that time. They'd do light research prior to the meetings and would weigh in, along with QA, so that they could provide the information. PM would then set the priority based on the amount of time a given fix would take.

Generally, QA either left both fields blank, or set initial values for the priority based on their own work within the system. The only priority/severity QA had immediate right to take is a '0' which indicated a defect that stopped/prevented all further testing efforts, and had to be addressed by the dev team immediately.

The first time I was involved in this sort of system was a large project between two partnering companies, where it was important to be sure the 'sister' company understood the defects that were being reported. The meetings were sometimes a pain, but it helped to keep QA OUT of the politics of the timeline and determining how development should spend their time.

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


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


Reged: 12/28/99
Posts: 1875
Loc: Chicago,Illinois,USA
Re: Defect Severity definition
      #228169 - 10/02/01 01:27 PM

quote:
Originally posted by Plummi:
If you use a numbering system, you are unconsciously adding "value" to the severity. That's for priority, which should be decided by the PM and not QA.

As far as adding value, remember that if you break up into severity and priority you should use a weighting scheme such that both numbers are combined. For that you need values. That weighting number is usually the number I bring to meetings and also gives you a nice top-hat structure to the metrics for severity and priority.

As to the second point, it depends on how closely Project Management and QA work together. In general, the PM should rely on QA for the basic information but will probably have the final say-so. For example, a PM is not going to necessarily know that it "blocks further testing" (to use my example) unless that is brought up my QA/QT - which means Priority 1 in my book.

quote:
This also lets me get on with my work quicker rather than having to cross reference to the Severity definitions and figure out which number I need to use.

Very true but numbers are easier to calculate with as far as that goes. (Although I tend to build spreadsheets such that if someone enters in "Critical," for example, that is transcribed to "1".) In general, I use a reference like "1 - Critical" for a Severity field so you get the best of both worlds.

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


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


Reged: 10/01/01
Posts: 71
Loc: Salisbury UK
Re: Defect Severity definition
      #228170 - 10/02/01 02:32 PM

Thanks guys, to be honest it's been a while since I had to incorporate this into a test plan (the definitions were usually already in place).

This being a new job, and essentially a new QA dept (of one!) there currently are no definitions in place.

What with all the other things on my plate at the moment, I just needed a jog of memory.

Thanks everyone for your input

Andy

------------------
Is it up? Is it down?


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



Extra information
0 registered and 8 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: 44221

Rate this topic

Jump to

Contact Us | Privacy statement SQAForums

Powered by UBB.threads™ 6.5.5