Weighing Bugs

Following is how I would define the severity of bugs. I think 4 as listed here suffices needs, most of the time…

The examples are not expected to be exhaustive and merely pointers and should be interpreted keeping the application context in mind. Nothing within the quality domain should be cast in stone. Do it and you may have just given an invitation to doom.


Critical (show-stopper) bugs are those that result in loss of key functionality, usability, and performance of a product in normal operation and for which there is no workaround solution available.

The problem is likely to impact most users. This level of bug will typically trigger a new release or patch in a very short time frame.

These also include bugs such as an embarrassing misspell of a product or company name in the splash screen, wrong video clip in the intro screen, misleading/erroneous help for a frequently used feature, and so on.

Examples:

  • Application crashing due to unhandled exceptions coming up on screens. These could be server side exceptions, SQL failing in a particular scenario.
  • Unable to log into application.
  • Errors that result in data loss/data corruption.
  • Unable to Add/Modify/Delete/View records severely impacting further use of the application or its dependent functionality.
  • Query/Search gets invalid records based on which wrong decisions may get taken .
  • Unable to generate a key report.
  • Severe miscalculations e.g. incorrect calculation of “Revenue for the year”.
  • Incomplete functionality e.g. key functionality is completely missed out.
  • Extra functionality wrongly added that impairs the application behavior in a way .
  • Improper / incomplete code implementation related to handling of platform or browser (e.g. application is working in IE but not in Firefox). This maybe ‘serious’ in cases where the impacted browser is not a ‘best-choice’ in terms of use / popularity.
  • Performance related issues.
  • Any other bug that forces a user to shut down the application.

Serious bugs are those that result in loss of key functionality, usability, and performance of a product in certain conditions. Problems that would otherwise be considered `critical’ are rated `serious’ when a workaround is known. It maybe that even if a workaround has been provided, the loss of functionality can only be sustained for a short time.

Examples:

  • Unable to log into application with a particular user id.
  • Errors that result in data loss/data corruption but for specific business scenarios.
  • Unable to Add/Modify/Delete/View records but not severely impacting use of the application or its dependent functionality.
  • Unable to generate a report but alternatives exist to view/interpret correct results.
  • Query/Search gets invalid records but alternatives exist to view/interpret correct results .
  • Severe data miscalculations dependent on data feeds / processing e.g. incorrect calculation of “Revenue for the year”.
  • Extra functionality added that is not expected or not estimated which might eat up substantial effort from prioritized testing tasks.
  • Code dependent on platform or browser.(For e.g. application is working in browser X but not in Browser Y ).

Medium Bugs – The bug of such type does not result in a failure, but causes the system to produce incorrect, incomplete, or inconsistent results, or the bug impairs the systems usability. These include minor display/ redraw problems, poorly worded error messages, minor design issues, and the like. If many Medium severity bugs get deferred; there will be a definite quality- degradation perception / effect to the product.

Examples:

  • Bugs related to field validations.
  • Less severe numerical discrepancies. For e.g. count of total number of records in a report is incorrect.
  • In appropriate error messages, help text.
  • Error message not displayed when required.
  • Complete description not visible.
  • Navigational issues. – Incorrect page or screen reference

Minor Bugs – Any bug that does not fit in the above 3 but is a inconvenience to the customer. The product, component or concept is working in general, but lacks features, has irritating behavior, does something wrong, or doesn’t match its documentation if provided.

Examples:

  • Standard font/font size not used.
  • Spelling mistakes on captions/ error messages/ dialog boxes /help text.
  • Incorrect data type accepted by a field
  • Incorrect positioning of messages.
  • Incorrect date format.
  • Incorrect tab order
  • Undesired/Inconsistent look and feel.
  • GUI standard violation.
  • Short cut keys and hot keys not working.
  • Position of fields on screens causing minor inconvenience.
  • Alignment of labels and fields on form.
  • Cursor position when form opens.
  • All cosmetic issues
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s