harder to tackle but I’m not willing to say it can’t be done, either. In fact, I would really love it if it could be done.
DOYLE: That would take a lot of work off … we would love that.
PARTICIPANT: I think that you could use part of the model-based testing and combine it with the human factors, present these cases for review. Our difficulty is hammering the keyboard and getting it to a place where we can look at it again, that you could use this technique early on to identify cases that you want to take a look at and look at the human factors and the fuzzy concepts you identified.
GROVES: Let me make sure I’ve got it right … Does model-based testing integrate its own notions of complexity as priors on the model? So if you had a region of activity which was very complex … that could be subjected to more testing?
ROBINSON: It’s probably been done; we’ve never actually done that, but what we’ve done is that—as you make up the model—you suddenly begin to realize that all of the arrows go into one spot. Or there are way too many arrows coming out of one. So you look at it and say, “that’s untestable.” It would be wonderful to have some sort of complexity you could just run on the rest …
MCCABE: If I could add to that … I did a company’s research that built some stuff. At that time, there was a thing called “data flow diagrams” (DFDs), and I developed some mathematics that could develop a test based on those diagrams. And the beauty of that is the requirements specification and the test specification were the same. So what would happen is that the agencies would develop DFDs as a specification, and we would derive a test based on that. Now the interesting thing is that if you [take a walk through the program and compare with] the DFDs, about 30 percent of them are off because they’ve never been tested. Because the DFD can lead you to places, and it never went there. And the way you’d find that out is that you derive the test, and you find things—for example—in the DFD like sections you can’t get into…. So we did that for a couple of years, published some things. Now there’s another set of work related to that, and that’s called “work flow testing,” developed by Musa at Bell Labs and used there and other places. It’s very much like what Harry’s talking about in that it adds what are called “characteristic nodes.” So you can take the clock, for example, and it might have a lot of usage scenarios, but it might be that scenarios one and two are used 90 percent of the time. So out of that [you can get a sort of stress test.]
But … the fundamental idea is to test up front, whatever the medium is, and to build the requirements in.
DOYLE: The diagram you gave; is that some kind of software that could be run on our instruments, to see how complex it is? Highly