171
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....
75
Company pays me to test good and not be careless.
You are asking this question here - you are not careless, you care about the job you do and the things you can improve on.
Don't take it personally and be professional
The point of finding bugs is not to blame anyone, but to enhance the product's quality. If your manager is blaming you personally, this is ...
54
As a developer with 15+ years experience, I'd say: please report the bug. I'd much rather have a ticket in the tracking system than a vague memory of a hallway conversation, or an interruption of what I'm working on. As Joel Spolsky put it:
At any given time, I can only remember two bugs. If you ask me to remember three, one of them will fall on the floor ...
35
Please do not resign.
As alecxe has said in his post, Perfect Software is a myth.
I would like to add, the difference between a tester and a developer is: It is very difficult to see how much a tester has contributed.
When a developer is given a task to develop a feature, this developer
will produce a tangible result, e.g. a clickable button.
But when a ...
35
Continue testing in this situation would be counter-productive and may lead to a "deadlock" - when the reported issues would depend on each other recursively.
make sure the management is aware of the situation
sit down with the development team - determine the most critical and problematic areas and the step-by-step process to get out of the testing "...
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 story.
My experience with testing comes from beta testing games, which I know is a less vital task, but the ...
29
It depends
I've been in this situation more times than I care to remember, and the general process I use works this way:
Triage all findings - At this stage I would be working to triage all bug findings into 4 classes:
Blockers - any bug that makes it impossible for the product to perform the basic user acceptance tests, or breaks crucial functionality. ...
28
I'm going to address what I feel is the elephant in the room here, because none of the other answers have 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.
...
25
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 ...
23
It is very admirable for you to consider a tester's role from this perspective.
The hard cold fact:
No one is happy when there is a bug found in their code. Imagine yourself as a developer, you have done coding, you have done unit testing and you feel pretty good when you check in your code. How would you feel when someone shows up shortly before code ...
20
I work as a Manual tester on a big project. My project follows Agile methodology. I test a Web-based application. I sometimes ask my self , that am i giving any value to the stakeholders?
So, the value that you are giving to stakeholders is the reduction in the amount of defects that go to production. The cost of fixing a defect drastically increases over ...
20
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 ...
18
As the other answers have said, do not blame yourself. Nobody can test any piece of software completely, any more than anyone can write completely bug-free software. It's too complex.
I'm going to quote an example from an article I wrote over at the Ministry of Testing Dojo: Ten Misconceptions About Software Testing. The quote is from a section explaining ...
15
In my own experience, I've found that this really depends on the culture of the team or company that you're working with.
On a team with good communication skills, and where everyone works together well, you may very well be able to just tell the developer about it, they take a look at it, and say it'll be fixed in 5 minutes. If it's longer, maybe they'...
15
What does your company management and the dev team say?
Do they require that piece of information in the Bug Report?
As a tester when you are reporting bugs you need to make sure you provide all the information that will help the development team trace, isolate, debug and fix the problems. So, who better to ask what type of information would best help them ...
15
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
You've got a pretty good grasp of the defect life cycle, however the terminology and even the flow can change from project to project and team to team. Most likely, "Open" is the same as "New". More important than what term to use is ensuring that the team are all using the same terms.
14
This is a simple, if uncomfortable, situation to be in. Unfortunately, it does happen from time to time and you need to be ready for it.
The fact that the defect has been found close to the deadline is, in the short term, irrelevant. Your team has found a high severity defect, so you report it. Given the short timescales, you ensure that everyone who ...
14
For testers to become more valuable and helpful for the development team...
Focus on helping developers earlier in the process
Focus on adding value much earlier in the process. Focus on working with developers before and as the code is being written, not after it has been deployed in a testing/staging environment. This will help change your role from a ...
14
A generic answer is: It's contextual; the team and stakeholders (which is who understand better the context) should work towards finding a good way - and periodically analysis its efficacy and improve on it.
However, I see three major approaches. E.g.:
1 - The team defines strict rules for labels:
High: The user cannot use some feature
Medium: The user ...
13
Major has more impact on how users can or cannot use the application than minor.
There is no industry standard what these terms mean. If it is necessary, you need to discuss the meaning with your team/company, as the meaning should relate to which action, turn-around time should be used.
Personally I do not care for priorities in words. Rather prioritize ...
12
We prefer to talk to developers first. Then, we together decide if detected error is a result of some quirk in processing and not even worth of bug, or, if it is worth a bug, we negotiate who will enter it to Bugzilla (we call if "buggify the feedback").
Often, developers prefer to write the bug description, because that way they can better describe the ...
12
Do not discuss defects immediately with developers. Mainly because context switching is bad for their focus and could take up to 5-30 minutes to recover from.
How to communicate a defect depends in which stage of development the defect is found.
When I find a defects during testing of a task of the current iteration then I document the defect in the ...
answered Jan 26 '16 at 21:37
Niels van Reijmersdal
25.7k2 gold badges39 silver badges92 bronze badges
12
I think, it is always good to discuss things in person. You are lucky you have that things going on at your work place. In many companies all communication happens only via a system and that at times creates lot of confusion. What you write and what the other person understands may be completely different.
For things like developers don't consider the bugs, ...
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
Deciding to release with severe bug (and escalate next release with a fix) or postpone release is business decision. It can be done only by someone who understands how customer works.
Maybe it is not a big deal at the end, and you can go on with the release (and inform customers what bug is, and find workaround until bug is fixed.
Maybe system is not safe ...
10
Ideally, suspend the testing. And it's time to refer the Test Plan document.
This is the time when one should look at the Testing suspension and resumption criteria section in the Test Plan document.
I can refer to the following three points that are generally mentioned under testing suspension criteria and this scenario looks like falling under point 1 ...
10
No
It absolutely is not valuable to measure bug count per hour of dev time. It is especially bad to measure bug count per hour for individual devs.
Devs on more complex or difficult code will generally have more bugs/hour than devs working on cleaner, more straightforward code. Similarly, devs will produce more bugs/hour at the end of a long workday than ...
9
There is no one "right" answer. The number and type of categories of defects that would be appropriate to your context depend upon several factors, including:
Type of application
Your team size
The level and frequency of "in the hallways" conversations between people on the team
The number of bugs you have "hanging around" waiting to be taken care of
etc.
...
9
In our organization, there's one defect (2nd one opened is a duplicate), but there are two test cases which fail.
Only top voted, non community-wiki answers of a minimum length are eligible
