Image-Based Testing for ATMs and New Device Categories
by Antony Edwards, on 11/9/17
Note: Back by popular demand, this is a repost of a previous blog by Antony Edwards.
SciFi worlds from the 1980s always included super powerful, intelligent computers that you could talk to. By the late 90s, the vision had moved on to worlds where everything is a computer and connected; maybe even us. And it’s this ubiquitous computing that I think is the most exciting and interesting part of technology: new device categories.
I like to think that Testplant plays a role in this story by helping people test new device categories and existing device categories that are becoming smart. Connected cars, vending machines, drones, washing machines, and payment systems—Eggplant solutions are used to test all these devices. It’s a perfect example of the strengths of image-based testing that we’ve been able to test the GUIs on all these systems (and we are focused here on the GUI testing) without any modification of Eggplant Functional.
There are three reasons image-based UI testing (and Eggplant Functional) can easily test all these new device categories:
- Technology independent. Different device categories typically run different software stacks. Operating systems are becoming more standard, but there are still many OS choices for embedded devices, and even the standard ones (e.g., Linux and WinCE) are often heavily customized. At the UI framework level, most new device categories are completely bespoke. So, the fact that image-based testing doesn’t care—at all—about the underlying implementation technology is key.
- System-level events. Most test tools inject events directly into the application being tested, but image-based testing (or at least Eggplant Functional) injects events at the system level. This may sound like a technical detail, but it's very important because it means that the testing tool can inject events it knows nothing about. The testing tool doesn’t need to know how many hardware buttons a particular ATM has and it doesn’t need to know the details of a card-inserted event on a payment system. So the testing tool can test systems it hasn’t seen before, without modification.
- Two-system model. Image-based testing tends to favor a two-system model, that is, the testing tool runs on a separate computer to the system under test (SUT). Most test automation tools assume that the testing software is running on the SUT (mobile testing tools are all two-system models). Obviously, you’re not going to port the testing tool to a washing machine, so testing new device categories almost always requires a two-system model, and so image-based testing is a natural approach.
My favorite example is testing ATMs (cash machines)—we’ve worked on several projects to help banks automate the testing of ATMs. They may not sound like the newest of devices, but ATMs are becoming much smarter as they continue to serve as one of the most common touchpoints between banks and their consumers.
ATM testing with Eggplant Functional
How can Eggplant Functional test an ATM? For connectivity, we use a KVM-IP switch. This is a standard hardware device that plugs into the standard I/O ports of the ATM, exports the display, can raise button-press events, and can raise touchscreen events. The KVM-IP switch includes a VNC server which means that Eggplant Functional can connect to and control the KVM-IP device and hence the ATM. From there, Eggplant Functional simply behaves as normal: It can see the screen, it can read balances and other information, it can press buttons, and it can tap the screen. That’s it. The tester doesn’t need to know any technical details of the ATM, they just need to know how to use an ATM, and if they are familiar with Eggplant Functional, they can immediately start creating automated tests.