>>Your point (a) is basically a philosophical one (is there a place for ROI in software QUALITY (accuracy)) and I simply cannot agree that ROI has any place in this (testing).
>
>Your argument would then have to assume that a project has unlimited budget. Most projects do not.

No, that's taking the easy cavalier way out.
Applications don't just 'happen'. They are ROIed before a line is ever written. Now you can't do a ROI (at least not a meaningful one) if you don't know exactly what you want to do.
Once you've got that in hand then each 'phase' of development can be assessed for its staff/time/resources costs and if the return is there then the project proceeds.

Each 'phase' is (relatively) well known as relates factors affecting costs. This is because of standards and prior observations and known competency levels, etc. (that assist with estimation accuracy). Now you can't get by with only 90% system design or 90% detail design or 90% coding and I contend that it is a fallacy to expect that it is OK to plan for only 90% testing [if the developer tests to only 90% and the system testers go to only 90% and the QA folks go to only 90% then you have less than 75% tested when all is said and done]

I agree that projects usually 'slip' and that because testing is at the end of the cycle, yet the pressure remains to SHIP ON DATE GIVEN, testing can suffer and usually does.
But that is a whole different thing than conceding at the start that testing only needs to be to the 75% level. That is definitely NOT the way to plan anything! Hell, if the project DID slip AND you had already set the cutoff at 90% testing (which really means less than 75% testing) then what would be your actual percentage tested??? - it could be anywhere from 0% to, say 20-40%!!!

Of course management always reserves the right to decide when 'enough' testing has been done. But I don't think many managers would be happy to be fooled by each test level saying that they'd done 100% of their testing (or 80% or 60% or whatever) when in fact that 100% was intrinsically based on 90% (or some lesser number than 100%) in the first place!


>
>> It is the beginning of a slippery slope where even worse trade-offs will undoubtedly be made. I imagine the day that processor makers, HD makers, NIC makers, printer makers, etc. adopt the same approach and the "fun" that will then ensue.
>
>Those trade-offs are already being made, or else we wouldn't have bugs in processors, HDs (witness the recent Fujitsu fiasco), and printer drivers. Obviously someone didn't test every scenario. That's because in the world of finite budgets and ship dates, it has to go out the door at some point.

Again I think you over-simplify (which, by the way, is the favoured technique to justify decisions that turn out to be bad).
You make no allowance for problems (UNINTENTIONAL errors and omissions) in test hardware/software/procedures/analysis) that may exist in the testing processes. It is certainly such that I would attribute to processor bugs and likely to HD bugs too. Probably NIC and other hardware too. I am confident that your Intels and your Maxtors and such amend their testing processes when such things come to light.
I certainly concede that DRIVERS are a problem but I really have to ask myself how much of the driver crap that happens is due to PLANNED short-testing. I suspect that these problems happen much earlier in the process and likely have some direct relationship to clarity of OS documentation setting requirements, misinterpretation of such documentation, competency of (software) design staffs and coding staffs and the absence of testing procedures for all conditions required. The question is, is this all happening by management planning or is it happening because of incompetence. I've gotta believe at least as much of the latter as the former, and probably much more.
>
>>Your point (b) I simply don't understand. Code that 'cannot be reached' CAN BE REMOVED without consequence.
>
>You sure about that? Are you 100% sure you've proven the negative statement that "the code cannot be reached"?

First, I only used the phrase that you used. Secondly, if I couldn't prove that some code could not be reached, then it would have to stay in. I guess you mean to suggest that one cannot prove a negative. I don't think that's applicable in the case stated (I *can* prove that the earth is not square and I *can* prove that a person cannot walk around the earth on the equator line).