95

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.

| improve this question | | | | |
  • 59
    Why should anyone doing their job good feel bad? – Embedded Jan 23 '17 at 19:21
  • 15
    Unless you actually report to the development department and not to a separate QA department, the developers can "want" anything they like, but they can't fire you for doing your job better than they do theirs. – alephzero Jan 23 '17 at 19:52
  • 16
    "i filed GUI defects.. business logic and some good genuine bugs" the way you are phrasing it sounds like you are making a distinction among two classes of bugs of different relevance/type, one of which might include questionable or subjective issues.. if that's the case perhaps you should get the development team, designers and whoever else might be interested in it, to meet and have a discussion so that you can agree on a shared understanding of what constitutes relevant issues... it might result in a healthier working environment, i think. And avoid further clashes down the road. – Patrick Trentin Jan 23 '17 at 21:00
  • 9
    No, the developers should feel bad about shipping too many bugs for testing. – user253751 Jan 24 '17 at 8:42
  • 9
    Always bear in mind, that the most trivial of bugs might be a symptom of something more serious. If a tester finds the trivial instance and flags it, the developer may fix the underlying problem and think "there but for the grace of God ...". The alternative is that the product is shipped and customers (many, high-profile, publicly) find the catastrophic version of the bug. – nigel222 Jan 24 '17 at 12:25

16 Answers 16

Active Oldest Votes
175

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.

| improve this answer | | | | |
  • 43
    +1 for signal-to noise ratio. Welcome on board, we need more people like you! – Peter M. - stands for Monica Jan 23 '17 at 20:12
  • 7
    Small S/N ratio means lots of noise for a given amount of signal. (Example: signal 10 units, noise 100 units, S/N = 0.1.) You should be aiming for a high (large) S/N ratio, which means lots of signal for a given amount of noise (example: signal 100 units, noise 10 units, S/N = 10). – a CVn Jan 23 '17 at 20:23
  • 7
    The tester in your example was doing his job, correctly. He is not required to know, and in fact he SHOULD not know, whether the problem is that each hyperlink is individually broken, or the underlying mechanism that handles the hyperlinks is broken. Each and every one of those hyperlinks is going to have to be retested, and the retest results recorded, and THAT IS WHAT YOUR AUTOMATED BUG DATABASE IS FOR. (I had a similar problem, many years ago. The software manager wanted me to write one giant bug. I insisted on writing a separate bug for each thing that had to be fixed and tested.) – John R. Strohm Jan 23 '17 at 22:32
  • 10
    @JohnR.Strohm That may be true for black box testers, that you don't want them to make any assumptions about the inner workings of the product, but that isn't the only kind of testing. Experienced testers will accumulate domain knowledge of the software they are testing and of software generally. And they should! It makes them more effective testers. It goes back to s/n ratio. If the tester did not recognize that all the bugs were duplicates, their manager should have, and created one bug to capture all the affected hyperlinks, and closed the rest as duplicates. – J Doe Jan 24 '17 at 1:34
  • 6
    The best testers don't ignore bugs but the best testers also don't train the devs to ignore bugs either. They also use their own time effectively. If you write up 100 duplicate bug reports, the devs will ignore your work, and you've wasted a whole lot of your own time that you could have spent looking for more bugs. – J Doe Jan 24 '17 at 1:41
32

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)

| improve this answer | | | | |
  • 2
    +1 for "it is a blow to the ego/pride to have someone find flaws in your work" You have to accept it, no-one says you have to like it. – deworde Jan 24 '17 at 8:24
  • 1
    Should not be a blow to the ego. We're all human, we all make mistakes. Somebody else has a complementary skill. He can find the mistakes, but quite probably would not be the right person to fix them. – nigel222 Jan 24 '17 at 12:36
  • 1
    @nigel222 you are correct in that it should not be a blow to the ego, or your pride, but we as humans are quite imperfect creatures aren't we. We have many bugs in our operating software so to speak. – NZKshatriya Jan 24 '17 at 13:28
  • 3
    Regarding the blow to the ego/pride of the developer. +1 because as you said, they have to learn to live with it. As a developer myself I don't feel at all personally attacked or degraded when QA finds a bug in my code. To the contrary, my favorite QA people I've ever worked with have been the ones who are thorough and report everything they can find. We may not end up fixing every small issue they find, but knowing about the small problems is better than not knowing. – Kevin Wells Jan 24 '17 at 18:31
  • 3
    It may help to have a talk with them and explain that you will sometimes file "bugs" that are subjective or that you think are detrimental to the product and that they are free to disagree and reject them without hurting your feelings. It's your job to report and it's their job to decide what to do. A simple conversation might resolve the problem. I had a programmer once who was upset at all the "nitpicky" comments in his code review. I told him that he's free to disagree or even to say "yeah, but it's not worth fixing". That was all it took. – David Schwartz Jan 26 '17 at 3:07
29

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.

| improve this answer | | | | |
  • 4
    I can't say that this is definitely true of the OP since we have such little information about them, but this is an important consideration for some people – Kevin Wells Jan 24 '17 at 18:32
  • 1
    @KevinWells I based my answer upon the words he used and the general impression I get from the way he wrote his question. I don't know for certain that his mannerisms at the office are the same as at a keyboard, but many people end up having their speech patterns partially bleed over into their written communications. – Nzall Jan 24 '17 at 19:41
  • 6
    The problem is that you are stating your conclusions as fact, not as something to consider. – JeffC Jan 24 '17 at 20:50
  • 2
    @JeffC I've amended my answer to clarify what I base my answer on and that it may be a faulty interpretation. – Nzall Jan 24 '17 at 21:34
26

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.

| improve this answer | | | | |
  • 5
    +1 for saying not all bugs have to be fixed. I've known QA people insisting on fixing every little thing with no regard for business value/actually being able to release. Personally as a developer I also have this tendency, but I can control it and see the bigger picture. – Sebastiaan van den Broek Jan 24 '17 at 7:22
  • 1
    Yes, "Won't fix" with reasons, is valid. So is debating those reasons. Maybe that should be "Won't fix, not ever, because ..." and "Won't fix, now, because too many other more pressing issues and not enough resources". – nigel222 Jan 24 '17 at 12:30
  • "not all bugs have to be fixed" Absolutely! However, it is normally not up to the QA or even the Dev to make that decision. Usually a product owner or BA would decide based on business value, which should be informed by both QA and Dev. But ultimately, it is usually someone like a PO who makes the final decision. – industry7 Jan 26 '17 at 20:29
  • I have worked with developers who didn't understand why the customer can't just use a command line like normal people. Some things you are going to argue more passionately than others. – David Cain Jan 26 '17 at 21:46
22

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.

| improve this answer | | | | |
  • IMHO the best answer. Print this and hang it in your cubicle: Non-trivial software always has bugs. Our job is to find them before the customer does. – RedSonja Jan 30 '17 at 8:09
16

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.
| improve this answer | | | | |
  • 2
    I somewhat disagree with #1... not all relevant bugs are just deviations from requirements... some are things that through experience, customer knowledge, etc. you think should be better. – JeffC Jan 24 '17 at 20:52
  • @JeffC, point well made. Have editted my point to reflect your comment. – Tufty Jan 25 '17 at 8:16
  • 1
    A point about #1: One thing developers hate is bug reports merely pointing out that "X should be better" without specifying how X should be. Granted, that is not QA:s job, but QA will get the heat for sloppy requirements. – Guran Jan 30 '17 at 10:13
  • @Guran I agree. QA's should never be saying that they 'just think it should be better'. If, as a QA, I think something can/needs to be better, I need to demonstrate how and why this is true. I need to provide evidence. However, if the system is behaving according to the requirements, then irrespective of my opinion, it's not a bug. – Tufty Jan 30 '17 at 10:36
  • @Tufty That's not an absolute, IMHO. I don't mind at all QA pointing out flaws that don't break an explicit spec, but I do mind QA bringing those up with the devs (apart from in a retrospective or similar). Those findings must be brought to product management or similar, someone with the authority to improve the specs, not just implement them. – Guran Jan 30 '17 at 13:13
12

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.

| improve this answer | | | | |
10

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
| improve this answer | | | | |
7

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.

| improve this answer | | | | |
5

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.

| improve this answer | | | | |
4

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.

| improve this answer | | | | |
3

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.

| improve this answer | | | | |
  • 1
    Why not filing a bug? If the responsible developer can work on package after some time, without a buglist the software should be re-tested. – CoffeDeveloper Jan 24 '17 at 13:40
  • The policy of only allowing so many hours of bugs to be reported is absolute madness. Only a certain amount of bugs will end up being fixed, but why would you tell your QA team not to record all of the bugs they find? Surely it is better to know about bugs that you decide later not to fix than to not know about them at all? – Kevin Wells Jan 24 '17 at 18:35
  • For example, what if you found a bug that was so central and critical that it would require a complete rewrite of the code base (unlikely I know, but go with it). Under this system you would not be allowed to report it at all since it would require more than the allowable bug fixing time. I simply can't imagine what the purpose of that policy would be other than creating a product with more bugs and having less understanding of it. – Kevin Wells Jan 24 '17 at 18:37
  • 1
    This practice isn't bad testing, it's pure bad management. I previously worked on a project where we were told to downgrade severities on a repeated basis because the number of serious bugs we were finding was causing some unpleasant conversations for our management and the people senior to them. It was not a comfortable place to work! – Tufty Jan 27 '17 at 10:05
2

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.

| improve this answer | | | | |
1

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.

| improve this answer | | | | |
1

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.
| improve this answer | | | | |
0

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.

| improve this answer | | | | |

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