eas ended up presenting the team with some of its greatest challenges.

responding update should be performed on state.

From a developer’s perspective, however, a program is never just a set of rules. There’s a control flow they create and have complete control over. A programmer will know exactly what’s to be executed first and what’s then supposed to follow according to the inputs received.

What’s fortuitous in our case is that we’re working from protocol specifications that are themselves sets of rules that let you know, for example, that if you’ve received message A, then you should update your abstract data model and your internal state in a certain way, after which you should issue message B. It doesn’t explain how a protocol flows from that point on. The combination of all those rules is what determines the actual behavior of the protocol. So there was often a direct correspondence between certain statements in each of these technical documents and the kinds of models we’ve had to build. That’s made it really easy to build the models, as well as to check to make sure they’ve been built correctly according to the statements found in the documents.

GRIESKAMP: Because this isn’t really all that complex, our greatest concern had to do with just getting people used to a new way of thinking. So to get testers past that initial challenge, we counted a lot on getting a good training program in place. That at first involved hiring people to provide the

nICo KICILLoF
Increasing the
interoperability
of our products
is a worthy goal
in and of itself.
We’re obviously
in a world of
heterogeneous
technology where
customers expect
products to
interoperate.

IllustratIon Base D on a Photogra Ph courtesy of nIco kIcIlllof

BInDER: How did you manage to convince yourselves you could take several hundred test developers who had virtually no experience in this area and teach them a fairly esoteric technique for translating words into rule systems?

GRIESKAMP: That really was the core risk in terms of taking the model-based testing approach. Until recently, model-based testing technology had been thought of as something that could be applied only by experts, even though it has been applied inside Microsoft for years in many different ways.

Many of the concerns about model-based testing have to do with the learning curve involved, which is admittedly a pretty steep one, but it’s not a particularly high one. That is, it’s a different paradigm that requires a real mental shift, but it’s not really all that complex. So it’s not as though it’s accessible only to engineers with advanced degrees—everybody can do it. But the first time you’re confronted with it, things do look a little unusual.

BInDER: Why is that? What are some of those key differences people have to get accustomed to?

KICILLoF: The basic difference is that a model actually consists of a rule system. So the models we build are made up of rules indicating that under some certain enabling condition, some cor-