Remote arcade games: de implementation of the Elaut project

Customer needs

Elaut – a global player in amusement and arcade games – was already familiar to Refleqt. In our previous case, you can read how, together with Cloudway, AppFoundry, and Gluo, we built a successful proof of concept (PoC) to validate the feasibility of remote arcade gaming. A major challenge in that project was latency.

When you operate a claw machine remotely to try and win a plush toy, you must be able to see via livestream how the machine responds. The video feed therefore cannot lag too much.

Once we had demonstrated that we had the expertise to realize this project with minimal latency, we were given the green light to start development. That is when the real work began.

Refleqt solution & deliverables

Livecadia development setup

Two applications were needed: one for players and another for configuration and monitoring. In the latter, the arcade operator can configure machines and prizes, and monitor how many players are logged in, how many prizes have been won, the average session duration, and when something went wrong during play.

From Refleqt, we complemented the front-end and back-end development team with one, and temporarily two, test automation engineers to safeguard the quality of the delivered applications. At Refleqt, we place strong emphasis on making our test automation solutions maintainable and as efficient as possible. That is why we temporarily added extra capacity shortly after project start, so we could get a full test automation solution up and running quickly and still keep up with the fast pace of feature delivery.

SCRUM approach

To keep development and testing running smoothly, we held daily stand-ups to review progress and worked in two-week sprints. As soon as developers produced a new version of an application or the backend, we immediately ran a sanity check on it to verify that the build was stable and testable.

This allowed us to move quickly. There were many changes, but thanks to frequent deployments of new versions, we could continuously work with the latest build in the test environment. When we detected quality degradation in that environment, we could immediately flag it to the development team.

Each sprint concluded with a retrospective meeting. These sessions were used to evaluate what went well and what could be improved. They helped us address obstacles in an agile and structured way.

Continuous integration with regression testing

For this project, we applied continuous integration. After each successful deploy to the DEV environment and a successful sanity test, we promoted the build to the TST environment.

Every night we ran regression tests to verify that everything that worked before still worked as expected. This provided developers with fast feedback on product quality and allowed bugs to be identified quickly. It is both easier and more cost-efficient to resolve issues early in the development lifecycle than at the end.

Functional testing and test automation

Functional tests are critical when developing applications. In these tests, you validate the application as if you were an end user, writing scripts to test each function of the app.

On top of that, we performed end-to-end testing. These tests are similar to functional tests but cover longer scenarios that span multiple components. They validate the full user journey and flow across:

- Front end

- Backend

- MQTT

- Arcade machines

The goal is to verify that the entire game experience runs smoothly, from logging in to claiming a prize.

At Refleqt, we always aim to automate as many tests as possible. However, some cases inevitably require a human perspective, which means manual testing remains essential.

For example, we tested the gameplay itself manually. You really want to experience the game as a player. That is why we encouraged the team to perform exploratory testing. Everyone involved—analysts, developers, the Scrum Master—was asked to regularly open the app on their phone and play a few games. Exploratory testing is a highly intuitive way of testing. It is less structured, but it delivers very valuable feedback.

Challenges and solutions

Because we were already running tests in the middle of the development phase, we often had to respond flexibly to many changes. Whenever there were modifications in the application’s setup, we updated the tests as quickly as possible.

At one point, there was a design change in the app. The layout was updated, which can have a major impact on a test automation solution. Fortunately, this did not become a real obstacle. We had chosen to work with a design pattern such as the Page Object Model. In this approach, each page or page component of the web application exists as a separate object in the test automation solution. When a page layout changes, it is easy to pinpoint which elements need to be updated in the corresponding page object. Functionally, the tests do not need to be changed, because functionality and page structure are proactively separated.

Another challenge was reaching as many users as possible. This meant taking into account the wide variety of smartphones and browsers. The web application had to be tested on both macOS and Windows, across multiple browsers, as well as on different mobile devices.

For mobile, we first researched the most popular devices in Belgium and the Netherlands. We included high-end, mid-range, and budget devices to achieve broad test coverage. This was important because not all screens have the same size, which directly impacts design, scalability, and ultimately the user experience.

Tools and technologies

- Test case design: BDD with Cucumber, Page Object Model

- Backend test automation solution: Java, Maven, Swagger Codegen, MQTT

- End-user-facing front-end test automation solution: Java, Maven, Selenium, BrowserStack

- Back-office front-end test automation solution: JavaScript, Cypress, BrowserStack

a result to be proud off

At Refleqt, we look back on this project with pride. First, because we managed to get a project of this scale up and running in a short time: the total duration was 11 months.

A second reason is the technological challenge. We worked with hardware and Raspberry Pis to control that hardware. This meant that we did not only execute front-end and back-end tests, but soon also introduced MQTT communication into our tests to interact directly with the hardware.

During testing, we uncovered a significant number of issues, which allowed us to keep the overall quality of the project high. We were able to pinpoint problems quite precisely. For example, if a backend call behaved as expected but an error occurred in the MQTT flow, developers immediately knew where to focus their investigation. As a result, we were able to react very quickly.

The project was also a strong example of cross-functional collaboration. Developers and testers worked closely together to deliver results in a short timeframe. When testers noticed something failing in the tests, developers often responded, “we are already working on that,” because they were also actively monitoring the test results after each deploy.

Do you have a challenging project that requires multiple areas of expertise? Get in touch with us: our testers and analysts are ready to put their skills to work.