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

order, that is, the test cases for the individual application pieces are executed fi rst.
When all of the pieces are validated, the test cases for the different business paths
are executed. The next section gives you some approaches for designing both kinds
of functional test cases.
There are some signifi cant limitations to test case development from use
cases. One signifi cant limitation of use cases is the absence of structural (non-
functional) software requirements like security, data management, and inter-
faces. Another signifi cant limitation of use cases is the absence of performance
requirements. We will explore alternative ways of developing structural test
cases in Chapter 8 and alternative ways of developing performance test cases in
Chapter 9.
7.3 AN APPROACH TO FUNCTIONAL TESTING
All functional testing uses business requirements and the associated software design
specifi cations as the validation yardstick. If the business requirement says the
software should do “x,” then functional testing validates “x” as the expected result.
If this topic sparks your interest, Whittaker's textbooks can give you more details
and the results of current academic research. [25] The functional testing objectives
typically include those described in the following subsections.
7.3.1 User Navigation Testing
If an application is strictly batch processing, then user navigation testing does not
apply. Most software has a series of end user and administrator screens for directing
the software's operation. The end user screens can be divided into two categories:
navigation and transaction. Navigation screens are those log on and log off screens
that control access to the software, all menus that provide alternate activity paths
thru the software, and all screen-to-screen linkage that represents a continuum of
some business activity. User navigation testing focuses on the user's ability to log
on to the software with appropriate authority, traverse the application to the de-
sired transaction screens, traverse the transaction screens correctly, and log off the
software. This kind of testing is not concerned with what transaction activity is
being performed on the transaction screens encountered, just that the screens can
be encountered in the correct sequence. As the transaction screens themselves have
become more complex, it takes fewer screen traversals to complete a business activ-
ity. The navigation becomes more intrascreen movement (tabbing) than interscreen
movement.
It is the tester's job to design and execute tests that traverse all valid navigation
paths and attempt to traverse as many invalid navigation paths as possible. The
valid navigation paths are found primarily in the user guide. The input/expected
result paradigm of black box testing becomes path taken/expected destination
paradigm.