Good State Graphs and Bad

 What constitutes a good or a bad state graph is to some

extent biased by the kinds of state graphs that are likely to
be used in a software test design context.
 Here are some principles for judging.
– The total number of states is equal to the product of the
possibilities of factors that make up the state.
– For every state and input there is exactly one transition
specified to exactly one, possibly the same, state.
– For every transition there is one output action specified.
The output could be trivial, but at least one output does
something sensible.
– For every state there is a sequence of inputs that will
drive the system back to the same state.
Improper State Graphs
 State Bugs-Number of States
 The number of states in a state graph is the number of states
we choose to recognize or model.
 The state is directly or indirectly recorded as a combination of
values of variables that appear in the data base.
 For example, the state could be composed of the value of a
counter whose possible values ranged from 0 to 9, combined
with the setting of two bit flags, leading to a total of
2*2*10=40 states.
 The number of states can be computed as follows:
– Identify all the component factors of the state.
– Identify all the allowable values for each factor.
– The number of states is the product of the
number of allowable values of all the factors.
 State Bugs-Number of States

• Before you do anything else, before you consider one

test case, discuss the number of states you think there
are with the number of states the programmer thinks
there are.
• There is no point in designing tests intended to check the
system’s behavior in various states if there’s no
agreement on how many states there are.
 Impossible States
• Some times some combinations of factors may appear to
be impossible.
• The discrepancy between the programmer’s state count
and the tester’s state count is often due to a difference of
opinion concerning “impossible states”.
• A robust piece of software will not ignore impossible
states but will recognize them and invoke an illogical
condition handler when they appear to have occurred.
 Equivalent States
• Two states are Equivalent if every sequence of inputs
starting from one state produces exactly the same
sequence of outputs when started from the other state.
This notion can also be extended to set of states.
 Recognizing Equivalent States

• Equivalent states can be recognized by the following

procedures:
• The rows corresponding to the two states are identical
with respect to input/output/next state but the name of
the next state could differ.
• There are two sets of rows which, except for the state
names, have identical state graphs with respect to
transitions and outputs. The two sets can be merged.
 Transition Bugs unspecified and
contradictory Transitions
• Every input-state combination must have a specified
transition.
• If the transition is impossible, then there must be a
mechanism that prevents the input from occurring in
that state.
• Exactly one transition must be specified for every
combination of input and state.
• A program can’t have contradictions or ambiguities.
• Ambiguities are impossible because the program will
do something for every input. Even the state does not
change, by definition this is a transition to the same
state.
 Unreachable States
• An unreachable state is like unreachable code.
• A state that no input sequence can reach.
• An unreachable state is not impossible, just as
unreachable code is not impossible
• There may be transitions from unreachable state to other
states; there usually because the state became
unreachable as a result of incorrect transition.
• There are two possibilities for unreachable states:
– There is a bug; that is some transitions are missing.
– The transitions are there, but you don’t know about it.
 Dead States

• A dead state is a state that once entered cannot be left.

• This is not necessarily a bug but it is suspicious.
 Output Errors

• The states, transitions, and the inputs could be correct,

there could be no dead or unreachable states, but the
output for the transition could be incorrect.
• Output actions must be verified independently of states
and transitions.
 State Testing- Impact of Bugs
• If a routine is specified as a state graph that has been verified
as correct in all details. Program code or table or a
combination of both must still be implemented.
• A bug can manifest itself as one of the following symptoms:
 Wrong number of states.
 Wrong transitions for a given state-input combination.
 Wrong output for a given transition.
 Pairs of states or sets of states that are inadvertently made
equivalent.
 States or set of states that are split to create
inequivalent duplicates.
 States or sets of states that have become dead.
 States or sets of states that have become unreachable.
 Principles of State Testing

• The strategy for state testing is analogous to that used

for path testing flow graphs.
• Just as it’s impractical to go through every possible path
in a flow graph, it’s impractical to go through every path
in a state graph.
• The notion of coverage is identical to that used for flow
graphs.
• Even though more state testing is done as a single case in
a grand tour, it’s impractical to do it that way for several
reasons.
 Principles of State Testing (Conti..)

• In the early phases of testing, you will never complete

the grand tour because of bugs.
• Later, in maintenance, testing objectives are understood,
and only a few of the states and transitions have to be
tested. A grand tour is waste of time.
• Theirs is no much history in a long test sequence and so
much has happened that verification is difficult.
 Starting point of state testing

• Define a set of covering input sequences that get back to

the initial state when starting from the initial state.
• For each step in each input sequence, define the
expected next state, the expected transition, and the
expected output code.
– A set of tests, then, consists of three sets of
sequences:
1. Input sequences
2. Corresponding transitions or next-state names
3. Output sequences
 Limitations and Extensions

• State transition coverage in a state graph model does not

guarantee complete testing.
• How defines a hierarchy of paths and methods
for combining paths to produce covers of state graphs.
• The simplest is called a “0 switch” which corresponds to
testing each transition individually.
• The next level consists of testing transitions
sequences consisting of two transitions called “1
switches”.
• The maximum length switch is “n-1 switch” where there
are n number of states.
 situations at which state testing is useful
• Any processing where the output is based on the occurrence
of one or more sequences of events, such as detection of
specified input sequences, sequential format validation,
parsing, and other situations in which the order of inputs is
important.
• Most protocols between systems, between humans and
machines, between components of a system.
• Device such as for tapes and discs that
complicated
drivers retry and recovery procedures if
depends on the state. have the
• Whenever a feature is directly and explicitly implemented as
one or more state transition tables. action
 TESTABILITY TIPS

1. A Balm for Programmers

The key to testability design is easy: build explicit
finite-state machines.
2. How Big, How Small?
There are about eighty possible good and bad
three-state machines, 2700 four-state machines,
275,000 five-state machines, and close to 100 million
six-state machines, most of which are bad