Test-Infrastruktur bei Geräteherstellern

Systemtests für Küchengeräte in der Großgastronomie bedeuten, Heizung, Motorsteuerung und Bussysteme vollautomatisiert auf echten Geräten zu prüfen. Ein Python-Framework steuert dabei Hardware wie Relaismodule und Stromversorgungen. Rund 2.000 Testfälle laufen jede Nacht, am Wochenende bis zu 30 Stunden am Stück.

Das Wichtigste in Kürze

• Rund 700.000 Zeilen Code stecken in den Kombidämpfern von RATIONAL, verteilt über mehrere Elektronikkomponenten, die über Bussysteme miteinander kommunizieren.
• Zehn Testautomatisierungsfachleute stehen bei RATIONAL etwa 70 Embedded-Entwicklern gegenüber, weshalb Skalierbarkeit der Automatisierungsinfrastruktur die größte strategische Herausforderung ist.
• Nächtliche Testläufe über mehrere Branches decken rund 2.000 Testfälle ab, wobei nicht das Framework, sondern die physikalische Aufheizzeit der echten Geräte den Laufzeitengpass bildet.
• Wo Heizzyklen zu lange dauern würden, simuliert das Team gezielt Temperaturwerte im System, um Abschaltlogiken zu testen, ohne das Gerät jedes Mal aufheizen zu müssen.
• RATIONAL verlagert das Testdesign schrittweise in die Fachbereiche: Das Testteam stellt Infrastruktur und Framework bereit, während die Fachabteilungen eigene Tests schreiben und pflegen sollen.

Großküchengeräte sind Software-Systeme mit Stahlmantel

Ein Kombidämpfer für die Großküche ist ein vernetztes Softwaresystem. In den Geräten von RATIONAL stecken rund 700.000 Zeilen Code, verteilt auf mehrere Elektronikkomponenten, die über Bussysteme miteinander kommunizieren und mit unterschiedlichen Firmwares laufen.

Die Hauptsoftware entwickelt der Hersteller selbst, die Elektronikkomponenten kommen von externen Firmen. Beide Welten müssen zusammenspielen, und genau an dieser Schnittstelle entscheidet sich, ob ein Gerät zuverlässig funktioniert.

Die Dimensionen sind nicht die einer Heimküche. Die größten Geräte verarbeiten über 90 Hähnchen auf einen Schlag, sind übermannshoch und bringen bis zu 70 Kilowatt Heizleistung mit. Software, die so viel Energie steuert, braucht einen Test, der diese Leistung real abbildet.

Warum der Test echte Hardware statt reiner Simulation braucht

Wer ein Gerät mit 70 Kilowatt Heizleistung testet, kommt mit Software allein nicht aus. Bei RATIONAL steht hinter dem Test eine eigene Hardware-Infrastruktur in eigenen Racks: Relaismodule, Remote-Stromversorgungen, Logic-Analyser und die Möglichkeit, Strom, Gas und Wasser gezielt an- und abzuschalten.

Bis hinunter zur seriellen Konsole am Gerät ist alles über Netzwerk erreichbar. USB läuft über Netzwerk, was Andreas Berger selbst als Herausforderung benennt. Diese Hardware ist ein Haufen Geld und Material, klar benannt als der teure Teil der Anlage.

Der limitierende Faktor im Testbetrieb ist nicht die Software, sondern die getestete Hardware. Wenn ein Gerät hochheizen muss, um die Heizung zu prüfen, wartet der Test die meiste Zeit auf physikalische Prozesse. Ein Server mit acht Kernen und 8 GB Speicher managt 18 gleichzeitig laufende Testgeräte locker. Die Wärme braucht trotzdem ihre Zeit.

Klarer Fokus: Systemtest und Regression, kein Unit-Test

Das Testautomatisierungsteam hat seinen Schwerpunkt früh festgelegt. Es macht Systemtests, Regressionstests und Low-Level-Tests bis hinunter auf die Bussysteme. Unit- und Modultests bleiben auf der Entwicklungsseite, Abnahmetests beim Anforderer.

Diese Abgrenzung ist eine Entscheidung, kein Zufall. Wer alles testen will, testet am Ende nichts richtig. Der Fokus auf Systemverhalten passt zu einem Produkt, bei dem das Zusammenspiel vieler Komponenten den Unterschied macht.

Ein typischer Testfall steuert eine Betriebsart an, etwa Kochen mit Heißluft, und prüft dann auf der Reglerebene, ob die richtigen Regler ansprechen, ob der Motor dreht, ob die Heizungen anspringen und ob die eingestellte Zieltemperatur erreicht wird. Darüber liegen Systemintegrationstests, die auch die Vernetzungslösung einbeziehen.

Was die Vernetzung der Geräte konkret leistet

Vernetzung bedeutet hier nicht, dass die Geräte untereinander kommunizieren. Sie bedeutet, dass Updates und Programme remote ausgerollt werden können. Große Ketten haben die Anforderung, ihre Gar-Programme oder ein Software-Update auf alle Geräte in allen Filialen zu verteilen.

Den dafür nötigen Dienst stellt der Hersteller bereit. Auch eine kleine Gaststätte kann dieselbe Vernetzungslösung nutzen, mit einem eigenen Account. Für den Test heißt das: das Ausrollen muss genauso geprüft werden wie das Garen selbst.

Warum Python die richtige Wahl für das Testframework war

Die Sprachwahl fiel auf Python, weil das Team nichts kompilieren wollte und eine kompakte Sprache mit vielen Bibliotheken brauchte. Andreas Berger kommt aus der C- und C++-Welt und kennt den Unterschied genau.

Wenn ich da versuche, eine Netzwerkverbindung zu machen oder eine serielle Verbindung, programmiere ich mir erstmal einen Wolf. Wenn ich das gleiche in Python mache, sind es zwei Zeilen Code.

Andreas Berger

Die Kompilierzeiten sollten weg. Heute pflegt das Team mehrere eigene Python-Packages, lädt sie automatisch in eigene Registries hoch und betreibt darum eine eigene Package-Infrastruktur. Die Entscheidung für Python bewertet Andreas im Rückblick als richtig.

Neben Python bilden GitLab und ein Testdesign-Tool das Grundgerüst. GitLab trägt die Pipelines und die Qualitätssicherung des eigenen Frameworks. Das Testdesign-Tool hilft beim Variantenmanagement: Ein abstrakter Testfall lässt sich über variable Testschritte auf 14 verschiedene Gerätetypen anwenden, ohne den Testfall zu vervielfachen.

Wie der Testbetrieb über Tag und Nacht getaktet ist

Das Ziel ist klar: Alle notwendigen Branches laufen nachts vollautomatisch durch, vom Start bis zum ausgewerteten Bericht. Pro Nacht werden zwei Branches getestet, jeder rund vier bis fünf Stunden, weil die Geräte nicht doppelt belegt werden können und eine Queue dahinter steht.

Pro Branch laufen etwa 2000 Testfälle. Um sechs Uhr morgens sollen die Ergebnisse vorliegen. Am Wochenende läuft ein Kompletttest, der in der Größenordnung von 30 Stunden liegt.

Tagsüber sind die Geräte im Einsatz für andere Aufgaben. Dann gibt es On-Demand-Läufe, wenn ein Entwickler etwas geändert hat und das direkt prüfen will. Außerdem entsteht hier neues Testdesign, das Team gibt Debug-Support bei komplexen Fehlern, prüft die eigenen Packages nach Refactorings und pflegt die Hardware.

Die folgende Übersicht ordnet die Taktung:

Risikobasiert testen heißt: nah am Kunden priorisieren

Das Team findet regelmäßig Fehler, und es priorisiert sie nach Wirkung. Kritisch ist, was dem Kunden wehtut oder viele Serviceeinsätze auslösen würde. Ein Fehler in der zehnten Unterebene eines Servicemenüs ist normalerweise weniger dringend.

Stabilisierungsbranches sind ruhiger, der Hauptzulieferbranch ist der kritischere. Ein klassisches Problem kennt jede Firma: Etwas wird geändert, und der Test bekommt es vorher nicht mit. Es kommt vor.

Gefundene Fehler bleiben nicht im Tool stecken. Das Team geht zu den Entwicklern, redet und klärt gemeinsam, wo das Problem liegt und wie es gelöst wird. Manche Störungen sind auch Infrastrukturprobleme, etwa ein ausgefallenes Netzwerk, die zuerst ausgeschlossen werden müssen.

Sicherheit testen, bevor das Gerät überhaupt Schaden nimmt

Der Personenschutz ist zunächst durch die Eigensicherheit der einzelnen Komponenten und deren Zulassung abgedeckt. Diese Schutzabschaltungen greifen spät, sie sollen Personen- und Gebäudeschaden verhindern, auch wenn das Gerät dabei schon zerstört ist.

Der Test setzt früher an. Er prüft die Abschaltungen, die die Software auslöst, bevor ein Geräteschaden entsteht. Wenn eine Komponente durchzuschalten droht, soll die Heizung rechtzeitig abschalten.

Solche Tests haben ihre eigenen Tücken. Ein leerer Dampfgenerator ist innerhalb kurzer Zeit kaputt, wenn man hineinheizt. Also darf er beim Test der Heizsperre nicht wirklich leer sein, das System muss aber annehmen, dass er es ist. An jede dieser Bedingungen muss man denken.

Genau hier hilft die Simulation. Ist die Heizung in vorgelagerten Tests bereits geprüft, spielt das Team Temperaturwerte direkt ins System ein und setzt gezielt ein Grad darüber oder darunter, um Heizabschaltungen auszulösen. So bleibt das Gerät heil, und der Test bleibt aussagekräftig.

Die eigentliche Herausforderung ist Skalierung, nicht Technik

Die größte Herausforderung ist das Skalieren mit der Entwicklung. Die Embedded-Entwicklung liegt bei rund 70 Software-Entwicklern an zwei Standorten, dem stehen zehn Leute in der Testautomatisierung gegenüber. Das Team will Stand halten, ohne personell mit der Entwicklung gleichzuziehen.

Daraus folgt ein Strategiewechsel. Statt komplette Testframeworks und fertiges Testdesign zu liefern, verschiebt sich der Fokus Richtung Infrastruktur. Das Team stellt Hardware und Software für die Tests bereit, das Testdesign sollen zunehmend die Fachbereiche übernehmen.

Die Logik dahinter ist einleuchtend: Wer die Requirements ändert, kann die Tests gleich mitpflegen und im Gegenzug seine manuellen Tests reduzieren. Das verteilt die Last dorthin, wo das fachliche Wissen sitzt.

Hinzu kommt die räumliche Verteilung. Ein Labor steht in Landsberg, eines in Wittenheim in Frankreich, wo eine Tochtergesellschaft die Kippbratpfannensysteme betreut. Zwei Kollegen dort gehören fachlich zum Team. Regelmäßige Besuche in beide Richtungen halten die Zusammenarbeit zusammen und verhindern, dass sich Gruppen an je einem Standort verselbstständigen.

Test-Impact-Analyse als nächster Schritt

Der nächste große Hebel ist eine Test-Impact-Analyse. Das Team arbeitet daran, Testfälle automatisiert umzusortieren, je nachdem was sich im Code geändert hat. Statt jede Nacht stur denselben Block abzufahren, sollen die relevanten Tests nach vorn rücken.

Gefragt nach dem Highlight der kommenden Jahre, nennt Andreas zwei Dinge: dass die Test-Impact-Analyse läuft und dass das Team die Skalierung der Firma gut mitgemacht hat. Beide Ziele hängen zusammen, denn eine kluge Testauswahl ist genau das, was ein kleines Testteam neben einer wachsenden Entwicklung handlungsfähig hält.