From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "Robert I. Eachus" Subject: Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) Date: 2000/08/04 Message-ID: <398A07DB.FD66D092@earthlink.net>#1/1 X-Deja-AN: 654232632 Content-Transfer-Encoding: 7bit References: <8ipvnj$inc$1@wanadoo.fr> <39654639.B3760EF2@eiffel.com> <3984AD1D.830B538@below.for.email.address> <3984DC2D.C707824@swbell.net> <3985F031.B4862B40@below.for.email.address> <39860178.3EC77DC9@below.for.email.address> X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 965347239 63.24.57.193 (Thu, 03 Aug 2000 17:00:39 PDT) Organization: The MITRE Corporation MIME-Version: 1.0 NNTP-Posting-Date: Thu, 03 Aug 2000 17:00:39 PDT Newsgroups: comp.lang.ada Date: 2000-08-04T00:00:00+00:00 List-Id: Simon Brady wrote: > Now that I think about it, it's wimpy to say "potentially" here. > Software quality isn't just about lack of bugs, it's about _confidence_ > that there's a lack of bugs. So if they cut testing (and hence lowered > their confidence in the software), I would argue that they're still > delivering a lower-quality product even if it happened to be bug-free. > Of course, some might say such a purist approach is commercially naive, > but then that's why I'm not a commercial programmer :-) There is a very subtle, but insidious fallacy in the above. Not to do ANY testing is quite likely to result in catastrophic failure. On the other hand, testing should always be one part, and often not the largest part, of a well planned quality assurance program. In fact, on a well managed project, anything found at preliminary design review time to be potentially difficult or impossible to test should be flagged for further design effort in an attempt to reduce overall cost. Sometimes you need to do those 'expensive' tests, that would have been cheap at almost any price on Ariane 5. But if you can change the design to make testing easier without impacting other requirements, do so. For another example, it is costly to create a thread level model of control flow in a large system. But if it is necessary to do so, often for timing analysis reasons, the model can also be used to do other analysis of project software. (Of course, this requires that the model be kept up to date during development.) On one project where this was done, it was determined that there was a race condition that could transition the system to a subset of states that could not be left. (This was done using hierarchical colored Petri nets.) Fixing this bug, which could have remained undiscovered for the life of the system, let alone througout testing, was trivial. Of course, if it had been discovered in a fielded system, it would probably have caused a plane to crash during landing. No amount of testing could have produced that level of trust in the software, even if it had resulted in the discovery of that bug.