How Severe Is Your Bug?
Download as PPTX, PDF1 like268 views
The document discusses the classification and prioritization of software defects, emphasizing the importance of identifying severity in relation to the defect's impact on the application's functionality. It outlines various levels of defect severity, ranging from feature and block defects to minor and tweak defects, and explains the criteria for defining priority levels, from immediate to low. Additionally, it highlights the need for testers to assess the impact of defects through a checklist to ensure effective resolution.
How Severe Is Your Bug?
- 1. How Severe Is Your Bug?
- 2. Software testing is entirely about finding defects in applications, right? Apparently, this can be considered as the principal goal of all the QA practices. However, all the defects diverge from each other. It cannot be stated if some are more important than others, yet it’s possible to locate and fix them all. Rendering to Murphy’s Law, a line of code will include a defect it can, hence even the apps that comprise one line of code will include at least one issue. And considering the fact that a tester usually tests large and intricate solutions, there will be oodles of defects. However there still stand limitations for budget and deadlines that force testers to categorize and prioritize the traced bugs so that the most urgent ones are dealt first while the minor issues can be doled out later.
- 3. How to Define Severity?
- 4. How to Define Severity? Severity is basically a parameter to denote the impact of defect on the application/ system, to determine how critical the defect is and what is its impact on the whole system’s functionality. The severity of a defect is related to technical aspect of the product and decides on how bad the bug is for the system. It can be defined by the tester based on the written test cases and functionality. Each technique of classification necessitates categories. Stages of defect priority are almost same and used all through the industry, though they might differ marginally from a company to another. We, at BugRaptors, use the following classification. Feature: A feature defect is when a feature is missing from the application. Block: This defect may block functionality and hence disturb the testing process.
- 5. How to Define Severity? Crash: A crash defect may cause the application close abruptly or crash and may also affect other aspects of the application. Major: A major severity defect causes a noticeable failure or departure from requirements. Medium: A medium severity defect affects unimportant functionality or non-critical data. It has an easy workaround. Minor: A minor severity defect does not cause a failure in execution of the product but is required to be mended. Text: The text defect neither affects the functionality or data, nor the efficiency or the productivity of the application but is merely an inconvenience and needs to be mended before the release. Tweak: Tweak defect means the minutest issue that needs to be resolved.
- 6. How to Define Priority? Defect Priority states the order in which a defect should be fixed. Higher the priority the faster the defect should be resolved. Defects and bugs are prioritized on the basis of the following: Immediate Urgent High Normal Low Immediate And Urgent Priority Defects: These are the defects that disrupt the functionality of an application/ software critically and are to be treated instantly. For example: Complete failure of a feature, unsuccessful installation
- 7. How to Define Priority? High Priority Defects: These are the defects that must be resolved as soon as possible as they can affect the system severely and might not allow its use until it is fixed. Normal Priority Defects: These are the defects that should be resolved in the normal course of the development activities. These can also be altered after a new version is created as they do not stagnate the working of the application. Low Priority Defects: A low priority defect can be an irritant but can be mended once the more serious defects have been fixed.
- 8. How Can Defects Be Classified? To begin with, a tester needs to measure the impact. Remember, even the slightest cosmetic defects can be repeated all over the product and will be a major concern to the end users. This way even the tiniest typo can no longer be reflected as a low- priority issue and will be classified elsewhere due to the impact it will be causing. Also, we follow a tiny checklist to make things little relaxed. The testers answer these listed questions and are able to determine the severity of the actual defect easily. Does the defect you have come across cause the application test to crash? Can the system in the test recover from the crash? Can the system recover by itself, without obligatory external efforts or third-party interactions?
- 9. Define if the defect is present or reflects in other sections of the system? If yes: are those sections linked to any other sections? Will the same arrangements authorize you, as a tester to repeat the defect easily, but in a different system? Is the defect replicable despite of the changes in the configurations? How many users are affected? All the users or just the categories that fall under this risk? Is the defect recurring? How often does it re-occur? What caused it? Which inputs can lead to the defect taking place? The depth of the impact can be deliberated through the isolation of the defect. This is how you will be able to determine and highlight both the occurrence and the sequence of the events that lead to the defect taking place.