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.


  1. Listening to footsteps of bugs - is a fantastic idea.

  2. @ Pradeep,

    I am glad that you liked the idea.


  3. Sorry, I some how messed up the name when addressing you at my end, so I thought I would drop by over here. I take back my comment about the images now though, it's only the image for this article that looks clip art-ish, all the others look great. The two small suggestions I had were 1) to use emphasis in your heading...pick want you want readers to look at, and 2) add a little space between the content and the sidebar, it is a little crowded, but like I said at my blog, I think your blog is great, and you have some great content here. Cheers, Simon.

  4. @ Simon,

    Thanks a lot for taking out time and verifying my blog design. I appreciate your 2 suggestions to improve the design. I will work soon to fix them up. Once again thanks a lot for your efforts and those kind words. Happy Testing/Designing... :)


  5. Hi,

    Your blog is great. I liked the "Two is better than one. Pair it!" idea (even i do it during my Exams). "Listen to the footsteps of the approaching bug!" indicates your practical thinking. Have a rocking future in s/w testing...

  6. @ The Blogger,

    I am happy that you found the post interesting. Thanks for your wishes...


  7. Debasis, You have given a very nice name to what many good testers might already be doing, hearing the footsteps of defect is wonderful expression. I tend to use it very often and thought will share how I use it. Most of the cases, defects are manifested because of some unhandled exceptions. In another words, presence of exceptions in the log files could be an indication that there are some defects around your current activities. To catch/hear this footstep ( Exception in the log file ), I normally write some small scripts to monitor all the log files generated by application under test and gets an alert everytime they have certain keywords (Exception/Error/Failure and so on..). Even if I do not get any defect and there is any exception in any of the log file, I always discuss it with the development team on why there is any exception and why it is not manifested in some error. This is one simple example of how you can ask your system to produce real noise after hearing footsteps in log file :) Nice Post.

  8. Hi Debashish,
    I suddenly noticed that ur Ads by google link is not properly visible. So i selected the content which was visible i.e., Ads By G and dragged the mouse toward right. It was now visible Ads By Google but a portion to the left side of the page are visible no more. We have to refresh the page again to see the content of the page properly. U can have a look at it.

  9. @ Testing Geek,

    It was a really interesting dimension to my original post that you added via your comment. I appreciate your effort. Keep commenting in future, where you feel you can add value to the blog post. Thanks.

    @ Mita,

    I am glad that "as a tester" you could notice this glitch. This is something I am already aware of! This is happening because; I am trying to a display a 728 wide Ad block in a 700 wide content area! As a result, some part is missing when it is being displayed. To get rid of this I need to expand my main content width to at least 728 pixels wide! And in turn I will have to get a wider Header image for the blog. I am not sure if I will do that in near future due to my already hectic working schedules. May be, I will do that in a couple of months, after creating a wider Header image for my blog. The rest part (expanding the content area so as to accommodate the wide Ad block) should not be a big problem, once I have a wider Blog Header image.

    Until then, I guess you will have to be displayed with "Ads by G"! Please bear with that. Furthermore, I thought it should not affect my regular readers by much, as most of them don't click on any Ads. :)

    Anyway, thanks for pointing out this. Keep reading and keep testing me/my blog/my writing/my ideas…


  10. I love your technique of listening to the application, very smart! I didn’t think about this when I worked as a software tester in a previous position, but I can use it today, even with my blog. After all, you never stop testing, or at least you shouldn’t! ;)

  11. @ JoLynn Braley,

    Thanks for visiting my blog and dropping your comment. I am happy that you found my ideas interesting!

    After all, you never stop testing, or at least you shouldn’t! ;)

    I wholeheartedly agree with your point. But I have started to realize that I should keep testing out of my personal life, of late! However, as I find it difficult to follow "No Testing at Home", I am trying to follow the next best approach, "No Bug-Reporting at Home" instead, thanks to Ben Simo's advice! :)


  12. Debasis ur idea is good..but do u mean to say that a tester who miss bugs are bad testers?


  13. @ Rajasri,

    Software testing is much more than just finding bugs. As testers our job is to reveal important mission critical information and bring them to the stakeholder's notice! Although finding bugs is just a subset of a tester's responsibilities, still it is an important role!

    Think of a doctor who is bad at diagnosis of diseases, a pilot who is bad at landing an aeroplane, a teacher who is bad at giving lectures, an actor who is bad at emotional roles, a crickter who is bad at fielding... Will you still say they are "NOT bad"/"good" at their professions? Hope you got my analogy!

    Happy Testing...

  14. Hi Debasis
    i am a huge fan of ur blog, but till now i was a silent spectator.
    i am a tester and working in finance domain.we are building an application which will be used for a customer care service; in which user will give account number and retreive document information.

    now i have filed a bug where account number text box is accepting initial multiple spaces with valid account number.
    it is not a requirement but as per my understanding it should be.

    now i am not getting how should i prove it.can u suggest any solid reason if u think it is a valid bug.
    waiting for ur reply
    please mail me at

  15. Hi Debashis,
    today i got your blog link luckly,
    at once read i became a crazy of your blog.
    eah word looks like a golden word.

    Thanks for your Effort.


  16. The first step you need to take is to develop a test case before you start software testing. A test case will make it sure that you have designed a applicable and beneficial process flow. Any way it is good to see a good information from your side.

  17. It is good to see a quality post from your side. I am not a software testing guy, but the company I am working with has a huge department of software testing in a sister company.


NOTE: Comments posted on Software Testing Tricks are moderated and will be approved only if they are on-topic. Please avoid comments with spammy URLs. Having trouble leaving comments? Contact Me!