Defect may be seen as the deviation in the actual working of a software product against what was specified and expected by it. A "defect" in a software product reflects its inability or inefficiency to meet the specified requirements and criteria and subsequently prevent the software application to perform its desired and expected working.
Since, the primary purpose behind testing is to trace out the maximum defects, present in a software product, a tester needs to be aware about the different forms of the defects, which may prevail in a software product. The understanding of the multiple variants of defects helps a tester, to identify and locate good amount of defects, easily and quickly.
Let's go through each of these types.
Types of Defects:
1) Severity Basis:
Severity defines the degree of impact. Thus, defect's severity reflects the degree or intensity of a particular defect, to impact a software product or its working, adversely. Based on the severity metric, a defect may be further categorized into following:
Critical: The defects termed as 'critical', needs immediate attention and treatment. A critical defect directly affects the critical and essential functionalities, which may affect a software product or its functionality on a large scale, such as failure of a feature/functionality or the whole system, system crash-down, etc.
Major: Defects, which are responsible for affecting the core and major functionalities of a software product. Although, these defects does not results into complete failure of a system, but may bring several major functions of a software, to rest.
Minor: These defects produces minor impact, and does not have any significant influence on a software product. The results of these defects may be seen in the product's working, however, it does not stops users to execute it task, which may be carried out, using some other alternative.
Trivial: These types of defects, have no impact on the working of a product, and sometimes, it is ignored and skipped, such as spelling or grammatical mistake.
2) Probability Basis:
One more angle to see a defect in a software application is on the basis of its probability to occur and getting encountered by the user. Based on the likelihood or the possibility of a defect in a software product in terms of percentage, it may be classified into following forms:
High: Signifies the high probability of getting traced out by almost all the users of the application.
Medium: Half of the users are able to trace out the defects presence in a software product.
Low: Generally, not detected any user or may be detected only few numbers of user.
3) Priority Basis:
Defects could also be seen from the business perspective, as which defects needs to be corrected first and which may be fixed at a later stage, based on the current need and demand of the business. Similar to probability basis, priority may also be categorized into following forms:
High: High priority defines the foremost need of a business, to correct a defect, as soon as possible, in the same build.
Medium: Medium priority defects comes next to that of high priority, and may be addressed in any next version or a release of a product.
Low: These types of defects, does not needs to be individually corrected. It may or may not be considered or corrected, along with any other defect, which needs to be fixed.
Apart from the above given basis, a software defect may also be considered on the following grounds:
Extra Defects: Defects due to the implementation of the requirements other than the client’s specified requirements and specifications.
Missing Defects: These defects, generally arises to due to the non-fulfilment of any of the requirements and specifications, as specified by the client or the user.
Wrong Defects: This defect shows the discrepancies between the specified requirements and what was considered and implemented. A requirement being misunderstood and misinterpreted by the project team, and subsequently incorporated by the development team, results into wrong defects.
In nutshell, it may be stated that the above stated types are based on the few of the perspectives of visualizing and categorizing a defect. However, a tester or a developer may classify and visualize a defect, in other various forms, based on their thinking, approach and way of perceiving a defect. You may also explore our next article on Severity vs Priority
.png)
.png)
.png)
.png)
