10 Critical Elements of a Bug:
Day #4

First things first: QA is responsible and accountable for the Severity field. Let me state that another way: QA owns the Severity field. No one else, only QA.

This is because QA is the team that is logging the majority of the issues, the team that is using the product day-in and day-out, the team that has the most in-depth understanding of how Severe an issue is for the end-user.

QA is the team that knows whether the issue, however simple or complex to fix, has a major adverse impact for the end-user or is only a minor inconvenience. Because of this: QA owns Severity.

Element #7:
Severity

Now, no two companies use the exact same definitions for the Severity of a bug, but this will give you a solid background regarding the use of this field. Use these as guidelines and then adjust the titles once you learn how your company designates its Severities.

Here are some guidelines to get you started:

• Crash or Freeze
• This is the most severe. This would be BAD for the end-user and thus is the highest level that can be selected
• The program crashes or freezes. The computer crashes as a result of the program you are testing. This is the highest severity
• Major Functionality
• A very important piece of functionality does not perform at all as it should. Either it doesn’t do anything, or it does the wrong thing. You are able to continue working in the program – it has not crashed or frozen – but it is not doing the right thing and it’s not a small thing
• Major Cosmetic
• A glaring visual issue that does not affect the functionality of the program would be considered Major Cosmetic. A single pixel width off is not major. An outdated copyright, however, could definitely be considered major, especially by a legal department
• Minor Functionality
• Much like Major Functionality, this is a piece of the program that is not behaving as expected. However, in this case there may be an easy workaround available to the user that is obvious or is something like a help page opening but the text is not positioned exactly where it should be on the page for a user to see it best
• Minor Cosmetic
• Here is where a single pixel-width issue would fall in terms of severity. If the colors don’t match exactly or there is some other art issue that is not obvious or screamingly ugly
• Suggestion / Feature Request
• This is something that you think should be added to make for a better user experience. Some companies like to categorize these not as “bugs” in their bugbases, but as “features”. This is fine, as the same rules still apply
• There are three things to keep in mind when entering a Suggestion bug (also known as a Feature Request)
• Write it up exactly as you would any other bug
• Be as clear as possible about what is, or is not, happening (the Result) from a user’s perspective so that when reviewed, people will understand what it is you think is missing or should be changed
• ALWAYS state a very clear Expected Result. Here you will describe WHAT you think should happen and WHY. If you can do this, then your suggestion will have a much better chance of being considered. Your suggestion will not be taken seriously if you cannot state the reason(s) that would make your suggested change worth undertaking. Your suggestion may have been considered in the design meetings and not included in this release due to the risk or complexity it would entail. Or it may not have been considered at all. If you can state clearly why it would enhance the end-user’s experience, then someone can make an informed decision as to whether they think this change is worth the effort
Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5 - Day 6 - Day 7
Return To Successful Quality Assurance Home


© 2008-2011 Successful-Quality-Assurance.com


SBI!