Customers shopping experience has been enhanced by retailers with sophisticated offerings such as multiple payment modes, self-service kiosks, gift cards or loyalty programs. Point of Sale or POS is one such inevitable convenience that retailers prefer for ease of business. Point of Sale/Service is nothing but a system which is a combination of hardware and software which helps process customer purchases. We may find the use of POS systems in retail Stores, restaurants, hospitals and almost everywhere these days where payments are involved. The easier and more seamless the transactions may seem, the more difficult and complex the backend gets. The system does not only accept payments but is also tightly integrated with warehouse, inventory management, purchase order and then share information with E-Commerce and Order management system standardization.
Testing Point of Sale
Retailers recognize that testing POS systems would provide an opportunity to shrink timelines, improve quality and reduce cost. Given the unique challenge with POS landscape it would be a daunting task to have tangible progress through testing. As stated above, if the system is so impenetrable what would be the test strategy to tackle the complexity? Automation testing couldn’t rather be the only solution considering the major implications of third party integration into the system, but it could majorly help in bringing down the labor/man hours while having the system intact and efficient.
With POS systems getting increasingly customized to retailer requirements, vendor level validation may be insufficient, requiring retailers themselves to invest in testing. Few challenges that vendors may come across are;
Long Test Cycles: Retail industry being fragile and customer becoming more impatient, faster time to market would hold the key to success. Reducing the test cycle time can be addressed using Test automation.
Scattered Deployment: POS being a complex system, the intricacy of integration and customization has forced multiple teams to work on it making it difficult to test due to scattered deployment.
Multiple Integrations: POS systems have a set of configurations that helps customers to customize the product according to their needs. This puts across the challenge of testing all possible scenarios which involves multiple integration and configuration changes.
Compliance: POS systems have a greater threat when it comes to tampering user data/transaction details and common issue of missing transactions. Utmost caution must be taken to adopt PCI-compliant, for tamper- proof infrastructure at all POS terminals
Peripheral Issues: POS operated with lot of peripheral devices associated towards the system. Validating their configuration and keeping the infrastructure intact would be a potential challenge.
How to start with Automating POS
Among all the speculation whether POS system can be automated or not, time has answered the question that it is possible. Automation testing practices if implemented efficiently can yield operative results in delivering high quality software while keeping the cost at bay. Business would definitely prefer saving time and money coming up with a test automation strategy. Test automation reduces the time to market of the product and decreases the testing cost while increasing test coverage and overall product quality. The automation strategy for POS should be designed using best practices of automation testing coupled with the requirements that cater to test the POS systems effectively. Below are few points that need to be considered before building up automation framework;
Selecting the Right Automation Tool: Choosing the best automation tool would hold the key to success of any project. It starts with the step to define your requirement on the purpose of testing and how robust it needs to be. Users may run different suites depending on the requirement which may vary from smoke test, functional test, regression test and provide feedback by viewing the log files to understand the success and failure of the suite. Once the requirements are well documented, precise and thoroughly reviewed the tool which can best meet the needs with lesser cost and implementation effort shall be considered.
For example, if an OMNIchannel retailer has to choose a right tool for automation testing what should be his lookouts,
- Which language or WPF applications is he going to operate, and what operating systems is he looking to test for?
- Is he just looking to test web application or considering support of mobile version of POS as well?
- If its mobile is it going to be Android or IOS ,or does he want to work with both operating systems
- What kind of testing (Unit, functional, regression etc.) is he looking for; does the Tool support maximizing return?
- How easy it is to provide input test data for complex or load tests?
Evidently, it makes it clear that choosing the right automation tool holds the key to your implementation considering the fact that each tool has its own challenges such as implementation complexity, usability aspects and cost-effectiveness.
Establishing your framework: After evaluating your tool, the crux of building automation testing would start from establishing the framework that would have a conceptual structure guiding the entity to expand in future. The framework should have a predefined set of processes which interacts between various components on which the scripts can be designed, deployed and executed. While testing POS, working on design patterns would be more efficient since it may show how to design the test suite which could be efficient and easy to maintain. To sustain low cost on maintenance it’s a must to minimize the code in such a way that we could reinvent or create it from scratch using existing functionality for common, generic or repeated operations. The more the framework could be reused the more the robust and portable it needs to be. Knowing your challenges in the form of Custom UI object and Dynamic UI while deriving the framework would help much in drawing down the cost and maintenance.
Scenarios to test: As stated earlier, the user must be aware about the test cases that could be automated with those that can only be tested manually. Preferably test cases that needs a lot of human intervention could be suggested to be automated with required data sets. Iterating processes could be ideal scenarios for automation, For e.g. The use case of purchase and return of a good using multiple payment methods and tenders could be one such scenario. Framework must contains use cases that are easy to adopt and fairly intuitive for new users. While your tests should be able to run on different software and hardware platforms and configurations, basic standardization and uniformity needs to be maintained for it to be robust and portable.
Interaction with third party tools: The success of implementation of automation testing would lie on how well the framework interacts with third party tools to accommodate fluctuating business needs. POS application generally interacts with multiple systems such as Merchandizing, Audit, e-commerce etc. While this increases the complexity of testing it also demands intense validation in terms of performance of the system that directly affects the business. To enhance the automation framework it should be volatile enough to integrate with third party applications. Configuration of test management tools, CI tools and extensive reports would be critical in creating a simple, flexible and scalable automation framework for POS.
As stated earlier, though POS system cannot be fully automated, users can accelerate their test design and development by automating the core system that would result in reduced cycle time. In-depth knowledge about POS systems and challenges associated with it should be addressed as priority while deriving your test strategy. Risk mitigation would only be possible when we have an effective test strategy which would help business to achieve their quality goals.
Latest posts by Naveen Srinivasan (see all)
- How to implement a robust Retail POS Automation testing strategy - May 25, 2017
- How continuous development shrinks cycle time between initiation and action - August 25, 2015
- Planning your browser compatibility tests - October 21, 2014