Functional Testing

Pertemuan 11
Intro
• The objective of functional testing is to validate the software behavior
against the business functionality documented in the software
requirements and specifications.
• Functional testing is achieved by a series of tests that exercise
increasingly more of the software that directly enables users to
accomplish this routine daily business.
FUNCTIONAL TEST CASES FROM USE
CASES
• The software development community has not yet standardized on
the development 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
Continued Fungtional Case
• 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.
• For example, if a developer were to write a use case for an online
purchasing system, the use case text might look like
• 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 from the
customer that the happy path does not encounter.
Actor Action Descripton
Costumer Log On A homepage screen sets up the application, counts the user
visits to the application, and starts the user at a main menu
Costumer Browse Catalog The customer is able to search the product c atalog by product
category, manufacturer catalog and ,number. interest from the
search can Products ofbe selected for further consideration
Customer Product Browse Detail The customer can display each selected product by description,
product and price, image, product a
Costumer Update shopping cart The customer can add, remove, or update products to be
purchased in the shopping cart.

Costumer Purchase shopping cart The be to products the review purchased, indicate customer
products delivery information, and collect customer billing/payment
information
Customer Purchase order This validates the customer’s ability to pay for the the to order
completion purchase a provides products, customer, and initiates product
delivery.
Log off This checks for completion of all customer actions during this
session before disconnecting from the customer.
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
• 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
Another Example
• An example of this individual piece testing would be the purchase
web page on which the customer indicates delivery information,
billing information, and method of payment)
• 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
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
• The more the individual web page validation that can be done before
the happy path and alternate path validation, the more successful the
first 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 activity-to-activity interaction instead
of asking which page might not be working correctly
• As each use case is refined 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
• There are some significant limitations to test case development from
use cases.
• One significant limitation of use cases is the absence of structural
(nonfunctional) software requirements like security, data management,
and interfaces.
• Another significant limitation of use cases is the absence of
performance requirements