Sometimes we neglect what really is a bug. Of course there are obvious bugs which you don’t need to seriously think about it, but sometimes it may be difficult to evaluate if something really is a bug or not. In the software development process several issues may arise, and not all of them are necessarily bugs.
Since bugs are a central piece in software development and testing we need an accurate description about what it is, so when those tricky ones occur we are able to make an accurate judgement about it.
There are several names for software bugs such as error, problem, failure, defect, etc. Just by listing these variations we have a better idea of what it is: some type of error, of course. But this is a very narrow definition because it’s impossible to firmly state whether something really is a bug based solely on it. We need solid parameters to be able to decide whether something really is a bug or not. I have found these solid parameters on Patton (6-7):
- The software doesn’t do something that the product specification says it should do.
- The software does something that the product specification says it shouldn’t do.
- The software does something that the product specification doesn’t mention.
- The software doesn’t do something that the product specification doesn’t mention but should.
- The software is difficult to understand, hard to use, slow, or—in the software tester’s eyes —will be viewed by the end user as just plain not right.
The first two items are quite straightforward, but some doubts may rise about the others.
On the third item, suppose a developer implementing a nice extra feature. Although it may be a nice feature, it may have side effects. The software tester will have more work to do, it may introduce more bugs or it may be part of a future release of the product (messing up with such plan). If you are a developer and have an idea for a new feature, talk about it to your team first.
The fourth item conflict with the third item, but it exists because no specification is perfect and will never cover every detail of the product. So here common sense and good communication must prevail. Ideally, the specification should be updated with new issues.
The fifth item covers any other possible bug, such as: a GUI icon is very small, a scrollbar is hard to use, a text is blurred, it’s difficult to find a piece of information, etc. As you can see it demands a lot of common sense and real world experience from the person who is testing, since these possible bugs are more subjective.
You may have noticed that only the fifth item doesn’t mention a product specification. This is due to the fact that it is a key documentation which must exist for any product. For more information about it read the article What is a Product Specification?.
Another important issue is the difference between the bug itself from a software’s failure. While the bug is the error itself, the root cause (e.g. code error, logic mistake), a failure is its consequence, its effect in the running software. Thus, a single bug may trigger multiple failures.
When a bug exists, but no one hit its failure, it’s called a latent bug (Patton 30).
Note that the way I’m using the terms bug and failure in this article is not universal. Anyone may use different terms and that’s ok. The important thing is that in the context of the discussion, in the context of a team, everyone is on the same page. I’ve chose bug as the root cause and failure as its consequence because they are very popular terms. When the bug term was coined it refered to the root cause of a failure, i.e., when a real life bug triggered a failure in the system.
I have found it very useful not only to myself as a software developer and tester, but also to the whole team (project coordinators, QA professionals, etc), helping to improve teamwork communication and software’s quality.
Patton, Ron. Software Testing. 2nd ed. Sams, 2005.