Automating Point of Sale (POS) Testing
-
Feb 25, 202115 min read
Vendors of Point of Sale (POS) software, system integrators and retailers who develop or customize packaged solutions should make implementing test automation a priority in their testing organizations. Not only is automating a cash register possible, it turns out that POS provides an excellent candidate for test automation, where a high degree of coverage and a good return on investment can be quickly achieved.
To reduce test creation, data management and test maintenance times, Qualitest has partnered with Zeenyx Software, using its flagship product AscentialTest in client engagements, which supports a wide variety of terminal-based emulators.
Zeenyx has had the opportunity to develop automated testing suites for two of New England’s largest retailers. Through these engagements, they have developed templates that can be ported from one POS application to another, minimizing the time to implement test automation, while providing a means for non-technical users to create automated tests without having to learn how to write scripts or use an inefficient record/playback tool.
Equally important for these clients was the need to reduce test creation, data management and test maintenance times, and collapse testing cycles. Another significant client requirement was the ability to leverage a single testing solution for both store and e-commerce sites.
The purpose of this paper is to provide a detailed understanding of the concepts, components and techniques necessary for automating the testing of a POS system using AscentialTest from Zeenyx Software.
Although the examples in this paper site experience with Coalition, Triversity and Fujitsu POS software, the templates can be applied to any windows or web-based POS application.
The first issue that may be encountered when attempting to configure the test environment is lockdown. POS devices are typically configured to prevent any foreground software application from running on the cash register. Since our testing agent, UA Server, runs in the background and is called from a test controller running on another machine, this security policy poses no problem.
In a typical POS lab, a testing tool will reside on a Windows-based machine that is connected via TCP/IP to the cash register where the agent is running. UA Server can be invoked remotely or locally before the POS software is started.
Peripheral devices pose the next challenge. Some POS systems, like the one displayed in Figure 1, provide configuration settings that allow the user to disable the receipt printer and the cash drawer. Whereas the printer may be enabled for tests where a ‘legal’ receipt is kept for a possible audit, it is disabled in others to prevent POS from requiring the user to frank a document in the middle of a test (See Special Topics for more discussion on franking).
In other cases, the request for franking can be averted in the test simply by hitting the <Escape> key or waiting for a timeout to elapse.
The cash drawer is typically disabled in one of two ways, a software configuration or a 3” by 3” by 18” block of wood secured in front of the drawer by a pair of carpenter’s vices. No kidding. It works extremely well!
There is also the question about how to simulate a scan or a swipe and there are two different approaches.
The first is to use a simulator which is available from most of the POS vendors. A simulator can
be called from the test script so that it will become a seamless part of the automated
transaction. Another approach is to input SKUs that would otherwise be scanned and credit card
numbers that would come from a swipe directly from the keyboard.
In fact, all of these inputs need to be tested to some degree, but only a small percentage of the
overall test coverage need come directly from the peripheral devices. It is important to prove
that the interface between the peripheral and the POS software is working properly, but the
larger part of a regression test can be validated using the keyboard or a simulator as the input
device of choice. The keyboard and the touch screen and/or mouse are peripherals for which
AscentialTest has built-in support so there are no special considerations for POS.
The AscentialTest automated test framework for POS is comprised of a set of test plans, a library of customizable steps for the various transaction types, and a data table to store test data. This framework is available for testing any POS application that runs on MS Windows or the web.
The framework promotes rapid implementation of test automation for POS. It is highly modularized, separating test plans, test steps and test data to promote both portability and maintainability. One of the basic requirements of its design is that it minimizes the amount of effort required to maintain tests across versions of the POS application. Creating tests is a process of assembling components rather than recording or scripting. Anyone with domain expertise can build test cases using this approach.
The steps that form the foundation of the framework can be broadly described in two categories, those that automate the actions of the cashier navigating through POS to complete transactions and those that capture information from POS and other retail applications to verify the results of the test.
Although the actual results of the tests are captured from many diverse sources including the Virtual Receipt, Electronic Journal, Credit Authorization module and any number of database systems, the results are normalized into a standard format for easy comparison to the expected results which are automatically generated based on test inputs.
This approach not only allows testers to build tests faster, it reduces test case maintenance and promotes reuse of tests across states/counties where taxability differs.
There are several different components of the test framework that address the parts of POS including the Cash Register GUI, Electronic Journal, Credit Authorization module and any number of databases that store information like Store Value Card data and receipts for refund processing.
Each of these components is recognized as an object in the project repository and is supported by a library of steps that are used to build automated tests. Modularization is important to support portability from one POS system to another and to minimize maintenance.
The Cash Register GUI, like the one displayed in Figure 2, is the most tangible part of the POS system.
The first requirement of the test tool is to recognize application objects. Object recognition is necessary to support context synchronization. Cash registers prompt the cashier for information when the register is in a ready state to receive it. Although some keystrokes may be buffered, it is important to keep tests in synch with transaction flow so that keystrokes are not lost. Tests should be designed to synchronize input based on the display of prompts in the same way that the cashier waits to be guided through each transaction. Object recognition is also necessary to interact with buttons, edit boxes and other controls to navigate through the POS application.
When errors are found or unexpected conditions occur during a test, a transaction may be aborted before completion, leaving the cash register in an unknown state. A special recovery mechanism needs to be implemented to ensure that the POS system is returned to the starting state before the beginning of each test. The recovery step detects the state of the system based on prompts. When the application is not in the starting state, it either cancels or completes the current transaction. A POS recovery step template is easily customized to handle any state in which the register may have been left.
POS testing is transaction based. To promote a system where tests can be easily built and maintained, a library of steps is developed to serve as the building blocks for automated transactions. Transactions are divided into steps, which are then shared amongst multiple transaction types.
For example, once a cashier inputs the items and discounts that comprise a sale, the transaction will need to be tendered. The steps required to tender a sale are the same as those required to tender a positive exchange, layaway deposit or any number of transaction types. Reusable steps are encapsulated so that they can be called from tests of any of the transaction types that require tendering.
By breaking tests down into small reusable pieces, no task is duplicated and maintenance is kept to a minimum. The following are descriptions of a small sample of steps for the cash register GUI:
EnterItem:
In most POS systems, item entry includes some or all of the following: Department, SKU, Quantity and Price. In other cases, Price is looked up in a database table referred to as the PLU. Figure 3 below shows the EnterItem step that is called from any test that calls for entering an item.
TenderWithCash:
There are steps available to handle tendering for each tender type. TenderWithCash is simple because in many cases it is not necessary to specify the amount of cash, unless of course the objective of the test is to ensure that the proper amount of change is calculated. Figure 4 below is an example:
TenderWithCreditCard:
Like TenderWithCash, this is an example of a ‘tender’ method which inputs the credit card number and effective date using the register’s keyboard or calling an api to simulate a swipe.
CaptureVirtualReceipt:
This step encapsulates the tasks performed to get the items, prices, quantities, subtotal, tax amount and total from the graphical representation of the receipt that is typically displayed on the cash register GUI called the Virtual Receipt. That information is stored for comparison against the expected results and other data that is captured during the test.
The library contains steps like those described above for parts of all of the transactions that can be completed through the cash register including Sale, Return, Exchange, CashPickup, MediaExchange, PettyCash, PostVoid, StoreValueCardPurchase, etc.
The Electronic Journal (EJ) is one of the primary targets for verification of every POS transaction. In some POS systems, it is an electronic image of the register receipt in text file format. In others, it provides the details of the transaction in XML or database format. Regardless of format, the details of the transaction are captured from the EJ so that they can be compared to the expected results, Virtual Receipt and other applications in the POS system. Although the format of the receipt for each transaction type may vary widely, the results are normalized into the standard format for easy comparison.
Despite PCI Compliance which discourages storage of customer data, there are a lot of other types of sales related information stored in database format needed for input or verification of automated tests, (e.g. Store Value Card balances and limits, items, prices and quantities from stored receipts, etc.). By embedding SQL queries, template steps are easily customized to capture data from these data sources.
One of the primary interfaces to the POS system is the Credit Authorization module where requests for approval for checks and credit cards are made. Responses are captured so that they can be compared to the expected results predicted for POS transactions. Depending on the format of the responses, they can be captured from a GUI that displays the results of each request or parsed from a log file. Regardless of how the responses are displayed, they are normalized to the standard results format so that they can be easily compared to other results captured throughout the test.
The Test Plan is a natural language description of test objectives in outline form. It documents the test requirements and strategy.
An outline is an efficient form of notation because it allows tests to be grouped, where test requirements are shared by multiple test cases. Where a list of test cases would require a lot of repeated language, an outline allows a requirement to be stated once and then “inherited” by the outline levels nested beneath it.
A POS test plan describes each transaction to be tested along with necessary test conditions. Figure 5 displays a section of the test plan template. The symbol [+] indicates that the line can be expanded to view hidden detail. In this example, if the Credit Card line in the fly-out on the right line were to be expanded, a list of the credit cards to be tested would be exposed.
A fully qualified test is described in one or several levels depending on the richness of the test requirements for a given feature. An example of the full description of a Sale transaction could be read as follows: “Large POS Regression Test / Customer Transaction / Sales / Regular Sale / Credit Card / VISA / Approval Expected”.
If the test plan were fully expanded, the lowest level branches of the tree would be reached. The terminal nodes, those with no children, contain only a TestCaseID, which corresponds to a line(s) in a data table, where the test case data that fulfills the requirements of the test is stored.
Test Data contains the specific inputs including SKUs, quantities, prices, tender types, etc., that fulfill the requirements of the tests described in the Test Plan. Each row has a key field called TestCaseID that corresponds to the test in the Test Plan. The rest of the columns in the row contain inputs that are consumed by the steps that carry out the automated actions of the cashier.
Once all the components have been customized for the POS system being tested, anyone in the organization with domain expertise in POS can build tests. It is a simple, three step process.
Tests are run directly from the Test Plan. With some exceptions described later under Special Topics, automated test cases are designed to be run unattended on a single or multiple targets. Suites can be run for minutes, hours or days depending on how many tests have been selected. Once test execution is complete, results are presented within the context of the Test Plan.
A summary including the number of successful vs. failed cases along with a number of errors is presented at the top of the report. Details are provided where errors occur, including a comparison of the actual and expected results.
To get the most benefit from automated testing, tests may be run across multiple divisions, states, counties, etc., where configuration may be required. For example, in order to automatically generate an expected total for a sale, it is necessary to know the state in which a test is being run. Because manual configuration is error prone, values such as state tax rate are looked up in POS data sources. Automatic lookups not only save time, but they also reduce test case maintenance by dynamically capturing current values.
To promote reuse of test cases across localized POS systems, strings for prompts and other
displayed data are separated from steps and replaced with global variables that can be easily
substituted with native language strings (Figure 6).
Whereas most automated tests are intended to run in unattended mode, there are others that require a document to be franked during the transaction. These automated tests are designed to run to the point of franking, where they then await a response for the user. Once franking is complete, the user clicks a button to continue the test to completion.
By combining Qualitest’s comprehensive testing services with AscentialTest’s ability to reduce test creation, data management, and test maintenance times, Qualitest is able to significantly collapse testing cycles for Point of Sale (POS) applications.
Client return on investment (ROI) is further increased by using predefined POS templates and leveraging a single testing solution for both store and e-commerce sites, resulting in improved software quality.
Qualitest is the world’s largest pure play software testing and QA company. Testing and QA is all that we do! We design and deliver contextualized solutions that leverage deep industry-specific understanding with technology-specific competencies and unique testing-focused assets. Qualitest delivers results by combining customer-centric business models, critical thinking and the ability to gain a profound comprehension of customers’ goals and challenges.
For more information on Qualitest services, please visit www.QualitestGroup.com.
Zeenyx Software Inc. was founded in 2006 by Brian Le Suer and Dave Laroche, former EVP of Research and Development and Chief Architect / Founder respectively at Segue Software. After leaving Segue, Brian and Dave worked together at Star Quality Consulting, a boutique consultancy serving Fortune 500 clients.
The goal of Zeenyx’s flagship product, AscentialTest, is to radically reduce test creation and maintenance times over previous generation automated testing products. Drawing on Dave and Brian’s experience as both product developers and consultants, AscentialTest was built around six key design criteria:
AscentialTest’s revolutionary step-based approach incorporates all six design criteria and has led to broad market acceptance across many different industries. AscentialTest is used by enterprise testing organizations at Fortune 500 companies, small one and two man testing teams at private firms, as well as multiple consultant organizations. Zeenyx Software is privately held and located in Hopkinton, Massachusetts.
For more information on AscentialTest, please visit www.Zeenyx.com.
