Example of Test Case From Use Case-Atm
Example of Test Case From Use Case-Atm
Example of Test Case From Use Case-Atm
Actors and use cases in an ATM machine. The following table contains the basic flow and some alternate flows for Cash Withdrawal use case in the diagram above: Basic Flow This Use Case begins with the ATM in the Ready tate. !. "nitiate #ithdraw $ Customer inserts ban% card in the card reader on the ATM machine &. 'erify Ban% Card $ The ATM reads the account code from the magnetic stri( on the ban% card and chec%s if it is an acce(table ban% card. ). *nter +", $ The ATM as%s for the customer-s +", code ./ digits0 /. 'erify account code and +", $ The account code and +", are verified to determine if the account is valid and if the +", entered is the correct +", for the account. For this flow1 the account is a valid account and the +", is the correct +", associated with this account. 2. ATM 3(tions $ The ATM dis(lays the different alternatives available at this ATM. "n this flow1 the ban% customer always selects 4Cash #ithdraw.4 5. *nter Amount $ The ATM the amount to withdraw. For this flow the customer selects a (reset amount
.6!71 6&71 6271 or 6!770. 8. Authori9ation $ The ATM initiates the verification (rocess with the Ban%ing ystem by sending the Card ":1 +",1 Amount1 and Account information as a transaction. For this flow1 the Ban%ing ystem is online and re(lies with the authori9ation to com(lete the cash withdrawal successfully and u(dates the account balance accordingly. ;. :is(ense $ The Money is dis(ensed. <. Return Card $ The Ban% Card is returned. !7.Recei(t $ The recei(t is (rinted and dis(ensed. The ATM also u(dates the internal log accordingly. Use Case ends with the ATM in the Ready tate. Alternate "n Basic Flow te( & $ 'erify Ban% Card1 if the card is not Flow ! $ valid1 it is e=ected with an a((ro(riate message. ,ot a valid Card Alternate At Basic Flow te( 2 $ ATM 3(tions1 if the ATM is out of Flow & $ money1 the 4Cash #ithdraw4 o(tion will not be available. ATM out of Money Alternate Flow ) $ "nsufficient funds in ATM Alternate Flow / $ "ncorrect +", At Basic Flow te( 5 $ *nter Amount1 if the ATM contains insufficient funds to dis(ense the re>uested amount1 an a((ro(riate message will be dis(layed1 and re=oins the basic flow at te( 5 $ *nter Amount. At Basic Flow te( / $ 'erify Account and +",1 the customer has three tries to enter the correct +",. "f an incorrect +", is entered1 the ATM dis(lays the a((ro(riate message and if there are still tries remaining1 this flow re=oins Basic Flow at te( ) $ *nter +",. "f1 on the final try the entered +", number is incorrect1 the card is retained1 ATM returns to Ready tate1 and this use case terminates.
Alternate Flow 2 $ ,o Account Alternate Flow 5 $ "nsufficient Funds in Account Alternate Flow 8 $ :aily ma@imum withdrawal amount reached Alternate Flow @ $ Aog *rror
At Basic Flow te( / $ 'erify Account and +",1 if the Ban%ing system returns a code indicating the account could not be found or is not an account which allows withdrawals1 the ATM dis(lays the a((ro(riate message and re=oins the Basic Flow at te( < $ Return Card. At Basic Flow te( 8 $ Authori9ation1 the Ban%ing system returns a code indicating the account balance is less than the amount entered in Basic Flow te( 5 $ *nter Amount? the ATM dis(lays the a((ro(riate message and re=oins the Basic Flow at te( 5 $ *nter Amount. At Basic Flow te( 5 $ Authori9ation1 the Ban%ing system returns a code indicating that1 including this re>uest for withdrawal1 the customer has or will have e@ceeded the ma@imum amount allowed in a &/ hour (eriod1 the ATM dis(lays the a((ro(riate message and re=oins the Basic Flow at te( 5 $ *nter Amount. "f at the Basic Flow te( !7 $ Recei(t1 the log cannot be u(dated1 the ATM enters the 4secure mode4 in which all functions are sus(ended. An a((ro(riate alarm is sent to the Ban% ystem to indicate the ATM has sus(ended o(eration. The customer can1 at any time1 decide to terminate the transaction .>uit0. The transaction is sto((ed and the card e=ected. The ATM contains numerous sensors which monitor different functions1 such as (ower1 (ressure e@erted on the various doors and gates1 and motion detectors. "f at any time a sensor is activated1 an alarm signal is sent to the +olice and the ATM enters a 4secure mode4 in which all functions are sus(ended until the a((ro(riate restart C reinitiali9e actions are ta%en.
"n the first iteration1 according to the iteration (lan1 we need to verify that the Cash #ithdrawal use case has been im(lemented correctly. The whole use case has not yet been
Basic Flow $ #ithdrawal of a (reset amount .6!71 6&71 6271 6!770 Alternate Flow & $ ATM out of Money Alternate Flow ) $ "nsufficient funds in ATM Alternate Flow / $ "ncorrect +", Alternate Flow 2 $ ,o Account C "ncorrect Account Ty(e Alternate Flow 5 $ "nsufficient funds in Account
The following scenarios can be derived from this use case: cenario ! $ uccessful cash withdraw Basic Flow
cenario & $ ATM out Basic Flow 2 of money cenario ) $ "nsufficient Funds in ATM cenario / $ "ncorrect +", .tries left0 cenario 2 $ "ncorrect +", .no tries left0 cenario 5 $ ,o Account C incorrect account ty(e cenario 8 $ "nsufficient Account Basic Flow 5
Basic Flow
Alternate Flow /
Basic Flow
Alternate Flow /
Basic Flow
Alternate Flow 2
Basic Flow
Alternate Flow 5
Balance
,3T*: For sim(licity the loo(s in Alternate flows ) and 5 . cenarios ) and 801 and combinations of loo(s have not been included in the table above. For each of these seven scenarios1 test cases need to be identified. Test cases can be identified and managed using matrices or decision tables. A common format is shown below1 where each row re(resent an individual test case1 and the columns identify test case information. "n this e@am(le1 for each test case1 there is a test case ":1 Condition .or descri(tion01 and all the data elements (artici(ating in the test case .as in(ut or already in the database01 and e@(ected result. To begin develo(ing the matri@1 start by identifying what data elements are re>uired to e@ecute the use$case scenarios. Then1 for each scenario1 identify at least test case that contains the a((ro(riate condition to e@ecute the scenario. For e@am(le1 in the matri@ below1 ' .valid0 is used to indicate this condition must be 'AA": for the basic flow to e@ecute and " .invalid0 is used to indicate the condition which will invo%e the desired alternate flow. "n the table below1 4nCa4 indicates that this condition is not a((licable to the test case. TC ":D cenario C +", Account Amount Amount Amount Condition D *ntered in in ATM Account .or chosen0 *@(ected Result
C#!. $
'
'
'
'
'
C#&.
cenario &
'
'
'
'
"
Cash
#ithdraw o(tion unavailable1 end of use case ' ' ' ' " #arning message1 return to Basic Flow te( 5 $ *nter Amount #arning message1 return to Basic Flow te( /1 *nter +", #arning message1 return to Basic Flow te( /1 *nter +", #arning message1 card retained1 end of use case
C#).
C#/.
"
'
nCa
'
'
C#2.
"
'
nCa
'
'
C#5.
"
'
nCa
'
'
"n the matri@ above1 the si@ test cases e@ecute the four scenarios. For the Basic Flow1 test case C#! above is %nown as a (ositive test case. "t e@ecutes the Basic Flow (ath through the use case without any deviations. Com(rehensive testing of the Basic Flow must include negative test cases to ensure that the Basic Flow is ta%en
only when the conditions are correct. These negative test cases are re(resented by test cases C#& $ 5 .the shaded cell indicates the condition needed to e@ecute the alternate flows0. #hile C#& $ 5 are negative test cases for the Basic Flow1 they are (ositive test cases for Alternate flows & $ /1 and there is at least one negative test case each of these Alternate Flows .C#! $ the Basic Flow0. cenario / is an e@am(le where having =ust one (ositive and one negative test case (er scenario is not sufficient. To thoroughly test cenario / $ "ncorrect +",1 at least three (ositive test cases .to invo%e cenario /0 are needed:
the incorrect +", is entered and there are tries left and this Alternate Flow re=oins the Basic Flow te( ) $ *nter +",0 the incorrect +", is entered and there are no remaining tries left and this Alternate Flow then retains the card and terminates the use case. the C3RR*CT +", is entered when there are no remaining tries left. This Alternate Flow re=oins the Basic Flow at te( 2 $ *nter Amount.
,otice1 that in the above matri@1 no actual values were entered for the conditions .data0. An advantage of creating the test case matri@ in this manner is that it is easy to see what conditions are being tested. "t is also very easy to determine if sufficient test cases have been identified1 since you only need to loo% at 's and "s .or as done here $ shaded cells0. Aoo%ing at the above table1 there are several conditions for which there is no shaded cell1 therefore1 we are missing test cases1 such as for cenario 5 $ ,o Account or "ncorrect Account Ty(e and cenario 8 $ "nsufficient Account Balance. 3nce sufficient test cases have been identified1 they should be reviewed and validated to ensure accuracy1 a((ro(riateness1 and eliminate du(licate1 e>uivalent or otherwise redundant test cases.
TC ":D
*@(ected Result
C#!. $
;7< $ /<;
27.77
277.77
&1777
uccessful cash withdrawal. Account balance u(dated to /27.77 Cash #ithdraw o(tion unavailable1 end of use case
C#&.
;7< $ /<;
!77.77
277.77
7.77
C#).
;7< $ /<;
!77.77
277.77
87.77 #arning message1 return to Basic Flow te( 5 $ *nter Amount &1777 #arning message1 return to Basic Flow te( /1 *nter +", &1777 #arning
C#/.
;7< $ /<;
nCa
277.77
C#2.
cenario / /<8;
;7< $
nCa
277.77
/<;
message1 return to Basic Flow te( /1 *nter +", nCa 277.77 &1777 #arning message1 card retained1 end of use case
C#5.
;7< $ /<;
The test cases above are only a few of the test cases needed to verify the Cash #ithdraw Use Case for this iteration. 3ther test cases needed include:
cenario 5 $ ,o Account or "ncorrect Account Ty(e: Account not found or available cenario 5 $ ,o Account or "ncorrect Account Ty(e: Account does not allow withdraws cenario 8 $ "nsufficient Account Balance: Amount re>uested greater than amount in account.
"n future iterations1 when other flows are im(lemented1 test cases will be needed for:
"nvalid cards .card is re(orted lost1 stolen1 is not from an acce(ted ban%1 has a damaged stri(e1 etc.0 "nability to read a card .card reader is =ammed1 off$line1 or malfunctioning0 Account is closed1 fro9en1 or otherwise unavailable Amount in ATM is insufficient or inca(able of creating re>uested amount .different than C#)1 in that one denomination is out1 but not all0 "nca(able of contacting ban%ing system for a((roval Ban% networ% goes off line1 or (ower failure mid$transaction
sufficient test cases1 (ositive and negative1 have been identified for each use$case scenario test cases address any business rules im(lemented by the use cases1 ensuring that there are test cases inside1 outside1 and at the boundary condition C value for the business rule test cases address any se>uencing of events or actions1 such as those identified in the se>uence diagrams in the design model1 or user interface ob=ect states or conditions. test cases address any s(ecial re>uirements defined for the use case1 such minimumCma@imum (erformance1 sometimes combined with minimumCma@imum loads or data volumes during the e@ecution of the use cases.