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

task for transaction fl ow testing is more complex than the transaction screen testing,
the effi cient tester will use sequences of successful transaction screen test actions to
drive more complex transaction fl ow testing. There is no need to reinvent transaction
screen test actions just for fl ow testing.
7.3.4 Report Screen Testing
Report screen testing is similar to transaction screen testing. The difference is that
you are attempting to retrieve and display data from the system using the report
screens instead of entering data using the transaction screens. The diffi culty in
report screen testing usually lies in the variety of ways an end user can specify
which data are retrieved (search criteria) and how these data are displayed (sorting
and formatting options).
The tester's job is to pay particular attention to the data retrieved and displayed
because the wrong data may have been selected or, worse yet, not all data requested
were displayed.
7.3.5 Report Flow Testing
Report fl ow testing becomes different from report screen testing when the report results
are provided in other modalities besides on-screen display. For example, hardcopy
output would be one of the more popular alternate report modalities. The tester must
ask the question, “Does the software send exactly the same results to the printer that
it displays on the report screen?” Having a printer option implies the possibility of the
report screen offering a selection of print fonts, another fertile area for testing. Another
rseport modality might be a print fi le to disk (fl oppy, hard disk, CD, or e-mail).
It is the tester's job to validate the report results on all the alternative report
modalities supported by the software. Similar to our suggestion with transaction
fl ow testing, use successful report screen tests to drive the report fl ow testing.
7.3.6 Database Create/Retrieve/Update/Delete Testing
Many applications use databases behind their transaction and report screens to
manage the application's data. Database functional testing is normally done in two
steps. The fi rst step is to test the database design viability by successfully performing
the application data manipulations outside of the application.
A brief word of explanation might be needed at this juncture. Databases are
managed by database management systems or DBMSs. Examples of DBMSs
are DB2, Oracle, Sybase, and MicroSoft Access. Each DBMS has a language for
describing data structures (DDLs) and manipulating data within these structures
(DML). Typically, a database administrator is well versed in both languages and
sets up the databases for the application development team. Once the databases are