Testing Lessons – Top 5 Secrets to Bug Hunting Success!

Testers should catch bugs in the software that they are testing. They should try to catch as many important bugs as soon as possible. Catching an important bug earlier on the Product Life Cycle can save the Project from financial losses and mitigate risks as compared to catching the same at a later stage in SDLC!

Testers are the voice of the customers/clients. They should work as the representative of the customer/client.

Testers are information providers. They provide important quality related information to the relevant stakeholders in a timely and usable fashion to support decision-making and assist in taking corrective action. Relevant stakeholders may include (but not limited to) customer/sponsor, intended users, management staffs, data analysts, data providers etc.
 
These are few of the roles that are considered as the role of a Software Tester. There can be other roles too depending on the context (like organizational structure, domain type, team size, skill level of the tester etc). Before writing further, let me clarify that this particular post is not to argue upon the possible roles of a Software Tester.

Whatever may be the roles of a Software Tester, "catching bugs" is one of the most important of them, in my opinion. Using various tools like Inflectra for testing is one of the easier ways, but sometimes automated testing is not enough, so testers need to be good at catching bugs. This (catching bugs) is one characteristic that differentiates a good tester from a mediocre tester. 

[NOTE: "Catching of bugs" should not be confused with "catching more bugs". Trying to evaluate a Tester's skill based on the bug count can be dangerous. Anyway, that is a different topic altogether and may be I would like to write about it in future.]

However, I must confess that I am one of those testers who are good enough at catching bugs. Once one of my friend-cum-colleague had asked me – “Debasis, what is the secret of your bug hunting ability? How do you find the bugs that are generally missed by other testers in the team?” Today, after almost a year after the incident, I am going to answer his question here. I will try to jot down few small yet powerful methods that have helped me in getting an edge over others as far as bug hunting is concerned. I am going to spill my bug hunting secrets here in a hope that it may help other testers in catching more bugs. So here they are:

1. Learn to break rules once in a while. Explore! I have seen testers missing bugs while trying to adhere strictly to pre-defined test cases. Test cases may be good at catching bugs. But the major problem, in my opinion, with test cases is that it is as difficult to attain near-100% test coverage using test cases, as it is impossible to attain a so called 100% bug free product! It is likely for a tester to fall victim to inattentional blindness, while trying to strictly follow a test case. So along with the test case, also try to explore the functionality under test. I have found it an effective method to catch more bugs that lurk around the functionality but are not covered somehow by the test cases.

2. Look for patterns! Software Bugs are gregarious in nature. They like to stay in groups. They like to infest similar/related functionalities. Most of the bug has its own unique nature that makes it singular. Try to identify it. Try to identify the pattern. While testing a new area, try to use your past test ideas which were successful in uncovering bugs in a similar functionality. Chances are more that you might soon come across some similar bugs in this functionality too. Making a list of the test ideas that helped you to hunt down some important bugs in past can help you too.

3. Hit it hard where it hurts the most! It is easy to get carried away when you come across a bug (can be a crash, a system hang, a functionality error, an UI problem, a performance bottleneck and so on). Take it easy. This might just be the beginning not the end! Don't be tempted to rush and log it into your bug/issue/defect tracker. Finding a bug merely suggests that there is a loose link in the software here. The system might have gone into an unstable state before you encountered the bug. Assuming that the system is in an unstable state abuse it more. Feed more insane inputs than ever. Fire up gallons of data inputs. Reduce the available system resources. Try to take it to a point where the application under test (AUT) might come to its knees. Who knows you might soon come across an uglier face of the earlier bug! When you find it, don’t forget to note down all the details and check the reproducibility before logging it into the tracker.

4. Listen to the footsteps of the approaching bug! Have you ever heard the footsteps of an approaching bug? Well, I have! By saying this I am not trying to exaggerate the whole issue. One of my common practices while testing (bug hunting!) is to wear my headset. This helps in a couple of fronts. It enables me to hear the various background sounds (like the ding of a warning message, buzz of different message boxes and alert messages etc.). In addition, it also helps me in hearing the sound of some error boxes that might run on the background but don't come on the screen due to some reason! Once I was testing a search box in a web application. When I was hitting the Search button I was hearing a ding but no error message whatsoever. Though the search result pages looked clean, the sound in the background aroused my curiosity. Enquiring more on this revealed that there was an error with the lexical analyzer of the search engine and for some reason the error message was not getting displayed on screen! There were more than 20 search result pages per certain search queries. I am wondering if I could still have caught the bug so easily, had I not been using my headset that time.

5. Two is better than one. Pair it! It is said that testers should never run out of ideas! While this is a desirable quality for any tester, unfortunately this is not always true. After all, a tester is also a human being and is prone to failure! There may be times when no test ideas look like uncovering any bug. I believe it happens with most of the testers. At least it happens with me. I call them as "Dry Days". When none of the test ideas that come into my mind are able to dig out any bug. In such situations I like to shift gears. I use to request one of my tester colleagues to come and test with me. This helps me (us!) from different dimensions. When two of us are testing the same thing at the same point of time, it helps each of us in building our own test ideas. It also helps me building on more test ideas on the test idea created by my partner and vice versa. When a tester works on the same project for a long duration, it is quite possible that the typical work pressure may wear down the spirit of the tester or may result in tunnel vision. Working once in a while in pair (Pair Testing) can work brilliantly in such situations. While testing in pairs you become more focused as you are testing in front of someone and this feeling of "I-am-being-watched" can do wonders in rejuvenating the wore down tester inside you. At least this strategy has worked nicely for me whenever I was going through a rough patch.

These are few of the things that have helped me in catching bugs more efficiently. These are practices that have worked for me in my context. However, these may or may not work for you, as your context might be entirely different from mine. Anyway, you can give them a try and see if they can help you in catching more bugs quickly than you are catching now! Do let me know your ideas and/or views on this through a comment. Here is to your Bug Hunting success!

Happy Testing…

Share on Google Plus

About Debasis Pradhan

Debasis has over a decade worth of exclusive experience in the field of Software Quality Assurance, Software Development and Testing. He writes here to share some of his interesting experiences with fellow testers.