As a PO I’m usually asking QA for some tests that actually show the product meets the requirements
There might be 50 pages proving it rejects bad input, and nothing showing it can successfully handle a perfectly correct case. We seem bad at training testers.
That sounds strange. I cannot comment on your particular case without seeing the test artifacts.
Generally speaking, there is nothing wrong with tests that ensure bad input doesn’t break the system, as this can easily lead to incorrect system states, damage to the environment, loss of data, money, reputation, and even lives - although most systems are not critical enough to threaten lives.
You wouldn’t need QAs if you only needed to validate that the product meets the requirements. In a typical company, many people are involved in that process. This includes the developer who wrote the code, the developer who reviewed it, and the people who conduct acceptance testing, among others. If your developers produce code that doesn’t meet the requirements, you’re in trouble.
I’m not saying that QA shouldn’t validate whether the system meets the requirements, but you don’t want them to do just that.
If they didn’t properly test validation I would complain about that, what that regularly miss is a test showing correct function for each major use case
Doesn’t sound too weird to me. In my experience, devs always focus too much on positive / correct inputs, as they want things to work. Which is why you need testers that will catch all the weird crazy ways people can break things.
Testers shouldn’t even see the code of it can’t handle nominal cases.
A QA engineer walks into a bar and asks where the bathroom is. The bar bursts into flames. The product owner says that the bar can be shipped anyway.
As a PO I’m usually asking QA for some tests that actually show the product meets the requirements
There might be 50 pages proving it rejects bad input, and nothing showing it can successfully handle a perfectly correct case. We seem bad at training testers.
That sounds strange. I cannot comment on your particular case without seeing the test artifacts.
Generally speaking, there is nothing wrong with tests that ensure bad input doesn’t break the system, as this can easily lead to incorrect system states, damage to the environment, loss of data, money, reputation, and even lives - although most systems are not critical enough to threaten lives.
You wouldn’t need QAs if you only needed to validate that the product meets the requirements. In a typical company, many people are involved in that process. This includes the developer who wrote the code, the developer who reviewed it, and the people who conduct acceptance testing, among others. If your developers produce code that doesn’t meet the requirements, you’re in trouble.
I’m not saying that QA shouldn’t validate whether the system meets the requirements, but you don’t want them to do just that.
If they didn’t properly test validation I would complain about that, what that regularly miss is a test showing correct function for each major use case
So it sounds like you need to use the words to tell them, do you know testing types and strategies so you can tell them which to employ?
Doesn’t sound too weird to me. In my experience, devs always focus too much on positive / correct inputs, as they want things to work. Which is why you need testers that will catch all the weird crazy ways people can break things. Testers shouldn’t even see the code of it can’t handle nominal cases.
The problem is that testers are competent, often intelligent individuals. Users, not so much.
That is not always the case, from my experience
“will not fix”