What should be a tester's reaction when any person from business team find a bug?

Question

I work with a business team where no one has been a developer or has studied software engineering. I have been working on their Android App as a QA for the past few months, and I have realized that they have been focusing and judging my performance not on the basis of how much I work and find bugs, but suddenly I am questioned when there is an issue detected by anyone from the business team.

I have been telling them that 100% tested and bug free product is a myth. But their answer to this fact is "Change your mentality to expect bugs". Of course this is not in a tester mind while testing a product, but this is fact.

Now I feel that they have made up their mind that my mentality is not correct.

How can I work with this group without being judged on an impossible standard?

Answer 1

I have been telling them that 100% tested and bug free product is a myth.

It might be the way you are telling it. Probably it is true, but having an attitude "it is not my problem" is not the right one. As a business I would like to see someone who cares.

Your reaction should be something like: "Damn! Let me figure out how we can prevent this the next time."

I will:

• Execute a Root-Cause Analysis
• Analyze development process for quality
• Increase test-coverage (manual or automated)

Change your mentality to expect bugs

I understand their thinking. I always tell our developers to think positive, because finding bugs is good.

Start testing the application by intent of finding defects/errors. Don't think beforehand that there will not be any bugs in the application. If you test the application by intention of finding defects you will definitely succeed to find those subtle defects also.

Answer 2

Production defects are always the metric of a tester's performance (or some other variations like ratio of prod issues to the ones detected on testing phase weighted by their severity for example). So what you can do is being aware of how the metric is defined try to manipulate that metric using the factors you have the impact to. Here are the couple of thoughts:

1. Depending on the definition of the defect term in your team you can advocate the issue to be treated as not a defect but rather a feature request (this might be possible because often the customer did not request some functionality and thinks this is a defect)
2. Advocate the severities you assign to the defects when create ones.
3. Force the devs to provide you as precise requirements and specifications on the features as possible
4. Treat production defects in a positive way. Learn what is the most important for your business so that you will study how to look at your app in more business oriented manner.
5. Agree on the definition of a defect after all, because the definition is quite important.

Answer 3

First reaction should be, buy some time to investigate the issue and co-ordinate to fix the issue. Then let them know "we would investigate why the issue has been leaked from our testing".

then,

1.Analyse why the bug has been missed, could be variety of reasons

    * Business use case wouldn't have been properly defined or not captured 
 properly

2. Bug would be replicated by only one specific set of data

3. Could be reproducible by only one specific flow.

Ways to mitigate:

1. map your tests with requirements and figure out whether there is enough tests in the area where business found out the bug, and add further regression tests where possible, by this way you can increase coverage.
2. Liaise with developers and ask what are the areas his/her code change would influence/affect, accordingly concentrate your tests
3. Involve business in your testing phase like witness testing, or making them to review your tests
4. Where possible add automation tests

by this way you could positively influence your testing and involve business in the QA process as well

Answer 4

I think that your reaction should, in part, depend on the quantity and severity of defects being found in production.

If they are finding minor issues, like misspelling a link name or similar, then I would acknowledge it, get it fixed and let them know how I will change the process to reduce the likelihood of it occurring again. If they are finding many of these, I would take a hard look at both my process and the dev process.

If they are finding serious issues or show stoppers, then I would acknowledge the issue, get it fixed asap and then perform a full root cause analysis to determine where the testing/dev process is failing. It is always possible that the failure is on the business side, in that they did not provide accurate or complete business cases and expected development to compensate for their vagueness.

Either way, I would strongly suggest integrating business users into a user acceptance testing phase. Get them involved and invested in the process, not just the results. This will help you build an atmosphere that is much more conducive to long term success.

Answer 5

Some reflections here.

Firstly, this sounds mostly like a cooperation and communications problem. In a situation like this I would sit down with the business team and carefully listen to how they perceive the situation you are in. What are their expectations and how can you as a QA and tester help in fulfilling them. Maybe they are willing to wait longer or pay more for correct software instead of earlier and less expensive but buggy?

Secondly, it is not you that is creating the software. I would sit down with the developers and delimit the responsibilities. It is the developers that is writing the code and it is their responsibility to write good code. What you can do QA is to make them aware of this fact. The acceptance test phase is not there to find bugs, it is there to stop a product if earlier parts of the process has failed and allowed bugs to be created. There really should be no bugs to find (or you should at least say so ) .

You can help the developers in fulfilling their responsibilities by doing automated test, regression testing and so on. You can teach them various techniques and tools to help in getting quality built in from the start. But it is still their responsibility to find and correct the bugs.

Answer 6

Ask them if they support preventing bugs like happening in the first place.

If they do, say that you would like to do this - prevent bugs, increase quality and have less issues encountered by users - by doing smarter testing earlier and more often.

Provide them with examples of unit, functional, integrated and exploratory testing and talk about how each area can help prevent bugs from happening by catching them during the full development process.

Answer 7

This sounds like there is a need to change perceptions here.

The initial reaction of the tester should be to thank them for finding the fault, after all its in everyone's interest to ensure the best quality produce reaches the customers/users. And this can help to instil the idea that regardless of your job title, everyone is responsible for quality.

Then you need to ensure both that a) the fault is suitably logged for resolution and b) that a root cause analysis is carried out to find out how the fault reached their level. And be open about showing the results of those analyses and if there's a need to improve your processes ensure you both admit this and fix it.

At the same time, you need to ask for their support in ensuring any root causes that are not part of your processes are picked up and resolved - is it developer processes (lack of unit tests/integration tests), is it in the requirements definitions and documentation, is it that business requirements have changed since they were documented and this hasn't been included in those documents?

Whatever it is, you need to be positive about any fault being an opportunity to improve things so that the faults /everyone/ miss and reach the customer (because they will be there) are as inconsequential as possible.