How should a Software Tester deal with missed Defects/bugs in Production?

Question

I work as a QA/test engineer in a small software company. I was assigned on Multiple(7 different) projects by my superiors in which i do testing, requirement gathering, client updates, resolving developers/clients queries & etc.I mostly do functional/black-box testing. Before the production release or showing it to client, I tested many good scenarios and found lots of defects in the code. Most of them got fixed. I did my analysis and sent it to client for his approval. I had a good test strategy. Now, this module went live in production servers and client have encountered few bugs which appears on specific conditions which he reported to me.Then i checked them & sent to Developer so that they can fix it but in response i got a mail from senior saying that "how did you missed this bugs you are not taking your job seriously this should not happen once you release it to client it has to be 100% bug free client should never encounter any bug, developer is not responsible for it only you is responsible for Quality & this mistake should never happen again".

I'm a junior tester here,My seniors and the stakeholders don't trust my work as a tester, as how dare I say that it PASS the QA. They think that I'm careless, not worthy of working, and risky.

Is it really possible to make any software bug free?

QA is the only person responsible for Bugs? even if he is testing several different projects at the same time & updating multiple clients & trying to complete the projects in deadline(Where time for testing & resolving bugs is not mentioned in the project scope & not even charging the client for same)?

I just want to know how to deal with this situation. can anyone suggest me what to do?

Answer 1

You're describing an immature organization, seemingly political, low performing team, hostile work culture.

There is no such thing as a 100% defect free product or service of any type. And a mature organization with high performing processes and capabilities know this and have a process of continual improvement while they also have contingencies to deal with post production care to deal with both known and unknown defects found by end users.

In a QA role, your mission would be to have a constantly improving QA testing procedures, including scripts in your case, that would allow improved defect identification but your goal should never be 100% defect free. Your post production goals should have some numbers against high to low severity defect finds that ought to be normally distributed or skews to the low side. And as long as defects found post production are within that distribution, your testing is working as designed.

What to do? It is clear your organization thrives on finding scapegoats in its human talent versus a focus on improving processes and capabilities and having realistic goals. The likelihood of you changing this is near zero, and by that I mean zero.

So you have the option of just shrugging it off and keep working and do the best you can or go look for a better job and organization. This is not to say that you did stellar work. I have no idea if you did or not but do know they all of our work can be improved every day. Do take a look at your processes and see if there was something you could have done better but do not take all the ownership here.

Answer 2

As with all management difficulties the real problem is communication not your skill level!

If your seniors make you feel uncomfortable, misjudge your role or undervalue your skill level you should talk to them.As a product manager,I put a lot of value into communication.

However by discovering defects early in the development cycle, QA testing will save time, money and frustration. The longer a bug goes undetected, the more costly it is to fix.

You need to do what you can to make yourself useful, as quickly as possible while causing as little overhead as possible.

I believe that your current job needs to be not only beneficial for the company, but to be beneficial to you, too. If you don't feel happy anymore about who you are becoming or the work that you are producing, you are not benefitting your job nor yourself to stay.

Answer 3

Yes it is possible to be 100% defect free and Yes it is QA's responsibility not to say its 100% defect free when it isn't.

The key to this of course is in the definition of 'defect'

A defect must be defined as functionality which doesn't match the specifications.

Each specification must have an agreed test, which if passed defines the specification as met.

QA must run all the tests and record the passes and fails.

The only way QA can do their job badly is by skipping tests by testing the wrong version or something or lying about the results. Everything else, defining the spec and the tests etc is shared responsibility.

If the tests all pass then any problems the customer finds are either because the test wasn't good enough (get sign off and agreement that the test design matches the spec) or the spec was wrong (customer should sign off on the spec)

Obviously in the real world the spec is rarely detailed enough that the tests are obvious or even possible. So getting sign off on the test design is THE most important step.

Always bring a few edge case questions to raise after agreement, (really just prior to) so that your boss realises its harder than it seems and accepts that even they can make mistakes.

If it looks like they are putting the whole responsibility on you, then you know there are going to be problems in the future.

If they are the ones suggesting extra tests then you know you should have put more work in and so do they! But at least its early enough in the process not to cause disaster