Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!ai-lab!rice-chex!bson From: bson@rice-chex.ai.mit.edu (Jan Brittenson) Newsgroups: comp.sys.handhelds Subject: Re: Re: The mythical bug-free code Keywords: hp48 Message-ID: <13218@life.ai.mit.edu> Date: 7 Feb 91 04:04:17 GMT References: <27af59f6:1922.2comp.sys.handhel <27b07042:1922.3comp.sys.handhelds;1@hpcvbbs.UUCP> Sender: news@ai.mit.edu Organization: nil Lines: 48 In a posting of [6 Feb 91 21:40:10 GMT] akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) writes: > Derek brings up a good point, HP could have inverted all the possible > matrices, and it would have taken a hell of a while longer. Along > this line, can you imagine if the testers tried every single HP > command on every possible combination of object type, and for every > situation of system flags, This is almost trivial. It's called a test suite. A limited test suite, i.e. a test suite that only exercises a couple of standard parameters spread out over a conceivable range, as well as some extreme cases to test the robustness of the code, would for sure have caught the matrix inversion bug. Probably the zero-size kermit transfer one, too. Bill Wickes mentioned the former was partly a result of human error (if I remember correctly). I take this to mean that something wasn't put into the test suite that should have been there. You don't have to test every function for every possible system flag setting - only for those that actually affect the behaviour. The reasons for this kind of test suites are fairly obvious: when you fix something broken, you will know when something else breaks in the process. > what happens if you press the on key right after another key, and if > you transfer 0 byte programs, etc., We can only guess how this is tested... My guess is that the development system allows a work station to exercise the calculator by doing serial I/O, pressing keys, etc. This is difficult, though, and much testing always has to be done manually to verify any interactive system. I'm sure HP compared the costs of replacing units which people had found defective to what longer testing would cost in terms of lost market shares, lost revenues and increased development costs. I'm sure HP, with plenty of "prestige margin," considered the rev A units ready for shipping. This doesn't mean I think it's wrong to ask HP to fix your calculator if it doesn't work properly. In fact, the archive/clock bug pisses the hell out of me, and I will ship my rev D calculator to HP as soon as I can live without it for a week or two. -- Jan Brittenson bson@ai.mit.edu