So how do you solve that, thoroughly and repeatably, without someone spending days in front of the panel after every update?
Here is how we do it. A robot arm presses "Heat up". A simulator makes the temperature rise. A system checks whether the display, the limit value and the warning message do exactly what the requirement says they should. Nobody is sitting next to it, and every single test step is documented with a screenshot.
That is SABOtap: the robot-based testing service from SABO IT for automated end-to-end testing of touch HMIs on real hardware.
Testing touch interfaces by hand is slow, inconsistent and hard to repeat across several firmware versions. The defects that go unnoticed on the lab bench show up later in the fully assembled device, and those are the expensive ones, because they surface late.
And in an audit? The test result is rarely what is missing. What is missing is the evidence that testing actually happened, and that it happened the way someone will really operate the device.
What makes a test credible in the first place? Not that something "worked", but that someone, or something, did exactly what a person would have done, and recorded exactly what happened along the way.
A robot arm operates the panel the way a person would: tapping, swiping, long-pressing. A camera continuously reads what is actually on the display. And a simulator feeds the device the sensor values it is meant to react to, temperature or digital inputs for example.
The closed loop in one sentence: the robot presses "Heat up". The simulated temperature rises. The system checks whether display, limit value and warning message match what the requirement calls for.
One thing matters here. SABOtap interacts with the physical device, not with the code behind it, and as a rule without any change to the firmware. Is that the same as classic hardware-in-the-loop testing? Not quite. HIL works at a much lower level and does not reproduce human operation. SABOtap tests from the perspective of the person who will actually stand in front of the device. SABOtap complements unit, integration and HIL tests; it does not replace them.
What happens when a control shifts by a few millimeters? In many automated tests: nothing. The system recognizes the button anyway, compensates for the shift in the background and reports "passed".
SABOtap does not. It reports the shift as a finding, not as a tolerance that gets corrected automatically. On the control panel of a machine or a medical device, the button that moved is the finding. Not something a test quietly irons out.
But how does the robot know what to test in the first place? Before anything is tested, a requirement has to be written in a testable form. That is what SaTI is for. In a first step, SaTI reviews your requirements and names what is unclear or incompletely described. The result of that review is the basis for the second step: the drafts of the matching test cases. A tester approves the drafts. SaTI does not replace that decision, it prepares it.
Does the device have to come to us? Not necessarily. There are two routes.
Testing service in our lab. You send us your device. We set up the test rig, run the tests and hand back the tested application together with all test artifacts: test cases, reports, findings.
Test rig at your site. If the device is not allowed to leave your building, the robot comes to you. It is not for sale: we set it up and run it at your site on loan for the duration of the tests, completely offline if you prefer.
In industry: PLC and HMI panels, operator terminals, robot control panels. In medical technology: diagnostic analyzers, patient monitors, infusion and surgical consoles, laboratory equipment.
And if a device cannot leave the building at all because it is subject to regulatory approval? Then the test rig comes to you. For medical devices, the testing service brings the same documentation and evidence discipline that our own development work follows: EN IEC 62304 and DIN EN 60601-1.
And what about devices whose panel you would rather not remove at all? For larger panels, and for cases where a device should not be dismantled at all, we are working on a second robot generation that tests directly at the machine instead of bringing the panel to the test rig.
We would like to know where the pain actually is for you. The time manual tests eat up? The coverage that is never quite complete? Or the traceability, the evidence that what should have been tested actually was?
And very concretely: which manual touch panel test would you most like never to run by hand again? Tell us in the comments. We read every one.
