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....
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 ...
Probabilistically, Jake is certainly correct.
However, computers are deterministic machines, so when you say that you can only reproduce a problem 1/5 of the time, what you're really saying is that you're only actually creating the situation that leads to the problem 1/5 of the time. You need to talk to the developer, and get a better understanding of ...
There will always be smart technical people who do not like to code. There will always be ways of taking advantage of their talents.
I'm a coder. And I love my manual tester. She see's the world differently than I do and that's exactly what I need. What I hate are manual test scripts that pile up without any automation behind them.
The solution isn't to ...
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 ...
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 ...
Pick a test area, measure how long it takes to test manually, then measure how long it takes to test with automation and how long you spend maintaining your automation. (There are other things you could try to measure too, e.g. bugs found manually vs with automation, but they can be hard to quantify.)
If automation is better, you'll have ...
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.
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 ...
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 ...
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 ...
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 ...
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 ...
The traditional definitions would be something like this:
A test suite is a collection of test cases related to the same test work. You might have a suite for regression, one for build verification tests, a suite that is specific for a component, and so on.
A test plan is generally a document which describes testing approach and methodologies being used for ...
To know how to write a test plan one must first learn to plan a test.
Planning test is a real thinker task. You should be asking a hell lot of question to learn about the domain of the project.
You should learn about the stakeholders of the project.
One part of planning consists of test estimation. Here is something that might get you started with it - ...
You can never be 100% sure that a rarely reproducible bug is fixed, you can only edge closer to 99.9999999...%
The simple way to monitor how confident you are in the fix is to run the reproduction steps over and over, logging how many times you (hopefully!) don't encounter the issue.
If the bug wasn't fixed, on the first test there is a 80% chance that the ...
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 ...
> The integration tests can sometimes take a long time,
> thus discouraging users from running the entire test
> suite prior to checking in
For the checkin-runs you can mark the long-running tests with their own category
and tell the test-runner to exclude those long-runners
You may also look at Is there a way to separate long running (e.g. ...
1) Are there a difference between those ones?
The Australian IT industry still views testing as a job that anyone can perform with minimal technical skills. A quick search on a leading recruitment site has a number of advertisements for Testers with requirements similar to the following:
At least 3 years experience in a Tester or Test Analyst role ...
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.
There will always be bugs that get past a tester and land in production. I have even had bugs that where in my face, we researched it, thought it was a fluke, because we couldn't reproduce it and then released the issue into production.
The best thing you can do is learn from it and prevent the same in the future. I write an automated test-case for each ...
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 ...
Seems that your boss (correctly) understands that to write automated test takes longer that perform the same test manually once, and is concerned that you will spend so much time automating you will not have time to do manual/exploratory testing. Tests are code too and needs to be maintained too, adapting them to the changes in the application.
Value in ...
Good job not abandoning the problem!
This does sound like a "scary" bug to me, and, potentially not only on the UI.
Here are some of the things I would do if I were you:
still create a formal issue in the bug tracker (you may put a "not-stable", or "requires more information" label on the ticket). Mention both your and the dev team manager.
try reproduce ...
"there is nothing to test"
That is a strong statement.
I like to use James Bach's definition of testing:
Testing is the process of evaluating a product by learning about it
through exploration and experimentation, which includes to some
degree: questioning, study, modeling, observation, inference, etc.
So, unless there is nothing new to learn about ...
It is possible to include some important approaches and goals for software testing that tend to be beneficial in creating effective test case scenarios in a wide variety of testing situations. They include:
Don't repeat yourself (e.g., keep scenarios "DRY"); don't repeat combinations of test inputs more than you need to because you would find ...
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:
When a new project development starts in an organization when does the testing role come in?
It depends on the company, industry, development approach, etc.
Two commonly referred to methods for development are Waterfall and Agile
In Waterfall you do the testing once the development of a feature is done.
In Agile you do the testing before* and ...