How to come up from the guilt when someone find bug in UAT/Production?

Question

I am not sure whether it happens only to me but it happens when someone found the bugs in UAT/Production, I feel very guilty about it when we missed a bug, sometimes it deviates my mind from my work & it takes a lot of time to focus on my task again. Please suggest me tips to overcome this situation.

Answer 1

In my experience, no tester likes to miss bugs.

That said, it's impossible to test everything, so some bugs will escape to UAT and/or production. Our goal is to catch as many of the biggest risk bugs as we can.

My suggestion would be to analyze any bug that's found in UAT or production. You're looking for how many customers/users would be impacted by the bug, how much damage the bug causes, whether it's possible to replicate the bug in your testing environment and if so, whether it's worth the time/effort to do it, and so on. Don't forget to include the possibility that the bug has been present for a long time, but user sensitivity to the new release has led to it being noticed.

Once you've done that, you can compare the results against your regression scenarios and decide whether you need to add tests for that problem to them. If you're automating, you have the information you need to decide whether to add tests for the problem to your automation.

Don't forget that you're human. You will miss things, sometimes ridiculously obvious things. I've been testing for over 10 years, and I still forget to check that a change to enable/disable/show/hide a field in certain circumstances (or add a default value to it) doesn't cause form submit to fail. In those circumstances, your best option is to apologize and make a note to yourself not to do that again (it's better not to say anything about the developers not checking either).

Answer 2

Guilt comes easy. The only thing to do is learn from your mistakes. There are a few things to do whenever a bug slips past:

1. Figure out when it was introduced. Some bugs may have been in the system long before they were found.
2. Create a regression test so it doesn't slip by in the future.
3. Figure out how it slipped by. This one can be a bit tricky. Sometimes you simply forgot to check something. Sometimes it's something you didn't think to check. Sometimes a developer makes a last minute change and didn't tell you just before sign off and you didn't re-test some functionality. All of these indicate a process failure. Could you have written down a checklist of things to go through prior to signoff? Could you have had dev review your test plan a little more thoroughly? Should you have code freezes, or double check for questionable commits late in the game? Figure out what part of your testing process needs a tweak so bugs like it are caught in the future.

Overall, there should be no finger pointing or blame. Your guilt is your own. Learning from your mistake doesn't mean beating yourself up, it means finding the hole in your process that let the bug get by and patching it up.

Answer 3

The bug leakage will happen some times. Because of this,you should not deviate from your work and take further proactive actions. From the issue, you can treat as a learning and add the scenario in your existing test cases. When going thro the user scenario (UAT/Production issue), you can create combination of scenarios to prevent this.

With this learning, you should proactively identify end user test scenarios with the project stake holders and give more focus in upcoming releases.

Answer 4

Why do you feel guilt?

If you compare that one defect to the tens or hundreds of defects you did identify, is it really significant in the bigger picture?

This is precisely why SQA is undervalued. You missed one defect, you caught hundreds - yet that one defect is what defines the perceived "value" of doing testing.

Now it's a little different if lots of issues are found in high environments, or if it identified a particular gap in coverage in your testing. Then I can understand feeling less than great. In those scenarios you have to audit your practices and understand how the issue occurred. That is one of the core functions of SQA, root cause analysis. Simply perform one on your practice, and work to prevent the issue from occurring again.

Answer 5

First and foremost, I'd ask what the source of the guilt is? If it's internal only, that's one thing, but if it's coming from an external source (ie, manager, etc) that's another.

After saying that, I'll say that no one likes missing bugs. But software engineering is called software engineering for a reason. Engineering is partly an exercise in balancing risk and reward. And that's why I realized that having delivery dates or outside commitments is a good thing; if they weren't there, we'd never ship a product. So, yes, a bug escaped. And maybe if you had another week, or month, or whatever testing, you could have found it. But that would have been a week, or month, or whatever amount of time that the end-user wouldn't have had access to the new product. So that's the tradeoff that has to be made.

Next, software development is a team sport. You didn't find a bug. But you didn't put the bug there.

Next, think in terms of quality assurance, and a career, and not in terms of bug hunting. You missed a bug. What can you do to make sure that a bug like that won't be in the product in the future? And I don't necessarily mean what can you do to find bugs like that in the future, what can you do to make sure that bugs like that aren't put in the product for you to find?

To give you a personal example: about a decade ago, I was involved in testing a major change to the guts of the OS I work on. And I found a lot of bugs. And then we shipped to the field, and clients found problems in areas I thought I had tested well. So there was a year of nights and weekends, working with development, working with clients, to understand what happened, and why we'd had all the escapes. And I felt bad; clients pay us a lot of money for our hardware and software. But we looked at the issues in the field and realized that we had no way of even detecting the problems, so no testing I could have done would have found it. So we ended up having to build new test tools, new data-gathering tools, and new test methodologies. And we've since shipped a bunch of similar functionality that was much less problematic than that first deliverable was.

Feeling guilty doesn't help. The bug is out there. Feeling guilty doesn't help you, and it doesn't help the end-user. What does help, and will make you feel better, is figuring out what you could have done, and can do in the future, to prevent similar bugs from escaping. Escapes are learning experiences.