I fully agree that you need to design in quality. I go by the adage "You can't test in quality". Regardless, you WILL test. The question is whether it is more economical to test before you release the product or once its in the customer hands. Some failures can have significant financial impacts(for example, how about a defect in a car engine control module that causes the engine to shut down -- VERY expensive). In the less impactful consumer market you will have degradation in sells if the quality falls below a certain point. It comes down to a tradeoff between risk to business vs. cost to test pre-release. One lower way to mitigate the risk is to turn up/down the depth of testing depending on the change. For example, if you are making some minor UI changes, you might want to do a very light regression test but if you are doing some fundamental refactoring of a core part of the product then you might want to have a more involved set of unit/subsystem/integration tests that cover as much of the product as possible.
One method we use is to err on the conservative side and to over-test initially and if the defect density is low enough then back off on later releases as the quality level is much better known and the resulting post-release risk is lower.
Bottom line, there is no hard rule, you have to know your costs and your risks and make daily tradeoffs between the two.
