Functional Testing
7.3 AN APPROACH TO FUNCTIONAL TESTING
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.
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 Transaction Screen Testing
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
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 7.3 An Approach to Functional Testing 105
set up, programmers can create new records, retrieve records, update records, and delete records using the DBMS language totally independent of any application.
Back to the fi rst database testing, the tester needs to see if the data in the databases can be managed per the application requirements. Using our previous transaction fl ow example, the tester must be able to successfully add a new user profi le, updating an existing user profi le, and deleting a user profi le just using the DBMS commands. What this kind of testing validates is the viability of the database design for the intended application. If the database design is not viable, then the application can never maintain its data correctly regardless of the expertise of the application programmers.
The second step is to test the application software’s use of the validated database design. This testing amounts to looking at the “back side” of the application after successful fl ow testing has been completed. The test results may look good on the screen; however, the testing question is “have those same results been correctly managed in the database by the application?” This kind of testing is easiest done by pairing up validated transaction fl ow screens with validated report fl ow screens. If what is seen going into the transaction screens appears on the report screens, chances are good (not 100%) that the underlying database structure that supports these screens is being manipulated correctly.
Testing application databases requires cooperation and collaboration between the tester and the database administrator due to the complexity of DBMS languages, design, and operations.