Automating Point of Sale (POS) Testing

Vendors of Point of Sale (POS) applications, system integrators and retailers that develop or customize packaged solutions should make implementing test automation a priority within their testing associations. Not only is automating a cash register possible, it turns out that POS gives a superb candidate for test automation, where a high amount of coverage and a fantastic return on investment can be quickly achieved.

Executive Overview

Vendors of Point of Sale (POS) applications, system integrators and retailers that develop or customize packaged solutions should make implementing test automation a priority within their testing associations. Not only is automating a cash register possible, it turns out that POS gives a superb candidate for test automation, where a high amount of coverage and a fantastic return on investment can be quickly achieved.

To decrease test creation, data management and evaluation maintenance times, QualiTest has partnered with Zeenyx Software, with its flagship product AscentialTest in customer engagements, which supports a huge array of terminal-based emulators.

Zeenyx has had the chance to develop automated testing suites for two of New England’s biggest retailers. Through these engagements, they’ve developed templates which may be ported from 1 POS application to another, minimizing the time to implement test automation, while providing a way for non-technical users to create automated tests without needing to learn how to write scripts or use an ineffective record/playback tool.
Equally significant for these customers was the requirement to decrease test creation, data management and evaluation maintenance times, and collapse testing cycles. Another substantial customer requirement was the ability to leverage one testing solution for both shop and e-commerce websites.
The purpose of this paper is to give a detailed comprehension of the concepts, elements and techniques necessary for automating the testing of a POS system utilizing AscentialTest from Zeenyx Software.
Although the examples in this paper website experience with Coalition, Triversity and Fujitsu POS applications, the templates may be applied to any windows or web-based POS application.


The first issue that might be encountered when trying to configure the test environment is lockdown. POS devices are generally configured to protect against any foreground program application from running on the cash register. Since our testing broker, UA Server, runs in the background and is known as a test controller running on a different machine, this safety policy poses no difficulty.

In a standard POS laboratory, a testing tool will reside on a Windows-based machine that’s connected via TCP/IP into the cash register where the broker is operating. UA Server can be invoked remotely or locally before the POS software is launched.

Peripheral devices pose another challenge. Some POS systems, such as the one displayed in Figure 1, provide configuration settings that permit the user to disable the receipt printer and the cash drawer. Whereas the printer might be allowed for tests where a’legal’ receipt is retained for a possible audit, it’s disabled in others to avoid POS from requiring the consumer to frank a record in the middle of a test (See Special Topics for more conversation on franking).

In other circumstances, the petition for franking could be averted in the evaluation by simply hitting the key or waiting for a timeout to elapse.

The cash drawer is typically disabled in one of 2 ways, a software configuration or a 3″ by 3″ by 18″ block of wood fastened facing the drawer by a set of carpenter’s vices. No kidding. It works really well!

There’s also the question about how to simulate a scan or a swipe and you will find two unique approaches.
The first is to use a simulator that’s available from the majority of the POS vendors. A simulator can
be predicted in the test script so it will become a seamless part of their automatic
transaction. Another approach is to enter SKUs that would otherwise be scanned and credit card
amounts that would come out of a swipe straight from the keyboard.
In actuality, all these inputs will need to be tested to a degree, but just a small number of the
total test coverage need come straight from the peripheral devices. It’s very important to demonstrate
the interface between the peripheral and the POS software is functioning correctly, but the
bigger part of a regression test can be supported with the computer keyboard or a simulator as the input
device of choice. The keyboard and the touch mouse or screen are peripherals for which
AscentialTest has built-in support so there are no special considerations for POS.

Test Architecture

The AscentialTest automated test framework for POS is comprised of a set of evaluation programs, a library of customizable measures for the various transaction types, and a data table to store test data. This
Frame is available for analyzing any POS application that runs on MS Windows or the internet.

The framework promotes rapid execution of test automation for POS. It’s highly modularized, separating test programs, test steps and test information to market both portability and maintainability. Among the fundamental requirements of its design is that it reduces the amount of work necessary to keep tests across variations of the POS application. Creating tests is a process of assembling components as opposed to recording or scripting. Anyone with domain experience can build test cases using this approach.
The measures that form the basis of the framework can be broadly described in two classes, the ones that automate the activities of the cashier navigating through POS to complete transactions and the ones that capture data from POS and other retail applications to check the results of the test.
Though the actual results of these tests are recorded from several varied sources such as the Virtual Receipt, Electronic Journal, Credit Authorization module and any number of database
systems, the results are normalized to a standard format for simple comparison to the anticipated results that are automatically generated based on test inputs.
This approach not only enables testers to construct tests quicker, it reduces test case maintenance and promotes reuse of evaluations across states/counties where taxability differs.

The Library of Test Steps

There are several different components of the test frame that address the parts of POS such as the Cash Register GUI, Electronic Journal, Credit Authorization module and some other
Number of databases which store information such as Store Value Card receipts and data for refund processing.

Each of these elements is known as an object in the project repository and is supported by a library of measures that are utilised to develop automated tests. Modularization is very important to support portability from 1 POS system to another and to minimize maintenance.

Cash Register GUI

The Cash Register GUI, such as the one displayed in Figure 2, is the most concrete part of the POS system.
The first requirement of the test tool is to comprehend application items. Object recognition is essential to encourage context synchronization. Cash registers prompt the cashier for advice once the register is in a ready condition to get it. Even though some keystrokes could be buffered, it’s very important to keep tests in synch with transaction flow so that keystrokes aren’t lost. Tests should be made to synchronize input depending on the display of drives in precisely the exact same way that the cashier waits to be directed through each transaction. Object recognition is also essential to interact with buttons, edit boxes and other controls to navigate via the POS application.

When mistakes are found or unexpected conditions occur during a test, a transaction may be aborted before completion, leaving the cash register in an unknown condition. A special recovery mechanism has to be implemented to ensure that the POS system is returned to the beginning state before the start of each test. The recovery step finds the condition of the system based on prompts. After the application isn’t in the starting state, it cancels or completes the current transaction. A POS recovery measure template is readily customized to deal with any condition in which the register might have been left.

POS testing is transaction based. To promote a system where tests are easily constructed and maintained, a library of measures is developed to function as the building blocks for automated transactions. Transactions are divided into measures, which are shared amongst multiple transaction types.

By way of instance, after a cashier inputs the items and discounts which include a sale, the transaction will have to be tendered. The actions required to tender a sale will be just like those required to tender a positive trade, layaway deposit or any variety of transaction types. Reusable measures are encapsulated so they may be called from evaluations of some of the transaction types that need tendering.

By breaking down tests to small reusable pieces, no job is replicated and maintenance is kept to a minimum. The following are descriptions of a small sample of measures for your cash register GUI:


In most POS systems, item entry contains some or all of the following: Department, SKU, Quantity and Price. In other situations, Price is looked up in a database referred to as the PLU. Figure 3 below shows the EnterItem measure that’s called from any test that calls for inputting a product.


There are measures available to handle tendering for each tender type. TenderWithCash is easy because in many instances it’s not necessary to define the quantity of money, unless of
course the aim of this test is to make certain that the proper quantity of change is calculated. Figure 4 below is an illustration:

Like TenderWithCash, this is a good example of a’tender’ method that inputs the credit card number and effective date with the register’s keyboard or calling an API to simulate a swipe.

This step encapsulates the tasks done to find the items, prices, quantities, subtotal, tax amount and complete from the graphic representation of the receipt that is typically shown on the cash register GUI known as the Virtual Receipt. That information is saved for comparison against the anticipated results and other information that is recorded during the test.

The library comprises measures like those described previously for parts of each the transactions which can be completed via the cash register including Sale, Return, Exchange, CashPickup, MediaExchange, PettyCash, PostVoid, StoreValueCardPurchase, etc..

The Electronic Journal

The Electronic Journal (EJ) is among the chief targets for confirmation of each POS transaction. In some POS systems, it’s an electronic picture of the register receipt in text file format. In others, it offers the details of the transaction in XML or database format. Regardless of format, the details of the transaction are recorded from the EJ so that they may be compared to the anticipated results, Virtual Receipt along with other applications in the POS system. Even though the format of this receipt for every transaction type can fluctuate widely, the results are normalized to the standard format for simple comparison.

Database Access

Even with PCI Compliance which discourages storage of customer data, there are a whole lot of other kinds of sales related information stored in database format necessary for input or confirmation of automatic tests, (e.g. Shop Value Card accounts and limitations, items, prices and quantities from saved receipts, etc.). By embedding SQL queries, template measures can easily be customized to capture information from these information sources.

Credit Authorization:

One of the key interfaces to the POS system is the Charge Authorization module in which requests for approval for checks and credit cards are created. Responses are recorded so that they can be compared to the anticipated results predicted for POS transactions. Based on the arrangement of the replies, they may be captured from a GUI that shows the results of each petition or parsed from a log file. Irrespective of how the responses are displayed, they are normalized to the normal results format so they can be readily compared to other outcomes captured during the test.

The Test Plan

The Evaluation Plan is a natural language description of evaluation objectives in outline form. It records the test requirements and plan.
An outline is an efficient form of notation as it allows tests to be grouped, where evaluation requirements are shared with multiple test cases. Where a list of test cases would need a good deal of repeated speech, an outline makes it possible for a requirement to be mentioned once and then”inherited” from the outline levels nested under it.
A POS evaluation plan describes each transaction to be analyzed together with necessary test requirements. Figure 5 displays a section of the test plan template. The symbol [+] suggests that the line could be expanded to see hidden detail. In this instance, if the charge card line in the fly-out on the perfect line were to be enlarged, a list of those credit cards to be analyzed would be exposed.

A fully qualified evaluation is described in one or several levels based on the richness of their test requirements for any given feature. An example of the entire description of a Sale transaction may be read as follows:”Big POS Regression Test / Client Transaction / Revenue / Frequent Sale / Credit Card / VISA / Approval Expected”.
If the evaluation plan were fully expanded, the lowest level branches of the tree could be reached. The terminal nodes, those who have no children, contain just a TestCaseID, which corresponds to a line(s) in a data table, where the test case data that fulfills the demands of the test is saved.

Test Data

Test Data contains the particular inputs such as SKUs, quantities, prices, tender types, etc., that satisfy the needs of the evaluations described in the Evaluation Plan. Each row has an integral field named TestCaseID that corresponds to the test in the Test Plan. The remaining columns in the row contain inputs that are consumed by the measures that execute the automatic activities of the cashier.

The Process of Construction Tests

Once all the components are customized to the POS system being analyzed, anyone in the business with domain experience in POS can build tests. It’s an easy, three step procedure.

  1. The test designer begins with a template test program and modifies it to meet the needs of the POS application being analyzed. Test cases can be added, deleted or altered.
  2. Automatic and manual tests are made by dragging reusable steps inside the test editor.
  3. Then, test case data is added to the data table to offer the inputs for each evaluation. It’s not necessary to understand programming concepts or possess more than a basic understanding of the testing instrument to make tests in this test system.

Running the Tests

Tests are conducted directly from the Test Plan. With a few exceptions explained later under Special Topics, automatic test cases are designed to be run unattended on a single or multiple targets. Suites may be run for minutes, days or weeks depending on the number of tests are selected. Once test execution is finished, results are presented within the context of this Test Plan.

A summary including the amount of successful vs. failed instances together with a range of errors is presented on peak of the report. Details are provided where mistakes occur, such as a comparison of the actual and anticipated benefits.

Special Topics


To get the maximum benefit from automatic testing, tests could be conducted across multiple divisions, counties, states, etc., where setup might be required. By way of instance, to be able to automatically create an expected total for a sale, it’s essential to understand the state where a test has been run. Since manual configuration is error prone, values like state tax rate are looked up in POS data resources. Automatic lookups not only save time, but they also reduce test case maintenance by capturing current values.


To promote reuse of test cases across localized POS systems, strings for drives and other
Displayed data are separated from measures and substituted with global variables which could be readily
substituted with native language strings (Figure 6).

Semi-automated test cases for franking

Whereas many automated tests are meant to operate in unattended mode, there are many others that take a record to be franked throughout the transaction. These automated tests are made to operate to the purpose of franking, where they then await a response for the consumer. After franking is complete, the user clicks a button to keep the test to end.


By combining QualiTest’s comprehensive testing solutions with AscentialTest’s capacity to decrease test creation, data management, and evaluation maintenance times, QualiTest can significantly collapse testing cycles for Point of Sale (POS) applications.
Customer return on investment (ROI) is further enhanced by using predefined POS templates and leveraging one testing solution for both shop and e-commerce websites, resulting in improved software quality.

Leave a Reply

Your email address will not be published. Required fields are marked *