How to Test Point of Sale (POS) System – Restaurant POS Testing Example

What is Point of Sale (POS)?

POS alias Point of Sale is a place where transactions take place. You can see POS systems in Retail Stores, Restaurants, Hospitals, and almost everywhere these days where payments are involved.

Most of you may very well understand what a barcode reader is or a wireless payment device is (the most used device for payment transactions) but POS, in reality, involves a lot of components and each of the components needs to be integrated well for it to run successfully.

In today’s article, I am going to write about what makes POS testing different from others. I have also incorporated testing tips throughout the article to make this helpful for our testing community.

• Example of Restaurant POS system testing included also

Let’s look at:

• What Makes POS Application Testing Different
• EPOS (Electronic Point Of Sale) Architecture
• EPOS Physical Components
• Levels/Functions of POS
• Example of Restaurant POS system testing included

---

#1) KORONA POS

KORONA POS offers a versatile cloud-based software for retail, ticketing, and fast-casual operations.

The solution is built to be the hub of business operations while allowing users a customized experience. KORONA’s point of sale comes with a flat-rate subscription, it does not include any hidden fees or contracts and is credit card processing agnostic.

Its core features include Inventory management, In-depth reporting, ABC analytics, Order level optimization, Vendor relations, Automated reorders, Franchise management, Employee permissions, CRM and loyalty, Modern payment integrations, Versatile hardware, Online ticketing, eCommerce, Accounting, Promotions, Multi-store management, and reporting.

Pricing: Free trial, 60-day money-back guarantee & No long-term contracts.

---

Recommended reading => How to Test an eCommerce Application

What Makes POS Testing Different:

POS System Testing looks complex, but it is not that tricky for those who understand the concept well. It is interesting because you get a feel of sitting in a store and executing your test cases since POS requires setup as you would see in any stores.

This makes it different when compared to sitting in your cubicle and running some checks in a web app. Organizations dealing with POS system testing maintain separate labs.

What are the challenges in POS testing?

• Multiple configurations as per the store requirement – I will explain with a simple example, say a retail chain wants to run a promotional offer only in one particular city, in such case, special configurations are required to be done for POS systems running in that city.
• POS requires a proper setup with all the devices, and also multiple types of hardware devices and versions of the software.
• Multiple devices require compatibility testing and also a thorough integration testing
• PCI compliant, because POS  test deals with end user’s card details.

POS Architecture:

Each of the terminals in a store is connected to a file server. The settings or the main configurations get done on the server and then pushed to each of the terminals in the store. The XML’s or batch jobs are used to do such updates.

For large retail stores or chain of stores, none of the changes are done locally. Since POS systems accept Card payment, they are integrated with the third party providers who mainly do credit card processing, so whenever a credit card transaction takes place, data is sent to the third party or banks for authorization.

(Click on image for enlarged view)

Image Source. 

POS Physical Components and How to Test These:

#1) Terminal – The terminal is the main screen that is used to enter the details of the transaction. These are mostly touchscreen devices. All the configurations, be it related to Product List, Pricing, Promotional Offers, Payment Modes, gets pushed to the terminal. This is the main device used at any POS.

• Terminal Testing requires validation to ensure that the devices are connected to the network and that the latest OS is running on it to support the POS app.

#2) Display Pole – Display Pole is the device that displays the item price once the product is scanned using the barcode scanner.

• Verify display pole displays the same price as seen on POS terminal

#3) Barcode Reader – Barcode Reader is used to scanning the products. After the scan is complete, a check is done in the backend to verify if the item exists in the inventory list and also retrieve the item price. Once the item gets sold the inventory is updated to reduce the available number of units.

Also read =>> Best Barcocode Maker tools review

• For the Testing purpose, validation can be done by scanning a product missing from the inventory list
• Validate by scanning products which are available in the inventory list but with no price tagged
• Validate by scanning products which are available in the inventory list with proper tagging to a price level.

Also read =>> Best Barcode Readers for faster checkouts

#4) Cash Register – Cash Register is used to storing Cash. For any cash transaction, the cash register opens immediately for cashiers to accept the cash from the customer and also return the balance amount if any.

• Cash Register testing can be done by selecting payment mode as Cash, and doing cash transaction with a refund amount.

#5) Handheld Device – Handheld devices are wireless devices which are used to accept credit card payments. These make it easy to get user authentication by carrying the device to the end user directly, where users can enter card pin.

• Testing can be done by creating a transaction by selecting a mode of payment as Card.
• Verification for the manual amount entry should be done.

#6) Printer – Printers are connected to each of the terminals and are called as register printers, these are used to generate the receipt after each transaction.

• Testers can verify receipt printing, check for alignment, text overwrites, Text size, Fonts, etc.
• Error Handling Case can be verified, say what will happen if the print is given when the printer is not in a ready state or the printer is out of paper.
• Verify the result when the printer goes offline or loses connection in the middle of the transaction.

Further reading =>> Best Home Office Printers

#7) Magnetic Swipe Reader – MSRs are used to swipe cards used for payment which can be debit, credit or Gift Cards. This is mostly used in retail stores or restaurants, but with changing times, where a user is required to key in the PIN for payment, at many places you would see that a wireless device is used for accepting card payments.

• In the case of Gift Cards, MSR’s are used for balance check, expiry date and for payment. Printed receipts are given to guests for authorization. Testers should validate these cases.

Also read => 7 Types of Software Errors That Every Tester Should Know

Levels/Functions of POS:

There are basically 3 levels or functions involved in POS.

Level #1) Application Level/Front Office Functions:

1) Sale Transaction – The main purpose of any POS system is facilitating transactions –

• Validating a successful Sale transaction which would include item scanning using either a barcode device or manual entry using the keyboard, ensuring the total payable amount gets calculated and displayed on the screen and it should end with a successful payment and receipt printing.
• Validating the correct tax amount calculation

2) Payment – Payment is yet another important area in scope for testers. This is due to the vast range of payment modes accepted by POS.A POS allows payment through Card, Cash, Gift Cards. They also accept certain coupon codes, discount vouchers.

• Cash Validation – Cash Validation is the simplest one to test. The system calculates the remaining balance and makes cashier’s job easy to refund the amount to the customer. Many a times the users might prefer to make partial payments- some by using Gift card (GC) and remaining by Cash. Testing should be done to validate if the system accepts and allows partial payments.
• Card Validation – Payment through Card would always require a third party authorization. Card payment starts by swiping the card – through MSR or a handheld device then taking customer’s authorization for the specified amount. The same amount then gets authorized by third party banks.
• Gift Card Validation – Testers can validate the expiry date, an amount on the card before redemption can be validated by swiping the card on the MSR, swipe it both ways to see system behaviour, validate in the partial payment transaction, validate by overpaying using the card.
• Discounts/Coupons/Promotional Offers – This is a tricky testing area because the systems are designed to accept a coupon code only and not all types of discounts, hence validation should consist of all types of combinations. Testing can be done by using a code which works on total amount or using a discount voucher applicable on certain items. Again, promotional offers are short-lived and aren’t applicable everywhere, hence testing for discount and coupons require a little care. Also, validate the order in which discounts are applied. Sometimes, store discounts don’t work over manufacturer’s coupons and sometimes they do. So, be extra careful when testing this.

Level #2) Back of House Functions

1) End of Day – End of Day is the most important activity done at the backend. During EOD, several reconciliations are done and backend systems are updated.

Several summary reports, including the daily sales reconciliation, get generated and sent to stakeholders because this gives an indication on how the day was in terms of sales. Also, a summary is sent to the banks for all the credit card transactions done during the day. Inventory system gets updated to reflect correct stock balance.

This forms one of the major areas for test. Important scenarios which can be included as part of EOD testing can be:

• Verify that EOD process run is successful. This will have several intentional failures to ensure the operational day is closed or not. Say in a restaurant, the managers will not be able to run EOD process if all checks are not closed if all employees are not clocked out from the system. Testing should include running this process including all checks with positive and negative scenarios. Usually, this is an automated process which is scheduled to run at a certain time interval in real stores. For testing purpose, this process should be tested manually.
• Verify Reconciliation Reports are generated and validate the contents of the report to ensure data on the report matches to the data from that particular store. For such types of testing, tester’s can manually create some transactions and keep a note of the data entered, and generate reconciliation report at the day end and match the data they entered. Reconciliation report would be more like a balance sheet with the debit and credit details.

2) Employee Scheduling – Another important BOH activity involves the scheduling function which mainly deals with creating a work schedule for employees. Employees should clock into the system as per their schedule.

Scheduling can be done manually or using an automated way by using data from past sales patterns and project labour requirement. The scheduling is a backend activity but the validation happens in the front end when the employee tries to clock in.

• Validation should include verifying an unscheduled clock in
• Scheduled Late Clock in and clock out
• Scheduled early clock in and clock out

3) Inventory Management – Another important area is the inventory management. Store Managers mainly require such systems to track products through each stage of the inventory cycle and also to have an idea before an item falls below the stock level.

Hence, Inventory systems are designed so that managers can order right product at the right time, in the right quantity from the right vendor and at the right price.

Test Validation should incorporate:

• Validation on quantity to be purchased
• Alerts if stock level goes below par
• Placing of order
• Validating the correct Item List with correct pricing is displayed on POS for selection
• Item and Price Association, Master level validation

Level #3) Corporate Level Functions

Corporate Level Functions doesn’t require you to sit in front of the POS system to do them but they are done using any laptop/desktop with the app or software installed but they are in some or the other way integrated with the POS systems. If corporate functions are done using a web application, there will be a mechanism that will push the changes or settings to the POS.

1) HR and Payroll – HR and Payroll system deals with employee recruitment, maintaining employee salary/wages, labour laws, Tax Details, Employee Availability and Employee Leave.

Mostly the payroll maintenance happens with a third party like ADP etc. hence the integration needs to be tested well. The HR activities mostly are maintained in-house. Payroll becomes a separate huge area for testing as it requires all sorts of calculations before an employee’s paycheck amount gets finalised. It forms a huge scope for testing.

• Validation could be done for HR activities like recruiting employees and then ensuring employees are imported to POS systems
• Salary/Wage calculation as per labour laws
• Employees ability to enter leave details

2) Finance and Accounting – Finance and Accounting system is the one that requires the reporting. P&L statements, planned budgets, variances, stores daily sales, etc. All these details are required by accounting team to ensure whether the POS store is on track or not.

A lot of decisions are taken based on these report’s analysis. Say, if the team decides to open a new store, based on historical data and analysis, the accounts team approves the budget and the area where the store could be opened. Also, such details help them find the areas for improvement.

• Validate the generation of proper reports
• Verify the analysis logic
• Validation of the income statement and balance sheet

3) Vendor Management – For the supply of goods, any retail industry would require vendors, now evaluating the right vendor who provides a reasonable pricing and to monitor their performance is all taken care by the vendor management system.

From testing perspective, below important validations can be done:

• Validating entry and maintenance of Vendor detail in the system
• Validate vendor pricing
• Validate Vendor performance by tracking on- time delivery, quality of products delivered, etc.

4) DW and BI – Data Warehouse enables any industry to store and keep details on the transaction for years which can be used to know the trends, formulate buying patterns, etc. Business Intelligence tools are used to retrieve this huge amount of data from different systems and give the end user an opportunity for analysis.

DW systems get updated from the data that comes from the POS systems. Hence, from testing needs, this again is critical for testing. Many organizations use BI tools or some develop in-house analytics. But in both cases, testing is required.

DW and BI systems help people at the corporate level by simplifying report generation and customizing reports as per their needs, it also helps a better performance tracking.

• Validation at POS level can be done for transactional data, but DW requires validating historical data
• Validate user’s report generation ability and customization using BI tool.

Conclusion:

I hope this article explained POS testing in detail. I have another detailed article on how POS system testing can be done for the restaurant industry.

Restaurant pos systems Testing Example:

=> Please read Restaurant POS systems Testing article here to understand more about POS with an example.