17

In my previous project, I was working as a black-box/manual tester. My major responsibilities were performing function testing, executing regression suites, running smoke tests etc. I was testing a core banking application. There were other automation guys on the team, but I was the only manual QA.

A new payment feature was introduced and I tested a lot of complex scenarios and found quite a few critical bugs that were eventually fixed. The build was released on the production server and there was a crash in a module that I tested. I missed the bug! I was asked to explain and justify everything and was rebuked by my manager and the incident was escalated to higher management as the bug caused a lot of problems to the end users. Luckily my job was still there.

How should a tester deal these kind of situations?

6 Answers 6

18

There will always be bugs that get past a tester and land in production. I have even had bugs that where in my face, we researched it, thought it was a fluke, because we couldn't reproduce it and then released the issue into production.

The best thing you can do is learn from it and prevent the same in the future. I write an automated test-case for each defect found in production, since these are the brittle parts of the application.

Second I would plan a root cause analyses session and use the 5 whys technique to find the cause. Now find a solution to improve here and make it future proof.

found quite a few critical bugs

If you are testing a part of an application or new functionality and you find quite a few critical defects, then maybe wonder if you need help in testing this mess. Finding more than a few simple issues means in my book that the code is spaghetti or the developers might be sloppy. You need to signal it and take action.

1
  • That last paragraph is perfect and will help keep you employed.
    – Paul Muir
    Commented Mar 15, 2016 at 13:00
4

first of all, the tester needs to check whether it was within our testing scope or not. If Yes then we have to do root cause analysis. Once you are known to the exact issue then you need to inform your project manager or QA manager.

The report part should include the exact impact of the bug found, also you should be ready with the proper explanation for the same.

3

First and foremost, analyse how the bug got past you. Find a way of preventing this, and things like it from happening ever again.

Second and maybe even more important, talk. Talk with everyone involved with getting new functionality out. As soon as requirements materialize, get your test approach on paper and scrutinize it AS A TEAM.
That a harmful bug got past you is bad. But you did not put it there. Getting good stuff out to the customer is the job of all of the team.

Finally.
So ask yourself, was it, in the end, justified that you got singled out to take the blame? Did you make a mistake? Or are you in a situation where it is just a bunch of people doing things? If so, maybe better to switch companies.

Hope this helps, and better luck next time.

3

If you was under the threat to lose your job as a result of letting a single bug to slip to PROD, you should consider looking for a job in saner company. It is just a matter of time when another bug will slip to PROD.

Quality is a team sport. Bugs will always slip, and pointing fingers and assigning blame does NOT improve quality. Firing you for a bug is NOT reasonable. It could be reasonable if you repeatedly let slip similar bugs. For few bugs, no pay increase is reasonable.

Dealing with a bug which slipped to PROD is not only responsibility of the tester who tested the module. Even more responsible is the developer who wrote the code. Both Dev and QA teams should analyze it, find a way to prevent it. Automated smoke tests? Developers suggesting which modules should be retested after changes? Etc.

You cannot test-out quality. Quality has to be designed and developed in. Testing can only show presence of the bugs, not it absence.

2

Make a habit of going through a test case ( if not at least high level test plan ) review with the whole team, its not unusual to miss a bug which can land in production

After review you can always say it was not part of plan so everyone is responsible not only you, may be no one ll point fingers in first place

If your manager does not understand this and joins others in pointing finger at you, start searching for a job in normal companies, these things can damage your confidence and you learn to just do things to cover your base which takes juice out of testers profession

-1

To Prevent Bugs in production you should test from a stakeholder view, A good knowledge in product and domain always help you to get the best test cases and apart from positive test cases always try for test cases which will break the code as even dev does the positive testing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.