TRANSACTION TESTING

Notes taken from Boris Beizer books:

Make a transaction flow walk-through a mandatory part of the preliminary design review. The walk-through should
include:
Discussion of a sufficient number of different transaction types (i.e. paths) to account for 98% of all transactions
with which the system is expected to contend. The designers should name the transaction, provide a transaction flow
for it, identify all processes, branches, loops, and so on.
Discussion of each flow or path through the various flows in functional, rather than technical, terms. If a
nontechnical buyers' representative who understands the application but not necessarily the implementation is
present, so much the better. The discussion should be understandable, relatively nontechnical, and to a great extent,
design independent.
Have the designers relate the selected transaction flows to the specification and show how the transaction,
directly or indirectly, follows from specified requirements. However, don't insist on a slavish one-to-one
correspondence, because that could result in a poor system or implementation.
Make transaction flow testing the cornerstone of system-level functional testing just as path testing is the
cornerstone of unit-level structural testing. For this you need a sufficient number of transaction flowcharts to cover
all possible transactions. Select a sufficient number of paths through those transaction flows to assure complete
coverage in the sense of every link and every decision being exercised at least once.
Select additional paths beyond coverage to take care of loops, extreme values, and boundaries
Select additional paths to correspond to weird cases and very long, potentially troublesome transactions
Publish and distribute the selected paths as early as possible so that they will have the maximal beneficial effect on
the project.
Get concurrence from the buyer that the execution of these paths will constitute an adequate system-level functional
test. Augment the test paths as necessary to achieve buyer concurrence, or alternatively, demonstrate how specific
paths of interest to the buyer are more effectively covered by the selected test paths.
Be sure that the designers know in general which paths will be selected, but not the details of those paths. You can,
for example, start with an unrealistically large set of loosely specified paths with the understanding that the number
of paths will be decreased as they are developed in further detail. The designers should have enough information to
investigate and test the general situation, but not so much information that they can develop an explicit "Mickey
Mouse" fix that covers a specific test case but which is otherwise useless.
Application Indicators:
How much of the system's behaviour can you model this way? The applicability can be judged from positive
answers to most of the following questions:
Are there discrete units of work?
Do work unit pass between processes by queues or similar interfaces?
Are there multiple servers?
Do processes work quasi-concurrently?
Do processes communicate by messages?
Bug Assumptions:

 The primary bug assumptions should be that individual processes work correctly (having been extensively tested
at an earlier stage of integration) and that the bugs to be found result from the incorrect implementation of inter
component communications and the vagaries of multitasking.
Wrong queues. Queues missing, extra queues, wrong kind of queues.
Incorrect births or splits. Wrong type born, wrong parent, duplicated.
Incorrect mergers or absorptions. Wrong merged or absorbed, lost.
Queue routing errors. Connections of outputs to the wrong input queue.
Queue discipline errors. Wrong queue discipline invoked.
Limitations and caveats:
Assuming a decent design: The design is hierarchical, there is a clear separation between processing and queue
management, with explicit transaction types, explicit transaction control records, and centralized transaction routing.
The better the design, the likelier you are to achieve good coverage with transaction-flow testing. That means you'll
be able to make reasonable predictions (with suitable tests) of the software's fitness for use. Suppose that it's a bad
design; is transaction-flow testing then not useful? It is still very useful. Transaction flow tests will break a bad
design easily. What you lose with a bad design is the ability to make statistically reasonable predictions about fitness
for use.
The single most important limitation of this model is the insistence on markovian behaviour. With nonmarkovian
behaviour you have no choice but to test every possible path for every possible transaction, because behaviour
depends not only on the data in the transaction but on its past history. That kind of testing is rarely practical.
Reasonable notions of coverage are useless for nonmarkovian behaviour. If you have such behaviour and you do the
tests suggested here, you will only achieve false confidence. Nonmarkovian behaviour can be arbitrarily complex, so
whatever you do to cover can represent an insignificant sample of the possibilities. What should you do if you
encounter nonmarkovian behaviour?
Remove it by design: Always the best option. The nonmarkovian behaviour usually isn't required. It comes about
because people didn't consider the issue.
Isolate it. Put a fence around it. You may have to do this when your model must include things such as human
behaviour or the behaviour of other systems you cannot control. Putting a fence around it can b done by imposing
operational restrictions (change the specification) or by grouping that behaviour in a submodel that you will test very
thoroughly before you get into that high-level system test.
Accept the risk. This may be appropriate. What's acceptable for entertainment software is not acceptable for lifecritical software.