CHAPTER 10
Test Scenarios

After gathering business requirements and transitioning them each into a format that looks like a pseudo-code, we have to extract test scenarios from each pseudo-code. A test scenario outlines a condition that needs to be tested. A test case is an element of a test scenario that specifies values used in the test. For example, in the business event A product arrives from a supplier, one test scenario could be a product arrives from an offshore supplier and another could be a product arrives from a domestic supplier.

Under the first test scenario, you might have the following test cases:

Test Case #1:
Offshore supplier: ABS Enterprise Ltd
PO: ABS-1199
Product: 200-AAA
Quantity: 100 cases

Test Case #2:
Offshore supplier: ABS Enterprise Ltd
PO: ABS-1300
Product: 333-CCC
Quantity: 1000 units
Product 200-AAA
Quantity: 500 cases

There can be many, many test cases for a given test scenario. Similarly, there can be many test scenarios for a given use case, and there can be many use cases for a business event. Figure 10-1 gives a basic schematic of the relationship between business events, use cases, test scenarios, and test cases.

FIGURE 10-1: Business Event, Use Cases, Test Scenarios, and Test Cases

Writing Test Scenarios

How can we write test scenarios based on a use case? Let’s return to the banking use case described in Chapter 9 and reprinted here as Table 10-1:

TABLE 10-1: Use Case for a Customer Making a Deposit

Event name A customer makes a deposit
Use case name Receive customer deposit at the bank counter
Unique use case ID UC 1.1
Goal  
Actor(s) Customer, teller, system
Brief description Customer makes an in-person deposit at the bank through the bank teller.
Precondition The teller is logged into the system and is authorized to perform the function of accepting a deposit from a customer.
Trigger Customer tells the teller that he or she wants to make a deposit to his or her account.
Main (ideal) flow

  1. Customer provides the teller with the following information:

    • Account number

    • Type of account into which the deposit is to be made (checking, savings, or investment)

    • Amount of the deposit

    • Method of deposit (cash, draft, money order, or check).

  2. Teller provides the customer’s account number to the system. (This will be facilitated by the GUI described under Assumption, below.)

  3. System retrieves the information about the customer’s account. (The account either exists or does not exist in the system. If it does not exist, the process follows the alternate flow or the exception flow, described below. An alternate flow may lead to the creation of another use case if it is very complex. An exception flow means that there exists a condition that calls for the termination of the process.)

    Account exists.

    (As an analyst or a subject matter expert, you decide which of these flows is your ideal flow. So, in this case, let’s decide that a legitimate account leads to the ideal flow.)

  4. System displays the following information:

    • Account number

    • Name on the account

    • Current account balance

    • Type of account (checking, savings, investment)

    • Status of account (active or inactive).

  5. Teller verifies the account is active from the account status shown.

    Account is active.

  6. Teller provides the following information to the system about the deposit:

    • Amount deposited

    • Method of deposit

    • Name of teller who received the deposit.

    • System records the deposit information and the following information:

    • Date and time stamp of the deposit

    • ID of the teller who received the deposit

    • Updated account balance.

6. Teller issues a deposit receipt to the customer. The receipt includes the following:

  • Date and time of the deposit

  • Amount of the deposit

  • Account number into which the deposit was made

  • Bank stamp

  • Teller’s signature.

  • Use case ends.
Post-condition success

Account balance is updated with the new deposit.

The system generates a receipt.

Alternate flow/exception flow

4. Account does not exist.

4.i. System displays an error message. (You may be able to describe at this point what the actual message should be.)

4.ii. Teller notifies customer that the account is not a recognized account.

6. Account is inactive.

6.i System displays an error message.

6.ii. Teller notifies customer that the account is inactive.
Post-condition failure Deposit is not accepted into the account provided by the customer.
Assumption There is a GUI for the interaction between the teller and the system that will allow the teller to enter all the information given by the customer when he or she makes a deposit.
Issues —

Test Cases

We have three test scenarios: the main (ideal) flow, exception flow 4 (account does not exist), and exception flow 6 (account is inactive). The number of test cases depends on how many variations of data combinations the business encounters. For example, how many variations of account numbers are there? How many account types are there?

For the banking scenario above, we can build a spreadsheet to show all the possible data combinations to be tested (Figure 10-2). This requires real patience—there could be many, many data combinations.

TABLE 10-2: Retail Banking Test Data Spreadsheet

The Test Specification Document

Let’s take a look at how to write test scripts from use cases. The contents of the example test specification document shown in Table 10-3, below, are extracted from the use case shown in Table 10-1.

Business process UC 1.1
Module Main flow
Function Receive customer deposit (at bank counter)
Cycle System test
Prerequisite Test 1.0
Test scenario 1.1
Test data 1
Prepared by John Smith
Date 06/20/2008
Test objective Validate the ability to receive customer deposit at the bank counter

TABLE 10-3: Retail Banking Test Specification Document

If the test result is not as expected and is not acceptable, a test problem report must be completed. Table 10-4 is an example:

TABLE 10-4: Example Test Problem Report

In Brief

Writing test scripts from use cases is an almost mechanical process. Follow each step identified in the use case, and you have the makings of all the scenarios you need to test. The challenge is in identifying every possible combination of data that should be tested and defining the expected results for each case.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.67.195