My feel is that this pattern leads to quantitatively better software that is qualitatively worse. There are two reasons for this:
1. QA teams come up with new ways to break software in the way humans use it. Automated tests etc confirm the software works as designed.
2. Because the org making this choice isn't stupid, they measure bug frequency and impact and find that "only X users have Y impact where Y is ranked as low" per each bug. No one bug is ever worth fixing. But, user X aren't seeing that one bug, they get hit by tens or hundreds of these on a regular basis. As a result, their perceived experience with a given product is poor and it feels buggy.
This idea that you can measure bugs in isolation and deliver perceived product quality is faulty. A user experiences a product as a whole, and if you can't evaluate that as well, you will be seen as delivering a poor product.
1. QA teams come up with new ways to break software in the way humans use it. Automated tests etc confirm the software works as designed.
2. Because the org making this choice isn't stupid, they measure bug frequency and impact and find that "only X users have Y impact where Y is ranked as low" per each bug. No one bug is ever worth fixing. But, user X aren't seeing that one bug, they get hit by tens or hundreds of these on a regular basis. As a result, their perceived experience with a given product is poor and it feels buggy.
This idea that you can measure bugs in isolation and deliver perceived product quality is faulty. A user experiences a product as a whole, and if you can't evaluate that as well, you will be seen as delivering a poor product.