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....
I would push back hard on this question.
An interview question is a machine designed to extract a signal from a candidate. Let's examine the parts of this machine.
"The most" has already been commented on. Why is it important that the answer be the most interesting? Why are you asking the candidate to solve an optimization problem in your interview? If ...
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 ...
A bug that is only a bug 50% of the time is still a bug.
I would still report/document it as a regular bug, but with an "intermittent" label - letting to know both developers and management about the bug, and that it is not reproduced all the time.
This way the issue would get its priority by the management, and the mentioned people may generate some ideas ...
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 ...
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 ...
Issue Reports (Bug Reports) are one of the main communication methods that QAers use.
You are creating a statement to your stakeholders - "I have found what I think is a problem, and here's my clear explanation of what it is and how you can see it too. Please look into this".
Understand the Audience for the Report
It's important to know who is going to ...
As a developer, this is the information I need to solve a problem:
Steps to reproduce.
In that order. Anything less results in difficulty either reproducing the issue or identifying differences in how the requirements are being interpreted. Anything more has the potential to confuse the developer.
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 ...
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 "...
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 ...
Yes, by all means - you must write a bug report! In your report, note that the bug is intermittent, and leave comments about your investigation, what you have done to try and reproduce the problem, and any other clues you can think of.
Developers may not be able to reproduce the issue, but they may be able to see the bug in the code itself, or add ...
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. ...
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.
I'd like to address the reporting aspect of the question. You say...
I just keep on writing excellent test cases and executing them, but then I don't have anything to show to the management. Sometimes it makes me think that I am not providing any value to the product
Even in the perfect world where the software leaves the developers' hands 100% bug free ...
Testing no longer means testing
Confused? We can imagine! The purpose of testing used to be fairly
clear–“Testing is the process of executing a program with the intent
of finding errors”. This changes when adopting agile and
I think the testing manifesto has it at the right end. Focus on preventing defects over ...
It is always a very good practice to start testing as early as possible.
By not fully implemented if you mean still under development, then I suppose that is not such a great idea. Yes, you can go for incremental build releases for testing, that might be helpful.
When you say that your testers all log the same bugs, well there's your problem!
Do you ...
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 be honest, I wouldn't be able to come up with any defect in particular.
If I were you, I'd rephrase my questions as situations, for example:
What actions would you take if you had to reopen a defect for the fifth time?
You need to retest a defect which has been resolved by a developer without any further comments or explanation. What actions would you ...
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 ...
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 ...
First of all, "no technical solution" isn't exactly correct. From my understanding, the technical solution is in fact very simple; either:
improve the Excel macro to provide better validations
or, make the import function of your application more robust to prevent errors (abort the import) and to clearly signal the problem values to the user.
I propose you ...
The severity of a bug is a measure of how important the bug is to the end user: how much it breaks, how badly it breaks things, how difficult it is to get work done with this bug in place.
The priority of the bug is a measure of how important the bug is to the development team. This will take into effect the severity, but also the development time and ...
I think the problem arrives from how you use your VCS:
You want to commit your code because you have finished a sub task and want to have it backed up in case of e.g. a hdd crash on your workstation.
Your testers see changes in the repo or get an automated build which they test.
One solution could be a separate working branch which is work in progress.
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 ...
Welcome to the crowd. In my experience they are the norm and the bane of Quality Engineering.
So first off - accept that and start making resources available for it.
Some techniques that you can use:
Allow sufficient resources. Be prepared to need to take days/weeks to fix intermittent failures
Collect examples. Some ...
Only one thing i would like to add apart from Joe's contribution.
Don't point out two or more issues in the same bug report. If you feel there appears another different issue when you follow the same steps, raise it separately, otherwise there the chance it get missed.
To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.
To me this is wrong KPI and there is been at least two discussions here why is so:
To expand on the link Phil K mentioned. Cem Kaner published a paper entitled "Bug Advocacy" which you can read about in a 100 page PDF at: http://www.kaner.com/pdfs/bugadvoc.pdf. It also forms the basis for the second BBST course.
Kaner outlines 4 major points of Bug Advocacy: (quoted directly from page 10.)
The point of testing is to find bugs
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'...