It is common in the Convenience and Retail Petroleum industry to use the term POS (Point Of Sale) to refer to all of the site components that the consumer interfaces with or is used to process/impact a purchase of fuel or store merchandise. This clearly includes POS, EPS (Electronic Payment Server), FCC (Forecourt Controller), CATs (Card Activated Terminals), and all the networking equipment. It is an easy stretch to also include electronic price signs, back office systems, safes, etc. The off-site systems that receive/send information from the site systems must clearly also be included. This includes the payment transaction processing hosts, settlement systems, pricing systems, etc. The required connectedness of retail systems is really quite complex.
What is “Quality”?
Quality can basically be defined by “functional” – does it work as planned, and “performance” – does it execute as fast and consistent as planned. Obviously, in any retailing/customer service environment, both are critical. The following characterizations apply: correct, accurate, consistent, reliable, stable, responsive, and quick.
Quality also must address normal and abnormal situations. This leads to the many use cases which represent planned and unplanned sequences of consumer interaction, high transaction volume situations which potentially stress the systems, and the frequently comical sequence of events that consumers often attempt.
How is it Impacted?
Any and all changes to any component in the integrated set of retail systems has the potential to impact the quality. This includes hardware, operating system, network, security rules, and all the application software. Testing is basically a risk management exercise and it is advised to approach testing from a skeptical perspective rather than assuming some obvious functions will work fine. The better the systems are architected, the easier it is to isolate testing to affected functions. Limiting and understanding changes enables a clearer view of what needs to be tested and how best to test – you can turn up testing processes quickly once scope of changes are well understood.. Having a detailed well-organized test plan with static test data and expected output supports expedited testing.
Who Tests it?
Many different stakeholders need to “test” the changed application. Their scope and focus varies by the risk they are trying to minimize. It may be best to describe this by stating some hypotheses on the dynamics of the stakeholders:
- No entity cares more about the consumer experience than the merchant/retailer.
- Consumers are fickle – one bad experience may cause a consumer to leave and never come back. This translates to the need for consistently good operations.
- Testing costs and takes time. Budgetary limits and quick time-to-market are not aligned with quality testing.
- Coordinating all the stakeholders is non-trivial.
- The networks and processors will test only their functionality, not the combination of programs that occur in reality.
- The cost for the product vendor to test all combinations of networks, processors, hardware, dispensers, backoffice, etc. is prohibitive.
- POS vendor stickiness in this industry is very high. The cost of change is huge.
- Contractual support for improvement is weak across the industry, at best.
- Holding product vendors accountable for poor software quality will cost something (e.g. establishing dependable regression tests).
What’s Ahead?
Most everyone complains about quality today (never say “all” and never say “never”). The complexity of retail systems is increasing combinatorially as EMV is deployed, more loyalty and mobile programs are implemented, more choices for networks come to market, remote asset management tools are created, security tools propagate, etc. The dynamics stated above are going to intensify. The first step to improve this situation is to realize and accept the challenge.
“Smart” Testing
As the complexity of retail systems increases, a collective approach on testing must be agreed and documented and must focus on what must be tested. We cannot afford to test everything. Time will be well spent in the test planning phase determining exactly what must be tested and how. Improved architectures of the primary applications and the increased adoption of standards should allow us to better isolate the impact of changes and develop laser-focused test plans that can be executed efficiently. Documentation of changes for a new release will be critical since that is the basis of test plans. Retailers must demand that these “release notes” be thorough and available early on in the development cycle. This will provide adequate time to the testing community to develop appropriate test plans. This should be much more of a science than an art.
Product vendors and retailers who invest in this now will be better off and will serve their consumers better in the future.
For more information, please reach out to Pat Raycroft at [email protected]
