terminal software has undergone major changes in the last few years. Complexity has increased manifold. Acquirers have always tried to facilitate the needs of their merchants with special features. But now we have seen the introduction of contactless (PayPass,
payWave etc), touch screens, app eco-systems (e.g.
CBAs Albert), mpos (e.g. Square) and many more.
One thing that has not changed is the strong demand of merchants for stable and reliable payment systems. If merchants can’t take payments, they lose revenue.
This means that terminal software vendors need world-class EFTPOS terminal testing and QA to uphold quality to keep pace and produce complex software.
A strong focus on testing has been introduced in software engineering years ago (e.g.
Test Driven Development). Modern software applications undergo a large number of automated tests before they are released. This trend has also arrived in EFTPOS software engineering,
but only to a certain extent. A key challenge is the involvement of different hardware components as key features of the terminals. To really test the unit as a whole, you need to press the keys and swipe the cards.
Unexpected Benefits from automated EFTPOS terminal testing
As terminal software engineers, we have been working on our test setup for over a decade. We started with simple simulators and have now arrived at a solution that includes a PIN and card entry
robot. Today, we can automate large parts of our testing. We for example do 80% less manual regression testing. We are on a path of continuous improvement. Our goal is to create
better quality software for our clients and for our testers to actually engineer tests instead of just running through test scripts. With the introduction of the robot we have made a significant step towards this goal. Interrestingly, the obvious benefits
of automation were were accompanied by a number of other very positive changes that were unexpected. Here is list of a few things that changed for us after test automation:
- Significant reduction of regression test time
- Better test quality, because the test tooling enforces the test staff to create clearly defined tests
- Increased number of test cases, as test staff are now busy creating new tests, instead of executing tests
- Introduction of load tests. These helped us to find a number of bugs that affected stability and caused issues that were extremely hard to find before.
- Our development team is more confident to make changes, as they know that the software will be tested well. Previously, we were more hesitant to touch certain areas of the code
- We managed to reduce our backlog of tasks and bugs by approximately 80% and keep it on that level
- Our test staff feels empowered, as their work is now more knowledge based and less repetitive and less operative
I am happy to share some of our experience. What is yours?
Come with us on a journey of continuous improvement!