Did you know that dividing bugs in classes can help you improve the testing process and detect them faster? You can also check Codoid.com for more information.
We have decided to divide the bugs in three classes; by nature, severity and priority. The classifier for the last two categories are already present in the tracking system but, we included the first category since it would help us giving the task of fixing them to the right team.
Bugs By Nature
Defects of Function
Functional defects arise when the software is not behaving in compliance with the functional requirements. These kinds of errors are detected with the help of functional testing.
Defects of Performance
Defects pf performance are about the software response time, speed, stability and resource consumption. They are detected in performance testing. An error of performance would be the system taking x times longer than what it was supposed to.
Defects of Usability
Errors of usability make the using the app inconvenient and give the user a bad experience. A layout of content that is hard to understand or navigate or a complex sign up procedure are examples of defects of usability. To detect these errors you can test the requirements whether they can be validated against the usability requirements and comply with the WCAG during the test.
Defects of Compatibility
As you may already have guessed, a software with compatibility issues will have trouble functioning with a certain types of browsers, hardware, operating system, and devices. You may even have trouble integrating the app with a software or making it operate under a certain configuration network.
Defects of security
These defects are weaknesses in the app that make it vulnerable to a security attack. The common security errors are susceptibility to SQL injections, encryption errors, weak authentication, XSS weaknesses and logical mistakes in role based access.
Bugs by Severity
We have categorized defects in multiple severity levels depending upon the technical impact it has on the system.
Defects of critical severity block the entire functionality of the system. You can’t proceed with the testing unless you fix this error first. The example of this defect would be a message of error when you log-in to the app.
A defect of high severity affects a key function of the app. The app then starts to behave in a way which is different than what was stated in the requirements. An example of this would be the email service provider not allowing you to add more than one recipient to the field.
Defects of medium severity affect minor functions in a way so that the app behaves in a way not stated in the requirements. An example of this would be broken link in the apps’ terms and requirement section.
These are small errors related to the app’s UI and may include irregularities in the size and font of a button.
Bugs by Priority
These defects are prioritized according to their business impact.
Defects of critical severity fall in this category, they need to be fixed within 24 hours.
Defects of this kind must be fixed if the exit criteria is to be met. An example would be not getting access to the app even after entering correct information.
These defects don’t need to be fixed in order to meet exit criteria but you should do it before the app becomes generally available.
Now that you know how to classify defects, you will not only be able to hand them over to the responsible team for management but also speed up the whole fixing process. It also increases the efficiency of the development and testing process.