This is an example of Restaurant POS System Testing. Please read part – 1 of this article below:
=> What is POS and How to Test POS System
Restaurant POS System:
A fine dining restaurant is a place we think of any sort of parties, treats or celebration. We visit the restaurant, book a table, order our food, relish the food, make the payment and then walk out of the restaurant, but behind the scenes a lot of activities take place.
In this article I will walk you through the different activities occurring in a restaurant and how it forms an integral part of any Restaurant industry. Read more to know on how we as testers can focus on critical areas as part of our testing.
A Restaurant Operation is mainly divided into Front of House (FOH) and Back of House (BOH). FOH activities include items like a server taking an order, receiving a payment, anything where you are facing the guest directly.
BOH activities include a cook preparing the food, or a dishwasher cleaning the vessels. These are mainly things which are not exposed to guests.BOH also includes the reporting and integration with other systems.
In this article I haven’t covered details on POS system; I have focussed more on POS as in any restaurant industry. To know more on what POS means, please refer to this article:
READ => What is POS and How to Test POS System
What You Will Learn:
Top Restaurant POS Software
- TouchBistro
- eZee Burrp!
- ShopKeep
- Toast POS
- Revel iPad POS
- BIM POS
- Epos Now
- CashFootprint Point-of-Sale
- FoodZaps Mobile Ordering + POS System
- Future POS
- Amigo Point Of Sale
#1) TouchBistro – POS built just for Restaurants
TouchBistro is the best all-in-one Restaurant Management POS System. It provides all the technology and features you need to run your restaurant on a fast, reliable and easy-to-use platform.
Features:
- Support all restaurants from food trucks to FSRs
- Payment Processing with cash, cards, and digital wallets
- Tableside Ordering
- Floor Plan & Table Management
- Menu Management
- Staff Management
- Inventory Management
- Reporting & Analytics
Front of House (FOH) Food Order Taking Flow
Guests Selects a Table, Servers enters the table number, and the number of guests in the POS. The server takes Order and enters in the POS and the system redirects this order to Kitchen. When the order gets ready, the Server is notified via the KDS system and then the Server serves the food to the guests. The server then generates the Bill/Check from POS system, takes payment from the guest, enter in the system and then close that bill/check.
Note -In US, the bill is called as check. So most of the POS used in restaurants are configured to use the terminology as ‘Check’. Also in my article, I have used the terminology as ‘Server’ to denote people who face the guests and take orders.
Now that you understand the overall flow of how an order is taken till the food is served and payment completed, here’s how we as testers can technically get involved in testing such systems. I have provided details on some of the key operations –
| Key Activities in Order Taking | What Testers can do |
|---|---|
| Table & Guest Details Entry | Testers will need to validate such scenarios depending on which method is used for food ordering – Dining – In a case of Dining, guests want to sit in the restaurant and have food, so servers should ensure they are seated on a proper table and at the same time enter the table number with the number of guests in the POS. Testers should test the functionality by inputting a valid value for table number and the number of guests field. Based on the system configuration the validation can be done. Say, table 99 doesn’t exist, so testers while testing provides input as 99 should see an error message like ‘Table # doesn’t exist, please enter a valid table number’. Also, a table shouldn’t accept other orders if a check is already open against that table. Say, guests are already seated on table 10 and if a server enters table # 10, system should throw an error. Many a times the UI lets you select the table instead of keying the number. This will totally depend on the POS system used. ToGo/Takeaways – In a case of ToGo, guests will come and order, but take the food along with them. In such cases, most of the systems dedicate a particular table number, so servers need to ensure they enter the predefined dummy table number while creating the order. Testers while testing should ensure that the order is tagged as ToGo if they use the table number dedicated for Togo. Online Ordering – In the case of online ordering the food is ordered via website/mobile and POS are integrated with the online system, so when the order is placed the POS DB gets updated, rest of the push to KDS and other systems can be manual/automated. Validating the Online Ordering system integrated with POS is a huge scope for testers as it extends opportunity where you can test the websites/mobile and POS as well. For Online Order table entry is not required, since guests order food online and do not visit the restaurant. |
| Creating a Check/Entering the Order | The Order Taking is still manual, so at some point, the server needs to come back and enter the same in the system (POS). The Order Entry is mostly termed as ‘Creating a Check’ For testing this functionality, testers should create orders by selecting items from the different menu, verifying by entering different quantities, removing items. |
| Order Modification/Add to Check | When the order is entered the very first time, the functionality is termed as Check Creation, now say a case where the guests want to modify their order which can be changing previously ordered item or asking for more quantities etc. In such cases, servers do not go and create new checks for same guests, what they do is modify the same check based on the order change. As testers, you should ensure validating the functionality where the POS system should allow for modifying same check, append an item, or increase quantity. Void an Item – Void terminology is used if an item has been ordered and later the guests decide to change or not take that item, in such cases, the servers uses the void functionality to void that item. |
| Payment/ Discounts/Coupons | Payment in restaurants can be done using any Mode– Cash Payment – If a guest decides to make payment through Cash, the server should ensure the mode of payment is selected as Cash while entering in POS. The remaining Cash, if any should be given back to the guests. Testers should ensure by testing the Cash Payment functionality by using different input combinations, testing for decimal amounts, negative amounts etc. Card Payment – Credit/Debit Card is the most used form of payment and this is also the most complex method when it comes to testing. Tester’s needs to ensure the credit card authorization works and this needs to be tested using a dummy environment since the transaction cannot be authenticated with real banks. Gift Voucher Payment – Many a times, the payment can be done using Gift Cards/Vouchers, it can also happen the full payment is done using GC/GV or partial payment. Important test scenarios should include validating the balance, expiry date before validating the payment functionality using GC/GV. Payment Using Coupons – Coupons are different to GV/GC. Coupons can be used as a direct amount or may be as a percentage. Hence, while testing, it needs to be taken care that valid coupon codes are tested and final amount calculates considers the entered coupon code. Sometimes the restaurant runs promotional offers where guests will be given coupon codes; such codes should be validated as part of coupon testing. Payment along with some Discounts – On several occasions guests are given a discount on the full check, say a 10% on the total bill, and on several occasions discount is on ordering particular food item. While testing, it is good to ensure validating the discount functionality by having a check with discounted as well as non-discounted items, payment by applying the discount % etc. Partial Payment – is also a very important mode where the payment can be done using two modes, say if a guests want to pay 50% by GV and remaining by Cash. The system should be validated to ensure partial payment works and the calculation works properly. The system, in this case, should allow an end user to enter two modes of payment, should calculate remaining payment by deducting the amount already paid using a different method. |
| Printing a Check | Printing a check is the functionality used by servers to print the check/bill which is given to the guests. Printing functionality can be validated by ensuring the correct menu items are displayed, with correct quantities and amount, tax amount, service charge, total payable amount, discounts if any, coupons used if any, on the check. Checks that are handed to the guests should display complete information. |
| Closing a Check | Closing a check means the Order is complete. A server closes the check after the payment is made. Closing the check also indicates that the current server is now available and the corresponding table is available for other guests. Testers can validate this functionality by trying to close a check before entering the payment detail and after entering the payment. |
Devices integrated with POS as KDS
Kitchen Display System (KDS) – Have you ever given a thought on how a restaurant manages its orders and serves its guests on time. Kitchen Display System is one of the most important devices used by restaurants.
KDS are display system with different monitor placed in the different location, it is connected to the POS, and this comes with features like displaying the order, routing it to the right station/location, and provides a warning to the kitchen staffs if the item has been taking too long.
KDS works based on the configuration done in the backend system, while testing, testers should ensure to test with all combination of configurations, hence KDS testing itself is considered to be a big module for the scope of testing. It also requires proper setup before this can be tested.
| Key Activities in KDS | What Testers can do |
|---|---|
| Ensuring Items are pushed to correct location | KDS have different display system in different locations like some items needs to be grilled, some need to be cooked, hence based on the items ordered, the items should be routed to correct display system. This can be tested by creating orders having different items from all categories and ensuring the items are pushed to the right location. |
| Clearing/Bumping Orders | When the orders are prepared and served, the servers are required to clear the KDS system; usually, there will be a button to bump the orders. Clearing can only happen after a certain status like prepared though it varies from system to system and configuration. |
| Colour Changing Functionality | The items displayed changes colour on the display system based on whether they are new, prepared or have been there for longer than expected time. It is important to test by configuring the system as per test needs and ensuring the status and colour changes if the time has crossed. Many updates are done manually, but if the item has been waiting to be prepared for a long time, the colour changes automatically to raise a warning alert. |
[image source]
Different Systems integrated with POS
A lot of other systems are integrated with the POS, some fall under Back of House functions and some are corporate level functions. Combined together all the systems are required for a restaurant to operate successfully.
Workforce Management
Workforce Management refers to the system which mainly deals with Employees.
WFM or the HRMS system in any organization provides a method to monitor employee productivity, maintain payroll, leave and absence tracking, and time tracking. Restaurants, like any other organization, also maintain a WFM system that is integrated with their POS.
Most of the time the configurations are done in the WFM app/tool and settings are pushed to POS system.
Features that can be tested as part of Workforce Management
- Employee Scheduling – This tool or utility lets manager schedule their employees. For successful running of a restaurant, a floor manager is required to ensure all types of employees are available during the restaurant open time. Restaurant employees usually work in shifts and it’s the manager’s responsibility to manage shift employees. Like in any shift, you would require a server, cook, dishwasher etc. As Testers, testing the scheduling function would include scenarios like validating if a manager is able to create a schedule, a manager should not be able to schedule and employee twice in the same shift, there should be a check on the total scheduled time.
- Employee Clock in/Clock Out – This basically tracks the timing an employee clocks in and clocks out. This functionality can well be validated against the schedule. Say, a server was scheduled to clock in at 9AM, and if the server tries to clock in at 10AM, the system should throw some warning or require some sort of override.
- Employee Payroll – One of the most important and complex areas. For validating, employee payroll testers needs to be aware of the labor laws of that particular country. Say in restaurant industry server (FOH) employees have fewer wages because they get a chance to earn tips from guests and BOH employees like Cook has a higher wage because they are not exposed to guests directly. While validating Payroll system, testers should ensure the configuration done for employee wages meets the law.
- Employee Absence/Leave – Such systems allow you to track employee leave and absence so the managers can ensure their day to day restaurant operation remains unaffected.
Inventory & Supply Chain Management
Inventory means stock hence Inventory and Supply Chain Management is a system that takes care of a restaurants inflow and outflow of material.
This system keeps track of the complete inventory, the number of units purchased vs. consumed. Store managers view the inventory reports and take a call if new units are required to be purchased. Testers should validate by ensuring system allows entering the correct quantity and raises alerts or warns if inventory goes low.
Menu Management
A Restaurant runs by maintaining a huge range of menu or list of food items, hence a separate system is required to manage the menu. The menu would require categorization of an item, tagging to a pricing level. When you visit the restaurant, you select items looking into different categories like the main course, desserts etc.
Such categorisations are taken care by the Menu Management system. The settings are done centrally and pushed to POS. Testing such system requires testers to create menu items with different combinations and validating the changes are pushed correct to the POS system.
Pricing Management
All the food items that get sold requires being tagged with a price.
Most restaurants operate pricing tiers where they tag different types of goods with different pricing levels. In order to test the Pricing system, a tester needs to be aware of the pricing model used by the restaurant and ensure to include test cases which would test items from all price levels.
Price levels are set and maintained at the corporate level and then imported into POS at store level because maintaining it at local level becomes difficult.
Conclusion
Though the scope of Restaurant POS testing is huge and I couldn’t cover everything in detail in this article, you are most welcome to reach out to me if you have any more questions or need more detail on any particular section.