Anda di halaman 1dari 8

Sample Test Plan Document

Overall Testing Structure:


The development team will be divided into three main groups:
o User Interface Team responsible for
o WithdrawInterface
o LoginInterface
o Business Logic Team responsible for
o WithdrawLogic
o Account
o LoginLogic
o Database Team responsible for
o AccountDatabase
o LoginDatabase
o The two actual databases
Milestone 1: Simple Withdrawal
Goals:
Ensure that a normal withdrawal (no errors in amount withdrawn, no overdraft) can be
performed from checking and savings accounts.

Goal Date: 4/11/08

Environmental Needs:
o Since no login window has been created yet, a temporary driver will be needed to
initialize the objects.
o Each method used in these tests should display a debugging message indicating that it
has been called.
o An account database with the following record must be on line:
AccountNumber: 1234ABCD
HasChecking: yes
CheckingBalance: 1000
HasSavings: yes
SavingsBalance: 200

Traceability:
o Withdraw scenario
o View Balance scenrio

Module Responsibilities:
o The WithdrawInterface must be able to input withdrawal amounts and populate the
account types, to handle the “Withdraw” button being pressed, and to call appropriate
methods in WithdrawLogic.
o The WithdrawLogic object must be able to handle calls to hasAccount, getBalance,
and withdraw in cases where there is no error, as well as to construct
AccountDatabase objects.
o The AccountDatabase object must be able to handle connecting to the database, and
getting and setting the balance of checking and savings.

Note: This milestone will act as a simple prototype for initial client demonstration. It will
also allow the client to view preliminary user interface design of the withdrawal window
and suggest feedback.

Test Cases:
WithdrawalInitialization

Description:
Make sure that all objects needed for this test can be set up.
Steps:
1. The driver constructs a WithdrawInterface object.
2. The WithdrawInterface object constructs a WithdrawLogic object, which
constructs 2 Account objects for checking and savings.
3. Each Account object constructs a AccountDatabase object, which creates a
connection to the database and accesses the appropriate balance of the account.
4. The Account objects call the getBalance method of their AccountDatabase objects
to get that balance, which they store as state variables.
5. The WithdrawInterface calls the hasAccount method of the WithdrawLogic object
for the parameters “checking” and “savings”.
6. Each call should return true.
7. The accounts drop-down of the interface should be populated with both “checking”
and “savings”.

GetBalances

Description:
Test ability to get balance values and display to user.

Intercase Dependencies:
o The WithdrawalInitialization test has been successfully performed.

Steps:
See steps 1-8 of the WithdrawalInitialization test
1. The user presses the “View Balances” button.
2. WithdrawInterface calls the getBalance method of the WithdrawLogic twice,
passing it “checking” and “checking”.
3. WithdrawLogic returns 1000 and 2000.
4. The WithdrawInterface displays a message listing the account balances.

SimpleCheckingWithdrawal

Description:
Withdraw $200 from checking, leaving $800.

Intercase Dependencies:
o The WithdrawalInitialization test has been successfully performed.

Steps:
See steps 1-8 of the WithdrawalInitialization test
1. The user selects “checking” from the drop down, enters 200 for the amount, and
presses the withdraw button.
2. WithdrawInterface calls the withdraw method of the WithdrawLogic, passing it
“checking” and 200.
3. The Account object calls the setBalance method of its AccountDatabase, passing it
800.
4. The value of the checking balance for the test account is set to $800.
5. The WithdrawInterface displays a message indicating successful withdrawal.

SimpleCheckingWithdrawal

Description:
Withdraw $140 from savings, leaving $60.

Intercase Dependencies:
o The WithdrawalInitialization test has been successfully performed.

SimpleCheckingWithdrawal

Description:
Withdraw $60 from savings, leaving $0, in order to perform a boundary test.

Intercase Dependencies:
o The WithdrawalInitialization and SimpleSavingsWithdrawal tests have been
successfully performed.
Milestone 2: Handling Withdrawal Errors
Goals:
Ensure that problems such as no accounts, illegal withdrawal amounts, and overdrafts are
handled correctly.

Goal Date: 4/18/08

Environmental Needs:
o Since no login window has been created yet, a temporary driver will be needed to
initialize the objects.
o Each method used in these tests should display a debugging message indicating that it
has been called.
o An account database with the following records must be on line:
AccountNumber: 1234ABCD
HasChecking: yes
CheckingBalance: 1000
HasSavings: yes
SavingsBalance: 180

Traceability:
o Withdraw scenario
o Insufficient Balance scenario

Module Responsibilities:
o The WithdrawInterface must be able to handle exceptions thrown by
WithdrawLogic and display appropriate error messages.
o The WithdrawLogic object must be able to detect illegal withdrawal amounts and
overdrafts, and be able to handle “no such account” exceptions thrown by
AccountDatabase.
o The AccountDatabase object must be able to detect and throw exceptions when a
specific account type does not exist.

Note: This milestone will be demonstrated to the client to insure error messages meet
usability standards.

Test Cases:
NoAccounts

Description:
Test ability to check whether system can handle users with no accounts.

Steps:
1. The driver constructs a WithdrawInterface object for account 5678ABCD.
2. WithdrawLogic attempts to construct Account objects, which in turn attempt to
construct AccountDatabase objects.
3. The AccountDatabase objects throw NoSuchAccount exceptions.
4. The accounts drop-down of the interface should not be populated with either
“checking” or “savings”.

IllegalWithdrawal1

Description:
Test ability to check divisibility by 20, by entering 150 as the withdrawal amount.

Steps:
1. The driver constructs a WithdrawInterface object for account 1234ABCD.
2. The accounts drop-down of the interface should be populated with both “checking”
and “savings”.
3. The user selects “checking” and enters 150 for the amount.
4. The WithdrawLogic object detects the error and throws an
IllegalAmountException.
5. An error message is displayed by WithdrawInterface.
6. No change to the database.

IllegalWithdrawal2

Description:
Test ability to check maximum withdrawal of $200, by entering 220 as the withdrawal
amount.

Steps:
1. The driver constructs a WithdrawInterface object for account 1234ABCD.
2. The accounts drop-down of the interface should be populated with both “checking”
and “savings”.
3. The user selects “checking” and enters 220 for the amount.
4. The WithdrawLogic object detects the error and throws an
IllegalAmountException.
5. An error message is displayed by WithdrawInterface.
6. No change to the database.

Overdrawn

Description:
Test ability to prevent overdrawn account, by entering 200 as the withdrawal amount for
a savings account with only 180.
Steps:
1. The driver constructs a WithdrawInterface object for account 1234ABCD.
2. The accounts drop-down of the interface should be populated with both “checking”
and “savings”.
3. The user selects “savings” and enters 200 for the amount.
4. The WithdrawLogic object detects the error and throws an
InsufficientBalanceException.
5. An error message is displayed by WithdrawInterface.
6. No change to the database.
Milestone 3: Logging In
Goals:
Ensure that login procedures are followed, including successful login and incorrect
password.

Goal Date: 4/25/08

Environmental Needs:
o Each method used in these tests should display a debugging message indicating that it
has been called.
o An account database with the following records must be on line:
AccountNumber: 1234ABCD
HasChecking: yes
CheckingBalance: 1000
HasSavings: yes
SavingsBalance: 180
AccountNumber: 5678ABCD
HasChecking: no
CheckingBalance: 0
HasSavings: no
SavingsBalance: 0
o A PIN database with the following record must be on line:
AccountNumber: 1234ABCD
PIN: 9876

Traceability:
o Withdraw scenario
o Insufficient Balance scenario

Module Responsibilities:
o The LoginInterface must be able to input PIN numbers, display error messages if a
PIN is incorrect, and construct a WithdrawInterface object if the PIN is correct.
o The WithdrawLogic object must be able to detect illegal withdrawal amounts and
overdrafts, and be able to handle “no such account” exceptions thrown by
AccountDatabase.
o The AccountDatabase object must be able to detect and throw exceptions when a
specific account type does not exist.

Anda mungkin juga menyukai