SOFTWARE

TESTING
(STATE TRANSITION
TESTING)
Engr. Sajid Saleem
 OUTLINE
 State Transition Diagram
 Notations

 Scenario based Explanation

 State Transition Table
 Types of Test cases
 Test Cases based on STT
 Applicability and Limitation
 Examples
 Manage Display Changes
 ATM
 Bidding 2
STATE TRANSITION DIAGRAM
 State-Transition diagrams, like decision tables, are another excellent tool to capture
certain types of system requirements and to document internal system design.

 These diagrams document the events that come into and are processed by a system as
well as the system’s responses.

 Unlike decision tables, they specify very little in terms of processing rules.

 State-transition diagrams are excellent tools to record the information of when a system
must remember something about:
 what has happened before or
 when valid and invalid orders of operations exist
STATE TRANSITION DIAGRAM
(NOTATION)
 This notation was created by Mealy. An alternate notation has been defined by Moore but is less
frequently used.

1. State (represented by a circle)—A state is a condition in which a system is waiting for one or more
events. States "remember" inputs the system has received in the past and define how the system should
respond to subsequent events when they occur. These events may cause state-transitions and/or initiate
actions.
 The state is generally represented by the values of one or more variables within a system.

2. Transition (represented by an arrow)—A transition represents a change from one state to another
caused by an event.
3. Event (represented by a label on a transition)—An event is something that causes the system to change
state. Generally, it is an event in the outside world that enters the system through its interface.
Sometimes it is generated within the system such as Timer expires or Quantity on Hand goes below
Reorder Point.
 Events are considered to be instantaneous. Events can be independent or causally related (event B cannot
take place before event A).
 When an event occurs, the system can change state or remain in the same state and/or execute an action.
 Events may have parameters associated with them. For example, Pay Money may indicate Cash, Check,
Debit Card, or Credit Card.
STATE TRANSITION DIAGRAM
(NOTATION)
4. Action (represented by a command following a "/")—An action is an operation initiated because of a state
change. It could be print a Ticket, display a Screen, turn on a Motor, etc. Often these actions cause something to
be created that are outputs of the system.
 Note that actions occur on transitions between states. The states themselves are passive.

5. The entry point on the diagram is shown by a black dot while the exit point is shown by a bulls-eye symbol.
SCENARIO FOR
ILLUSTRATION
 To get to Stateless U, we need an airline reservation. Let's call our favorite carrier (Grace L. Ferguson Airline &
Storm Door Company) to make a reservation.
 We provide some information including departure and destination cities, dates, and times.

 A reservation agent, acting as our interface to the airline's reservation system, uses that information to make a
reservation.
 At that point, the Reservation is in the Made state. In addition, the system creates and starts a timer.

 Each reservation has certain rules about when the reservation must be paid for.

 These rules are based on destination, class of service, dates, etc.

 If this timer expires before the reservation is paid for, the reservation is cancelled by the system.
• The circle represents one state of the Reservation
—in this case the Made state.

• The arrow shows the transition into the Made

state.

• The description on the arrow, giveInfo, is an

event that comes into the system from the
outside world.

• The command after the "/" denotes an action of

the system; in this case startPayTimer.

• The black dot indicates the starting point of the

diagram.
• Sometime after the Reservation is made,
but (hopefully) before the PayTimer
expires, the Reservation is paid for.

• This is represented by the arrow labeled

PayMoney.

• When the Reservation is paid it transitions

from the Made state to the Paid state.
• From the Paid state the Reservation
transitions to the Ticketed state when
the print command (an event) is
issued.

• Note that in addition to entering the

Ticketed state, a Ticket is output by
the system.
• From the Ticketed state we
giveTicket to the gate agent to
board the plane.
• After some other action or period
of time, not indicated on this
diagram, the state-transition path
ends at the bulls-eye symbol.

• Does this diagram show all the

possible states, events, and
transitions in the life of a
Reservation?
• If the Reservation is not paid for
in the time allotted (the
PayTimer expires), it is
cancelled for non-payment.
• Customers sometimes cancel
their reservations.

• From the Made state the

customer (through the
reservation agent) asks to
cancel the Reservation.

• A new state, Cancelled By

Customer, is required.
• In addition, a Reservation can be
cancelled from the Paid state.

• In this case a Refund should be

generated and leave the system.

• The resulting state again is

Cancelled By Customer.
• One final addition. From the Ticketed state
the customer can cancel the Reservation.

• In that case a Refund should be generated

and the next state should be Cancelled by
Customer.

• But this is not sufficient. The airline will

generate a refund but only when it receives
the printed Ticket from the customer.

• This introduces one new notational element

—square brackets [] that contain a
conditional that can be evaluated either
True or False.

• This conditional acts as a guard allowing

the transition only if the condition is true.
 Note that the diagram is still incomplete.

 No arrows and bulls-eyes emerge from the Cancelled states.

 Perhaps we could reinstate a reservation from the Cancelled NonPay state.

 We could continue expanding the diagram to include seat selection, flight

cancellation, and other significant events affecting the reservation but this is
sufficient to illustrate the technique.
CAUTION
 Note that the state-transition diagram represents one specific entity (in this case a
Reservation).

 It describes the states of a reservation, the events that affect the reservation, the
transitions of the reservation from one state to another, and actions that are
initiated by the reservation.

 A common mistake is to mix different entities into one state-transition diagram.

 An example might be mixing Reservation and Passenger with events and actions
corresponding to each.
STATE TRANSITION TABLES
 A state-transition diagram is not the only way to document system behavior.

 The diagrams may be easier to comprehend, but state-transition tables may

be easier to use in a complete and systematic manner.

 State-transition tables consist of four columns:

 Current State
 Event
 Action
 Next State.
 Table 7-1: State-Transition table for Reservation.
Current State Event Action Next State
null giveInfo startPayTimer Made
null payMoney -- null
null print -- null
null giveTicket -- null
null cancel -- null
null PayTimerExpires -- null

Made giveInfo -- Made

Made payMoney -- Paid
Made print -- Made
Made giveTicket -- Made
Made cancel -- Can-Cust
Made PayTimerExpires -- Can-NonPay
 Table 7-1: State-Transition table for Reservation.
Current State Event Action Next State
Paid giveInfo -- Paid
Paid payMoney -- Paid
Paid print Ticket Ticketed
Paid giveTicket -- Paid
Paid cancel Refund Can-Cust
Paid PayTimerExpires -- Paid

Ticketed giveInfo -- Ticketed

Ticketed payMoney -- Ticketed
Ticketed print -- Ticketed
Ticketed giveTicket -- Used
Ticketed cancel Refund Can-Cust
Ticketed PayTimerExpires -- Ticketed
 Table 7-1: State-Transition table for Reservation.
Current State Event Action Next State
Used giveInfo -- Used
Used payMoney -- Used
Used print -- Used
Used giveTicket -- Used
Used cancel -- Used
Used PayTimerExpires -- Used

Can-NonPay giveInfo -- Can-NonPay

Can-NonPay payMoney -- Can-NonPay
Can-NonPay print -- Can-NonPay
Can-NonPay giveTicket -- Can-NonPay
Can-NonPay cancel -- Can-NonPay
Can-NonPay PayTimerExpires -- Can-NonPay
 Table 7-1: State-Transition table for Reservation.
Current State Event Action Next State
Can-Cust givelnfo -- Can-Cust
Can-Cust payMoney -- Can-Cust
Can-Cust print -- Can-Cust
Can-Cust giveTicket -- Can-Cust
Can-Cust cancel -- Can-Cust
Can-Cust PayTimerExpires -- Can-Cust
STATE TRANSITION TABLES
 Using a state-transition table can help detect defects in implementation that enable invalid paths
from one state to another.

 The disadvantage of such tables is that they become very large very quickly as the number of
states and events increases.

 In addition, the tables are generally sparse; that is, most of the cells are empty.
CREATING TEST CASES
 Information in the state-transition diagrams can easily be used to create test cases.
Four different levels of coverage can be defined:
1. Create a set of test cases such that all states are "visited" at least once under test.
2. Create a set of test cases such that all events are triggered at least once under test.
3. Create a set of test cases such that all paths are executed at least once under test.
4. Create a set of test cases such that all transitions are exercised at least once under test.
CREATING TEST CASES: (ALL
STATES)
 Create a set of test cases such that all states are "visited" at least once under test.

 The set of three test cases shown below meets this requirement.

 Generally this is a weak level of test coverage.

CREATING TEST CASES: (ALL
EVENTS)
 Create a set of test cases such that all events are triggered at least once under test.

 Note that the test cases that cover each event can be the same as those that cover each state.

 Again, this is a weak level of coverage.

CREATING TEST CASES: (ALL
PATHS)
 Create a set of test cases such that all paths are executed at least once
under test.
 While this level is the most preferred because of its level of coverage, it
may not be feasible.
 If the state-transition diagram has loops, then the number of possible paths
may be infinite.
 For example, given a system with two states, A and B, where A transitions to B
and B transitions to A. A few of the possible paths are:
 A→B
 A→B→A
 A→B→A→B→A→B
 A→B→A→B→A→B→A A→B→A→B→A→B→A→B→A→B
 ... and so on forever.

 Testing of loops such as this can be important if they may result in

accumulating computational errors or resource loss (locks without
corresponding releases, memory leaks, etc.)
CREATING TEST CASES: (ALL
TRANSITIONS)
 Create a set of test cases such that all transitions are exercised at least once under test.

 This level of testing provides a good level of coverage without generating large numbers of
tests.
 This level is generally the one recommended.
 Test cases can also be read directly from the Current State Event Action Next State
state-transition table.
null giveInfo startPayTimer Made
 The selected rows in the following table
Made payMoney -- Paid
shows all the valid transitions.
Made cancel -- Can-Cust
Made PayTimerExpires -- Can-NonPay
Paid print Ticket Ticketed
Paid cancel Refund Can-Cust

Ticketed giveTicket -- Used

Ticketed cancel Refund Can-Cust

 In addition, depending on the system risk, you may want to

create test cases for some or all of the invalid state/event
pairs to make sure the system has not implemented invalid
paths.
TEST CASES BASED ON STATE
TRANSITION TABLE
ID Description Input Expected Output Actual Output Status

TC-1 Information Given (Null) Starting State (Made) Made State Made State Pass

TC-2 Payment made (Made) Payment made (Paid) Paid State Paid State Pass
TC-3 Payment (Made) Payment (Can-Cust) Cancelled by Cancelled by Pass
Cancelled cancelled Customer state Customer state
TC-4 Payment Timeout (Made) Payment Timer (Can-NonPay) Cancelled Cancelled by Non Pass
Expired by Non payment state payment state
TC-5 Print the ticket (Paid) Print the ticket (Ticketed) Ticketed state Ticketed state pass
TC-6 Payment Refund (Paid) Cancel for Refund (Can-Cust) Cancelled by Cancelled by Pass
Customer state Customer state
TC-7 Cancel Ticket (Ticketed) Ticketed (Can-Cust) Cancelled by Cancelled by Pass
and Refund Customer state Customer state
TC-8 Using the Ticket (Ticketed) Ticketed (Used) Used State Used State Pass
APPLICABILITY AND
LIMITATIONS
 State-Transition diagrams are excellent tools to capture certain system requirements, namely
those that describe states and their associated transitions.
 These diagrams then can be used to direct our testing efforts by identifying the states, events,
and transitions that should be tested.
 State-Transition diagrams are not applicable when the system has no state or does not need to
respond to real-time events from outside of the system.
 An example is a payroll program that reads an employee's time record, computes pay, subtracts
deductions, saves the record, prints a paycheck, and repeats the process.
EXPLAIN IT IN YOUR WORDS
– ACTIVITY 1
 Software name – Manage_display_changes
Specifications – The software responds to input requests to change display mode for a time
display device.
 The Display mode can be set to one of the four values:
• Two corresponding to displaying either the time or date.
• The other two when altering either the time or the date.

 The different states are as follows:

• Change Mode (CM): Activation of this shall cause the display mode to move between “display time
(T)” and “display date (D)”.
• Reset (R): If the display mode is set to T or D, then a “reset” shall cause the display mode to be set to
“alter time (AT)” or “alter date (AD)” modes.
• Time Set (TS): Activation of this shall cause the display mode to return to T from AT.
• Date Set (DS): Activation of this shall cause the display mode to return to D from AD.

https://www.softwaretestinghelp.com/state-transition-testing-technique-for-testing-complex-applications/
EXPLAIN IT IN YOUR WORDS –
ACTIVITY 1
Reset
(
Changing time / Displaying Alter R) /
M) Date
(S3) (C date (S2) (AD)
Time
S ode D)
Displ et (TS) / an g
e M
ate
(
ay Ti Ch lay D
me (T p
) Dis

/ Dat
a
(CM) Disp Set (D
Displaying S Changing date
Reset
(R Mode (T) l ay
Da t ) /
Alter T ) / time (S1)
an g
e
i me
e (D
)
(S4)
ime (A
T) Ch lay T
p
Dis

/ Event
/ Action
EXPLAIN IT IN YOUR WORDS
– ACTIVITY 2
 Let’s consider an ATM system function where if the user enters the invalid password three
times the account will be locked.
 In this system, if the user enters a valid password in any of the first three attempts the user
will be logged in successfully. If the user enters the invalid password in the first or second
try, the user will be asked to re-enter the password. And finally, if the user enters incorrect
password 3rd time, the account will be blocked.
 EXPLAIN IT IN YOUR WORDS
– ACTIVITY 2
En
ter
Pi

Incorrect Pin / Incorrect Pin /

n

Enter Pin Enter Pin

Current Event Action Next
State State
1st try 2nd try 3rd try Start Enter Pin ----- 1st Try
1st Try Incorrect Pin Enter Pin 2nd Try
1st Try Correct Pin ----- Access
Correct

Incorrect Pin
Co
Granted

Co
rre

r
2nd Try Incorrect Pin Enter Pin 3rd Try

r
ct

ect
Pi
Pi

P
n

in
2nd Try Correct Pin ----- Access
Granted
3rd Try Incorrect Pin ----- Account
Blocked
Access Access
granted 3rd Try Correct Pin ----- Access
blocked Granted
EXPLAIN IT IN YOUR WORDS
– ACTIVITY 3Current State
null
Event
--
Action
startBidTimer
Next State
Listed
Listed bid -- Active
Listed BidTimer expired Start Delete Ignored
Timer
Ignored relist Start Bid Timer Listed
Ignored DeleteTimer Delete Item null
Expired
Active bid -- Active

Active BidTimerExpired Start Delete Sold

Time / notify
Buyer / notify
seller
Sold Delete Timer Delete Item null
Expired
THANK YOU