Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und habe wieder eine Folge vom German Testing Day mit im Gepäck. Bei mir zu Gast Andreas Berger von RATIONAL. Sein Abstract hat mich sehr spannend gemacht, denn RATIONAL ist Küchengerätehersteller und er spricht über Systemtestumgebungen und das habe ich zuerst gar nicht zusammengebracht. Was es damit auf sich hat und wie wichtig ein guter Test für
den Küchenprofi ist, hört ihr in dieser Folge. Viel Spaß dabei! Hallo Andreas, schön, dass du da bist. Hallo Ritschi, schön, dass ich da sein darf. Ja, sehr fein. Wir sind hier am German Testing Day 2024 in Frankfurt, so hier halbzeit vom Haupttag fast schon erreicht. Das geht dann bald in die Mittagspause rein. Hast du deinen Vortrag schon gehabt? Nein, den habe ich am Nachmittag. Ah ja, da hast du den Vortrag.
Das ist schön, da kannst du jetzt schon mal deine Gedanken hier sortieren, damit du dann noch besser performen kannst. Ja, ganz spannende Sache. Ich habe den Abstract vorhin weg gelesen und wir haben uns auch kurz unterhalten. Ihr macht ja Küchengeräte. Genau, wir machen Kombidämpfer und Kippfandensysteme für Großküchen. Ja, das ist jetzt nicht was, wo man sofort an Systemtest oder an Testing generell
denkt. Nein, definitiv nicht. Aber steckt natürlich Software drin, oder? Ja, jede Menge. Also wir haben ungefähr 700.000 Zellen pro drinnen in den Geräten und mehrere Elektronikkomponenten, die alle über Bussystem miteinander verbunden sind, mit verschiedenen Firmwares und so. Ja, es ist jede Menge Zeug drin. Ja, und das macht ihr alles selber? Also ihr entwickelt die Software und die... Die Hauptsoftware wird selber entwickelt, die Elektronikkomponenten kommen von externen Firmen,
müssen aber damit zusammenspielen. Ja, ja, ja. Ja, und sprichst du ja über die Systemtestinfrastruktur und so. Wie macht ihr denn das? Wie ist denn so euer... Lass uns da mal so einen Erfahrungsbericht draus bauen. Unser Ziel ist, alles auf Nacht automatisiert zu testen. Also nicht alles an Funktionen, aber alle Branches, die notwendig sind. Und es muss vollautomatisch laufen, vom Start bis zum ersten Bericht, sag ich mal, der dann ausgewertet wird und alles auch über Netzwerk
erreichbar sein. Und wir haben eine massive Infrastruktur dahinter, sprich mit eigenen Racks, wir haben Elektronikaufbauten, Relaismodule, können Stromversorgungen ab- und zuschalten, Gas, Wasser an- und ausschalten und bis auf die Serie der Konsole runter auf den Geräten haben wir alles drinnen. Genau, also das ist ein technologisch herausforderndes Thema für das Team auch, weil wir ja das Gerät verstehen müssen von der Funktionalität, von der Hardware, wie die
Hardware zusammenspielt, von der Software und dann aber auch noch unsere eigene Infrastruktur. Das heißt, wir haben die ganze Hardware dahinter, wir haben unser eigenes Python-Framework dahinter und wir haben auch noch unser Testdesign, das wir ja auch noch machen. Also es ist wirklich ein Moloch und wir sind da im Moment bei, in der Embedded-Entwicklung ungefähr bei so 70 Software- Entwicklern auf zwei Standorten und haben dagegen zehn Testautomatisierungsleute stehen.
Okay, nochmal zur Einordnung auch, weil vielleicht nicht, da geht es ja jetzt nicht um Geräte, die ich mir zu Hause in meine Küche baue, oder? Also es ist ja eher natürlich der größere, kannst du so ein typisches Szenario mal bringen, wo eure Geräte im Einsatz sind und wie das aussieht? Zum Beispiel hier in so Restaurants, in so Hotels, Restaurants, alles was so Großküche ist, also wo es um Verpflegung geht von 30 Essen bis Oktoberfest-Größe, also wo auch unsere Geräte
stehen. Und die größten Geräte von uns können über 90 Gockel auf einen Schlag durchjagen, also das ist schon, die sind dann so übermannshoch. Okay, also da ist schon ein bisschen Energie dahinter, weil du jetzt auch gesagt hast, da Strom zu- und abschalten, das ist jetzt im Heimumfeld vielleicht jetzt nicht so relevant. Also beim größten Gerät 70 Kilowatt Heizlastung. Also nichts was man daheim angeschlossen kriegt. Ja, das ist klar. Genau, und dann spielt natürlich
auch Sicherheit eine Rolle. Sprich, dass ich nicht die Tür öffne und dann der Lüftermotor weiterdreht und so Sachen auch, genau. Wie habt ihr euch denn diesem Testthema so genähert, oder wie sieht das aus, du hast ja gerade gesagt, es muss alles automatisiert laufen bei euch auch. Wie seid ihr denn da so rangegangen und was habt ihr da so aufgebaut? Oh, wie wir rangegangen sind, ist, ja gut, das kommt in meinem Vortrag auch nochmal. Im Grunde haben wir früher,
wenn eine Software rausgekommen ist, hauptsächlich manuell getestet. Das heißt, die Software ist auf eine Testsoftware gebaut worden, sind dann Herrscher und Werkstudenten, Entwickler aus verschiedenen Fachbereichen ins Labor und haben dort getestet über Wochen. Und im letzten größeren Projekt ist dann mein Chef zu mir gekommen und hat gemeint, bauen wir die Testautomatisierung
auf. Und ich hatte zum Glück auch schon ein paar Schulungen in dem Bereich, was Testen an sich betrifft, so Testmanagement, Testanalyst, so Sachen und mich auch viel damit beschäftigt. Und dann habe ich im Grunde allein angefangen damit und wir haben dann die ersten drei Jahre mit zweieinhalb Leuten gearbeitet und der Schwerpunkt, wir haben halt unseren Fokus
von Anfang an gesetzt. Wir haben gesagt, wir machen Automatisierung, wir machen Systemtest, wir kümmern uns nicht um Unit-Tests oder um Modul-Tests, das ist wieder auf der Entwicklungsseite. Abnahmetests sind beim Anforderer. Also wir sind wirklich schwerpunktmäßig in diese Regressionstests oder auch ganz Low-Level-Tests wie Bussysteme reingegangen. Und dann überlegt, wir machen die Infrastruktur dazu, was brauchen wir für das Testdesign, was brauchen wir als Framework dahinter,
welche Programmiersprache nehmen wir. Solche Entscheidungen sind alle. Haben wir da alle gemacht. Ja, es ist ja auch ein ganz schönes Brett zu bohren. Also wenn du sagst, es sind jetzt auch zehn Automatisierer, die das quasi bedienen. Und kannst du uns mal eine Idee geben, was sind so typische Tests, die ihr dann so damit umsetzt, die ihr da macht?
Typische Tests, ich weiß nicht, ob es die typischen Tests gibt. Was wir zum Beispiel machen, wir steuern eine Betriebsart an, zum Beispiel Kochen mit Heißluft und prüfen dann, ob unten auf der Reglerebene in der Software die richtigen Regler angesteuert werden, ob der Motor dreht, ob die Heizungen anspringen, ob er die Zieltemperaturen erreicht, die wir einstellen.
Solche Tests sind zum Beispiel die ganz rudimentären, die wir machen. Dann gibt es natürlich jetzt noch Systemintegrationstests, wo wir auch unsere Vernetzungslösungen mit reinziehen und mit testen. Ja, ja. Was heißt denn da Vernetzung? Also das, ich sag mal, für mich als Nicht-Küchenprofi im Großumfeld, wie spielen diese Geräte zusammen?
Vernetzung ist ein bisschen anders. Das ist nicht, dass die Geräte selber zusammen spielen. Zumindest nicht so als Hauptfokus, sondern dass wir auch Remote-Updates einspielen können, beziehungsweise der Kunde. Jetzt denkt man an eine große Kette, die so im Markt sind, wenn du jetzt nimmst, KFC oder sonst irgendwas. Sondern die haben dann teilweise die Anforderung, dass sie sagen, sie wollen ihre Garprogramme auf die Geräte ausrollen. Es ändert sich was und
die wollen die rausrollen. Sie wollen Software-Updates in ihre ganzen Filialen ausrollen. Und die Vernetzungslösung stellen wir zur Verfügung. Und auch der Kunde, also die kleine Gaststätte könnte auch eine Vernetzungslösung machen. Das gleiche System im Prinzip, bloß mit eigenem Account. Ja, verstehe. Ah ja, also gut, Aufgabe war alles automatisieren. Gebt mal Gas. Genau, so kann man es sagen. Ja, genau. Also ihr habt euch dann quasi auf die
Suche gemacht nach Programmiersprache. Was habt ihr da so ausgewählt? Was waren für euch dann so die, dass das sind Tools oder Methoden, die für euch da passen? Also Programmiersprache war relativ einfach. Da bin ich auf Python gegangen, weil ich nichts schwerpunktmäßig, ich wollte nichts, was ich kompilieren muss. Und ich wollte eine Programmiersprache, die kompakt ist und sehr viel Bibliotheken mitbringt, wo ich auch so wenig machen muss. Ich komme aus der C/C++-Welt
ursprünglich. 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 Coder. Die Kompilierzeiten wollten wir weg haben. Wir wollen ja nicht erst kompilieren. Wir haben jetzt auch so eine Package-Infrastruktur, bei der wir mehrere Packages selber maintainen und automatisch unsere eigenen Registers hochladen und so weiter. Das war
die richtige Entscheidung, finde ich. Und von der Infrastruktur, was habt ihr da aufgebaut? Wie habt ihr das gestaltet? Meinst du jetzt Software-Infrastruktur? Ja, so wohl ist es auch. Die Hardware-Infrastruktur ist ein Haufen Geld und Material, ganz klar. Also wir haben Remote- Stromversorgungen, Relais-Module, Logic-Analyser etc. Das ist alles über Netzwerk verbunden. USB
über Netzwerk, auch eine Herausforderung. Was die Software-Infrastruktur betrifft, verwenden wir GitLab, also unser Basissystem, sage ich mal, für die ganzen Pipelines, auch für die eigene Qualitätsabsicherung von unserem Framework. Wir haben von Inbus die
Testbench als Test-Design-Tool. Das hilft uns vor allem auch beim Varianten-Management. Wir haben dann einen abstrakten Testfall und können dann pro Variante, wir haben ja allein 14 verschiedene Geräte-Typen, können wir sagen, okay, der Testschritt ist jetzt für den Geräte-Typ und der nächste ist für den anderen Geräte-Typ. Wir haben aber nur noch einen Testfall und die Testschritte werden variabel konfiguriert. Dann eben die Python-Package-Infrastruktur. Das sind
so die drei Software-Hauptteile. Wie oft laufen die Tests bei euch? Wie sieht so die Pipeline aus? Unsere Tests laufen jede Nacht für zwei Branches. Das heißt, wir können die Geräte ja nicht doppelt belegen. Das heißt, wir haben auch eine Queue dahinter stehen und wir testen zwei Branches. Das heißt, jeder Branche ungefähr vier, fünf Stunden pro Nacht. In der Früh wollen wir die Ergebnisse um sechs Uhr da haben und am Wochenende machen wir einen Komplett-Test eigentlich. Da sind wir
irgendwo in der Ecke 30 Stunden, die wir abfahren. Und tagsüber sind die Geräte aber auch im Einsatz und belegt. Da machen wir entweder On-Demand-Testläufe, wenn jemand sagt, du ich habe da was gefektert, lass uns mal ausprobieren und lass uns mal auf dem Gerät laufen. Ansonsten testen wir da unser Test-Design. Sprich, wenn wir neue Tests integrieren, probieren wir selber aus. Wir
debuggen auch, wir geben auch Debug-Support. Wenn es komplexe Fehler sind, die der Kollege nicht von der Entwicklung an seinem Platz nachstellen kann, machen wir das in der Test-Automatisierung und auch unsere eigenen Packages überprüfen, wenn wir in unserem eigenen Package-Framework Refactorings machen, neue Funktionen einführen und so. Das läuft dann auch alles tagsüber und Hardware-Umbauten natürlich und Hardware-Pflege. Wie viele
Testfälle habt ihr denn da so automatisiert? Irgendwo in der Ecke 2000 irgendwas Testfälle laufen pro Nacht, pro Branche. Und da relativ lang, es waren ein paar Stunden, hast du gesagt. Genau, da ist es weniger, dass das Test-Framework der limitierende Faktor ist. Das wäre schnell genug. Bloß so als Eindruck, wir haben 18 Testgeräte, also wenn man die ganzen Elektroniken und alles mitrechnet, die gleichzeitig laufen und wir haben einen Server dahinter mit irgendwie
8 GB Speicher und 8 Kernen und der managt das ganz locker vor sich hin. Überhaupt kein Problem. Der limitierende Faktor ist unsere eigene, die Hardware, die wir testen. Weil einfach wenn ich das Gerät hochheize und prüfen will, ob die Heizung läuft, dauert.
Wir warten die meiste Zeit da drauf. Aber das ist natürlich auch wahrscheinlich auch viel in der Automatisierung in Richtung, dass man einen guten Ablauf findet, dass man genau solche Sachen an die richtige Stelle auch packt, wo die Heizung läuft und nicht danach wieder was anderes braucht oder so was. Dass man das alles abkühlt oder so was. Ja genau, das ist genau das Thema, dass man nicht abkühlen muss. Und was wir natürlich auch machen,
das wir simulieren zum Teil. Wir schreiben dann Werte rein, wenn wir schon wissen, okay die Heizung läuft, die vorherigen Nester haben das getestet, dann spielen wir einfach Temperaturwerte ein ins System und sagen, du hast jetzt die Temperatur und dann geben wir einen Grad drüber, einen Grad runter, wenn es zum Beispiel um irgendwelche Heizabschaltungen
geht oder so was zum überprüfen. Ja, okay, verstehe. Jetzt ist es ja, also diese, so eine Automatisierung macht ja, hat ja mehr oder weniger zum einen so schauen, okay, es läuft alles noch weiterhin, aber auch gerade in der Nacht jetzt auch Fehler zu finden. Wie ist denn so die Fehlerquote? Ist das so, dass in der Früh immer wieder da auch wirklich Fehler auftreten oder ist es für euch eher so ein, ja so ein, es läuft noch alles gut
weiter Regressionstest, der da läuft? Ne, wir haben schon regelmäßig immer wieder mal Fehler, die wir finden. Vor allem auf zum Beispiel, das kommt immer auf den Branchen an. Jetzt die Stabilisierungsbranche sind natürlich da ruhiger. Der Hauptzulieferbranche, wo dann auch Effektruhigungslaufen etc. ist, dann eher der, der mal ein bisschen kritischer ist mit dem, dass man wieder was aufschlägt. Es gibt natürlich die klassischen Themen,
die man in jeder Firma kennt, sage ich mal. Es wird was geändert und wir kriegen es vorher nicht mit. Soll vorkommen. Kommt auch einmal vor. Ich würde mal sagen, alles in allem ist es gut, aber wir finden schon Fehler und wir gehen natürlich risikobasiert
fort. Das heißt, für uns sind die Sachen kritisch, wo ich sage, die dem Kunden dann auch wehtun oder die einen Haufen Serviceeinsätze verursachen würden etc. Und wenn es jetzt die zehnte Unterebene in irgendeinem Servicemenü ist, dann ist es normalerweise nicht mehr so kritisch für uns. Das ist so unsere Methode, wie wir da rangehen. Aber es ist auch eine
enge Zusammenarbeit mit den Entwicklern. Das heißt, wenn wir was finden, gehen wir zu den Entwicklern, reden mit denen und dann schauen wir, wie das gelöst wird, wo das Problem auch liegt. Wir haben auch Infrastrukturprobleme zum Teil. Netzwerk fällt mal aus. So was kommt auch vor. Das müssen wir vorher dann prüfen. Genau, verstehe. Du hast jetzt ja auch schon gesagt, es gibt immer wieder dann auch so Problemchen. Was sind denn gerade so die größten Herausforderungen bei euren Tests oder so was?
Die größte Herausforderung ist das Skalieren mit der Entwicklung. Wir wachsen zurzeit massiv, was die Entwicklung betrifft und wir wollen nicht in der Situation landen, dass wir in der Testautomatisierung so viele Leute haben wie in der Entwicklung. Wir müssen aber auch schauen, dass wir Schritt halten können. Das heißt, wir haben strategische Projekte mitlaufen, um Testfälle anders anzuordnen, automatisiert, je nachdem, was sich im Code
geändert hat zum Beispiel. Wir versuchen auch, was jetzt eine große Herausforderung ist, was wir ändern uns gerade von unserem Hauptziel. Also dieses Jahr war es so, wir haben Testdesign, komplette Testframewerke zur Verfügung gestellt und wir gehen jetzt eigentlich so ein bisschen in die Richtung zu drängen, dass wir in die Infrastrukturrichtung gehen. Das heißt, wir stellen die Hardware, wir stellen die Software für die Tests zur Verfügung, aber das Testdesign
kann von den Fachbereichen gemacht werden. Das ist jetzt im Moment so ein Ansatz, weil wir sagen, die ändern ja auch die Requirements, können sie gleich die Tests mit pflegen und auch ihre manuellen Tests reduzieren. Das ist gerade so ein Schritt, den wir gerade in Bewegung haben. Und das denke ich, ist im Moment die Hauptherausforderung an der
Front. An der anderen Stelle, wir haben zwei Testautomatisierungslabors. Eins ist in Landsberg, wo ich auch mein Büro habe und eins ist in Wittenheim in Frankreich, wo unsere Tochtergesellschaft ist, die die zweite Produktreihe betreuen, also die Kippfahnen-Systeme. Dort haben wir auch zwei Kollegen sitzen, die gehören fachlich zu meinem Team dazu. Und das untereinander am Fliegen zu halten, ist auch immer ein bisschen eine Herausforderung, auch mit dem Kontakt.
Wir fahren regelmäßig zu denen runter, die kommen regelmäßig auf zu uns, alle paar Monate, weil ich ansonsten in so eine Gruppenbildung von den Leuten vor Ort an der einen Niederlassung laufen kann. Ja, verstehe. Sehr spannend. Du hast vorher gesagt, auch das Thema Sicherheit ist ein wichtiges. Da geht es ja auch bei Hitze und bei solchen Sachen, wenn du sagst,
da ist so viel Strom auch drauf. Das muss ja dann auch gut abgesichert sein. Habt ihr da noch einen speziellen Fokus in euren Tests oder in der Automatisierung drauf, diese Sachen auch wirklich abgesichert zu haben? Also die Safety an sich, dass man jetzt sagt, niemand wird verletzt, ist erst einmal durch die Eigensicherheit der einzelnen Komponenten gegeben. Das heißt,
es wird während der Entwicklung von den Geräten auch durch Zulassung etc. geprüft. Was wir aber schon machen, ist die Sicherheit, zum Beispiel wenn jetzt um Heizsperren geht, dass die Heizung rechtzeitig abschaltet, wenn jetzt irgendeine Komponente durchschalten sollte und nicht alles abfackelt. Diese Abschaltung ist aber so spät, die soll ja nur einen Personen-Schaden verhindern oder einen Gebäudeschaden, dass unter Umständen das Gerät schon zerstört
ist. Und wir gehen dann schon in die Richtung, dass wir versuchen, Tests auch zu machen, wo diese Abschaltungen im Vorfeld getestet werden, weil die Software vorher schon versucht abzuschalten, dass schon der Geräteschaden nicht entsteht. Und das stellt dann auch ein bisschen Herausforderungen dar, nämlich wenn ich jetzt zum Beispiel einen leeren Dampfgenerator habe und ich heize rein, dann ist der halt innerhalb kurzer Zeit kaputt. Und wenn ich
jetzt die Heizspäre teste, darf natürlich der DG nicht leer sein. Ich muss immer was sagen, dass er leer ist und lauter so Sachen. An das muss man halt alles denken. Und so spielst du dann schon mit rein. Ja, verstehe. Sehr spannend. Wenn wir uns in fünf Jahren hier wiedersehen, 2029, German Testing Day, wir treffen uns hier und ich sage, Andreas, wir hatten doch vor fünf Jahren
den Podcast. Wir wollen jetzt noch einen machen. Was willst du mir erzählen, was war das Highlight, was in diesen fünf Jahren bei euch in der Automatisierung passiert ist? Das Highlight wäre wahrscheinlich, dass unsere Test-Impact-Analyse läuft und dass wir die Skalierung von der Firma gut mitgemacht haben. Das wären wahrscheinlich meine zwei Highlights. Impact-Analyse automatisiert auch? Ja. Ah ja, das ist ein Thema, an dem ihr jetzt auch arbeitet?
Das ist es, was wir daran arbeiten, damit wir die Testfälle umsortieren können. Ja, super. Wir werden das in fünf Jahren checken, ob das dann so ist. Wir treffen uns dann wieder hier und dann schauen wir mal, was dann daraus geworden ist. Super, vielen lieben Dank, Andreas, für die Einblicke. Fand ich mal sehr spannend, auch mal wieder in so einem Hersteller-Kontext zu sehen, was da eigentlich Software auch für einen Stellenwert
hat und da auch die Tests dementsprechend natürlich auch. Das macht man sich ja häufig gar nicht so bewusst, wenn man gerade in so einer Kette ist oder irgendwo ist, was da eigentlich im Hintergrund an Software wirkt, die natürlich auch funktionieren muss, damit der Schnitzel schön warm ist. Okay, wirklich. Genau. Ich danke dir schön, wünsche dir noch viel Spaß heute hier auf der Konferenz und bis spätestens in fünf Jahren. Vielen Dank, Rötschi. Gerne. Tschau. Tschau. [Musik]