Test Scenario

TEST SCENARIO SUMMARY

Scenario Number: S2
T2 IRA (Individual Retirement Account) Savings Account,
Business Scenario depositor < 70 1/2 years old
Type:

Prerequisite Test C6
Case Numbers:

C9

Test Case Numbers: C4

C5

C18

C19

C20

C21

C22
TEST SCRIPT

Action Simulated Test Action and Data Expected Actual Result

# Date Case Result OK/FR #
#

1. Jan 2 C15, Enter identifying No analysis

C16, information : John required.
C17, Johnson, 100 Main
C18, St., Vancouver,
C19 B.C., V7E2X9,
Male, born Jan 1,
1956, on
"Customer
Information"
screen.

2. Jan 2 C4 Enter account type Message OK

of IRA Savings "Deposit amount
and deposit insufficient for
amount of .99 on account type" is
"New Account displayed.
Information"
screen. Set start
of account cycle to
26th (will go from
26 through 25).

7. Feb 4 C15 Enter $50 No analysis

withdrawal amount required.
on "Account
Maintenance"
screen.

8. Feb 10 C15 Enter $25 No analysis

withdrawal amount required.
on "Account
Maintenance"
screen.
TEST SCRIPT

Action Simulated Test Action and Data Expected Actual Result

# Date Case Result OK/FR #
#

49. Jan 27 C19 Enter identifying Message: FR#41 Opening

information: John "Excessive of savings
Johnson, 100 Main withdrawal account was not
St., Vancouver, transactions, IRA prevented.
B.C., V7E 2X9, savings account
Male, born Jan 1, can not be
1956, on opened." is
"Customer displayed.
Information"
screen. Enter
account type of
IRA Savings and
deposit amount of
$1000 on "New
Account
Information"
screen. Set start
of account cycle to
26th (will go from
26 through 25).

later include various test conditions. The business scenario types are identified uniquely using a T and
consecutive numbers.

BUSINESS SCENARIO TYPE LIST

Business Business Scenario Type

Scenario Type
Identifier

T1 IRA Savings Account - depositor is 70 1/2 years old or older

T2 IRA Savings Account - depositor is less than 70 1/2 years old

T3 IRA Timed Deposit - depositor is 70 1/2 years old or older

BUSINESS SCENARIO TYPE LIST

Business Business Scenario Type

Scenario Type
Identifier

T4 IRA Timed Deposit - depositor is 59 1/2 years old - term deposit within
91 days through 10 years

T5 IRA Timed Deposit - depositor is less than 59 1/2 years old - term
deposit within 91 days through one year

T6 IRA Timed Deposit - depositor is less than 59 1/2 years old - term
deposit > one year < or = two years

T7 IRA Timed Deposit - depositor is less than 59 1/2 years old - term
deposit > two years < or = 10 years
Identifying Business Scenario Types

One method of identifying the business scenario types to supplement the customer's list (or create it, if none is
supplied), is to determine the business scenario types using a table. First, identify important scenario headings,
(e.g., IRA (Individual Retirement Account) Savings Account and IRA Timed Deposit). Then, add further
important characteristics, (e.g., age and term of deposit).

BUSINESS SCENARIO TYPES - RETIREMENT ACCOUNTS

IRA Savings Account depositor is 70 1/2 years old or older

depositor is less than 70 1/2 years old

IRA Timed Deposit depositor is 70 1/2 years old or older

depositor is 59 1/2 years old term within 91 days through

10 years

depositor is less than 59 1/2 term deposit within 91 days

years old through one year

term deposit > one year < or

= two years

term deposit > two years < or

= 10 years

A test case includes a condition required to test the requirement, including the type of test data
required to create the condition, and the expected result. Each test case is uniquely identified,
(e.g., assigned a number).

Create the Test Cases

Use the Traceability Matrix to identify the requirements and their source. To create the test case,
first use the applicable specification, such as the Functional Design Specification, to identify the
conditions to test. For example, consider the requirement that each new applicant must be
screened to determine if they are already known to the customer's business. The Functional
 Design Specification identifies a function called Verify New Applicant. The conditions to test
within the function are:

• new applicant applies for a new account,

• existing customer, with an active account, applies for a new account,

• existing customer, with a closed account, applies for a new account.

For the condition new applicant applies for a new account, the expected result is the person is
identified as one who is not known to the system. The condition and expected result compose
the test case. For this particular requirement there are three test cases, one for each condition.

Use the Black-Box Testing technique to assist with the development of the test cases. Consider the
following principles when developing the test cases:

• The optimum test case is one with the highest chance of detecting an error.

• Prepare test cases for invalid and unexpected situations as well as valid and
expected ones.

• Define separate test cases to satisfy each test objective to ensure that the
purpose of the test is not confused. For example, define functional test cases separate
from performance test cases.

Define test cases to test the access of and error handling for data and processes distributed
across the network. Define test cases to test the synchronization of updates to data distributed
across the network. Consider the complexities added by a graphical user interface environment
and define test cases to test the ability of the application to manage such things as multiple open
windows.

A sample illustrates the process of defining test cases for each requirement. A template can be
used for the creation of the test cases.

Create Test Cases For Each Area

The test process encompasses a number of areas. Create test cases for each of the areas. The
testing of the business processes and functionality is the focal point of the test, therefore, many of
the areas are tested with the functionality.

For example, interface testing is incorporated into the testing of the functionality. Process testing,
which ensures that edits, calculations, and database updates are performed correctly, is a by-
product of functionality testing. Conversion is tested as a function, though it is not a function that
will be needed after the system is fully implemented. Security is tested by incorporating security
levels into the test case conditions where it is applicable. Human Interface and Usability testing
are evaluated while the functionality is tested, but need to have identifiable test cases. Standard
human interface and usability tests may be added to each scenario, (e.g., for human interface
testing, a standard test is an access key is assigned for each function available through a mouse
key, and for usability testing, a standard test is edit messages explain the cause of the error).
The use and evaluation of documentation, such as user aids, and the use of forms is also
incorporated into the testing of the functionality. Performance is tested by monitoring response
times while functionality is being tested.
 Volume testing, stress testing, storage testing, and recovery testing are conducted separately
from the functionality testing. Test cases are created for these tests, but they are not
incorporated into the business scenarios.

Tips and Hints

Use the Traceability Matrix to cross reference the requirements to the test cases to ensure each
requirement is addressed. Add a column to a copy of the matrix and identify the test case for
each requirement by number or name. Complete the matrix as test cases are created.