How I build automated testing for the payment terminals

Payment terminals are devices used to process card transactions and must undergo extensive certification before being released to the market. Therefore, it is essential to test them quickly and reliably. I named the project as Mastoo (code name: MR2).

The MR2 architecture

To achieve this, our team are building a solution for automation testing with a combination of robots, cards, a point-of-sale server, and a terminal management system. The brief diagram is as follows.

This graph depicts a system architecture for a testing framework involving various components integrated to interact and facilitate Quality Assurance (QA) processes. Here’s a detailed breakdown:

1. Robot Arm Adapter: This component appears to interface with a robotic arm, likely for physical automation tasks that require mechanical actions.
2. ADB Adapter: The Android Debug Bridge (ADB) Adapter is used for communication and automation of Android devices, suggesting this system also tests Android applications.
3. Maestro Adapter: This adapter is probably linked to a Maestro system, which might refer to a tool or platform used for orchestrating or managing automation tasks.
4. POS Adapter: The Point of Sale (POS) Adapter indicates integration with POS systems, allowing for the testing of transactions and other POS-related functions.
5. MASRTOO Server: At the centre of the diagram is the MASRTOO Server, which serves as the core hub for coordinating interactions between the various adapters and components.
6. Region:
   • API Gateway: This component handles API requests and routes them to the appropriate services.
   • Lambda Function: This is a serverless compute service that runs code in response to events and automatically manages the compute resources.
   • S3 Bucket: Amazon S3 (Simple Storage Service) is used for storing data, such as test results, logs, or other relevant information.
7. QA Facing Interface: This interface is designed for QA personnel to interact with the system. It likely includes a graphical user interface on both desktop and mobile devices, as well as access to POS devices for direct testing.

Workflow Explanation

• The Robot Arm Adapter, ADB Adapter, Maestro Adapter, and POS Adapter send data and commands to the MASRTOO Server.
• The MASRTOO Server processes these inputs and coordinates actions across the system.
• The server communicates with the Region (cloud services) through an API Gateway which directs calls to Lambda Functions for processing and utilizes S3 Buckets for storage.
• Outputs and interactions are made available to QA personnel through the QA Facing Interface, allowing them to monitor and control the testing processes, view results, and manage devices including POS terminals.

This architecture is designed to provide an integrated, automated, and efficient testing environment for various devices and applications, streamlining the QA process.

Building the testing server

We are building a back-end server with Nodejs for scalability. It is the data source and the liaison between several agents, e.g. robot arm, terminal and AWS services.

The front end is separated from the back end and can be deployed separately from the back end.

Figure 2: The front end is created with ReactJS.

Read more testing articles