Functional Testing
7.2 FUNCTIONAL TEST CASES FROM USE CASES
There is a relatively new scoping technique called use case that software developers employ to capture functional requirements of a system for the purpose of scoping the project. The technique became popular in the mid-1990s fi rst as an object-oriented design technique and later broadened in appeal for other types of software develop- ment. If this topic sparks your interest, there are a number of recent textbooks that can give you more guidance about writing use cases. [23, 24]
The software development community has not yet standardized on the devel- opment team role that should write these use cases. Some organizations give this responsibility to the developers. Some organizations give this responsibility to the testers. Some organizations give this responsibility to a business analyst. As long as use cases are written by someone, testers can take advantage of these use cases when writing functional test cases.
The building blocks of this approach are actors, use cases, happy paths and alternate paths. Actors are those business roles who are going to directly use the software. The happy path is the sequence of actions that the actor must take in order to accomplish a specific use case. Alternative steps that could be used by an actor to complete the use case represent contingency use cases (customer not found, credit denied, accessories not available, and so forth.) to a happy path. A kind of node diagram of the software emerges that displays all the high-level tasks for a specific business role and the steps necessary to accomplish these tasks. This node diagram is translated into a text descrip- tion. The combined node diagram and text description constitute the use case documentation.
For example, if a developer were to write a use case for an online purchasing system, the use case text might look like Figure 7.1.
As stated in the Use Case # 001 title, this is a happy path, that is, all steps are expected to be completed by the customer in the sequence shown. An alternate path associated with this happy path would be dealing with rejection of the customer’s attempted payment. The same products will ultimately be purchased as with the happy path, but there will be intervening action needed to solicit acceptable payment from the customer that the happy path does not encounter.
Use Case #001 provides a high-level description of the sequence of steps that the actor (customer) must take to complete an online purchase. Recall that in the test case content description in Chapter 5, there is a sequence of test steps. For functional testing, here is the helpful crossover. Consider drafting a test case for each use case
happy path and each use case alternate path, bringing the use case sequence of ac- tions into the test case steps almost one-for-one. Figure 7.2 shows what the steps of the Use Case #001 happy path test case might be.
Actor Action Description
Customer Log on A homepage screen sets up the application, counts the user visits to the application, and starts the user at a main menu .
Customer Browse catalog The customer is able to search the product c atalog by product category, manufacturer catalog ,and number. Products of interest from the search can be selected for further consideration.
Customer product Browse
detail
The customer can display each selected product by description,
product a product image, price, and the quantity in stock.
Customer Update shopping cart
The customer can add, remove, or update products to be purchased in the shopping cart.
Customer Purchase shopping cart products
can customer
The review the products to be purchased, indicate customer delivery information, and collect customer billing/payment information.
Customer Purchase order completion
This validates the customer’s ability to pay for the the to order purchase a
provides products,
customer, and initiates product delivery.
Customer Log off This checks for completion of all customer actions during this session before disconnecting from the customer.
Figure 7.1 Example use case for an online purchasing application Use Case 001—product purchase (happy path)
7.2 Functional Test Cases from Use Cases 101
Step no. Step Expected result
1. Log on Access the main menu
2. Browse catalog Find a blue widget
3. Browse product detail Display the blue widget descr.
4. Update shopping cart Add the blue widget 5. Purchase shopping cart products
6. Purchase order completion Get blue widget purchase confirm
7. Log off Exit the application successfully
Buy the blue widget
Figure 7.2 A full business path test case from use case
The fi rst draft of the use cases and the test cases have insuffi cient details to either write code or execute tests at this time. Both do represent a roadmap to the additional level of details needed for writing code and executing tests.
As the design phase of the software development project continues, details become available that spell out how each actor can accomplish the use case activities—menus, data entry web pages, data search web pages, report web pages, printouts, databases for purchases, and so forth. As these details emerge from the design work, the tester can identify the pieces that need testing individually before they can be tested together, possibly implying more test cases.
An example of this individual piece testing would be the purchase web page on which the customer indicates delivery information, billing informa- tion, and method of payment. For the purposes of discussion, one web page is assumed to collect all of this information. The purpose of the test case for the purchase page is to rigorously test all of the data entry fields (delivery street address), dropdown lists (state code and credit card), radio buttons (5-day ground, second day air, and so forth), and any other buttons on the page. The intent is to completely validate this web page before it is included in a happy path test case. Figure 7.3 shows what the steps of the more detailed purchase page test case might be.
The more the individual web page validation that can be done before the happy path and alternate path validation, the more successful the fi rst time path tests will be. The other way to look at it is that if all of the individual web pages work as advertised and one of the paths fails, then you can focus on the activ- ity-to-activity interaction instead of asking which page might not be working correctly.
It is hopefully clear now that use cases are a powerful basis on which to develop business path test cases. Use cases contain the business functionality to be veri- fi ed. As each use case is refi ned by additional requirements and design detail, the tester can leverage the more detailed use cases to develop detailed test cases for the individual application pieces. Execution of the test cases then proceeds in reverse
Step no. Step Expected result
1. Launch the purchase order screen Screen appears
2. Enter purchaser name Accept valid names
3. Enter purchaser address street Accept multiple addresses 4. Enter purchaser address state Select multiple states 5. Enter purchaser address zip Select multiple zip areas 6. Select method of payment Select check/credit card 7. Exit purchase order screen Screen stops successfully Figure 7.3 A full business path test case from use case
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.