DEFECT SEVERITY Fundamentals 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. Severity is denoted as: S1 = Critical S2 = Major S3 = Minor S4 = Trivial CAUTION: Defect Severity is one of the most common causes of disputes between Testers and Developers. The Tester classifies the Severity of Defect as Critical or Major The Developer doesn’t accept that: They believe that the defect is of Minor or Trivial severity.

Severity Types Severity defines how severe will be the impact of a defect on the performance of the system. Critical: Such a defect does not allow the application to work properly due to system failure or corruption of data. Critical defects do not allow the user to move any further and puts them in a miserable position. Example: Unsuccessful installation, complete failure of a feature.

Severity Types Major: The major defects are little less severe than critical defects. They can cause system to fail There is another possible way of achieving the desired result The user need not get trained for this. Example: A feature is not functional from one module but the task is possible to do if 10 complicated indirect steps are followed in another module/s.

Severity Types Moderate: These defects do not cause the system to fail but produce wrong or contradictory output. Minor: Defects that do not cause system failure or affect the usability of the system It is possible to rectify easily Example: A minor feature that is not functional in one module but the same task is easily possible to do from another module. Cosmetic (Trivial): Defects related to the outlook or appearance of the system are called cosmetic defect. Example: unimportant layout discrepancies, spelling/grammatical errors.

Priority Types When a defect is reported, the test report mentions priority along with the severity of the defect. Priority actually tells the developer the order in which defects should be resolved. Priority can be of the following types: Low: The defect does not require immediate attention and should be rectified after the defects with higher priority have been resolved. Medium: The defect should be resolved soon after the defects with higher priority have been resolved. High: Priority requires immediate attention and should be resolved as soon as possible.

According to these.. If a defect has high priority and high severity There is a problem in the basic functionality of the system The user is not in a position to use the system. Such defects should be rectified immediately. Defects having high priority and low severity can be something like spelling mistake in the company’s name or issues with logo. Such defects are of low severity But they must be rectified immediately and should be considered as high priority defect.

According to These… High severity and low priority defect means that there is a major defect in some module but the user would not be using it immediately the defect can be rectified a little later. Low priority and low severity defects are generally cosmetic in nature They do not affect the functionality of the system such defects are rectified in the end

Severity And Priority