A fair question to ask is: why is a mobile and software company building robots? The honest answer is that nobody planned to. We just followed a testing problem until it grew a mechanical arm.
Many of our customers and partners come from industry. For them, we have built applications that communicate with hardware, and very often that includes some interaction directly on the machine, usually through a touch panel. We also work closely with partners who develop firmware for control units and human-machine interfaces, and we support them with testing as well.
For testing these solutions, the standard approach is simulators or modified machines. That always bothered me. You cannot claim a proper end-to-end test when you have replaced a rather important part of the system with something that only pretends to be it. You are not testing the product. You are testing an imitation of the product. If you have ever watched a device pass every test on the simulator and then behave differently on the real machine, you know exactly what I mean.
So to do a proper end-to-end test, you need a real finger pressing a real screen on a real device; all manual. And manual testing at that layer has hard limits. Humans get tired and miss things after the fourth hour, and I have yet to meet a colleague willing to tap the same button sequence for 72 hours straight. I asked. Nobody volunteered.
And the stakes at this layer are high; everyone in industry already knows it. A UI or firmware bug that reaches the field is among the most expensive bugs a device manufacturer can have. It means service calls, updates pushed to installed machines, in bad cases a recall or a re-run of certification. Catching such a bug in the lab costs hours. Catching it in the field costs an entirely different order of money, and some trust on top.
I am an automation fan, so the question formed itself: how do we automate testing with the machine in the loop?
For touch panels, what you need is really not complicated. You need someone who presses the correct part of the screen and reads what the screen says. That is the whole job description.
In the world of automation, “someone” means a robot.
I drafted the idea and started investigating what already existed. There are open robot designs built exactly for tapping on screens, so the pragmatic first step was obvious: take one, build it, learn from it.
We did, and we learned mostly what it could not do. We started with a design for testing on mobile phones, but we quickly learned that we needed to scale it up and change it to test industrial panels. The first prototype could tap, but it could not read the screen and tell us whether the application actually did the right thing. A robot that presses buttons blindly is a demo, not a test system. It could touch reality, but it could not verify it, and verification was the whole point.
Still, that first build was not wasted. It told us precisely what we needed and what off-the-shelf could not give us.
So we built our own robot, and we kept the delta kinematics on purpose. A delta bot is fast; it is a proven design, and it does not overcomplicate things the way other robot architectures would. This matters more in testing than anywhere else: your test tool must be the thing you trust, otherwise you spend your days debugging the judge instead of the defendant.
The second half of the problem was reading the display. The solution is simple, in the sense of the idea, not in the sense of building it: we mounted a camera and added visual recognition with OCR. The robot now sees the screen the way a tester does. It taps, then it reads the result and checks it against the expectation.
One design decision I want to highlight, because it goes against the current fashion: Sabotap does not use self-healing test automation. If a button moves from its expected position, we do not cleverly find it and carry on. We report a failure. In regression testing of an industrial device, a button that wandered off is the bug. We want to catch it, not forgive it.
The third piece closes the loop: sensor simulation. Many devices we test react to physical inputs like temperature or digital signals. So we built a solution for this: Sabotap can feed simulated sensor data to the device over standard industrial protocols, while the robot operates the UI. Press “start heating”, ramp the simulated temperature, verify the display follows. That is a system-level test, fully automated, running while everyone is asleep. With this piece, the test finally covers the whole reality of the device: the screen, the logic, and the physical inputs it lives with.
We presented this setup at the SPS trade fair in Nuremberg in November 2025. The robot behaved well.
The conversations at the fair were worth more than the demo itself. The clearest lesson: for Sabotap to be useful beyond one project, the software has to move easily from one device to another. So we reworked the software stack with exactly that goal. New project, new panel, new test cases, same platform. The goal did not change, we still test the real device; we just no longer start over for the next real device. Sabotap is running and usable today, with adjustments made per customer, as it should be with hardware that meets the real world.
To be fair, we still need to make some adjustments per project, especially in sensor simulation, as every project is different and thus has different needs. And I believe it is better to customize than to overscope a robust solution that can account for every variant. We would likely not be doing anything else for years.
Since then, we also connected Sabotap to SaTI, our AI tool for reviewing and generating requirements and test cases. We tried this combination on Sabotap scenarios, and it worked well. You put in requirements, get reviewed test cases, the robot runs them, and a human oversees everything. SaTI has its own story, which I will share in another post soon.
While prototyping and building Sabotap, I ran into an interesting challenge: sometimes you cannot remove the touch panel from the device to put it into the robot. You need to test it attached to the machine. On a real device setup. And as you probably noticed from the previous text, we love figuring out challenging problems. We are now working on a prototype of this version of Sabotap exactly for that: the robot that reads the display and interacts with the machine while mounted on it. It is the same idea pushed one step further: if the panel cannot come to the lab, the test comes to the panel.
And once a robot can operate a machine in place, it can do more than test it. It can automate the machine to do things on my behalf, which, let’s be honest, also sounds great.
Sabotap started with a simple discomfort: the most user-facing layer of our products was the least automated one, and the usual workaround was to test a copy of reality instead of reality. Now we have a robot that taps, sees, simulates, and reports, around the clock, without getting tired or creative. Every bug it catches in the lab is one that never reaches the field.
If you build devices with touch panels and this sounds familiar, send us your test scenario. We will give you an honest answer about whether Sabotap is a good fit. And don’t worry, the robot will not tap on you.
