To make the detection and prioritization of defects faster and easier, I recommend applying to them rigorous classification techniques. Below, I outlined the approach we take at ScienceSoft to classifying software bugs and listed the most common types of bugs, accompanying them with examples.
Three common classifications of software bugs
I single out three classifications of software bugs: by nature, by priority, and by severity. While the classifiers for the latter two are present in bug tracking systems by default, I recommend setting up a classifier for the division of bugs by their nature as well since it helps streamline the assignment of bug fixing tasks to the responsible teams.
Software defects by nature
Functional defects
Functional defects are the errors identified in case the behavior of software is not compliant with the functional requirements. Such types of defects are discovered via functional testing. For example, in one of our recent testing projects, a functional defect was found in an ecommerce website’s search engine. It didn’t return any results when a user typed in a product ID, while it was stated in the requirements that the search could be conducted by both a product’s name and ID.
Performance defects
Performance defects are those bound to software’s speed, stability, response time, and resource consumption, and are discovered during performance testing. An example of a performance defect is a system’s response time being X times longer than that stated in the requirements.
Usability defects
Usability defects make an application inconvenient to use and, thus, hamper a user’s experience with software. A content layout that is difficult to scan or navigate and an overly complex signup procedure are the examples of usability defects. To identify such defects, ScienceSoft’s test engineers and business analysts (or UX designers) validate software against usability requirements and Web Content Accessibility Guidelines (WCAG) during usability testing.
Compatibility defects
An application with compatibility errors doesn’t show consistent performance on particular types of hardware, operating systems, browsers, and devices or when integrated with certain software or operating under certain network configurations. Compatibility testing is carried out in order to discover such issues. For instance, testing a mobile app for car insurance claim estimation, we uncovered that it failed to behave according to the requirements on Android 8.0 and 8.1. The defects were related to the changes in font size, content alignment, and scroll bar.
Security defects
My colleague Uladzislau Murashka, Penetration Testing Consultant and Certified Ethical Hacker, says: “Security defects are the weaknesses allowing for a potential security attack. The most frequent security defects in projects we perform security testing for are encryption errors, susceptibility to SQL injections, XSS vulnerabilities, buffer overflows, weak authentication, and logical errors in role-based access”.
Software defects by severity
At ScienceSoft, we classify defects according to severity based on the technical impact a defect has on a system and single out the following severity levels:
- Critical defects usually block an entire system’s or module’s functionality, and testing cannot proceed further without such a defect being fixed. An example of a critical defect is an application’s returning a server error message after a login attempt.
- High-severity defects affect key functionality of an application, and the app behaves in a way that is strongly different from the one stated in the requirements, for instance, an email service provider does not allow adding more than one email address to the recipient field.
- Medium-severity defects are identified in case a minor function does not behave in a way stated in the requirements. An example of such a defect is a broken link in an application’s Terms and Requirements section.
- Low-severity defects are primarily related to an application’s UI and may include such an example as a slightly different size or color of a button.
Software defects by priority
A defect priority characterizes an error’s business impact. In ScienceSoft’s projects, a project manager, a product owner, or any business stakeholder identifies defect priority. We single out the following priority levels:
- Urgent defects need to be fixed within 24 hours after being reported. Defects with a critical severity status fall in this category. However, low-severity defects may be classified as high-priority as well. For instance, a typo in a company’s name on an application’s home page doesn’t have technical impact on software, but has a major business impact, hence, is classified as urgent.
- High-priority defects are the errors that must be fixed in an upcoming release in order to meet the exit criteria. An example of a high-priority defect is an application’s failing to navigate a user from the login page to the home page even though a user has entered valid login data.
- Medium-priority defects are the errors that may be fixed after an upcoming release or in the subsequent release. An application returning the expected result, which, however, formats incorrectly in a particular browser, is an example of a medium-priority defect.
- Low-priority defects are the errors that do not need to be fixed in order to meet the exit criteria but require fixing before an application becomes generally available. Typos, alignment, element size, and other cosmetic UI issues are usually included in this group.
Download template: Project Defect Template
Why does correct defect classification matter?
Having learned the basics of defect classification, you will not only make sure that defect handling is assigned to the responsible project teams but also streamline defect prioritization. It, in turn, speeds up defect fixes and increases the overall efficiency of the testing and development processes.
As defect severity and priority levels impact the evaluation of the development process efficiency and may influence payments and penalties in case of outsourced development, it is crucial to define the criteria for assessing the defect severity and priority that work for your project. In case you feel like you need a consultation on setting up severity and priority assessment criteria or performing other defect analysis tasks, you are welcome to leave us a request.
Source: ScienceSoft
