The Research and Development (R&D) center of Y Soft in Brno usually accommodates around sixty people on a daily basis. Today, you would find only one or two engineers in the office – they come to the office to check on the robots that are being used by the developers during their day-to-day job.
The Y Soft development department focuses on developing a smart print solution called SafeQ that reduces document-related costs and provides key functionalities, including security and print management, print queues, scanning workflows, etc. To develop a distributed system such as SafeQ, a software engineer needs to make changes to the source code. Those changes are then pushed to the main source code repository and automatic tests, security checks, and other tests are performed. In the next step, an artifact is built from the source code, which is then used for an automated installation of a testing station. Next follow the setting and execution of testing procedures that are usually fully automated. This complex flow is called the Continuous Integration (CI) and is repeated so that each software engineer can contribute to the shared source code effectively. The CI flow is usually followed by the deployment and launch of an application in the different types of testing environments and later in a production environment, an extended form of the CI known as the Continuous Delivery (CD).
At Y Soft, we have to deal with a few specific issues regarding this process. Our print solution requires a wide printer compatibility. In our case, printers are the third-party devices made by printer manufacturers such as Konica Minolta, Xerox, HP, Ricoh, Sharp, etc. The interconnection of these printers and the central print management node must work for the user to be able to print out their document on any printer in their company. So how do we test the correct function of the printer software automatically, when the only interface is the touch screen of a printer usually controlled by the user? It would seem only logical to create a software-emulated printer and use it for automated testing. But a software-emulated printer inevitably misses an important part – the hardware. Moreover, printers are usually closed environments, and so there is no universal way to emulate them. To ensure the correct functionality, an end-to-end user scenario needs to be performed using the correct hardware appliance. Since we are working with a number of different devices from different vendors, it is necessary to test at least one representative printer model of each vendor. And here’s the catch: developers can hardly test their code changes on real multifunctional printers while working from home, because they rarely have one available at home.
Our own in-house developed smart robotic system called Robotic Quality Assurance (RQA) solved our remote multifunctional printer testing problem. The RQA system enables its users (our developers) to control the physical device remotely by tapping the display and the buttons, while at the same time monitoring the device by a camera, as a result showing the user what is happening on the device in real-time. The robot is placed in front of a tested device (in our case a printer), and is calibrated with the device in such a way that it is able to reach all the operable elements of the device – mainly the display and the buttons. A camera is placed above the robot and the device, so that it can capture the tested object. A software engineer then uses an application available from a web browser to control the robot. Using simple actions, the engineer instructs the robot to click on a certain place on the display. At the same time, the engineer is provided with a real-time, live image from the camera. As a result, they can see everything that is happening on the printer, except perhaps for when the printed paper comes out of the printer. But we have a solution even for that kind of an issue: our RQA system includes paper sensors that are placed on an appropriate location of the printer output tray and monitor the papers coming out of the printer.
However, we do not use the RQA system only to remotely control the multifunction printers. The robot hardware is complemented by a sophisticated system of intelligent actions of the robot and image processing of the camera-acquired images to provide us with a feedback from the tested device. As a result, the RQA system can work completely independently, based on the test scenario composed of given high-level actions. Instead of instructing the robot to “Click on the button A,” the scenario says, “Go to screen Main menu.” First, the RQA system analyzes the current screen and finds a way to the destination screen, and then the robot continuously clicks on the buttons that lead to the destination screen while analyzing the image for any unexpected behavior.
As you can see, thinking innovatively and working on automation prepared Y Soft to be able to overcome such an unexpected situation as we happen to be in right now. Even though they’re working from home, our developers can still easily make sure the product has the required quality. And I have to say – they seem to like working with the robots a lot.
