8

How do you mentally deal with this? For example im testing on a "Virtual" Environment of the customers set up....but a lot of things are simulated either due to not having the equipment etc...

When small issues come back I beat myself up over it.

How do I get past the fact that im never going to be able to find everything?

4 Answers4

16

There are a few things I try to remember about finding bugs in production:

  • Quality isn't binary. If you measure your performance by whether there are bugs, you will always fail. Instead, I consider whether the quality is improving.

  • Failure is a learning opportunity. When a bug makes it into production, I ask myself what I could have done differently. Sometimes the answer is a new test case, or a different way to test. Sometimes I might even conclude it would not have been worth the effort for me to find the bug.

  • Quality is a shared responsibility. You did not say whether you are a one man shop, but if you are not, other members of your team are responsible for quality too. Sometimes the right way to deal with certain kinds of bugs is for the developer to spend more time testing.

  • Beating yourself up does not improve quality. This is hard to remember, but punishing yourself does not help you find bugs.

  • It's just software. We all want to do a good job. At the same time, there is more to life than the contents of the bug queue. The other parts of your life are important too.

  • An old boss who said that most things could / should be "growth opportunities" so you never have to worry about good or bad so long as you learn. – MichaelF Aug 20 '13 at 10:18
  • 1
    As my manager recently told me, "No bug was ever created by QA or a tester". If there are areas that aren't being tested, perhaps you could expand into them. But I completely agree with user246's first point. – John Oglesby Aug 20 '13 at 23:41
8

How do I get past the fact that im never going to be able to find everything?

There's nothing to get past here. You need to convince yourself that "finding everything" isn't actually your role. Your goal is to help your company get to "good enough". And understanding what is "good enough" in the context of your company and your customers is the key.

I strongly recommend that you grab a copy of "Perfect Software and other illusions about testing" by Gerald Weinberg. This book is a high-level look at some of the "big picture questions" about testing, such as: Why do we have to bother testing? Do we have to test everything? What makes testing so hard? Is perfect software possible? Why can't we just accept a few bugs?

http://www.allthingsquality.com/2010/04/another-addition-to-my-qa-bookshelf.html

Reading this can help you understand that perfection cannot be a realistic goal.

Joe Strazzere
  • 14,118
  • 1
  • 27
  • 61
6

Mercfh, I know you've accepted user246's excellent answer, but here are a few more things for you to consider:

  • It's impossible to fully test anything non-trivial. It's often impossible to test every path through a system.
  • Many bugs are in the eye of the beholder. What I mean by this is that something which bothers a customer enough to report a bug is often not something a tester or programmer would have thought was a bug.
  • No tester can ever reproduce a customer's environment. Even if you have the equipment and the configuration and an exact hardware match, you don't - and can't - have the volume of use the customer experiences, nor do you know exactly how the customer navigates through your system. Where I work, we're supporting an elderly web application that is IE only (yes, there is work in progress to support non-IE browsers). Despite customers being told this repeatedly, we still get error reports from customers using other browsers.
  • As Phil says, every bug you do find and get fixed is one your customers don't find. And every bug that does escape is one that you put on the list to check for next release (This is often how regression test suites get built).
  • Even if everything you and the rest of your team does is perfect, there's still the interactions with other systems to consider. Customers can and do report bugs to you that are actually problems with third party items - but you still end up being the ones who work around them to make your customers happy.

Just a few thoughts to help you keep perspective. You and the rest of your team are human: things will slip through. As long as you're learning and improving, you're making progress.

Kate Paulk
  • 31,513
  • 8
  • 54
  • 108
3

User246 has a great answer, to add to it you could list the things you did find before the customers did

Phil Kirkham
  • 3,577
  • 1
  • 17
  • 15
  • Adding to all the points listed in the answers, one point I motivate myself with is this. I'm really get motivated when I change an issue to "passed" when I'm convinced I have propably tested it. And one by one all issues (of a certain version) are ok. When we used the bugtracker mantis some years ago, which colors the issue lines regarding to their states I liked to see turning all issues from red to green one by one. – bish Jan 11 '15 at 08:10