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


44

I would operate under the assumption that your developers are documenting this somewhere, since I would also assume that they are good developers who care about good development practices. As a developer myself, I strongly believe that developers should be expected to describe what they've done in a language other than code. It doesn't have to be ...


33

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


30

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


28

As a developer, not a QAist, I have a responsibility to provide software that meets the specs, with as few errors as possible. From my perspective, QA has the responsibility to inform me of any errors that I have made. I place them in extremely high regard for that. When QA tells me that "they found a bug" they found that bug in a particular commit. The ...


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


25

If request sounds reasonable (which includes taking into account my other priorities), I would spend some more time researching. If not reasonable, I will respond "sorry this is the best I can", and if my polite refusal to spend more time researching is not enough for the developer, I will ask my manager to make the decision. I would also mention to ...


23

Good and Interesting question. Here are some to make the tester's job easier: Developers should perform basic testing before giving the product to the tester. Include QA from the beginning of the project, not when the product is ready to test. Work as a Team, not as two different departments [Developer & QA] As the developer, never ask the QA to ...


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


20

I see several possible problems here: There are reported bugs that the test team can apparently reproduce but the development team has trouble finding/fixing. This suggests that there is insufficient information in the bug report. In situations like this, it can be helpful to provide an exact set of reproduction instructions. If you are testing a standalone ...


18

In this situation - unfortunately - your best option is the slow and painful method. I've used it as a general tester, and for test automation. The way I approach this is to use these techniques: Find gaps in use cases/specifications wherever possible - Every time a tester finds a hole or an unconsidered situation in a use case, specification, or design ...


17

Simple answer 'NO!' Complex answer 'No, provided you are doing the following...:' 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 You aren't duplicating bugs You are reporting the bugs in such as way as ...


14

Treat them as equals. I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.


14

It depends. As Joe Strazzere explained, it is a matter of discussion between devs and testers. The question is what factors to consider in such a discussion. I think Danny R. Faught explained that pretty well in How to Make your Bugs Lonely: Tips on Bug Isolation. There is no clear dividing line between the bug isolation and reporting that the tester ...


14

Request a meeting between upper management of QA and DEV and explain the goals of what you are asking. I think the description you provided in the question is a good start at explaining the why of the ask. This additional information, for instance, may help a tester to find similar issues in other parts of the application or can provide ideas for ...


13

Just a few quick ones off the top of my head: Run the code they've completed at least once on their machine before marking it as 'Done'. Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written Encourage QA to participate in sprint planning/grooming, design ...


13

I've worked in both roles for a while and my recommendation is: Pair (before coding when possible) on test plans See QA as an asset that is protecting you and customers from the mistakes we all make Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding Don't assume that they can pass ...


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


11

If they have the knowledge to fix in, why not ? I can see where the bug should still be reported for those places that want traceability etc and presumably the tester will first write a failing test to demonstrate the bug...


11

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


10

I know this problem way too well. There's no "right" answer, unfortunately, but there are some things you can do to help with this problem. Dependency map - do you have a list of application features that have heavy dependencies and tend to break when changes occur in other areas? If you know changes in feature X tend to break feature Y, you know you always ...


10

Greater communication between dev and qa so that qa already knows about wip issues. Communicate first in person where there is disagreement, then document the agreement. Clear definition on what quality metrics are being used at your company. More discussion and planning up-front before the first line of code is written. Talk about what testing is ...


9

As a tester on a small team in a large organization, my answer may be skewed from that of a tester in another situation. I'm all fine for testers fixing bugs, but, we also need to realize that we specialize in testing, and developers specialize in coding. We could fix it, and it could break something else that we don't know about. At the end of the day ...


9

Most other answers suggest that requirement to be better in testing is understanding the code - but that requires skills what most QA testers do not possess. Deep understanding the code is not required. In most cases, code changes are way too complicated and obscure for QA to be able to glimpse anything relevant from just reading the code in detail. What IS ...


8

I'm going with my favorite response here: it depends. Sometimes the decision is made because that's the language the tool supports. Sometimes the language is a flavor of the language used by the development team - this often happens where there's an expectation that the development team will be writing at least some of the test automation code. Sometimes ...


8

Testing is not a standalone activity because: resolving bugs means talking with product and development to make sure that the bugs are well understood and that the path to correct them makes sense for all. understanding business requirements and what an application is trying to achieve means working with business users and product owners understanding ...


8

Many companies I've worked for shared a policy... ...and that policy is: Testers are free to consult with developers while attempting to characterize, isolate or reproduce anomalous behavior. Once a tester can document the steps necessary to faithfully recreate the behavior, the developer should be able to take it from there. Developers are free to consult ...


7

No, they shouldn't. The major reason is that the natural role of Developer is to stand up for idea that "the program is working". The natural role of QA is a direct opposite: to prove that "the program is not working". If the same physical person acts for two opposite roles, this may lead to compromises with themselves. Specifically speaking, sooner or ...


7

As a manual/exploratory tester who works very closely with developers I find that the best way to improve my effectiveness is to learn as much as possible about programming in general, plus the languages/technologies (e.g. Drupal, WordPress) being used. Being able to code to the same standard as a developer is not a requirement to be an effective tester, but ...


7

This is a simple point, but very effective: Be a developer who says "thanks" or "good catch!" or something positive whenever a tester finds a defect. It's the daily currency of the respectful working relationship. All the formal processes are good, but they flow from the basic attitude of respect.


Only top voted, non community-wiki answers of a minimum length are eligible