test automation for payment terminal applications€¦ · our test engineers can concentrate on...

Test Automation for Payment

Terminal Applications

Sari Salin-Tuomela

Co-Speaker – Jani Kytöaho.

Test Automation for Payment Terminal Applications

Case: Robot

Agenda for our presentation

• Short Intro to speakers Sari and Jani, and Nets• Products• Challenges in test automation for the products• Approach• (First)and Second Robot Solution• Technical description of the Robot• Benefits• Video• Future• Questions?

Who We Are

• Sari is Head of QA in IT Merchant Services, based in Finland Helsinki office.

• Long history with testing-related functions; coding and testing, coding test tools, test management, team lead, test training, etc.

• ssali@nets.eu

• Jani is DevOps Specialist in the POS team, based in Finland Helsinki office.

• Long history with embedded mobile sw development: System Specialist, Release Manager, Tech Lead and Team Lead.

• jkyto@nets.eu

NETS - INTRODUCTION

At Nets, we specialise in powering digital payments. We connect banks, businesses and consumers via an international network facilitating digital payments. Spanning across the Nordic region, we provide a broad range of card services, account services, and payment solutions for merchants.

Who we are

Our Full Nordic and Baltic Presence

Key services for customers

BANKING SECTORBANKS, BUSINESSES& PUBLIC SECTOR MERCHANTS

• Card schemes

• Direct debit schemes

• Electronic ID schemes

• E-invoice solutions

• Clearing services

• Card management services

• Acquirer services

• Back-end processing

• Issuer services

• BPO services

• Information services

• Digitisation services

• Mobile solutions

• Payment Terminal solutions

• Financial acquiring

• E- and m-commerce

• Prepaid and vouchers

IT Merchant Services

Testing Payment Terminal Applications

Payment Terminal CategoriesINTEGRATED MOBILE

INTEGRATEDCOUNTERTOPMOBILE UNATTENDED

iPP350(Communication

via ECR)

iWL250B(Bluetooth + ethernet)

iWL250G / 3G(GPRS or 3G)

iSMP(Bluetooth to mobile,

tablet or ECR)

iCT250E(Ethernet, standalone

or integrated)

PIN PAD iUP250

CONTACTLESS READER iUC180B

CARD READER iUR250

CONTACTLESS READER iUC150B

Spire Spg7(3G, GPRS)

Spire Spc5(LAN)

Payment Applications (PA)

• We have 300 000+ terminals on the market.

• We get the terminal HW and Operating System from the vendor and on top of these we build our own payment applications.

• We have currently 6 different payment applications on the market -the goal is to consolidate all these to only one payment application.

Challenges in PA Testing

• In addition to many types of terminal hardware there are also many different configurations of the payment terminal software.

• At one point we ended up with ~50 different configurations.

• We work in agile mode and need fast feedback on the product quality.

Challenges in PA Testing

• To automate testing of payment terminal software there is no commercial off-the-shelf software available.

• Security is top priority and we have no means to access the ”internals of the terminals”.

• We decided to try whether a physical robot simulating real users could solve our test automation challenge.• Proof of Concept.

Proof of Concept

• Relatively low-cost; do market research on available solutions• Open source sw• Able to run 24/7• Low-maintenance• Minimum human intervention• Easy-to-write tests• Start with simple functions like basic chip purchase• Vendor independent solution• Environment agnostic • Expandable (technically) and financially scalable (multiple Robots)

Challenges for the Robot

• How to handle different types and makes of terminals?

• How to press buttons on different terminal types?

• How to read the terminal display?

• How to verify (paper) receipts?

• How to feed the card to the TUT?• Chip card

• Contactless

• Magnetic stripe

• How to be able to use different test cards?

Our Approcah

• We looked into several alternatives, googled, contacted other companies, etc.

• Also looked at commercial solutions, from high-end industry robots to some payment terminal specific solutions.• Too expensive

• Were made to handle only one terminal

• Used proprietary software and didn’t fit into our ambition of using open source software

• Soon found ShapeOko 2.

First Robot Solution

DIY - assembled Modified for testing

First Robot Solution

• Ready at the end of 2015.

• ShapeOko 2 is a 3-axis open source CNC (Computerized Numerical Control) milling machine – DIY kit.

• Parts cost ~1500 eur.

• Cooperated with a Finnish company Eficode to build the Robot and the first version of the control library.

• Used for functional and non-functional testing.

• Can handle only chip cards.

Second Robot Solution

• Second Robot solution with ShapeOko 3 was ready last spring 2017.• Easier to assemble.

• Faster than first solution.

• More sophisticated card feeder and now also contactless arm included.

Benefits

• We can make the Robot execute the simplest tests. Our Test Engineers can concentrate on more creative and difficult scenarios.

• We can execute tests anytime, e.g. during the night and get results in the morning (from Jenkins).

• We can easily do long-period testing to see whether there are memory leaks or e.g. sw crashes.

• We improve test coverage, and overall quality.

Technical Description of the Robot

Brief Introduction of Robot Framework

• Default test automation framework in Nets

• Initially developed by Nokia Networks and is nowadays sponsored by Robot Framework Foundation

• Uses keyword-driven testing approach

• Can be extended by test libraries implemented either with Python or Java

• 0perating system and application independent

Problem 1: How to control the robot?

• Robot is controlled by sending serial data over USB port

• Most computers are able to do that

• Our selection was Raspberry Pi 3

Problem 2: How to move the robot?

• Robot is moved by sending commands with G-Code language

G01 F5000 X120.0 Y193.0 Z0.0

Movement type Speed X-coordinate Y-coordinate Z-coordinate

Problem 3: How to send coordinates?

• There are many software that can stream G-Code to the robot but none could be used with Robot Framework

• We wrote custom Robot Framework library to move the robot

Problem 4: How to make it easy?

• Button coordinates are predefined

• Testers don’t have to know how robot is moved. They should concentrate on writing test cases.

Problem 5: How to physically press buttons?

• Robot is originally made to cut materials like aluminum, wood or plastic

• We had to replace drill withfingerlike mechanism

• Best option was to design the finger by ourselves

3D-designing and printing

• We studied 3D-modelling and printing and experimented different solutions for the finger

• After few iterations we had a solution that was robust and accurate

Problem 6: How to read terminal screen?

• We didn’t have any software interface to read terminal screen

• Only option was to use camera to capture screen image

• Requirements for camera• Fast

• High resolution (HD or better)

• API to control image capturing

• The best option was to use camera module for Raspberry Pi

Problem 7: How to detect text from the image?

• We use optical character recognition (OCR) to detect if captured image has any text on it

• Tesseract was best option to do the OCR• Open source engine with wide OS support

• Good API

• Supports a wide variety of languages

• Highly configurable and can be trained to detect also text with custom font

Problem 8: How to make it easier?

• Testers should not worry about image capturing, processing and OCR

Problem 9: How to insert cards?

• Robot electronics is a 3-axis motion control system • There was no way to add 4th axis and coordinate the motion with rest of the

system

• Chip card is inserted by using belt driven linear actuator

• Contactless card is tapped by using servo based solution

• Arduino Uno with motor shield is used to control motors used in above solutions

Chip CardInsertion

Contactless Card Insertion

Card Control Board

Robot VideoTest case: Chip - Purchase - Amount field displayed in PIN entry

Future Development

• Use of a card probe (from UL) to be able to change the card used in testing.

• Add magnetic stripe card probe (from UL).

• Tune the Robot to make it faster.

• Make OCR faster.

• To be able to handle touch screen.

• Unattended and Integrated terminals not in the near term scope.

• Preparing the Robot to be able to handle mobile acceptance (e.g. Dankort).

References• GRBL Wiki: https://github.com/gnea/grbl/wiki

• G-Code: https://en.wikipedia.org/wiki/G-code

• ShapeOko3: https://www.shapeoko.com/wiki/index.php/Shapeoko_3

• Arduino: https://www.arduino.cc/en/Guide/Introduction

• Tesseract: https://github.com/tesseract-ocr/tesseract/wiki

• Raspberry Pi: https://www.raspberrypi.org/

• Sketchup: https://www.sketchup.com/

• Ultimaker: https://ultimaker.com/

• RFW CNC library: https://github.com/Eficode/robotframework-cnclibrary

Thank you!

Sari Salin-Tuomela&

Jani Kytöaho