Write Test Cases For ATM Machine: Interview Prep

Write Test Cases For ATM Machine

If you are going to attend an interview in some of the top ATM manufacturer like NCR Corporation India Pvt Ltd, In such cases it’s imperative to understand how ATM works and they may ask to write Test Cases for ATM Machine.

Whenever any person asks you to write test cases. He doesn’t want to see whether you write it correctly or not. He wants to see how analytical you are. How you approach any new challenges and how to starts with this problem statement.

Test Case Creation is an art and this is more like the flow of though. Since we are here to get an idea about test cases. So we are going to write high-level test cases. Still, you want to see test cases template in detail then read my post difference between test cases and test scenario

So let’s start writing test cases for ATM without any delay. In this post, we will follow these categories as per its definition to write test cases for ATM

  • Philosophical
  • Economic
  • Operational
  • Value addition

Philosophical Test Cases: This section will cover built, look and feel, components and simplicity of use.

  • Check all components are clubbed together and are intact as a complete functional unit.
  • Check the internet, power supply and space of its installation. Space is one constraint that should be tested first.
  • Check ATM’s labels are intuitive. One example of the intuitive message – Insert Card When Signal is Green, Cash, Receipt Text should be written on machine.
  • Check the Keyboard to enter the password. This might be a separate keyboard or will be on screen.
  • Check eye-catching colours should be used for labels.
  • Check the weight of the ATM and should not be easily movable.
  • Check texts are readable
  • Check font of texts written on the machine and on-screen are easily readable.

Economic Test Cases: This kind of test cases always talks about the cost.

  • Check the operational electric power required.
    • Try to operate on less than expected power. This should not harm the ATM.
    • Try to operate on more than expected power. This should not harm the ATM.
  • Check unit of power used in per unit of time.
  • Check All safety measures to safeguard end-user from
    • Electrocute
    • ATM falls on the user during use.
  • Check internet speed which is required.
    • Throttle internet speed and check its operation
  • Check internet data consumed per unit of time on use and without use.

Operational Test Cases: This kind of test cases covers all the functionality and attributes of the ATM.

There are multiple components in ATM, That will be verified functionally
Card Reader
Cash dispenser
Keyboard if not touch screen
Receipt Printer
Display and buttons attached on-screen or off-screen.

Card Reader

  • Check whether the card is working correctly or not by inserting the valid card. Follow all instruction on the screen and see if asking for pin or not.
  • Check Above test cases for all other banks cards
  • Check correct message is coming or not when inserting the card in a card reader with the wrong alignment.
  • Check the invalid card and see a message stating invalid card is coming on screen or not.
  • Check instruction on the screen, if user insert card when the machine is not ready like green lights or some notification is not up.
  • Check card collection notification or message appears on the screen after one complete transaction. (Valid for cash collection and balance enquiry).
  • Check the message on the screen when the user inserts valid card but inserts the wrong pin.
  • Check the message when using an expired card. Card expiry message should appear on the screen.
  • Check extreme cases of safety, if the user provides the wrong password more than 3 attempts. Card block message or connect with bank message should appear on the screen.

Cash Dispensar & Cash Withdrawl

  • Check cash withdrawal is possible with a correct pin.
  • Check cash withdrawal limit in one transaction (Like in most of the Indian bank it say maximum 10k or 20k).
  • Check user can only ask for money withdrawal in multiple of 100 or 500 depends on the machine.
  • Check multiple cash transaction with a single pin
  • Check money withdrawn from the account as per available balance. ( Try more than available balance and see )
  • Check session timeout in the complete transaction process
    • Enter card and wait for next one minute or two
    • Enter card and navigate as per instruction on the screen and wait on pin page
    • Enter card and follow all instruction and wait when cash is out from the dispenser and now check the balance.
  • Check the balance in the following cases
    • when money withdrawal is successful.
    • when cross free transaction limit.
    • when the transaction fails.
    • when power cut or resources fail during a transaction.
    • when the transaction is interrupted by pressing the cancel button.
    • when the transaction is interrupted by pressing any button on the screen.

Keyboard / Touch Screen

  • Check correct text is inserted when pressing the button on keyboard either on-screen or from the keyboard. ( For this enter correct set of pin once and then incorrect set of the pin)
  • Check cancel button is working correctly
  • Check enter button works correctly when the user enters the correct pin and click it
  • Check functionality of all buttons available.
  • Check is there any other way to perform all action without using the keyboard ( This is the negative case)

Receipt Printer

  • Check receipt printer prints receipt after each complete transaction only when user opt for a receipt
  • Check when the user opted no receipt.
  • Check message printed on receipt in case of cash withdrawal or balance enquiry.
  • Check one receipt for one complete transaction.
  • Check error message appears when there is no paper to print or user is notified when providing its input for receipt.

Display & Keys attached with screen

  • Check error message for all failure or success
  • Check keys available on-screen works accordingly.
  • Check the right set of instructions appear on the screen when the valid card used.
  • Check operation on-screen.
  • Check message are visible and readable to the user and in the language selected.
  • Check banks detail appears only with the correct pin.
  • Check message for low balance, failed transaction, technical problems, transaction exceed, transaction limit exceed and any failure appear on the screen.

Value Addition Test Cases: This kind of test cases are for customer satisfaction.

  • Check transactions are easy to use and information and navigation are intuitive.
  • Check atm should be feature-rich.
  • ATM installed with security feature
  • CCTV installed properly to counter any wrong did.
  • In case of help, executive or guard should be installed.
  • Cost of ATM should be in market competition with the best attributes for sale of ATM.

So here I am concluding high-level test cases for ATM. Hope you understand it and will use the same approach while creating the test cases for anything. If you find this post valuable then share it and also comment here.
To read more about ATM, read this link Automated Teller Machine (ATM).
Reference:
Initial Functional Test Cases for Example ATM System

Bug Reporting – An Art to explain your bug effectively

Bug Reporting is an art of articulating all required steps to reproduce any found anomaly in any system. These anomalies might be any failure, fault or error in the behaviour of feature in Test.

It means we have multiple questions that should be addressed first

Question 1: What is a bug

Question 2: How to report

So let’s address the first question about Bug.

Bug: Bug in any software is defined as a fault, failure, error or anomaly that intends software in Test to produce an unexpected result which system was not supposed to deliver.

Once anomaly occurs. We need to report it and this reporting process which contains precise information about the bug is called Bug Reporting.

Bug reporting is an art and this can be honed through your effort to provide every single detail that can help the developer to fix a reported bug.
To make bug reporting a single source of truth that will be used by the developer to reproduce and fix it, bug reporter needs to provide the following details

Bug’s Unique ID: Every single logged defect/bug must have a unique id. But if you are using any defect/bug tracking tool, then don’t worry this will be the task of tool to assign unique number to newly raised bug.

Bug Summary: Every bug should have a precisely written summary which states the bug behaviour in a single line.
Let’s assume that when you clicking on submit button of any form on provided web application / mobile application, the system is crash. So this can be reported with the following bug summary.

System crashed when user clicking on submit button of <xyz> form

Build Version – Build detail is very important for any of the bugs raised to reproduce it.

Bug Description – This section is going to contain the following detail.
1- Steps to reproduce the bug.
2- Screenshots if any needed.
3- All system logs
4- Expected Result
5- Actual Result
and if you found any link which helps in fixing this bug technically. We should also add such resources. Because this can save the time of developer because he doesn’t search on the internet for a specific fix.

Date of bug reported: This will be automatically generated if team is using a bug tracking tool otherwise we need to add date for each bug.

Reference Document: Although such document is always placed on a common team location. From where anyone can refer to the requirement, design of the product. So if you want to add a specific section of such document then add it with the ticket.

Bug Reporter: Each bug should have reporter name/id.

Current Status: Status of any bug is very helpful to track the progress.

Assignee: Developer assigned to fix newly raise defect.

Environment/Platform: This section contains the environment used to detect bug (URL). Along with this if we are testing any web-application, in such case we should also specify the browser as well. But we are working on mobile application, in such case, we should provide the detail of the operating system (version for android/iOs).

Component: Product component where this defect has been found. This component information narrow down the assignee of the defect because in general, we all know which developer is working on which component.

Severity: This detail should be mentioned, how hard this bug is going to impact the current status of the product (Application). QA should add this with each reported bug.

Priority: Urgency to fix any of logged defect. Because of bug, companies face the loss of money and reputation in the market. So this is one factor which decides the tenure of a bug in the system.

We have seen all the information needed for good bug reporting. But there is a number of other good practices which should be followed by every QA during login any of any bug.
1- Always check whether your bug is not duplicate. So we should make one practice to search a certain keyword in a database of bugs.
2- QA should mention how many time, he or she was able to reproduce this bug.
3- We should always try various steps to reproduce the same bug in the system. Because many a time bug is due to certain test data.
4- QA should always intimate respective developer about the bug or should discuss with the developer before raising any bug in the system.
5- It is imperative to be polite in writing.
6- If QA should always cc some of the relevant senior stack-holder.
7- Qa should be optimistic that newly raised bug could be the inception of a new feature in the system.

Bug

The benefit of good bug reporting

1- This will reduce turn out time for any of the raised defect.
2- This will reduce conflicts between QA & Developer.
3- More and more bugs will be fixed without spending additional time by QA and Dev to reproduce it.
4- This increases the quality of the product with passes of time.
5- This will create a sense of ownership and will create a though among the team that Quality is everyone’s responsibility.
6- This will increase the trust of management in the team.

References:
1- Wikipedia.org
2- https://www.techopedia.com/

1 2 3 4 53