Functional Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 104

One of the more complex aspects of user navigation to both develop and test is
the aspect of “stateless” user screens, that is, user screens that you can land on from a
variety of other screens without a prerequisite screen sequence. Indeed, it is common
for several “stateless” screens to be active at the same time.
7.3.2 TransactionScreenTesting
Once an end user or administrator has navigated to a transaction screen, he or she
will perform some meaningful business activity on that transaction screen. The
transaction screen normally has input data fi elds, lists of choices, options, and action
buttons (Add, Change, Delete, Submit, Cancel, OK, and so forth). Some kind of
results may be displayed on the transaction screen after appropriate action buttons
are pressed.
It is the tester's job to design tests that validate the operation of every fi eld,
list, option, and action button on each transaction screen against the business
requirements, the user guide, and the administrator guide. If results are also
displayed on the transaction screen, then the black box inputs versus the expected
result technique is used to validate the displayed results.
7.3.3 Transaction Flow Testing
Transaction fl ow testing takes the transaction screens that have been validated by
testing and determines if their combined results of correct navigation completes the
intended business activity in some specifi ed way. An example of transaction fl ow
testing is to validate customer profi le updates as
transaction screen 1 for customer name, address, and contact person
transaction screen 2 for customer line of credit approval
transaction screen 3 for customer payment terms and discounts
transaction screen 4 for profi le summary and update action
transaction screen 5 for viewing updated customer profi le
The result of the sequence of fi ve screens being completed is expected
to be a master fi le or database fi le update with all the information collected on these
transaction screens. Another example of transaction fl ow is when you purchase
something online. The expected result is a purchase order for the product(s)
you want to order and pay for. A third example of transaction fl ow is when you pay
a bill online. The expected result is a transfer of funds from your bank account or
posting against your credit card to the company you are paying.
It is the tester's job to validate that correctly completing the sequence of
transaction screens does provide a correct result. The tester also validates that if any
of the system's business rules are violated, the system does not provide any result
(all results under the circumstances are normally not valid). Although the tester's