Test (and Design) are part of the development strategy. Depending on what your business goals are, you should optimize Design\Development\Test for it. Sometimes these goals are principals that you want to brand around (e.g. robustness for a DB server product) or tactical decision that adapt to a stage (catching up, learning, leapfrogging, supportability, locking a market). These are scenarios that I've seen (and some of them worked on) over the last years:

* Deliver a strong v1 too late * Deliver a small v1 that outs a new market and allows competirors to catch up * Develop a vnext backcompat-focused product and be surpassed by a new\exisiting competitor * Develop a heavily customer focus product and get trapped in impossible\contradicting requirements * Deliver a weak v1 and lose market credibility * Deliver a secret v1 and have no real market for it

If you have a clear view of the business goals, Test becomes less an opinion and more of a resourcing puzzle (still hard though). It's a great world of tradeoffs between layering tests, testability features, customer research\partnership\simulation, fast development, legacy ownership, responsibility distribution, exhaustiveness, documentation, community\customer engagement, reusability of tests, reusability of product code.