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-