5 Types of Software Bugs you Should Watch Out for
Although the powerful insect lobby convinced Disney to portray bugs as cute creatures (see image above), any good programmer knows their mischief and cruelty.
In today’s article, we’ll take a look at the worst foes you might end up facing on the cyber battlefield! Let’s analyze the 5 main types of software defects categorized according to their nature, which are:
- Performance bugs
- Functional bugs
- Usability bugs
- Security bugs
- Compatibility bugs
Later on, we’ll also spend a few words regarding bugs’ severity and priority levels.
1. Performance bugs
Software performance is an essential element in determining its usability and greatly influences users’ perception of the product.
It is mainly related to the stability, speed, or response time of software resources. Any defect that undermines these features falls into the performance bug category.
This type of programming defect causes significant performance degradation and leads to a frustrating user experience, not to mention user abandonment and the potential loss of millions of dollars.
Is the response delay ten times longer than described in the requirements? We are probably facing a performance bug. A really BAD performance bug, I’d say.
Performance bugs hide well
Dealing with performance bugs can be especially tricky. In fact, according to research, fixing performance bugs is generally more difficult than fixing non-performance bugs, even though the two types of fixes are equally prone to errors.
While most non-performance bugs can be detected through observing the negative effects of bugs, a large percentage of performance bugs must be spotted through code reasoning.
Basically, performance bugs usually don’t generate incorrect results or crashes in the program under test. Therefore, they cannot be detected simply by checking the software output.
“According to research, fixing performance bugs is generally more difficult than fixing non-performance bugs, even though the two types of fixes are equally prone to errors.”
Can we fix this issue?
Developers need better tools and greater mastery to spot performance bugs and test patches.
Specifically, the performance bug detection process can be improved with efficient profiling techniques and test oracles, which are mechanisms to decide if the software performance under a certain workload is acceptable.
Unfortunately, the lack of adequate test oracles for this specific task is a well-known problem that will need to be addressed in the future.
2. Functional bugs
Functional bugs affect the functionality of a piece of software.
YOU DON’T SAY?
We are talking about errors that make the software behavior not compliant with the declared functional requirements. This type of defect can be spotted pretty easily through functional tests.
An example of a functional bug could be the non-reaction or the total crush of the program to user input, such as pressing a button.
Another case may concern the search engine of an e-commerce site that does not recognize the product ID but only the name, contrary to what is stated in the specifications.
Is it really a bug?
While functional bugs are generally easier to fix than performance bugs, as explained in the previous paragraph, that doesn’t mean testers always have an easy time.
Especially in the case of an external team, the testers are not 100% aware of the software functionality or its implementation and operation in different scenarios.
Because of that, it may not be so straightforward to determine whether some feature is designed a certain way or if it is actually broken.
For example, if a specific accounting software functionality works in a different way than other similar software, this could be a developers’ precise choice.
How to manage functional bugs
Consider the following situation: testers have noticed that a form field is not validated and think they have found a functional bug. At this point, they should look for any clues that the developers intended to validate the field.
Good evidence of their suspicions would be that the field is validated in some cases but not in others.
To sum up, testing the software under a multitude of different conditions and combining the suspicious feature with other features to spot potential differences can help us clear our minds.
A pair of special cases
Two other peculiar cases that could create doubts on how to deal with the problem are edge case bugs and forced bugs. Edge case bugs only occur when a feature is used in a “weird” way.
Let’s say that you repeatedly opened and closed a menu as fast as you press the buttons for a Tekken combo. Meanwhile, you minimized the app and finally threw your computer out the window. This could trigger an edge case bug (and prove that you need some valium).
Even forced bugs only occur under very specific conditions, such as clicking multiple items simultaneously on your smartphone screen.
These types of defects will occur with extreme rarity and will therefore be treated as low priority or irrelevant bugs.
3. Usability bugs
When an application is more enigmatic and weird than a Jigsaw puzzle, the main reason could be a usability bug. Usability bugs, in fact, undermine the user experience making software over-complicated to use.
We may be dealing with an interface that is difficult to navigate or with a new account registration that is excessively long and frustrating.
Be careful not to confuse functional and usability bugs. For example, if you enter a password that exceeds 10 characters in a text box whose limit is programmed to be 10 characters, this is a functional defect.
But… what if you do the same and the app refuses your password (as expected) without sending a validation message such as “enter a password between 1 and 10 characters”? This could be confusing and therefore falls into the category of usability bugs.
How do we discover usability bugs?
Such kind of defect is relatively easy to detect: it appears when users struggle to manage an interface.
Real users are actually the protagonists of the testing phase, a necessary method to ensure that a website, app, or other product is actually intuitive, enjoyable, and easy to use.
It consists of asking users to interact with the software and complete specific tasks. This is generally done under researchers’ observation to spot any problems that create confusion.
If the same usability problems are faced by many users, the testing team will give recommendations in order to fix them.
Easy to spot, difficult to understand
While usability bugs are easy enough to spot, the same cannot be said for their fixes. Understanding what doesn’t work in an interface may be tough cause we’re talking about flaws whose nature is very vague and unclear.
In fact, it would be more appropriate to talk about usability defects in general, because such faults do not depend necessarily on actual bugs (errors made in the program’s design or its source code), but maybe on specific graphical and usage choices of the developers.
The problem may not even depend on the interface but on the user’s mistakes, such as typos. Maybe the tester hasn’t noticed a fundamental feature of the program (make him a coffee!). Or he does not understand the meaning of an icon that was thought to be clear.
That’s why knowing the context as a whole (eg what the user was doing to get what) and testing with multiple subjects can help clarify the situation.
4. Security bugs
Security bugs are software defects that allow bad guys to gain unauthorized access or control on a computer system. Such security breaches may be carried out by compromising user authentication, access authorization, or data integrity and confidentiality.
Security bugs are usually the result of two main causes, namely non-conformance with software requirements or an error/omission in the requirements.
Problems with software requirements
Non-conformance with software requirements may be, for example, a coding error or an input validation defect. It can be detected relatively easily thanks to specific verification and validation techniques and prevented by security assurance procedures.
Improving such methods via software security assurance programs is the way-to-go if you want to ensure the security of your software.
Errors or omissions in software requirements, on the other hand, are a real pain in the a**. If the software requirements are incorrect or incomplete, such faults can be much more difficult to identify.
That’s the case if the software performs according to requirements under normal use but behaves incorrectly in specific system states.
Dealing with security bugs
Improving the development process and creating software with fewer bugs is the best way to enhance software security and reduce vulnerabilities. This can be done in the first place with proper security architecture and design analysis.
Such a process is divided into four phases:
- Logical analysis evaluates the equations and algorithms
- Data analysis verifies the usage of each data item in the software’s design
- Interface analysis checks the interfaces’ relation with other components, including the hardware
- Constraint analysis assesses how software components react to restrictions imposed by real-world requirements
After that, it’s time for the code analysis. This second phase ensures that the software source code is free of defects, implements the required design, and meets all security requirements.
The techniques used for code analysis are basically the same four already described for the architecture and design analysis.
And then came the testing…
The final phase is software security testing. This stage involves a penetration test (don’t think wrong!) which should confirm the results of the previous analyzes.
To this end, it will examine the behavior of the software and assess that it meets all security requirements.
5. Compatibility bugs
Last but not least, let’s talk about compatibility bugs. This kind of defect impairs the performance of software when it is run on particular types of hardware, browsers, operating systems, and so on.
Among the many compatibility defects, we can mention variations in the user interface, flaws in scrollbars, changes in CSS style, content alignment, or font size.
In recent years, software compatibility and optimization on many platforms played a vital role in determining the success of a product. Just think of the insane amount of different devices and operating system versions flooding the mobile phone market!
Sadly, CD Projekt RED didn’t agree with that when releasing Cyberpunk 2077 for PS4.
Spotting compatibility bugs
In order to detect bugs and ensure compliance with compatibility requirements, any software must undergo a compatibility test, usually performed during the early stages of quality control.
This testing procedure verifies the compatibility of the developed software product with a wide range of other objects.
And for “wide”, I mean WIDE: operating systems (MAC, Windows, Android…), devices (Bluetooth, USBs, printers…), mobiles (devices of different sizes, operating systems, features…), network (varying bandwidth and operating speed), browser (Chrome, Firefox…), and software versions.
This research is conducted by designing various test cases and configurations, running software in those environments, and observing any bugs which will then be fixed by the responsible team.
Classifying bugs by severity and priority
Software defects are not labeled based solely on their nature. When it comes to categorizing bugs, two other fundamental classification criteria are their severity and priority.
Software bugs by severity
Bug severity measures the impact a software defect can have on the functioning of an application feature.
Depending on the threat the bug poses to the software, its severity can be categorized into four different levels, usually determined by quality analysts and test engineers:
Low: bugs do not cause any obvious system errors, they are mainly aesthetic and related to the user interface of an application, eg. slightly different colors of a logo.
Minor: bugs can produce unexpected or unwanted behavior, but not enough to totally disrupt system operation, eg. broken links in the Terms and Requirements section of the app.
Major: the main functionalities of an application cannot work properly, eg. a banking app whose users are not able to transfer money to other accounts.
Critical: bugs that trigger complete system shutdown or make an application inaccessible to users, eg. login doesn’t work
The bug severity rating is primarily based on how often the bug can occur. This is because even minor bugs, when repeated constantly, can totally ruin the user experience. Once the defect has been isolated and identified, it can be examined to assess its severity.
Software bugs by priority
Bug priority refers to the urgency of fixing and eliminating a bug from a software. It measures the level of priority that should be given to its resolution during the debugging process. We can divide it into four levels:
Low: no worries! the bug is probably only cosmetic and can be fixed later, eg. typos and element size.
Medium: the bug can be fixed without too much urgency during development and testing, eg. an app that randomly fails to send email notifications to subscribers.
High: this defect should be fixed before the product launch or in the first available patch because it affects one of its core functionalities, eg. the CC section in the mail doesn’t allow users to add multiple contacts.
Urgent: the bug completely compromises the main functionalities of the application and must be corrected immediately, eg. the system crashes every time. SIGH…
While the Severity status is based on the technical aspect of the product, the Priority status is determined by the Product Manager in accordance with the customer’s requirements.
This gives an idea of how closely the choices regarding priorities are linked to business planning and financial evaluations.
Are severity and priority always related?
Generally speaking, we can say that severity and priority are closely related. Critical faults generally take priority in the debugging phase, while low-severity bugs are usually at the bottom of the list.
But that’s not always the case. Suppose a typo in our company or software name appears on the app home page. This bug is simply cosmetic and won’t affect any basic functionality, but it can be of high priority as you don’t really want to look like a careless amateur!
And the opposite situation? Think of an application that continually crashes on very old devices or operating systems. This can be considered a critical bug but will probably not be prioritized as it affects a small number of users.
Know your bug!
As Sun Tzu said, “know your enemy”. This rule also applies in programming, where a correct classification of software bugs helps greatly to streamline and speed up any testing process.
As soon as you know what you are dealing with, bug fixes can be assigned to the appropriate team and prioritized in the most efficient way.
This will save you a lot of time, effort, and money. Not to mention the satisfaction of crushing bugs like Sergeant Rico in Starship Troopers.