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?

  • Welcome to SQA stack exchange. I've edited your question to make it less a request for opinion so it's less likely to be closed.
    – Kate Paulk
    Oct 2, 2017 at 11:43
  • 2
    "What should be a tester's reaction when any person from business team find a bug?" - you should thank them and offer to help them file a bug report. Oct 2, 2017 at 12:23
  • 1
    "Change your mentality to expect bugs". - You are trapped to fit the expectations of people who believe that wishfully and strongly thinking something will help to make it happen. This is common between sales people - it helps them to deal with the amount of rejections they will necessarily face when talking to prospective customers. This cannot end well for you. You, your QA manager or project manager need to inform them about software product life cycle and adjust their expectations. If not, be prepared to get the blame for eventual failure and to find a new job. Oct 2, 2017 at 14:40

7 Answers 7


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.


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.
  • I don't like the 'manipulate the metric' idea: you should focus on doing the best you can. Not only looking the part. Discuss the metrics being used if they are useless. And many are!
    – Ray Oei
    Oct 4, 2017 at 16:07
  • @RayOei sure you must do your best. However often the metrics are not the subject for discussion. I do not see criminal in metric manipulation (implying your're doing your job well). It's like the tax optimization. If a person acts rationally they always search for the balance between own interests (gain money,build reputation) and the counterparty interest (get the quality product for their money, get relevant reports on the progress and state). After all it is the responsibility of a management to introduce the system that would allow to gather the reliable metrics of team performance.
    – Alexey R.
    Oct 4, 2017 at 16:16

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".


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 

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

  1. 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


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.


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.


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.


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.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.