Testing is an Art while determining the severity of a defect found in a system. The classification of impact of Defect is important for following reasons:
Testing is an Art while determining the severity of a defect found in a system. The classification of impact of Defect is important for following reasons:
1. It helps to determine the efficiency of Test Process.
2. It helps to decide the priority of the defect, hence improves overall development process by fixing higher priority defects first.
3. The bug tracking process can be made more effective if the severity of the defect is clearly defined.
The focus of this paper is providing some ideas on Defect Severity and its classifications.
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 Defect Severity.
Defect Severity or Bug Severity?
A bug is matured term of defect. 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 doesnÙt have any impact on operation of system (like cosmetic errors etc.), it is appropriate to mention as Defect Severity rather than Bug Severity.
Answer yourself the following before determining the severity
Following questions allows you to decide yourself the measure of severity.
1. Does the system allow me to work even after defect occurs?
2. Does the system recover from the defect by any means?
3. If the defect is recoverable, does the system can do this on its own or any external effort is needed to recover from the defect?
4. Did I check whether the same defect is reflected in all other related sections (or entire system)?
5. Can I be able to repeat the defect in some other system having same configuration (O/S, Browsers etc.) as that of the system where I found the defect?
6. Can I be able to repeat the defect in other configurations also?
7. Does the defect affect only particular category of users or all?
8. How frequently the defect occurs?
9. Which inputs make the defect?
The severity level increases if the answer for some of the above question is ‘YesÙ and for some others ‘NoÙ. For example, if the answer for question 1 is ‘YesÙ, 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, “HTTP error occurs when navigating to particular screen”. Sometimes, a minor defect repeats in all sections or the frequency of such defect is more. In such cases, impact of the defect is more in users perspective 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.
1. Analyze the defect with what class of inputs does the defect supports.
2. Make sure that the defect occurs only with particular sequence of operation or list out other sequences, which cause the defect.
Defect Classification by severity
The impact of Defect Severity can be classified into four categories:
1. Fatal 2. Major 3. Minor 4. Cosmetic
Fatal Defects are the defects, which results in the failure of the complete software system, of a subsystem, or of a software unit so that no work or testing can be carried out after the occurrence of the defect.
Major Defects are one, which also causes failure of entire or part of system, but there are some processing alternatives, which allows further operation of the system.
Minor Defects does not result in failure but causes the system to produce incorrect, incomplete, or inconsistent results, or the defect impairs the system usability.
Cosmetic Defects are small errors that do not prevent or hinder functionality.
Following are examples of type of Defects, which falls under each category.
Fatal Defects
Functionality does not permit for further testing.
Runtime Errors like JavaScript errors etc.
Functionality Missed out / Incorrect Implementation (Major Deviation from Requirements).
Performance Issues (If specified by Client).
Browser incompatibility and Operating systems incompatibility issues depending on the impact of error.
Dead Links.
Recursive Loop.
Major Defects
Functionality incorrectly implemented (Minor Deviation from Requirements).
Performance Issues (If not specified by Client).
Mandatory Validations for Mandatory Fields.
Images, Graphics missing which hinders functionality.
Front End / Home Page Alignment issues.
Minor Defects
Screen Layout Issues
Spelling Mistakes / Grammatical Mistakes.
Documentation Errors
Page Titles Missing.
Alt Text for Images.
Background Color for the Pages other than Home page.
Default Value missing for the fields required.
Cursor Set Focus and Tab Flow on the Page.
Images, Graphics missing, which does not, hinders functionality.
Cosmetic Defects
Suggestions
GUI image color etc.
Subscribe to this comment's feed
| < Prev | Next > |
|---|
