I would agree, Peter, but you have to understand that I am constrained in what facts I can present. I cannot, by contract, list bugs or bug counts - and I wouldn't anyway ethically - but I can provide generalities.

In general: We had a lot more tools and techniques for VFP 9 to find bugs and we used them arduously. Since VFP 3, the tools and procedures used to find VFP bugs have grown dramatically - furthermore, the ability to create regression tests to ensure that squashed bugs stay squashed has grown and the test suite has grown commensurately.

Unless we're talking about completely new features, code coverage on existing features is pretty extensive.

And for VFP 9: Major parts (report engine, SQL) of VFP were overhauled...the trade-off was - as always - risk between new functionality and breaking existing code. I have to admit that we rolled the dice. With our limited budget and resources, we assumed risks.

But what were we supposed to do? I was under intense pressure to cut features and as a long-time VFP developer I didn't want to do that. I revamped our testing process many times to try to achieve an optimal testing environment.

I believe we achieved the best that could be done under the circumstances. VFP9 is doggone stable. That it is iffey with a dot-matrix printer is regretable but would testing for that been worth taking resources away from other critical improvements? I think not.


>>Yeah, Jess.....it does annoy me :-)
>
>But John, rather than stating it indeed annoys you, you'd better take some time to comment with facts and arguments. Jess has only been argumenting and you shouldn't be annoyed by that. Arguments and facts are a far better service to us all here: it makes things clearer. Your arguments are of importance to us. We appreciate them.