>>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!).
>
>It is impossible, this has been demonstrated by IBM, and a few texts. Why set yourself up for failure from the start? Pick a reasonable number (IBM's study suggested 80%) and work toward that.

It is important to point out that, to aim for (say) 80% one has to know what contitutes 100%. Else your 80% can just as easily actually be far less!
Years ago IBM took major steps to simplify their product combinations in any line because the permutations and combinations they offered at the time (and my memory tells me it was 13 or possibly 15 individual parts for their mainframe OS) proved impossible to deliver WITH QUALITY (i.e. minimum failure rates).

>
>>2) Taking product-knowledgeable people and tasking them with identifying all of the permutations and combinations of conditions that can arise in the product.
>
>Why do you continually insist that this is possible, when nearly every text on testing software ever written insists that it is not? You cannot test for every condition in a non-trivial piece of software. You won't live that long. If someone thinks they've tested every condition in their software, they are deluding themselves. They may have tested the most common conditions, but not every one.

You (the VFP Team) chose to limit your supported platforms to Win2K and WinXP in the first place, leaving out Win98, Win98SE, WinME and WinNT. So I'd say you cut your test requirements below 80% right from the start!
I said at the outset that it is known to be impossible to test 100% of everything. But if you don't consciously list the whole 100% and then consciously decide which of those are to be excluded then how do you know what percentage has actually been tested???
VFP8 is extremely STABLE. But it must be noted that some of the bugs reported (not affecting "stability" of VFP) ought not to exist and it seems fair to conclude that there was something missing in the testing (planning and/or execution). This **can** suggest that when one starts out with the premise that 100% testing is impossible then 80% is really just some imaginary number determined by some artificial cut-off. I would have more sympathy for your premise if, for instance, you said that 100% testing for critical/important functionality and 80% for less important and 60% for trivial changes was the objective. You could even limit such detailed test requirements to the latest of MS' home and business OSes, with somewhat less acceptable for other older OSes.