4 More Reasons Bugs are Missed

The following is a Guest Blog Post by Cullyn Thomson from Tellurium.  You can follow Cullyn on Twitter at @CullynT and Tellurium at @te52app, and we also suggest you visit the Test Talk blog.
You can also read more about Tellurium – “Plain English” automated testing tool – from their site http://www.te52.com

My last guest  post covered 4 reasons why bugs make it to production. But are those the only reasons we sometimes miss things? No way!

Here are 4 more reasons why a bug may be missed – along with some tips on how to respond:

  1. It was hiding in plain sight.

Some of the most frustrating and annoying bugs are those that we miss even though they’re right in front of our eyes.

Typos, bad time zones, outdated descriptions… whether they’re new bugs or have been around for a long time, they can prompt facepalms and groans of “How did we miss that?!”

We may miss these bugs that are hidden in plain sight because we’re so accustomed to looking at our application.

What you can do about it: The good thing about these types of “D’oh!” bugs is that they remind us of the importance of looking at our application with new eyes. When testing, don’t let yourself glaze over anything out of habit or familiarity. Practice active attention to detail, read text carefully, and try to put yourself in a new user’s shoes.

Island in plain sight

  1. There wasn’t enough time to test, so that area was skipped intentionally.

You’ve probably heard it and said it multiple times yourself: there will never be enough time and resources to test everything. This statement can be true no matter how long or short your release cycle is.

This is why prioritizing your testing is so important. When you can’t cover every possible scenario, something’s gotta give. If you decide to forego testing an area of functionality because it seems low risk, you may miss some bugs existing in that code.

What you can do about it: If skipping that area of the application was a conscious decision based on your risk assessment, there may not be anything you should have done differently. File a bug report when the problem is discovered (just don’t let it get lost in the backlog!) and carry on.

Time image

  1. There wasn’t enough time to test, and that area was skipped accidentally.

Sometimes no matter how organized we are, our estimate of how long it will take to test a given area of the application is off.

When testing a particular feature or set of features ends up being more complicated and time consuming than anticipated, we may get so caught up on that point that others we’d planned to cover fall by the wayside accidentally. All of a sudden, we’re out of time for testing, leaving bugs happily dwelling in the untested code – and if you go ahead with the release, those bugs will reach your users.

What you can do about it: Be transparent about your testing progress, changing priorities, and concerns you have while testing. If you won’t be able to get to something in time, discuss it with your team. They may be able to lend a hand, or the PO may decide to postpone the release.

  1. It was discovered, but it was too costly to fix then and there.

As testers, we’re responsible for providing developers and product managers and owners with feedback about the quality, reliability, and usability of the app at any given time. We’re not (or we shouldn’t be) the final decision makers about whether a release goes out as scheduled or not.

There are all sorts of factors to consider when deciding to go live with a promotion or to hold back – factors that impact the team, the users, and the company’s reputation and bottom line. As such, sometimes it makes sense to push out a release even with a known bug or two.

What you can do about it: Give the best and most useful feedback you can when testing, and share it early and often. Be sure that your testing notes are clear and concise and that your bug reports make it easy for the developer to resolve any remaining issues in follow-up tickets if the ultimate decision is to release with bugs.

What do you think are some of the common reasons bugs make it to production? Share your thoughts in the comments below.

 

  • Pingback: Testing Bits – 8/16/15 – 8/22/15 | Testing Curator Blog()

  • Raptors

    I agree with your last point, we’re responsible for providing developers and product managers and owners with feedback about the quality, reliability, and usability of the app at any given time. We’re not the final decision makers about whether a release goes out as scheduled or not.This is one of the mistake that we make so make your testing notes clear and concise and that your bug reports make it easy for the developer to resolve any remaining issues.

Shares