Testable by Design?!?

A few years back I was at a Rational Conference in Philly and sat in on a presentation by Sam Guckenheimer titled "Quality by Design". We all have heard of Performance, Scalability, Robustness, Configurability, and even CA's "QWAN" being factored in during the design phase, but what about testability. We all have seen so many times in our career where testing gets "trimmed" in the project schedule once the rubber meets the road. Are there things that we architects can do to help preserve some dignity in this ever-shrinking phase? Modularity, Use Case driven, Unit Tests (like NUnit or the likes) and of course our lip service to the cause can all be elements to help preserve this phase, but I wonder what else can we do. With the rise of SOA architecture we see even more of a need to "prove" out a single service/layer/slice (you pick the term). Everyone's canned response is to just have the developer build the tests as they build the main code. We know that it doesn't always play out like that. The way I see it, many of the challenges with the "automated" testing support systems, is that is still requires MORE effort than management is willing/able to invest. The crux is the lack of context. We still need humans to add the context to most of the tests in order to be useful. What if, I am just thinking aloud here, MS could add some additional Attributes that a tool could reflect one, have a user enter some additional context to (in addition to message signature & the likes) so we could easily piece together a string of Unit Tests with setup & tear down to create useable system tests. These additional metadata would need to be centrally located and workable by the non-technical business analysts in order to contain any business value. Not free just cheaper. Sorry, I digressed, back to the Architecture. Any thoughts on what we could build into the core design to make testing less of a chopping block victim?