The Bug

The three letter word which is the sole purpose of doing testing is BUG. Like the bugs we have in the real world, some hiding all the time, some quite obvious, some quite harmless, some very dangerous, some quite easily found and some very hard to find. Similar is the story of the Software bugs. We as software testers, have the primary responsibility of finding as many bugs as we can in the software. Finding a bug should give you the feeling of ecstasy, with the feeling ranging in intensity in sync with the threat the Bug posesJ, take this line with a bit of pun. A bug has its own life stages; it goes from Discovery to Investigation to fixing it to closing it. In between the major spans of a lifetime it can go through a few other middle phases which are currently not being discussed about here.

The first thing to do when one comes across a bug is to report it and there are a lot many tools available for doing the same which I will be highlighting more in different posts or one can report them in the simplest possible way of writing it down in a text file. The bug has a Severity and Priority associated with it. The favorite question in many a interview is "What is the difference between severity and priority?" It's quite simple to figure that out once you start working as a tester but from what I have gathered I will put the difference as follows:

The priority of the bug can be from High to Medium to Low. The bug which is given a high priority is the one that requires immediate attention in perspective of the product or the thing being tested and a bug with Low priority is safe to be tackled later if there are other really pressing issues to be taken care of. The levels of priority is decided based on the kind of bug one finds, this bug need not be a major functionality loss to be of a High priority, it can be affecting no functionality at all but still be of high priority for example: the logo of the company is not correct which may be an outcome of a copy paste from somewhere on the world wide web. The logo being wrong does not affect the functionality part at all but it still is a high priority bug.

Whereas, the severity of the bug can be defined based on the amount of damage its causing such as its Crashing the application, or it's a Functionality Loss , or it's a problem in the User Interface or its an enhancement to the existing functionality. The severity is a parameter that will indicate whether the bug is totally blocking the user i.e. it crashes the product and the user is unable to do anything else. OR the bug is blocking a particular functionality but its allowing the user to do other things or access other functionalities the product has to offer. OR the bug is only something that is misplace on the user interface of the product but looks ugly or is out of place. Or the bug is an enhancement to the existing functionality of the product.

Going by the Logo example above, the bug can have a Priority 4 (4 being the highest and 1 being the lowest) and Severity can be say 2 (4 being the highest and 1 being the lowest) if the product with the logo is to be release in a timeframe of 6 months and the logo is wrong in say one place, this is true in the context of software only. But the Severity would be 4, if the product has to be release in the coming week.

So a bug with Priority=4 and Severity=4 is the one which has to be given immediate attention by a developer and it also is a one that should not be missed on the part of a software tester. Such bugs a lovingly also called as "Show Stoppers". Not that the other bugs can be ignored, even a bug with a Priority=1 and Severity=1 is a bug and it deserves equal importance but as we say in the real world it can wait. Most of low priority and low severity bugs attract the word "Deferred" in the world of software testing. This word means this bug can wait till probably the next release or the next milestone.

A lot has been written about the Bug, but a lot can be written still. What would follow in the post about the Bug that follow later would be the steps to write down one when you find one, more examples that would help you decide the severity and priority of the bug, the To and Fro movement of the bug between a tester and a developer and a lot more.

A bug is a problem but it's a reason to rejoice for a software tester. Best of luck for finding a lot of BUGS.