TRANSACTION FLOW TESTING

 Transaction flows are introduced as a representation of a

system’s processing.
 Transaction Flow testing are to the independent system tester
what control flow were to the programmer
 Control Flow graph- Structural model
 Transactional Flow graph - Model of the structure of the
system’s behavior .
SOME BASICS OF TRANSACTION FLOW

 Transaction
 Usage
 Implementation
 Perspective
TRANSACTION

 UNIT OF WORK SEEN FROM SYSTEM USER’S VIEW POINT

 Sequence of operations, some of which are performed by a
system, persons, or devices that are outside of the system.
 Begin with BIRTH i.e. they are created as a result of some
external act.
AN EXAMPLE- Online Information Retrieval System

 Access Input ( Tentative Birth)

 Validate Input (Birth)
 Transmit acknowledgement to requester
 Do Input processing
 Search File
 Request directions from the user
 Accept Input
 Validate Input
 Process request
 Update file
 Transmit output
 Record transaction in log and cleanup ( Death)
 User viewpoint- Single Transaction; System viewpoint – 12
steps and ten subsidiary tasks
OVERVIEW: Online Information Retrieval System

 PC - Terminal controller for several dumb terminals

 Terminals- used to process forms
 User specifies the desired action, and terminal controller
requests the appropriate form from a remote central computer.
 Forms- Several pages long, contains multiple fields.
 Compressed version of form is then transmitted by the central
computer to minimize comm. line usage.
 Form is translated by the terminal control PC to be displayed by
dumb terminal.
 Terminal control only transmits the answers (contents of the
blanks) back to the central computer
 As each page of the Form is filled out, terminal controller
transmits the answers to the central computer, which either
accepts or rejects them. If the answers are invalid, a diagnostic
code is transmitted by the central computer to the terminal
controller, which in turn translates the code and informs the user
at the terminal. Finally, the system allows the user to review the
filled out form.
 Online Information Retrieval System
CANCEL

P1 P2 P3 P4
RE-ORDER
ACCEPT
USER D1 REQUEST ORDER PROCESS
A WAIT ORDER FROM B
START TYPE 1 FROM THE CPU FORM
THE CPU

D2 YES
P5 P6 P7 P8
TRANSMIT NO
B PAGE TO C ACCEPT FIELD ANY MORE
WAIT TRANSMIT
TERMINAL INPUT FIELDS D
ANSWERS TO CPU

P9 P10 D3

WAIT FOR YES NO NO

USER
D ACCEPT CPU MORE
CPU TO VALID ? WANTS EXIT
CONFIRM PAGES ?
CONFIRM REVIEW ?

P12
NO TRANSMIT
DIAGNOSTIC EXIT
TO TERMINAL YES SET UP REVIEW
ANALYSIS: Online Information Retrieval System

 Process P1: Several subsidiary processes accomplished by the

transmission of the request for an order from the central
computer.
 Process P2, P6: Wait states for input.
 P3, P4: Real processing steps.
 D2, D4 : Decisions dependent on program structure. Which
branch is taken at D3 is determined by user’s behavior.
USAGE- Transaction Flow Testing

 Indispensable for specifying requirements of complicated

systems, especially online systems
 Big system has thousands of transaction flows. The flows are
represented relatively smaller flow graphs.
 Loops are infrequent as compared to Control flow graphs. The
most common loop is RETRY after user provide incorrect inputs
repeatedly.
IMPLEMENTATION

 Transaction Flow: Representation of a path taken by a

transaction through a succession of processing modules(
token) such as a transaction control block that is passed from
routine to routine as it progresses through its flow.
IMPLEMENTATION- An Example

 This transaction goes through input processing which

determines its type and then goes through processes A and B.
 Result of B may force the transaction to pass back to process A.
 Transaction then moves to C , then either D or E , and finally to
output processing.
 IMPLEMENTATION- TRANSACTION FLOW
D

INPUT S A S B S C S S

TRANSACTION FLOW E

INPUT QUEUE OUTPUT QUEUE

EXECUTIVE/HANDLER/DISPATCHER/ OUTPUT
FRONT END
OPERATING SYSTEM MODULE

A B C D E
PROCESS QUEUES
PROCESSOR PROCESSOR PROCESSOR PROCESSOR PROCESSOR
DISPATCHER QUEUES

Application Processes

SYSTEM CONTROL STRUCTURE

1 DO ALL DISC DO TAPE DO NEW DISC

3
B'S READS C'S WRITES B'S WRITES

DO DISC DO TAPE DO DISC

3 D'S READS A'S READS E'S WRITES
1

EXECUTIVE/ DISAPTCHER FLOWCHART

ANALYSIS- Implementation

 Executive/ Scheduler/ Dispatcher: Controls the system.

 Processes ( Boxes), Processing Queues( Links).
 Transaction enters an input processing module in response to
the inputs received, e.g., at a terminal.
 Transaction is created by the act of filling out input queues
(Figure B) for process A, but process A will not necessarily be
activated immediately. When a process has finished working on
the transaction, it places the transaction control block on a
scheduler queue. The scheduler then examines the transaction
control block and routes it to the next process based on the
information stored in the block. Scheduler contains tables/ code
that routes the transaction to the next process.
ANALYSIS- Implementation

 In systems, that handles many hundreds of transaction types,

this information is contained in tables rather in code.
 Figure C shows possible implementations of this transaction
processing system.
 There could be different transaction flows in the system, all
using processes, A,B,C,D,E, and disc and tape reads and
writes, in different combinations. Processing might be in order,
B,C,A,E,D, or an other combination. Different combinations may
have different Wait priorities depending on the requirement.
SCHEDULER CALLS

 Assuming that there’s return of control to the scheduler after

each process box.
 The whole program is organized as a single loop. First the
scheduler invokes processing module B, which cleans up all
transactions waiting for B processing at that moment. Then the
disc reads are initiated and the scheduler turns control over to
module C, which clears up all its tasks.
 After the tape writes are initiated, module B is invoked again to
take care of any additional work that may have accumulated for
it . The process continues and finally the entire loop starts over
again.
PERSPECTIVE

 In Transaction flow testing we don’t restrict ourselves to no. of

computers, it could be SIMD, MIMD, communication could be
via data structures, over communication lines, processing
queues.
 We assume nothing about the system’s executive structure or
operating system: interrupt driven, cyclic, multi processing etc.
 Transaction flow testing is the ultimate black box technique
because all we ask is that there be something identifiable as a
transaction and that the system will do predictable things to
transaction.
CONTROL FLOW GRAPH vs TRANSACTION
FLOW GRAPH
 Defining Links (Block) :In control flow graphs we define link as a
set of instructions such that if any of them is executed, all
(barring bugs) would be executed. For Transaction flow graphs
this definition changes to identify all processes of interest
(Example 1).
 Another difference is that the Decision nodes of transaction flow
graph can be complicated processes in their own rights.
 Third difference is the effect of interrupts in our transaction flow
model. Interrupts can do the equivalent of converting every
process box into a many splendored thing with more exit links.
BASICS OF TRANSACTION FLOW GRAPHS

 Births
 Mergers
BIRTHS

 Decision Nodes: It depicts that transaction will take either

alternative, but not both, This is a decision point of transaction
flow.
 Biosis : The incoming (Parent) transaction gives birth to a new
(Daughter) transaction whence both transactions continue on
their separate paths, the parent retaining its identity as a
transaction, this process is referred as Biosis.
 Mitosis: This is similar to Biosis except that the Parent
transaction is destroyed and two new transactions (Daughters)
are created. This is referred to as Mitosis.
MERGERS

 Transaction flow junction nodes are as complicated as

transaction flow splits. Following are some types of Mergers.
 Junction : This is similar to junction in control flow graph (figure)
 Absorption : A predator transaction absorbs a prey and predator
is retained, however, prey is gone. Therefore this process is
called Absorption (figure)
 Conjugation : In this , the parent transactions merge to form a
new daughter. This is called Conjugation (figure)
 ALTERNATE 1 PARENT
DAUGHTER

Parent
Parent

DAUGHTER
DAUGHTER
ALTERNATE 2

MITOSIS

DECISION BIOSIS
Assumptions

 Assume that the transaction flow model is imperfect but that the
correct model is untried. As with all models, we ignore the
complications that can invalidate the model and use what we
can apply with ease. After all, models for testing are intended to
give us insights into effective test case design- so it doesn’t
matter that they are imperfect as long as the testing results are
good.
COMPLICATED CASES

 Biosis: Follow the parent flow from beginning to end. Treat each
daughter as a new flow, either to the end or to the point where
the daughter is absorbed.
 Mitosis : This situation involves three or more transaction flows:
from the beginning of the parent’s flow to the mitosis point and
one additional flow for each daughter, from the mitosis point to
respective end.
 Absorption : Follow the predator as the primary flow. The prey is
modeled from its beginning to the point at which it’s eaten.
 Conjugation : Three or more separate flows- the opposite of
mitosis. From the birth of each parent, proceed to the
conjugation point and follow the resulting daughter from the
conjugation point to her end.
TRANSACTION FLOWS- ILL STRUCTURES

 It’s a model of a process, not just code. Humans may be involved in

loops, decisions and so on.
 Parts of the flows may incorporate the behavior of other systems over
which we might have no control.
 The number of transactions and complexities of the individual
transaction flows grow over time as features are added and enhanced.
 Systems are built out of modules and the transaction flows result from
the interaction of those modules. Good system design dictates that we
avoid changing modules in order to implement new transactions or to
modify existing transactions. The result is that we build new paths
between modules, new queues, add modules, and so on, and tie the
whole together with ad hoc flags and switches to make it work. We may
have to fool existing modules into doing the new job for us- that’s
usually preferable to changing many different modules. It’s not unusual
to deliberately block some paths in order to use a common part for
several different kinds of transaction.
WALKTHROUGHS

 Discuss enough transaction types i.e. paths through transaction

flows to account for 98% to 99% of the transactions the system
is expected to process. Adjust the time spent and the intensity
of the review in proportion to the perceived risk of failing to
process each transaction properly. The designers should name
the transaction, provide its flowgraph, identify all processes,
branches, loops, splits, mergers and so on.
 Discuss the paths functionally rather than technically.
 Ask the designers to relate every flow to the specification and to
show how the transaction, directly or indirectly, follows from the
requirement.
WALKTHROUGHS

 Select additional flow paths beyond C1 + C2 for loops, extreme

values, and domain boundaries.
 Select additional paths for weird cases and very long, potentially
troublesome transactions with high risks and potential
consequential damage.
 Design more test cases to validate all births and deaths and to
search for lost daughters, illegitimate births, and wrongful
deaths.
 Publish and distribute the selected set of test paths through the
transaction flows as early as possible so that they will exert the
maximum beneficial effect on the project.
 Make the transaction flow testing the cornerstone of functional
testing as path testing is the cornerstone of the unit testing. For
this one needs to achieve C1 and C2 coverage of the complete
set of transaction flowgraphs.
PATH SELECTION

 Select a covering set of paths based on functionally sensible

transactions.
 Try to find the most tortuous, longest, strangest paths from the
entry to exit of the transaction flow.
 Create a catalog of those weird paths. The act of discussing
those weird paths will expose missing interlocks, duplicated
interlocks, interface problems, programs working at cross
processes, duplicated processing- a lot of stuff that would
otherwise have shown up only during the final acceptance tests.
SENSITIZATION

 Most normal paths are easy to sensitize- 80% to 95%

transaction flow coverage (C1 + C2) are easy to achieve, while
simple paths are easy to sensitize there are many of them, so
there’s lot of boredom in test design.
 How about the off paths, exception conditions, path segments
on which we expect to find most of the bugs? The reason these
paths are often difficult to sensitize is that they correspond to
error conditions, synchronization problems, overload responses,
and other anomalous situations.
 The biggest challenge is testing a protocol across an external
interface. In order to test abnormal paths we may have to ask
the other system to simulate bad transactions or failures.Its
tough to sensitize such path segments if we are going to be fair
about it . It’s not as bad if we are ready to play DIRTY
SENSITIZATION- TAKING THE WRONG SIDE

 Use Patches- Put a patch into our system or a patch into the
system of external interface. In either case, someone has to put
an unrealistic patch.
 Mistune - Test a system sized with grossly inadequate
resources(5% to 10%). This helps t o force most of the resource
related exception conditions.
 Break the Rules - Transactions always require correctly
specified data structures to support them. Often a system
database generator is used to create such objects and to assure
that all required objects have been correctly specified. Bypass
the database generator and use patches to break all rules that
are required to go down the desired path.
 Use Breakpoints - put breakpoints at the branch points where
hard-to-sensitize path segment begins and then patch the
sensitization control block to force that path.
INSTRUMENTATION

 Instrumentation plays a bigger role in transaction flow testing as

compared to unit path testing.
 Recorders, Loggers, OS: information of path taken for a
transaction must be kept with that transaction. For this we can
use recorders( central dispatcher), loggers and in some
communication system such traces can be provided by using
operating systems.
 Instrumentation can be made part of the system design.
Elaborate the design as needed to provide complete transaction
flow tracing for all transactions.
EXECUTION

 For transaction flow testing of a system of any size, make sure

we execute the tests using automation tools from the beginning.
 If more than a hundred test cases are required to achieve
C1+ C2 transaction flow coverage, you will be running and
repeating these transactions not once, but hundreds of times
over the project’s life.
 Transaction flow testing with the intention of achieving C1 + C2
usually leads to a big ( four or five fold) increase in the number
of test cases. Without automated execution it wont be possible
to expect correct results.