>>Everything has a much higher chance of being caught if (non-comprehensive list):
>>1) Setting an objective to test 100% of the code and earnestly working toward it even in the knowledge that 'it is impossible' (because it surely WILL be impossible if one starts out with that premise!).
>>2) Taking product-knowledgeable people and tasking them with identifying all of the permutations and combinations of conditions that can arise in the product.
>
>I'm curious if you could expand on your proposal here. How many software development projects have you managed and tested with this methodoloy, and how do they relate in scope to the VFP product?

I've been involved in a few projects, Mike, where roughly what's described is what was done in the QA phase.
In those cases I'll admit that the starting point was a canned set of test scripts that 'proved' the overall product (untouched portions) and the new detailed test cases were limited to those parts of the system that had been changed and those components that had direct interaction with the changed parts.
It is also true that NOT all negative outcomes were resolved prior to implementation but all known problems from QA were fixed before we left the site several months later.

These were all for custom application systems, but the principles are the same. And I would hazard that MS has tools and equipment for testing that we can only dream of.

By the way, I've said, and repeat, that overall the VFP Team has done a bang-up (that means great) job on VFP8. It IS stable and it does perform well overall. The point of my message was to refute CraigB's non-sequitur.