Point of Sale (POS) Testing: Restaurant POS Testing Example

In this article, we will explain in detail about what makes Point of Sale (POS) testing different from others. We have also incorporated testing tips throughout the article to make this useful for the testing community.

What is the Point of Sale (POS)?

Point of Sale (POS) is where the transactions will 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 Point of Sale, in reality, involves a lot of components and each of these needs to be integrated well for it to run successfully.

• Examples of Restaurant POS system testing also included 

How to Test Point of Sale (POS)

In this article, let’s look at the following:

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

KORONA POS

KORONA POS offers 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, does not include any hidden fees or contracts and is a 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 the feel of sitting in a store and executing your test cases since POS requires setup as you would see in any store.

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 this 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, as well as multiple types of hardware devices and versions of the software.
• Multiple devices require compatibility testing and also thorough integration testing
• PCI compliant because POS test deals with the card details of the end user.

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. XML’s and batch jobs are used to make such updates.

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

(Click on the image for an 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, get pushed to the terminal. This is the main device used in 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 scan the products. Once the scan is complete, a check will be 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 will be updated to reduce the available number of units.

Also read =>> Best Barcode Maker tools review

• For Testing purposes, 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 store 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 a payment mode as Cash, and doing a cash transaction with a refund amount.

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

• Testing can be done by creating a transaction by selecting the mode of payment as Card.
• Verification of 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, in 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 checks, expiry dates 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. It allows payment through Card, Cash, and Gift Cards. They also accept certain coupon codes and discount vouchers.

• Cash Validation – Cash Validation is the simplest one to test. The system calculates the remaining balance and makes it easy for the cashier’s job to refund the amount to the customer. Many a time users might prefer to make partial payments – some by using a 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 that works on the total amount or using a discount voucher applicable on certain items. Again, promotional offers are short-lived and aren’t applicable anywhere, hence testing for discounts and coupons requires 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 activities 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 the correct stock balance.

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

• Verify that the EOD process run is successful. This will result in several intentional failures to ensure the operational day is closed or not. Say in a restaurant, the managers will not be able to run the 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 purposes, this process should be tested manually.
• Verify Reconciliation Reports are generated and validate the contents of the report to ensure the data in the report matches to the data from that particular store. For this type of testing, testers can manually create some transactions, keep a note of the data entered, and generate reconciliation reports at the end of the day to match the data they entered. The reconciliation report would be more like a balance sheet with 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 method using data from past sales patterns and project labour requirements. The scheduling is backend activity but validation happens on 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 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 the following:

• Validation on quantity to be purchased
• Alerts if stock level goes below par
• Placing of order
• Validating the correct Item List with the 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 Point of Sale 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.

Most of the payroll maintenance happens with a third party like ADP etc. hence the integration needs to be tested as well. HR activities are mostly 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 can be done for HR activities like recruiting employees and then ensuring employees are imported to POS systems
• Salary/Wage calculation as per labour laws
• Employee ability to enter leave details

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

A lot of decisions are made based on these reports’ 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. Such details also help them find areas for improvement.

• Validate the generation of proper reports
• Verify the analysis logic
• Validation of 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 of by the vendor management system.

From a testing perspective, the below important validations can be done:

• Validating entry and maintenance of Vendor details 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 enable 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 Point of Sale systems. Hence, based on testing needs, this 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 better performance tracking.

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

Conclusion

I hope this article was effective in explaining the Point of Sale testing in detail. We also have another detailed article on how POS system testing can be done for the restaurant industry. Feel free to share your thoughts and feedback in the comments section below.

We would love to hear from you. 

Restaurant Point of Sale System Testing Example:

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