This is progress from more dogmatic ways of thinking about testing. One thing that would be interesting to explore is how things can change over time. Somethi

This is progress from more dogmatic ways of thinking about testing. One thing that would be interesting to explore is how things can change over time. Something that you thought would be stable may end up not being as stable as you thought. I feel this should factor in somehow. Quality is a multi-pronged effort. It starts with the architecture, design, coding. As this says, the connection between testing and quality is vague. Testing can give you more confidence the quality is there or it can show you the system under test is of poor quality but it won't change one into the other. If you have something of poor quality, you do a lot of testing, you file a lot of bugs and fix them most likely it's still of poor quality. Testing definitely has a role in building high quality systems but on its own is insufficient. This discussion reminds me a little of efficient frontier in portfolio management. There is some optimal mix of all your development activities just like there is a mix of different assets in your portfolio. The assets you pick and their mixture affect the probability distribution of the outcomes. Just like in portfolio management part of the problem is that the historic performance of these assets doesn't necessarily indicate future performance.