How to classify a bug
Testers must initially classify each reported bug with two fields: Type and Severity. Neither have any impact on payout. However, customers reserve the right to reclassify bugs as necessary and will assign a bug value which will determine any additional payout on the bug report. We ask both customers and testers to be fair with their decisions of classification and reclassification of all bugs.
Graphical User Interface (GUI): Bugs that affect the presentation, look or layout of pages, images and form elements.
Examples: Misalignment, broken images, wrong sized graphic elements, inconsistent colors on a link, button or menu, etc.
Functional: Bugs that produce an unexpected/illogical application behavior where the end result differs from the expected result.
Examples: Search returns the wrong results, clicking on a link takes you to page X instead of the intended page Y, etc.
Technical: Bugs that produce error messages or malfunctions of the application.
Critical: Bugs that are mission critical to the core functionality of the application and for which there are no workarounds. These bugs absolutely must be fixed before the customer can release the app to the public. Note: A critical bug is extremely rare and should only be used in instances where, if you were the product manager, you would delay the launch of a product due to this one bug.
Examples: Cannot log in, cannot check out or save my shopping cart, an email client that has a bug that prevents users from sending/receiving emails, etc.
High: Bugs that are related to the core functionality of the application, but don’t have to be fixed before product launch. However, these bugs should be fixed in the first available patch or release after launch.
Examples: A flash demo doesn’t load properly, a bug tracking application that does not allow users to set a bug type/severity, a typo in the large text of the homepage banner, etc.
Medium: Bugs that do not affect any critical user functionality. Typically, medium severity bugs have workarounds that allow users to accomplish the desired task that the bug may have hindered or the function may still operate but in a degraded fashion.
Examples: A travel site that randomly fails to send email notifications, search results page that displays the right results, but formats incorrectly in Chrome browser etc.
Low: Bugs that do not interfere with core functionality and are just annoyances that may or may not ever be fixed.
Examples: A misspelling in the middle of an interior page, text being displayed in the wrong location, the sitemap loads improperly in IE6.
Understandably, the testing manager and customer are more familiar with the tested software and reserve the right to re-classify bug types. We ask both our customers and testers to respect the decisions of classification and re-classification, and ultimately be fair with these decisions.
To discuss this topic on the forums, please click here.