Types of Bugs in Software Testing

Types of Bugs in Software Testing
March 24 10:00 2011 Print This Article

There is no software without bugs. Every day testers all over the world encounter new and new software defects and issues. But some of them have become sort of common as they appear more frequently than others.

Today we are going to identify the most common types of bugs all testers should know. This will help to look for software issues in the most likely places instead of performing a random search. Also, testers can face unusual software bugs.

Incorrect calculations

This type of problem can be caused by a lot of reasons, e.g., wrong algorithm, data type mismatch or just coding errors. Sometimes, a cost of these bugs can be very high. History knows a lot of examples when a wrong number provoked accidents or huge financial losses.

For example, let’s remember the famous Ariane 5, a rocket developed by the European Space Agency. It was supposed to float in space but in reality, ended up exploding only 40 seconds after its launching. Money losses were estimated at $500 million. The reason was an unpredictable conversion from a 64-bit floating point number to a 16-bit signed integer value. As a result, 16 bits were not enough to represent the necessary value so calculations went wrong.

Functional errors

All the functionality of any program should operate correctly. It means that an expected result of operations should coincide with an actual one. But often they don’t. As far as there are programs, which have quite a big range of functions, there is a great probability of bug omission. Such type of errors can vary from unclickable buttons to inability to use the main functionality of the software.

Error handling errors

All the software problems occurred during an interaction with the user should be handled successfully. Besides, a user should be clearly informed about the cause of the problem and possible ways out. If a user types something incorrectly, he / she should receive a quite informative message not to do the same mistake again.
There is a good example. In 1997 the USS Yorktown, a US Navy warship, drifted for two hours because of a software crash. A crew member typed “0” to the database and made the computer divide by zero. That caused a buffer overrun and led to the program crash and loss of ship control.

Communication errors

Software should be easy to use and provide all necessary instructions and recommendations for users to interact with a program. Sometimes it happens that a new feature is implemented, but you cannot find it even using documentation. Also, if you have uploaded a file or have sent a letter, you should receive a message with the operation status. Haven’t received it? That is it – a communication error. Errors of this type seem not so serious but, actually, they can make your customers select your competitor instead of you.

Syntactic errors

We all are humans and may make grammar mistakes. Especially, it happens when the product is translated into different languages. While testing GUI of the product, it is important to switch languages and check the correspondence of the elements with the documentation. Just take a look at this contradictory message received from Remmina Remote Desktop Client. The word “success” is probably pasted by mistake, but it can perplex users for some time.

Missing command errors

Sometimes it happens, that you cannot close a pop-up window without performing some actions, even if you don’t want to. This is missing command errors. That can be not only the absence of button but also the absence of a logical option.

Boundary related errors

In our life, everything has a limit. The same we can say about software resources. Maximum text size, maximum number of simultaneous users, memory limit allocated for one element – if all of this is not anticipated by developers it will definitely cause problems.

Probably, the most famous problem of this type is the “Year 2000 problem” or so-called “Millennium bug”. Previously, in the majority of programs, years were represented only with two digests, e.g. 85 or 98, which meant 1985 and 1998 respectively. The problem arose when it came to 2000 because computer systems would have interpreted it as 1900. Though the problem was anticipated, it still cost around 300 billion dollars throughout the world to deal with the problem.

Related Posts:

About Article Author

view more articles
Nataliia Vasylyna
Nataliia Vasylyna

View More Articles
  • Jonathan

    How do you define a defect in the absence of a specification or the specification is incomplete?

    For example, what if the product implements the specified functionality, but it is hard to use. So I go back to the specification (if I’m lucky enough to have one) and it says nothing about ease of use. Is this a defect — the software matches the specification as written?