New answers tagged qa-process
0
No.
But I can see why management are making the terrible mistake of thinking the answer is yes. There are three cases:
A bug is caught by a planned test
A bug is caught by QA exploratory testing, or other means
A bug is not caught
While case 1 might be better than case 2, both are much, much better than case 3.
But the attitude that testing should be all ...
1
Well, ideally the designed tests should cover all error cases.
Exhaustive tests are very costly, and in the end the management must decide what confidence level they want to achieve, and how much money they want to spend on it, aiming at a sweet spot depending on the application. This money should obviously be used most efficiently.
Exploratory tests, ...
2
"One can predict the ways in which a software should work but cannot predict the ways in which it will not work."
Testing is inherently an exploratory activity.
If we deprive or even blame an activity for its core characteristic then basically we are turning it into an empty ritual.
Exploratory Testing
1
The "blame QA for bugs" mentality should be stamped out in management circles. The primary point of QA is to find problems which means they should be actively praised and sometimes even rewarded for doing so. Each bug they find is one that customers don't (assuming that it gets fixed). That not only improves sales but also reduces maintenance costs ...
0
I agree with you regarding QA should find as many problems as they can especially with exploratory tests.
Assuming your management implements a policy in wich your testers are not allowed to deviate from your predefined behaviour. With this policy in place you just created a very expensive automatic testing suite. My point is: test cases you can anticipate ...
36
I think the first big problem here is the attempt to assign blame. In accident reports, the FAA doesn't start with who to blame, they start with what went wrong and what were the causal factors. Assigning blame causes all types of unintended consequences.
In the worst case, if you blame/penalize QA for finding bugs that were not foreseen during the design ...
5
Identifying problems should never count against anyone, as it leads to a culture of defensiveness, cover-ups and people attempting to game the metrics.
In theory you could track the ratio of bugs found during planned and unplanned testing, as it could indicate that you are not spending enough time on risk assessment.
However, if the developers know what the ...
10
First, the previous answers are good and bring up different view points to consider.
I agree that management shouldn't be finding ways to blame QA for missing bugs or finding bugs in unexpected, unplanned ways. That's a huge benefit to the team and a good skill to have when doing testing.
My take on this is why is there only "happy path" test cases ...
7
I think your tittle can also read "should we blame QA for finding bugs?", to which I hope no one replies yes, although I'm not so certain about the management in your organisation.
You got it right, not all test ideas or bugs can be expected when reading documentation, requirements, or other documents. You simply have to interact with the system to ...
3
Testing is always partially exploratory, and for any reasonably complex software, testing can never completely exhaust all the possibilities. Meaning, you will always find more issues and think of more scenarios as your knowledge about the application grows. Requiring all the scenarios upfront is just not realistic.
12
There can be a several reasons for test cases for bugs found later during exploratory testing not being identified during the project planning phase.
Couple of them may be,
Testers are humans. To err is human. Humans make mistakes. IF not wouldn't we be god instead?
From what you have written, you do the planning along with the whole team and not in ...
1
Only a consistently manually reproducible bug with specific given
steps should be logged in the system.
If a bug found through manual or automated testing is not consistently reproducible then it should be investigated more by QA engineer to come up with definite minimal reproducible example.
Specifically with automation, there could be good number of ...
1
From what you have written, I'm not certain if you mean bugs in the test code, or bugs in the product. I think it's important to distinguish between the two.
Every QA team has different processes.
Not a problem to me. If something works in one team, why force them to change?
due to various reasons there are cases where a test fails, and a regular restart ...
Top 50 recent answers are included