Bug finding heuristics

I come, I see and I report bugs.

Testing has become so natural to me that I have been reporting bugs on the road, finding issues in any website, even I have 100% success rate in finding an issue in any restaurant’s menu that I visit. How do testers like me do that?


(Photo by me 🙂 )

All testers who are good at finding big bugs use heuristics, whether or not they know it. Here is a list of the heuristics that I mostly use:

You must click what you see

This story goes back to mid-1990s when I was first learning how to operate computers. I’d ask so many questions to my mentor (who happened to be my elder brother too) where as he wanted me to explore stuff at my own. He suggested me “to click what you see and then see what happens”. 18 years or so have past since I received this advice and this is the biggest trick that works in finding bugs.


The belief has two parts. One, I have a firm belief in the human race that they err a lot. Secondly, I have belief in me as a tester that I can catch it. That is where if with this belief you test a website, you’ll find a bug in 5 minutes.

The road less traveled

This heuristic is usually applied in exploring new markets or new arenas but is equally applicable in bug hunting. The feature that has been least tested or the pages that have a likelihood of least visit will yield you the bugs faster than well tested areas.

No User would do that

This is usually an excuse of ‘not a bug’ by the fellow programmers or project managers but it works really well as a heuristic. All penetration testing is based on this and Dan Ashby has a great post where he analyzes putting a shoe on the keyboard.

Software bugs are like real bugs

This is a very interesting analogy and I wrote about it in details earlier. Though it is usually mentioned only in the Pesticide paradox, but if you consider software bugs to live in colonies, you can find more bugs. As soon as you spot a bug in an area, dig around and all the brothers and sisters and fathers and mothers and cousins and extended family members of the bug will be living nearby.

Do you use any of these? Or what heuristics you use to find bugs?


Tags: ,

10 responses to “Bug finding heuristics”

  1. H Hamid says :

    Great post. Thank you for sharing the secret recipie of successful bug finding.


  2. SamreenM says :

    and i guess one more thing.. Getting over the ‘what if its not a bug’ syndrome. So what if its not a bug, it will be closed later. but if it happens to be a bug, it is a good catch 🙂


  3. Sohail says :

    Nice Caption, “I come, I see and I report bugs”.. 🙂
    Undoubtedly, Testing instincts are very important..
    Every feature should be checked following the metaphor of “Guilty unless proved innocent”… with a apex of “suspicions” like real “Detector”..:)


  4. Heena says :

    Interesting article..The best one I came across is “no user would do that” stuff.. What if 1 out of 20 users do that?? Quite difficult to convince project manager and developers on this stand.


    • majd says :

      Thanks Heena for your comment. You are right that ‘No User would do it’ is normally used as an excuse to not fix issues. In today’s world of heterogeneous devices and people connecting to the systems, there is always a possibility that some user would do that.


  5. Henke Hagman (@HenkeHagman) says :

    I hate the “no user would do that”-answer. I just did it, OK? So yes, the user’s WILL do it. /rant off/


    • majd says :

      Thanks Henke for your comment. ‘No User would do that’ is actually a very good tool/heuristic for the tester rather than an excuse to not fix an issue.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.