How defective a defect can be?
How defective a defect can be?
The main purpose of software testing is finding defects, Right??
The answer for this would be Yes, that can be considered as a primary goal of all QA processes indeed. But there are several types of the defect so we cannot say that some are more important than the others. However, exhaustive testing and fixing all the defects is nearly impossible.
What is Defect?
If the actual result is not matching the expected result then this leads into a defect. Hence, any divergence from the specification mentioned in the product functional specification document is a defect.
How big is the Defect?
The intensity of a bug can be determined by knowing its Severity and Priority.
As a software tester – we deal with large and complex applications and find several defects but due to some limitations like project completion deadline, budget limitations etc. testers have to prioritize the bugs found so that the critical bug can be resolved as early as the possible and small bug can be fixed later.
There are many advantages of classifying the bugs according to their severity and priority Some of them are listed below:
- Efficiency and productiveness of the test Process can be decided
- Increases the effectiveness of Bug-tracking efforts
- Potentially harmful defects can be fixed ASAP in the development life cycle
Defect Severity
What is Defect Severity?
Severity is nothing but the extent to which the bug is making harm to your application and what is its effects on the system
How to decide Severity?
Severity can be determined based on the below categorization:
- Critical/Major: These defects result in complete failure of the application under test. Usually, Critical defects include the crash of an entire system or its sub-systems. After such defect application seizes completely.
- Moderate: These defects do not cause complete termination, but lead to produce wrong and incomplete results.
- Minor: These defects neither result in the termination nor damage the usability of the system. Also, the expected results can be obtained by working around the defect.
- Cosmetic: Defects which are related to the up gradation of the application and where the improvements are related to the look and feel of the application.
In addition to the impact of a defect in an application, its importance to fix it is also vital. So it is necessary to also know about the Priority of the defect as well.
Defect Priority
What is defect priority?
Priority is nothing but the order in which we should fix a defect. i.e Should we fix it now, or later or fixing it, is not required.
How to decide Priority?
Priority can be determined based on the below categorization:
- Low: The defect which is an irritant but can be deferred until critical defects have been fixed.
- Medium: The defect which can be resolved in the normal development cycle i.e . its fixing can be delayed until a new build is created.
- High: The defect which affects the application severely and must be resolved as soon as possible. Until these defect gets fixed the system is of no use.
To understand the Severity and Priority of a bug and their interconnection, let us see some combinations with an example of a famous E-Commerce site Amazon.com
- High Priority & High Severity: Defect which does not allow the user to use the application and attacks the main functionality
Example: Suppose you log in to Amazon.com -> Add Products to the cart->Proceed to checkout and then the system crashes. So the Severity of this will be High as the whole purchase Functionality is not working. Also, the main purpose of Amazon.com is to Buy the products so all the buyers will face the problem. This makes the Priority of this issue High and which needs to be Fixed as early as possible for the purchase process to work.
- High Priority & Low Severity: For Example The spelling mistakes that happen on the main page of the application. So here, in this case, priority will be high as from the end user perspective spelling mistake that too on the title or heading is a big deal but Severity will be low as fixing such a small mistake is not a big task.
Example: Suppose in the amazon.com website, the logo is displayed as ‘Amazon’ with the letter “a” missing. As this defect is not hampering any of the website’s functionality the Severity of the defect will be low but as the Company logo is the identity of any brand as it impacts the user experience the Priority of this defect will be high.
- High Severity & Low Priority: An error because of which user cannot use the application but occurs in that functionality of an application which is rarely used by a user so the priority will be low.
Example: Suppose the tester clicks on Settings->Legal & About link in the Amazon website and the page is not displayed. This defect will have High Severity as the functionality is not working. But as the Legal and About link is rarely used by the users the Priority of the defect will be Low.
- Low Priority and Low Severity: For Example, Any spelling mistakes which is within a subsection and is not observable easily or suppose any page, say FAQ of an application is loading slowly then both the priority and the severity will be low.
Example: Suppose that the tester clicks on Terms and Conditions hyperlink present at the bottom of the home page and the page has some alignment issues or the content of the page has a spelling mistake, the defect will be said as Low Priority as the user rarely read this page and it does not impact the User experience. The Severity of the defect is also Low as it does not affect any of the website’s functionality
Hope this article will help you to decide the size of your bug and to decide their severity and priority as well, if not then you can always contact us at ProtoTech Solutions to know more about their association.
HAPPY TESTING!!!!!!
Author: Ayushi A
Contact us:
info@prototechsolutions.com
ProtoTech Solutions
