4 ms·

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

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.

thelittlenag 5y ago
The most common pattern I've seen, which dovetails with this analysis, is that new features are thus treated as more important as long as there is a path around existing bugs. Bugs gets treated as technical debt, and given as much priority.
sanitythrowaway 5y ago
The best QA setup I've seen was a parallel one. Devs and QA were given the same requirements doc, and independently worked out their assumptions and implementation. QA was often ready before dev work was done so sometimes devs could even run their tests locally to see if they pass. It was really remarkable. It's frustrating its not so clean usually.
- thebean11 5y ago
  That seems like it would only work on very specific types of software teams. I've never been given a requirements doc that prescribed exact interfaces or anything even close.
  - ivan_gammel 5y ago
    True, but documented test cases can help too, because developers can use them along with requirements for better understanding of the problem.

thelittlenag 5y ago

The most common pattern I've seen, which dovetails with this analysis, is that new features are thus treated as more important as long as there is a path around existing bugs. Bugs gets treated as technical debt, and given as much priority.

sanitythrowaway 5y ago

The best QA setup I've seen was a parallel one. Devs and QA were given the same requirements doc, and independently worked out their assumptions and implementation. QA was often ready before dev work was done so sometimes devs could even run their tests locally to see if they pass. It was really remarkable. It's frustrating its not so clean usually.

thebean11 5y ago
That seems like it would only work on very specific types of software teams. I've never been given a requirements doc that prescribed exact interfaces or anything even close.
- ivan_gammel 5y ago
  True, but documented test cases can help too, because developers can use them along with requirements for better understanding of the problem.