5 simple reasons why you missed bugs and how to prevent it

Missing bugs sucks.

To some extent, it’s one of the worst nightmares of testers.

Why so? If you are in software testing, you may know that there has been a testing misconception that testers are in charge of catching all bugs in the system. Testers are considered as gatekeepers or goalkeepers. When there’s any bug leaked to customers and causing loss such as sales, company reputation, potential customers, etc. testers are often the final source where fingers are often pointed to (with a high consensus). Things get worse if missing bugs is part of a “blame game”.

Missing bugs is not fun at all…but there are reasons behind that.

In this post today, I would like to point out 5 reasons why you often miss bug and what you can do to prevent it from happening again.

#1: You missed bug because you didn’t test it

This is obvious.

If you didn’t test a feature, a component or test cases, there would be a high chance that bugs would be slipped through your hands to customer’s hand.

Of course, there are several reasons why you didn’t test a feature, well you might forget to test a feature or your test design is not good, but more often, here are common reasons:

• You may not be aware of “secret” changes made by developers. Developers may intentionally hide that from you or they simply think those changes are minor, so no testing or update needed.
• You may not be aware of feature changed that management failed to communicate to testers

What can you do to prevent that?

• Keep eyes on any changes may have in the system in each build release especially changes on critical components or last minute changes. If you are in double, just ask up about such changes and if possible, bring up the risks if testing is skipped on such changes.
• Ask management for a transparent communication. Speak up and be bold to ask for such information in the future. The key message to convey here is not about you tester but it’s more about the risk, the quality of the system.

#2: You didn’t cover all corner cases.

Bugs are shy. They are often hiding from testers, so it’s not easy to catch them. It requires a little more efforts to discover them.

In many cases, you need to follow set of complicated steps or various combinations to trigger the bug. Technically, software is getting more and more complicated to serve and meet business needs these days. As a Blackbox tester, you may not be aware of how complicated the system is or how its components work together. As a result, you didn’t cover enough test coverage or corner cases where bugs often hide.

These kinds of bugs sometimes make people wonder “who the hell on earth would do that”. Well, “whatever can go wrong, will go wrong“.

What can you do to prevent that?

• As a tester, you need to put you in user’s shoes to understand how they often use the products. Sometimes, their behavior is weird, but you know what, that’s just how they use the software. Don’t underestimate how “creative” end user is.
• Learn to know how system works technically. In many cases, you don’t have to know about how components talk to each other or understand every line of code. However, understanding the system from a technical point of view can help you detect good bugs.
• If you have a lot of time, spending more time to design and cover as many combinations as possible. Of course, doing this will cost your time and effort, but if it’s worth your effort, just do it.

#3: You missed bug because you overlooked obvious bugs

Strangely enough, missed bugs are often also the obvious bugs. By “obvious bugs“, I mean the bugs are right in front of testers, but testers didn’t recognize them.

It’s painful. I know, but that happens all the time. Why so?

There are some reasons why you didn’t see such obvious bugs:

• You may be too focused on testing a specific area of the system that you didn’t even care to look for problems in other areas.
• You may be too focused on another task that your mind is not put in “bug detection mode”. For example, when you worked on designing test cases, you may be interacting with the system but your mind is not in bug-detection mode so you could miss obvious bugs.
• You took the same routes to test a feature again and again.

“Insanity is doing the same thing over and over again and expecting different results” – Albert Einstein.

A tester’s version:

“Insanity is testing the same way over and over again and expecting bugs found”

What can you do to prevent that?

• To be honest, I’m not sure how to resolve this especially if you are not the type of “multi-tasking” tester. What I can suggest is to always keep you in “bug detection” mode so that you can point out obvious problem.
• You can also try to approach the system from a different perspective, apply different techniques to test the system.

#4: You were put under time pressure

“Ship it or RIP it”.

It’s getting common these days that we need to get the software out of doors as soon as possible…and it’s fine. There’s a valid reason behind the “ship it” idea. However, the flip side is that testing team is often put under pressure to finish up the testing (either by working overtime or skipping some tests).

Naturally, when you are in hurry, you overlook things and when you overlook things, you miss bugs.

What can you do to prevent that?

“Don’t ship it”.

I’m kidding 😀

Actually, the solution is not to find ways to not miss bug when testing under pressure. The solution is to find ways so that you are NOT put under pressure when testing.

Here’s my suggestion: If time is fixed, let’s communicate to cut down the tests and perform the risk analysis. The idea is to tell management what you can test, what you won’t test and the risks entailed if you won’t test a feature/component.

#5: You saw the problem but you didn’t report it.

Wise man said: “Whenever you see the problem, report it immediately”. That’s considered as rule of thumb, a mantra when it comes to testing. However, sometimes testers didn’t follow that.

How many times when you found a bug, you promised yourself to report it later. But then you switched to another task, another task, and then “later” became “never”. You entirely forgot to report the bug and sadly that bug would go back and bite you. 🙁

In other cases, you were not confident enough to report it ( E.g: I don’t want to bother developers) or you underestimated the importance of the bug (E.g.: this bug is low severity, nobody cares, so just skip it). As a result, you decided not to report it. It turned out that that unimportant bug (to you) turned out to be a critical bug (to someone).

Still remember this? “A bug is something that bug someone that matters” (Yes, from James Bach)

A bug doesn’t matter to you, it doesn’t necessarily mean that it does not matter to someone else.

What can you do to prevent that?

If you think it’s a bug, just report it (of course, always support your bug report with your reasoning why you think it’s a bug). Please note that doing this is not just a CYA activity (Read: Cover Your Ass). It’s a good practice that testers should practice more often.

Final thoughts

As testers, our job is to test the product and provide valuable information to management about the product. In some cases, we play the role as the final gate to assess the product before it goes to customer’s hand. It means that pressure is on us when we miss a bug. However, we testers are just human and like people say “we are not perfect”. We will make mistakes at one time or another. Some may make more mistakes than the others… and it’s okay.

Here’s the important point to note:

Missing bugs is bad and it gets worse when people take that opportunity to start the blame game or pass the ball around.

Don’t do that.

As testers, let’s take this situation as an opportunity to review the testing process and see where the weak link is and prevent it from happening again. As a team, we are all in charge of quality, not just testers.

That’s it! No more missed bugs, no more nightmare, sleep tight testers!