Should a tester feel bad about finding too many defects/bugs in the product?

Question

I work as a junior black box tester in a small software house. I work in a medical industry web application. I was assigned a module to test. I did a lot of research and risk analysis and logged at least 25 bugs/problems. Now I think that the developers are mad at me, as it indicates that their coding is not good enough and is a direct attack on their work efficiency, quality, and productivity. I see that they don't talk to me and are ignoring me. I have increased their work. They have fixed a few bugs but want to reject others. I have filed GUI defects, business process flow issues, etc.

Should I stop filing too many bugs in the future, as it will show that I just file them without researching, just to get noticed? It seems like I want to increase the bug count.

Answer 1

There is only one situation where a tester should feel guilty about finding too many bugs in a product, and that's if all the bugs that are found are symptoms of the same bug.

I was working on a game that had integrated help with hyperlinks inside, and there was a bug where if you clicked on a hyperlink, it went to the home page rather than the correct page. We had one tester that decided to file a bug against each hyperlink rather than the root bug.

As QA, our responsibility is to find and report issues in such a way that it can help a developer fix the issues we find. Part of that involves ensuring that our signal-to-noise ratio is as good as we can make it.

Answer 2

Your job is to find bugs that could negatively impact those using the program, and in the health arena, these bugs could also potentially impact patients as well.

If you find flaws and true bugs that need to be addressed, you should flag them, end of the story.

My experience with testing comes from beta testing games, which I know is a less vital task, but the end result is the same. The more things that are corrected before the launch of the product, the better the initial sales will be and the better the reception of the product will be.

I wouldn't worry too much about how the coders respond to you. They do work hard at what they do, and it is a blow to the ego/pride to have someone find flaws in your work (again, personal experience). But as long as you are not rubbing these flaws in their faces, or acting high and mighty about things, any friction should pass.

In the end, everyone just needs to work at their given functions as best as they can to ensure that the product released is in the best possible state.

And don't worry, the general public will find bugs that even you missed. (personal experience again, lol)

Answer 3

I'm going to address what I feel is the elephant in the room here because none of the other answers has really mentioned it yet. Note that this answer is based on the wording of the question. I may be misinterpreting this wording, this is my conclusion based on word choice and sentence structure.

Finding bugs is fine because that's what you're paid for.

However, I think the real problem here is not that you find so many bugs, but that finding those bugs has given you a certain boost to your ego. From reading your word choices ("excellent work", "threat to other's job security", "I'm revealing their mistakes",...), I get a certain impression of you. I get the impression that you think you are much better than your coworkers, both in the testing department and in the development department. And because you think you are better, you act like you are better, both towards us and your coworkers.

Whether or not you actually ARE better is beside the point. The point is that your coworkers dislike you because you appear to be flaunting your findings in their faces and not showing a measure of humility. This is not an "I am too good at my job" problem, this is an "I'm too big for my boots" problem. As long as you are acting like you are the only competent person at your job, your coworkers will not like you. People who act like that are often one of the first to be targeted during reorganisations because they have a big impact on coworker morale and productivity.

Again, finding a lot of bugs is fine and should be encouraged. Acting like you're amazing because you find so many bugs and rubbing it in the faces of your coworkers is NOT fine and should not happen.

Answer 4

Is there someone responsible for deciding what bugs should be fixed? If so, how do they feel about it?

Is there a specification that the software is not meeting?

You need to log everything that is actually a bug. You should log things that an end user would think is a bug even if it meets the spec. Whether they should be fixed is a discussion and you have to pick your battles.

You may need to adjust your approach. I find the leading question to be pretty effective: Hey I noticed this thing that I found confusing, is this what was intended?

You need to let the developers know that you are on their side and that it is a collaborative effort.

So the short version is, file everything and don't intentionally be a jerk.

Answer 5

Obviously you shouldn't feel bad for doing your job.

As for feeling good and being sure you really are doing your job well however there are a number of other things you can consider. Your feelings of inadequacy and being disliked will be greatly helped by focusing on some of the following:

• Know what the business metrics for quality are.
  Make sure bugs respect the business priority. Bugs that affect new signups are more important to some businesses than bugs that affect new orders and vice-versa. They also can have different priorities at different stages of a companies life-cycle. What is considered a bug worth fixing will often be different for a startup compared to a large corporation because of the resources that can be applied and because of the need.

• File the type of bugs that get fixed.
  Over time you will start getting a good sense of what the company values fixing. Focus on those sort of bug reports over the sort of ones that never get fixed despite your best presentation and explanation.

• File good bug reports.
  Make sure your steps to reproduce, screenshots, initial variables, browser used, etc. are all well documented. Make sure that the steps to reproduce are clear and easy to follow. Make it easy for a junior developer to follow.

• Don't expect developers to be excited about bugs the way Quality Engineers are. QE folks can punch the sky when they find a really odd or obscure or hard-to-reproduce bug. Developers are more likely to punch them. haha

• Get good feedback.
  Meet weekly with management and make sure are doing what they want. Then worry less about those developers.

• Be a quality advocate.
  Push for more QE involvement, push for good standards and good ideas, show that you care about your craft.

• Be a customer advocate.
  Speak for their point of view - It's not that you find the dropdown hard to use, it's that the business has a wide diversity of users including older users with browsers magnified and the dropdown doesn't fit in the designed layout box for them, leading to word wrap, blah, blah".

• Aim for respect, not friends.
  Some developers may resent you a little, but over time you may be surprised to find how much they value you. If you stay true to your beliefs, over time you will be trusted and relied on to perform your role.

• Learn the back end.
  As best you can try and learn what you can of the back end. The ability to peruse logs examine databases, view browsers network requests can be hugely useful for developers looking at your bugs

• Learn and apply automation.
  It will leverage and supplement your QE manual testing knowledge. Doubling your income is also common - just in case that interests you.

• Be prepared for much patience.
  I recently worked in a situation where 80% of UI bugs went in the backlog for 6 months. Then hires were made and catch up was done. Much patience was required. Think of such a backlog as the justification for more dev and qe hires and for more emphasis on quality upfront.

• Pay attention to tone when talking about bugs.
  Make sure you criticize the functionality and say why not the person or any motivations you might perceive (correctly or not) them as having.

• Ignore the paranoid thoughts
  Talk to your boss and make sure you are doing the job they want.

• Become an expert in the business domain
  Learn the details of the industry, the business and the customers so that when you file bugs and when you have discussions you can bring this additional knowledge to the conversation, the knowledge that developers may not have.

• Look to be physically embedded with the development team rather than sitting in another area.

• Constantly innovate with new ways to test, new devices to test, new approaches to use

• Learn, teach and connect with other Quality Engineer professionals.

Remember to think Add Value.
In any particular testing or bug reporting activity, think about whether you are adding value to the business as the business measures it.
For example my business measures revenue from web usage. I pushed for better webform error reporting (better usability and accessibility). My company measured the increased revenue of $1m a year. I am helping them to meet their primary quality goal.

Answer 6

Simple answer 'NO!'

Complex answer 'No, provided you are doing the following...:'

1. You are reporting relevant bugs (i.e. deviation from requirements) or things which can be shown to impact functional or non-functional aspects of the system, not merely things you think should be better
2. You aren't duplicating bugs
3. You are reporting the bugs in such as way as to make the bug easily recreatable for the developer so they can easily find the root cause
4. You are reporting problems with the application, not problems with the developer. Blame is a bad thing.

Answer 7

You should not stop finding bugs.

You may want to adjust how you report them. As RomSteady pointed out, creating a ticket for each failed link when all have the same root cause is not efficient, and it can look like a tester attempting to inflate the number of bugs reported. A better way would be to report a single bug and list all the known links (or whatever common element your situation includes) in that single bug report.

Are you on an agile team with grooming sessions? If so, do you offer your opinion on acceptance criteria and how you will test features? If so, you will give developers a better idea of what tests their code needs to pass in order to pass QA. They should know already, but sometimes they are focused on the happy-path and not on all the tests that QA will apply.

You mentioned GUI, business logic, and "some good genuine bugs too". All of those are genuine bugs, but if your team is focused on getting the logic correct and GUI will be covered in a future effort, you might want to focus less on the GUI testing. A discussion with your QA manager or with the product owner should clear up what is expected in each phase (assuming that you have different phases).

The alternative to you finding bugs is for your customer to find them. No one wants that.

Answer 8

If this is a medical application you are talking about it is serious stuff. What if the bugs affected real users? Developers would be much less happy if they put in life threat someone or if management has to retire a product or make public excuses. Nowadays it is pretty standard for software having minor bugs, but a medical application should be as much as bug-free as possible.

A good developer should not be angry about bugs, but rather be happy, and a good manager already know how software development work so should not put under too much pressure its team unless really necessary:

• It has been caught before product release
• It is pretty standard for a programmer fixing bugs daily
• If you have to focus on programming it is hard also to focus on testing
• A tester Always reports bugs
• A regular user usually not (unless particularly angry or determined)
• If the user is your client, he will report bugs and he will not be happy if the project already cost him much money or required a good amount of time.

Literally a project for which bugs are not reported at least on a weekly basis:

• Too simple project: no value every other company could easily create a better clone
• Not much-used project: maybe there are bugs but no one incurred in them
• Bad management: if there are no bugs it's time to move on further work (extra features or different projects).
• Bug fixes should drive development, they give a correct idea of what should work and is not working, this allows to manage priorities between fixes and features
• In important projects it makes sense adding automated testing so that every fix and feature comes with new tests that avoid breaking pre-existing functionality

Answer 9

No, of-course not, not even when you find defects in an application that you already tested and did not change. Think about it this way, you keep growing and learning. So you will find better ways to find defects. Unless you slacked and took shortcuts on purpose, maybe then you should be feeling bad.

Do talk with the developers why they are ignoring you. Ask them how you can better help them. Learn what would best improve your process to prevent defects, instead of finding them after coding try to prevent them during or before coding.

As a tester, you have a signaling function. Ever defect you find is a signal something got through the quality-process. Just be sure you do not doubt yourself. If you think it is a defect report it!

Some signals:

• Usability / UX defects, maybe you need a better designer
• Functional defects, maybe the developers need to test their work better
• Requirement defects, maybe the business needs more communication with developers
• Business logic defects, maybe the developers need to write more unit-tests
• Trivial defects, maybe you need a triage to categorize defects before developers get them
• Recurring defects, maybe you need automated (end-2-end) tests
• Security defects, maybe you need to do external security audits
• Unreproducable defect, maybe you need to write better reproduction steps, prevent ping-pong with developers

Just a quick list of possible issues and possible actions. I would advise to do a root-cause analyses for your defects and try to catch the real root causes instead of solving symptoms.

Define a quality standard with the whole development team. That includes developers, testers, but also business people, sponsors, and managers. Write down the expectation and keep in improving your quality-process after each defect coming through the process. Just make sure everyone has the same goal in order to prevent the things you describe. Naturally, I think everyone wants to deliver high quality.

Answer 10

I suggest you to reconsider what is a bug and what is not a bug.

Maybe your coworkers are just lazy or hurt by the criticism. If that's the only thing going on - that's their problem.

But maybe some of the stuff is not a real bug or problem? Especially if they want to reject it?

You see something as a "business flow issue". But maybe there was some genuine reason (particular case that you didn't notice) why it is made the way it is and can't be done otherwise?

Maybe there is a problem that you didn't understand the way something was intended to be done? In that case you filed "this is done wrong" while the actual problem was that the intended workflow wasn't clear enough.

Or maybe they were specifically told by a manager to create worklow in a certain way that you see as "GUI defect"?

If you see a bug - just report it. If you see a flow issue, you should bring it up in a way of discussion - "why is it done like this? it seems to me that it might be easier if done this way". Don't just insist that you are right and know how everything should be done.

Answer 11

Normally, you should file all bugs as long as they're unique and and you describe them well, including a reproduction scenario and any other relevant data.

But I have worked in a place where we weren't allowed by management to file more than X development hours worth of bugs, nor were we allowed to file bugs that couldn't get scheduled. So we had to talk to the developers informally to gauge the expected time per bug. And on one package we could file no bugs since the responsible developer simply wouldn't work on it.

Bottom line: do what seems reasonable first, if complaints come in, do as you're told.

Answer 12

It is perfectly understandable to feel bad about finding too may defects in the product: people prefer to cheer for the winning team.

The team is not the testing department, it is the company. So if you find that you can put work on the developers' plates faster than they can work it off (as well as do new developments), you are part of a process locking your team down.

That is no reason to rejoice. So you need to figure out how you can best contribute to improving your team's performance. That means prioritizing bugs, trying to track down possible root causes or pinpointing who might best work on the bugs, trying to group several symptoms into a single bug where possible, queuing bugs possibly resolved by other fixes or ongoing developments in your personal to-be-checked-later queue in order to maximize efficiency of dealing with the workload you uncover.

Basically you want to maximize the improvement of the product as a result of the workload channeled due to your part of the team work (which are more than just your own working hours).

There are valid reasons for treating the tested product as a black box. But don't treat your team as a black box.

Answer 13

Absolutely NOT. If testers find some meaningful defects some time dev feel irritated but tester should no worries about such kind of things. Tester should perform their testing like as end user perspectives. and always provide their suggestions, improvements to the upper level management.

Answer 14

Absolutely not, testing the functionality and finding defects is the tester job. Just think this way, the more defects you find before the product goes into hands of end user, the more stable the product will be. Remember, fixing the defects during testing phase is less costlier than fixing the defects after product is available to end users. So it is better to find it sooner rather than later.

Answer 15

In my opinion, NO tester should feel bad about finding more bugs if, Every bug reported:

• is not redundant or pointing to the same core issue in a different form.
• adding further business value to the overall product quality.
• in a neutral objective way without pointing to someone.
• by providing as much as possible information which is helpful for the developer to fix it.

Answer 16

First you should be proud of yourself that you've found a large no. of bugs. Once all the bugs get fixed, it will help to increase the quality of the product. Don't worry about what others say. It's your job to find bugs and file them. Do your work promptly, you will get appreciated for sure.

Answer 17

You shouldn't feel bad about finding too many bugs.

Firstly, what is too many? Are two bugs too many? Are two hundred bugs too many? Your findings are either bugs or not, if they are - report them.

Secondly, you might want to consider the social impact your reports have on developers. Maybe reporting 200 bugs to one person or to one team might make them look bad or make you look adversarial. In that case, try to group multiple bugs under one report, and maybe withhold reporting on some bugs (save them for later - maybe after fixing the first 178 bugs, the remaining 22 will magically be gone as well - that is, if bug fixes don't create a new batch of too many bugs).