Quality Testing

Quality is delighting customers

What is a Defect Severity? What are the negative effects ?

Hi friends,

I am learner of manual testing & Automation testing.  I am here to enhance my learning on Defect Severity & want to know its negative effects & aspects.

I hope any tech developer can help me over here in resolving the issue.

Views: 232

Reply to This

Replies to This Discussion

Defect Severity:

Bug/Defect severity can be defined as the impact of the bug on customer’s business. It can be Critical, Major or Minor. In simple words, how much effect will be there on the system because of a particular defect.

Severity can be categorized into three types.. Read more using below links

Diff b/w Severity and Priority

Infographic - Diff b/w Severity and Priority

Hi Kyle,

In manual testing, Defect severity is the measure of impact a defect has on the development or operation of a component application being tested.
For e.g. EmailID verification email not sent after successful registration is a high severity defect as it has a high impact on application as well as client's business whereas a typo error is a low severity defect as it won't block any functionality of application.

Hi,

Defect Severity or Impact is a classification of software defect (bug) to indicate the degree of negative impact on the quality of software. In simple, severity is nothing but how much does it impact the application. Different types of severity are as follows: Blocker (Showstopper), Critical, Major, Minor and Trivial.

Showstopper - User can never navigate further which stands as a blocker. It does not have a work around

Critical - The defect affects critical functionality or critical data. It does have a workaround

Major - The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.

Minor - The defect affects minor functionality or non-critical data. It has an easy workaround. Example: A minor feature that is not functional in one module but the same task is easily doable from another module

Trivial - The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors.

Priority

It is nothing but how much importance has to be given to defect logged. Priority can be of following types:

  • Low: The defect is an irritant which should be repaired, but repair can be deferred until after more serious defect have been fixed.
  • Medium: The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.
  • High: The defect must be resolved as soon as possible because the defect is affecting the application or the product severely. The system cannot be used until the  repair has been done.

Few very important scenarios related to the severity and priority:

High Priority & High Severity: An error which occurs on the basic functionality of the application and will not allow the user to use the system. (Eg. A site maintaining the student details, on saving record if it, doesn’t allow to save the record then this is high priority and high severity bug.)

High Priority & Low Severity: The spelling mistakes that happens on the cover page or heading or title of an application.

High Severity & Low Priority: An error which occurs on the functionality of the application (for which there is no workaround) and will not allow the user to use the system but on click of link which is rarely used by the end user.

Low Priority and Low Severity: Any cosmetic or spelling issues which is within a paragraph or in the report (Not on cover page, heading, title).

Please feel free to reach out to me at ajay.k@indiumsoft.com and our official website is www.indiumsoft.com

--

Thanks & Regards,

Ajay K

Defect Severity or Impact is a classification of software defect (bug) to indicate the degree of negative impact on the quality of software. ISTQB Definition. severity: The degree of impact that a defect has on the development or operation of a component or system.

Corporate Gifts Gurgaon

Severity determines the defect’s effect on the application. It represents the impact on the business of the client. Defect Severity is totally based on how important functionality is blocked or if that functionality functions incorrectly & accordingly add Defect Severity.

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.

  • Analyse the defect with what class of inputs does the defect supports.
  • Make sure that the defect occurs only with particular sequence of operation or list out other sequences, which cause the defect.

It is the degree to which the defect can influence the software. At the end of the day it characterizes the effect that a given defect has on the deliverables. For instance: If an application or site page crashes when a remote link is clicked on, for this situation clicking the remote link by an user is rare yet the effect of application crashing is extreme. 

RSS

TTWT Magazine


Advertisement

Advertisement

Advertisement

Advertisement

© 2017   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service