Keep calm and don’t let bugs bite you!
Software quality assurance is a tricky science. Surely everybody has heard of a software life cycle but what about defects? Surely many things are occurring to a bug from the time it is located and up to the point it is fixed. This is what may be called a bug life cycle indeed.
Some Bug basics
What is a bug? Any software behavior that is different from how the application was meant to work. This knowledge is based on the requirements. When are bugs located? Through out test execution, of course. But, mostly, there are some issues occurring at any particular stage of the project and that is just what testers have to deal with every day.
We are to get a bit more specific for all to become crystal clear. What happens when you are analyzing requirements and are finding something that simply seems wrong or something you will not have the potential to test? Well, we have encountered a defect you may raise (all depends on your current defect management process). Frankly speaking you always should raise defects if something is actually different in any way from what it is originally supposed to be, otherwise testing looses value. That is why bugs may be located in every single part of the project and not only in software’s code. Bugs you are to alert people about. For all’s sake it may be a simple typo, but you never know for sure, thus raise the issue and fix it if possible no matter what your personal judgment has t say about this or that bug’s value.
The math within testing is quite simple: locate + report + fix = win! Things are rarely going different although they may seem to.
What to do when a bug is located?
What are a tester’s actions when he has found something that seems like a defect? Before logging it, that is. A tester is to make sure a defect is really a defect. Taking a look at the requirements or a small chat with peers usually solves that issue. But this step is quite relevant as you can’t allow yourself to raise incorrect defects and, especially to do so more than once.
The next step: assigning the bug
Who will be responsible for the defect’s fix? Such decisions had to be made some time ago during test plan creation stage. Or, at the very least, if this is decided later on the appropriate info has to be documented in the test plan.
How to do so in the right way? When you are sure you are facing a defect you are to log and record it appropriately for the person you are assigning it to has no trouble reproducing the bug. Be sure your report is as informative as it gets.
After a bug is fixed its life cycle is over. But stay sharp, the next ones are coming.