To write Test Cases for an ATM machine, you need to take into account a number of factors. Infrastructure verification testing of the environment, validating IT security as well as ensuring functionality of the application. SIT and UAT test cases also need to be written to ensure the application works.
As far back as I can remember from my student days learning Computer Science, an automated teller machine (ATM) application was always featured somewhere.
In this article I’ll go through some test cases for an ATM machine.
I’ve compiled a list of possible test scenarios that you may want to consider as part of your test approach that you can include in your test plan document.
I’ve then elaborated and given you an example test case.
This isn’t an exhaustive list but I would suggest that you always refer back to your original requirements documentation.
I’ve included an array of tests for functionality, user experience as well as acceptance tests.
I haven’t included any non functional tests as this will usually come from an overarching non functional (NFR) document from your organisation.
Non-functional testing is a monster on its own.
However, if this is something you are interested in, please let me know and I may update this article accordingly.
Before we Start
There’s probably not that many people who can say that they’ve fully tested an ATM machine end to end.
I haven’t either.
However, having worked and currently working in the banking industry for almost 10 years in the UK, I think it puts me at a slight advantage compared to others.
In addition, being a regular user of ATM’s I suppose does help somewhat too.
To understand the context of the Test Scenarios, please also read the assumptions below
Assumptions
There are a number of assumptions I’ve made when writing each test scenario for you.
Initially I started with writing test cases just for an end user withdrawing cash.
However, I found that there is such a big scope so it’s better to be clear from the outset.
| Assumption Number | Description |
| 1 | The test cases focus primarily on system, system integration testing and user acceptance testing. Unit Testing is not in scope. |
| 2 | Assume that the Automated Teller Machine (ATM) in this article is the one you find outside retail outlets, petrol/filling stations etc. Also known as a ‘hole in the wall’ in the UK. It has limited functionality. In scope items/functionalityChecking your balanceWithdrawing cashChanging your PIN. Out of scope items/functionalityDepositing moneyTransferring money to other accounts, switching between account typesChecking transaction typePurchasing other goods or services such as phone top up cards, gift cards etc. |
| 3 | Non functional requirements are out of scope for this article |
| 4 | ATM Security requirements are out of scope for this article. |
| 5 | Infrastructure testing is out of scope |
| 6 | The physical process of inserting money into the cash dispenser. |
Positive Test Case Scenarios
- User wants to make a cash withdrawal but unsure if they have enough cleared funds in the account
- User wants to make a cash withdrawal but has insufficient funds
- User wants to make a cash withdrawal which exceeds their limit. (Can do this over several transactions provided it does not exceed the limit)
- User wants to display balance on screen
- User wants to print balance
- User exceeds limit for invalid PIN attempts.
- User inserts their ATM card but the card is rejected as it has been blocked by the bank.
- User inserts card but the card reader has an error reading the card
- User wants to withdraw cash but the ATM machine has run out of a particular note type. User is asked to select another preference.
- User wants to withdrawal cash using an incorrect multiple (E.g. User wants to withdraw £50 but only £20 notes are available. The system gives the user an option to choose another amount to withdraw.)
- User wants to change the PIN number of their ATM card.
- Verify that the user is logged out once the user’s card has been returned.
- Verify no money has been withdrawn from user’s account when the cash dispenser is empty
- User requests withdrawal of cash during a system failure
- System fails and users cannot insert their ATM card.
- User wants to end activity and requests their ATM card to be returned.
ATM Backend Operations
- Verify Audit Log of transactions is recorded and updated
UI/Functional Test Cases
- Verify each ATM screen renders and looks as per the UI specification
- Verify that button/touch screen takes user to the correct screen
- Verify PIN entry is masked
- Verify PIN attempts is 3 (or whatever is in the spec document)
- Verify error message is displayed when user enters invalid PIN.
- Verify wrong PIN locks user out (and potentially retains user’s card)
- Verify error message when cash dispenser is empty
- Verify the amount dispensed is correct (physical eye check)
- Verify that the amount of money in the cash dispenser reconciles with the transactions for the day. (E.g. if the ATM had £10,000 at the start of the day and £7,000 was withdrawn by end of day, the ATM should have £3,000 in cash remaining).
- The card reader cannot read the magnetic strip and an appropriate message is displayed.
- An end User claims that the system debited the account of £x but the ATM did not dispense any cash.
- The ATM has a connectivity failure (e.g. the Link Network is down).
If you find that the quality of error messages is non-existent or poor, then it is YOUR responsibility to raise this as an issue.
Any other quality issue such as usability or user experience should also be raised.
Negative Test Cases for ATM Machine
You should add tests that generate exceptions or try to cause the system to crash.
A good example of a negative test case is to include some boundary value analysis and equivalence partitioning conditions.
Test Case Description: An ATM User wants to withdraw £50 and print a receipt – Happy Path
Below is an example user journey from a test scenario above.
- User inserts card into ATM
- Users Enters Correct PIN number
- User selects option to display balance on screen
- Screen displays sufficient funds
- User select the Withdrawl Cash option.
- User enters the amount they want to withdraw (less than the cleared funds available).
- The ATM system accepts the request.
- ATM transaction complete
- Card is returned
- The ATM dispenses the cash
For each test step, don’t forget to add your actual and expected result.
From a User experience perspective, you should ensure that there is an appropriate message at each stage of the user’s journey.
You might also be interested in how to write a test case.
A Note on Audit Logs
Every transaction that is made should be recorded in an audit log. I’m not going to write every single test case for that in this article.
However, each time a positive, negative or any error is generated, this MUST be recorded and tested to ensure it has been captured correctly.
In fact every item or transaction needs to be captured in an audit log.
This is incredibly important when it comes to governance and regulation of financial transactions.
The best way to do that is to include a step at the end of your test cases to verify that the audit log has recorded user actions.
Summary
Software Testing for an ATM machine can be quite straightforward or quite complex.
You can use the test cases above and use them as part of your test plan and any future regression testing activities.
I hope the examples above have give you a good idea.
What I would recommend, is that you ensure that you capture all your requirements in a Requirements Traceability Matrix (RTM) document to make your life much easier.
