177

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


31

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


23

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


20

It depends Each company has its own process for handling customer-reported defects. The one I'm most familiar with is more or less as follows: Customer support person attempts to reproduce defect and updates the report with any extra information Customer support or product owner searches defect management tool to determine whether or not the defect has been ...


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


18

It depends on your policy if you have one. It could go either way. It could also be that it goes to the PO and they should approve it before continuing with the fix or putting it in the backlog.


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

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


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


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

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


10

It depends on the company to company and it's organizational work culture. In my current and previous companies, When a end user reports a bug first it goes/assigned it the QA team. Then the QA team tries to replicate it in lower/Test environments (sandboxes). If it's a valid issue then QA team documents the exact steps to reproduce it and after that it get'...


9

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


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


9

First of all users should report using a reporting system, they should not be aware where does it go. From there it depends on the size of your company, the product and how mature it is, the SLA you promise, the resource the company have and the kind of issues you expect. Some examples I've seen over the years- A big financial company, all user issues are ...


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


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.


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

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


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