Skip to main content

Currently Skimming:

Quality Right from the Start: The Methodology of Building Testing into the Product
Pages 153-163

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 153...
... OIL, thanks. QUALITY RIGHT FROM THE START: THE METHODOLOGY OF BUILDING TESTING INTO THE PRODUCT Robert Smith CORIC: The next speaker that we have is Robert Smith, who's currently a visiting scholar with the Hoover Institute at Stanford.
From page 154...
... What I want to do is to give a case study of work done at Computer Curriculum Corporation, to talk about particular testing challenges and solutions there, and to see if I can malce the relevant CAI-to-interactivesurveys connection. And since writing this slide I've realized that CAI has two meanings here there's "computer assisted instruction" which is where I'm coming from and there's "computer aided .
From page 155...
... You wouldn't think it would be, but that presents at a very micro level, that creates some problems, and those are probably amenable to some of the techniques Mr. McCabe suggested because they tend to use discrete little pieces of code.
From page 156...
... We did a lot of code reviews, and we did lots of design reviews of a particular part. We did white box testing with rooms full of people, we did black box testing, and so on.
From page 157...
... Robinson; I've never had a whit of luck with these little automated test tools that, you lcnow, save your screen, save your mouse clicks and your lceystrolces and then run them back. It might be OIL for regression testing, but every time we've tried to use them yol1 find that they break right away, and usually it's because something lilac you added a menu item and now the mouse only moves down 3 inches when it should have been 4, and whatever doesn't work.
From page 158...
... This part being done by the individual authors of the individual modules, expressing their sort of a priori opinions. And then the exercise, this is typically written in the underlying implementation language, C+ +, say, but it would be handled similarly by different people.
From page 159...
... And then some other things these are just less interesting things. Of course, we had source control defect tracking, QA procedures designed for fast turnaround, smolce tests, and all that.
From page 160...
... What I would suggest is that you see if you could do this, and start with the CASES product just as a methodological suggestion and add some statements to that language that would allow you to say, at each choice point and each error/consistency point and back-up condition, what you're expecting. And see if you can build some automated testing around that, if you haven't already done that.
From page 161...
... I would give you a possible suggestion there; I would say that something that was XML-based, for example, but that could output CASES as its object output so that you could use all your same deployment systems, but would show you various views including texts, graphs, flowcharts, and so on, and would impose the authoring environment impose conditions on the authoring process. SO, for example, you require that there be test conditions.
From page 162...
... , but the place I've seen it apply is when an organization puts the product out in, maybe, four or five sites simultaneously. While testing the product, you know where that error is; you lcnow where some null errors are.
From page 163...
... McCABE: One thin" we didn't talk about that we ought to comment on is relative cost of testing software versus surveys. In software, it's quite high; in software, it's often, in the total budget, maybe 60 percent.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.