View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Add page
Show collection (0 pages)
Collections help

Search

QA Processes/Defects Severity Priority

Contents

Introduction

This document is intended to be a guide for Triage Team when prioritizing reported defects.

On a weekly basis, Triage Team verifies new defects (with status New).

Triaging a bug involves:

How to determine the severity of defects

Severity is a technical measure. It is an assessment of the impact of the defect without regard to other remaining work or the current schedule. The only reason severity should change is if exists new information that can be used to re-evaluate the previous assessment.

The classification of impact of a defect is important for following reasons:

What is defect Severity?

A defect is a product anomaly or flaw, which is variance from desired product specification. The classification of defect based on its impact on operation of product is called Severity.

A defect usually refers to as bug only if it affects operation of system and negatively impacts the user of the system, while defect itself may not have any impact on operation of system. In other terms, all bugs are defects but not all defects are bugs. Since severity classification also includes those anomalies, which does not have any impact on operation of system, it is appropriate to mention as Defect Severity rather than Bug Severity.

Following list consist of some questions that may allow you to decide yourself the measure of severity.

The number of Yes on the previous questions should give you a good idea about the severity.

For example, if the system stops working, then further testing of the system is not possible and hence severity is high. Also the defect should be generalized as far as possible. I.e. after you find the defect, try to find out that the defect is repeated in all cross-browsers, cross-O/S etc.

Some tips on finding the severity

Decide the impact

Some defects are obvious to decide its severity. For example, "404 HTTP error occurs when navigating to particular screen". Sometimes, a minor defect repeats in all sections or such defect is much more frequent. In those cases, the impact of the defect is higher from the point of view of an user even though it is minor defect. Hence, such defects get higher severity.

Isolate the defect

Isolating the defect helps to find out its depth of impact.

Defect Classification by severity

The impact of Defect Severity can be classified into four categories: Critical, Major, Minor and Trivial.

Critical defects are those which results in the failure of the complete software system, of a critical subsystem so that no work or testing can be carried out after the occurrence of the defect. It also applies to data loss failures and with processes that leave inconsistent data stored on the database.

Major defects are those which also causes failure of entire or part of system, but there are some processing alternatives which allows further operation of the system. It also applies to the system crashing, or aborting, during normal operation of a non-critical flow.

Minor defects do not result in failure but causes the system to show incorrect, incomplete, or inconsistent results (note that show inconsistent results is way different of generating inconsistent results at database level as explained above). A critical usability issue fits also in this category, as well as if there is a simple workaround.

Trivial defects are small errors that do not prevent or hinder functionality, typos, grammar mistakes, wrong terminology, general usability issues and styling.

Examples

Following are examples of type of Defects, which falls under each category.

Critical defects

Major Defects

Minor Defects

Trivial Defects

Assigning a priority

What is Defect Priority?

Defect Priority signifies how important and urgently it is to fix this defect. In other words Priority means how high it is in the backlog of tasks. The Defect priority status is set by Management/Triage Team based on the existing functionality, customer requirements and based on Product Roadmap. It also has to be aligned with the Company Objectives. Priority is related to scheduling to resolve the problem. It is a pointer towards the importance of the bug and if High priority is mentioned then the developer has to fix it at the earliest. It also influenced by the technical aspect of the product, reflecting how bad the bug is for the system and also largely related to Business or Marketing aspect.

Defect Classification by priority

Defect Priority is classified into the following categories:

Nevertheless, defect priority is a subjective decision so it could vary from the above categories and, to determine the proper priority, following few points needs to considered:

Definition of priority

The level of business importance assigned to an item, e.g. defect.

Especially when there is a large of number of defects then management of the defect is taken care based on the Defect Priority of the Defect which helps to minimize the product instability.

Setting the priority on a defect

While it is very important for a reporter to set the right Severity, the Priority should be kept as Normal, by letting Triage to set the proper one.

It is possible for a reporter to set a Priority, though. It can be done to help the Development Team on taking the most relevant issues to be fixed first. For example, if the reported defect is a regression on a Stable release currently experienced by several Customer, the fix must be ready before a regular issue.

It is important to note that Priority may change over the time. Triage, on top of setting the priority when receiving a new issue, will periodically review the backlog of open issues to ensure the order of fixing matches current Product Roadmap.

Work precedence

Developers should use Priority to manage their work precedence. This tasks queue is strict. If an Immediate defect is still open, no work on Urgent (nor lower) defects should be started. In case a lower priority defect fix is required, its priority should be raised to meet this criteria.

In case of two or more defects with same priority, the higher severity has to be addressed first.

Retrieved from "http://wiki.openbravo.com/wiki/QA_Processes/Defects_Severity_Priority"

This page has been accessed 38,290 times. This page was last modified on 12 March 2015, at 09:22. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.