>>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.
>
>>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.

Mike,

I think that part of the problem may be this. As a programmer, I've been taught that "proofs" are part and parcel of my job. Where an infinite number of possibilities exists for an algorithm, we use proof by mathematical induction to prove or disprove the correctness of the algorithm.

A complex piece of software, however, cannot be proven by this methodolgy, especially when the software is reliant on the external environment, in this case Windows. You may have individually proven every algorithm, but interaction between algorithms and the event driven OS introduces more possibilities than can be reasonably proven.

Further, because of the interaction between the application an the OS, there may be bugs that cannot be fixed by, say, the Fox Team.

Here's an example of a bug with a VFP function that you guys can't fix. I haven't tested this on XP yet, but this is replicatable on versions of Windows up to 2K SP3.

Use LOADPICTURE() to get a reference to a 16x16 16 color icon. Next use SAVEPICTURE() to save it out under a different file name. If you look at the properties of the two files, you'll find that the newly created file is 128 bytes larger than the original. Further, it cannot be opened by something like ImagEdit.exe.

Now I realize that the docs for SAVEPICTURE() indicate that you can only save it in bitmap form. LOADPICTURE(), however, indicates that you can load an icon, and SAVEPICTURE() does work correctly with other icon formats.

As you know, this isn't a problem that you folks can fix. It's a problem with the underlying API call (OleSavePictureFile()).

BTW, I mentioned this to John Koziol.:-)