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 2024 aus Frankfurt mit dabei. Jetzt bei mir zu Gast Carsten Günther von der Firma Marquardt, der uns auf die Reise mitnimmt, wie sie ihre CI/CD Pipelines neu gebaut haben, dazu auch eine neue Plattform geschaffen haben, Klammer auf, Open Source Klammer zu und welche Erfahrungen er damit hat, über diese
Pipeline Qualität in die Projekte zu bringen. Und jetzt viel Spaß bei der Folge. Hallo Carsten, schön, dass du da bist. Danke. German Testing Day 2024 hier in Frankfurt. Es läuft gerade die letzte Keynote, Abschluss Keynote und wir nutzen das auch für die letzte Podcast Folge hier in dem Format. Okay, last but not least. Last but not least. Du hast gerade deinen Vortrag auch hinter dich gebracht und quasi gerockt die Stage und jetzt bist du hier im Podcast. Super.
Ja, ich habe deinen Abstract vorneweg gelesen und da fand ich es sehr spannend. Es geht um CI/CD Pipelines und mal so ein bisschen, was braucht man eigentlich und wo geht es hin. Vielleicht das Rahmen, ihr seid Automobilzulieferer. Frage ich nur, aber ja, also ein Großteil unserer Projekte ist im Automobilbereich. Kannst du das ein bisschen einschränken, was ihr da macht oder
gerade auch in Software? Wir haben verschiedene Produkte. Markward ist ein großer, wir bezeichnen uns als großen Mechatronik-Experten, also sehr hardware-lastig, komplexe Hardware-Entwicklung, hat dadurch auch Nachholbedarf im Software-Entwicklungsbereich. Ziemlich viele Software-Entwickler, die bei Markward arbeiten, kommen klassisch aus der Hardware-Entwicklung.
Ich bin ja auch Elektrotechniker, also ich passe da die Vos aufs Auge. Genau, unsere Produkte reichen von Batterie-Management-Systemen über Bedienelemente, LEDs, so diese Touchpanels, diese schönen Glas-Touchpanels zum Beispiel so im Auto, über diese LEDs, das ist in der aktuellen S-Klasse, das ist so ein LED-Streifen und da sind wir halt Experte drin. Also da gibt es wirklich die Cracks, die genau wissen, wie so eine LED angesteuert worden ist.
Das klingt jetzt trivial, aber das sind halt keine LEDs, die bei Raumtemperatur funktionieren müssen, sondern das sind LEDs, die auch, ja jetzt blöde Beispiel, aber die in Sibirien bei minus 30 Grad genauso schön leuchten müssen, wie in Nordafrika bei, keine Ahnung, 35, 40 Grad. Ja, wo ich halt mit meiner S-Klasse so hinfahren kann. Wo du halt mit deiner S-Klasse so lang fahren willst. Ich meine, da gibt es halt Leute,
die so eine S-Klasse gerne fahren, deswegen. Aber ja, so eine Geschichte. Und dann halt auch wirklich Bedienelemente jeder Art, also Touch und Feedback. Also du brauchst ja Feedback, gerade im Auto ist bei Touch-Elementen immer wichtig, haptisches Feedback zu haben als Fahrer, weil das funktioniert nicht so, als ob ich zu Hause mit meinem iPad sitzen würde.
Auch wirklich abgeriegte Materialien. Also wir hatten neulich mal so einen Tech-Day, da wurde vorgestellt so Schiefer, so dünn geschliffen, ich glaube es war Schiefer, ich weiß es nicht genau, aber es war so dünn geschliffen, dass es transparent wurde und dann halt ein Touch-Panel dahinter. Und es ist halt, wenn du das anfässt, das klingt, das fühlt sich richtig hochwertig an. Das sind schon fancy Sachen, die wir hier machen. Und dann halt eben auch,
ja wir stellen auch Waschmaschinenknöpfe her. Das ist jetzt nicht Automobilbereich, aber eigentlich egal. So ein Waschmaschinenknopf, der hat auch ganz viel Funktionen drin. Und früher war Markwart der klassische Schalter-Markwart. Heute ist halt in jedem Schalter ein Mikrocontroller drin und dadurch immer Software. Genau, da kommen wir ins Spiel. Ja schön. Also ihr macht auch Software, habt da ganz viel und da ist dann gedacht,
die ICD-Pipelines, wie können wir es besser machen? Was war denn die Not? Also wo kommt denn das Thema her? Die Not kommt eigentlich ursprünglich aus der Automatisierung. Also tatsächlich bei uns in der Firma wird sehr viel noch manuell gemacht. Kundenspezifische Anforderungen, Artefakte, die geliefert werden müssen, werden teilweise manuell erstellt. Sprich
Automatisierung ist ein großes Thema und natürlich auch Testen. Wenn man Automatisierung und Testen und Regressionstests und automatisiertes, repetitives Ausführen von Tests, wenn man das machen will, dann kommt man eigentlich um CI/CD nicht drumrum. CI/CD ist eigentlich die Antwort. Also eigentlich ist das CI, Continuous Integration. Da geht es ja eigentlich darum, dass ich täglich, mehrmals täglich, meine Änderungen in einen Trunk, in eine Mainline einspiele und so einen
zur Verfügung stelle und so mit Leuten zusammenarbeite, zusammen an einer Code-Basis. Natürlich alles getestet mit einer gleichbleibenden, hohen Qualität. Und ja, da ist die Not, weil die Softwarequalität ist einfach nicht da, wo sie sein soll. Ist sie nie. Also man fängt gerade so im Automobil- oder auch im Embedded-Bereich, kommt man ganz oft von kleinen Spielprojekten, die man mal so, also ich mache auch zu Hause mal irgendwas und da fange ich auch nicht an mit
meiner CI-Pipeline. Da hecke ich ein bisschen und dann freue ich mich, da blinkt die LED. Ich habe es so in meinem Vortrag gesagt, so dieser Dr. Brown-Effekt, wo der niederkniet an seinem DeLorean, den er noch nicht kannte, den er erst in 30 Jahren baut, wo er sagt, der Fluxkompensator, ja endlich habe ich was erfunden, was funktioniert. Das ist ja so die Freude vom Softwareentwickler, dass man irgendwas, wenn man erstmal irgendwas hackt, wozu hackt man das denn, wozu programmiert
man denn? Damit am Ende irgendwo irgendetwas etwas tut und funktioniert und das ist ja diese Freude und gerade im Embedded-Bereich. Und da ist man total schnell und irgendwann wird das Produkt aber komplexer. Wenn man dann spätestens anfängt, sowas zu verkaufen und man hat verschiedene Kundenanforderungen, dann kommt man ganz schnell hin, dass man Tests braucht, automatisiert,
um die Qualität hoch, um die Qualität gleich zu halten und da ist die Challenge. Und die ist bei Maglort genauso da, wie sie auch vorher bei anderen Firmen, bei denen ich gearbeitet habe, war auch immer da. Und wie nähert ihr euch dem jetzt oder was waren so die Steps dann dahin, das mal in den Griff zu kriegen? Zum einen ist bei Embedded-C-Entwicklungen ganz wichtig das Bildsystem. Und man braucht ein einheitliches Bildsystem. Also so ein Bildsystem ist eigentlich nicht etwas,
was jeder Entwickler bedienen will. Ein Entwickler hat Spaß daran, Funktionalität umzusetzen und da kommen wir ins Spiel. Wir bezeichnen uns als Plattform-Ingenieur. Plattform-Engineering ist ein großer Hype gerade und das finde ich super geil, weil nämlich ich hatte bisher keinen Namen für das, was ich gemacht habe. Ich mache Tools. Es gibt immer so eine IT-Rolle, gerade in so einer Softwareentwicklung, da gibt es die, die die Tools machen. Und ich fand diesen Titel "Der,
der die Tools macht", das klingt wie "Der, der mit dem Wolf tanzt". Das klingt doof. Und jetzt kam irgendjemand mit diesem Plattform-Engineering. Für mich ist es Plattform-Engineering. Also wir versuchen eine einheitliche Plattform aufzubauen. Wir nennen das SPLE-Plattform, Software Product Line Engineering, wo wir quasi den Entwicklern alles an die Hand geben, damit sie ihr Produkt entwickeln können mit Fokus auf Produkt, ihr Produkt konfigurierbar machen können und Varianten
bilden können von Produkten, um damit Kunden zufriedenzustellen. Also Markwart ist ja eine Firma, die Produkte herstellt und diese Produkte an möglichst viele Kunden verkaufen. Also wir haben ja Endkunden. Wir stellen ja nicht direkt Produkte her, die jetzt direkt der Endconsumer sieht, sondern Waschmaschinenknöpfe, Batteriemanagementsysteme, eine LED im Auto.
Da ist ja immer noch ein Kunde dazwischen, der das customised haben will. Und diese Challenge, den Entwickler zu enablen, seine Software konfigurierbar zu machen, diese Konfiguration zu testen, das ist so unsere Challenge mit unserer Plattform. Und da sind wir aktuell auf dem Weg. Und natürlich, wenn du so eine Plattform entwickelst, dann willst du natürlich dem Entwickler auch alles an die Hand geben, dass er seine Changes integrieren kann,
ohne etwas kaputt zu machen. Und da ist ja CI eigentlich vorneweg. Ich habe es in meinem Vortrag gesagt, mir wurde gesagt, als ich angefangen habe, bei meinem ersten Job im Embedded-Bereich, hieß es, da ist dein Code, dafür bist du verantwortlich, aber verändern bloß nicht. Du kannst Sachen kaputt machen. Du fragst dich halt, hä? Als Softwareentwickler, ich dachte, das ist mein Job, Software zu ändern. Und jetzt sagt er zu mir, ändere bloß nichts.
Ja genau, weil nämlich jede Arbeit, die ich mache, das war keine fehlertolerante Umgebung. Du musst ja versuchen, fehlertolerant zu sein. Also wenn jemand Fehler macht und ein Softwareentwickler wie jeder Mensch macht Fehler, wir sind alle, ein Kollege hat mal verglichen mit Chuck Norris. Chuck Norris ist der Einzige, der Software entwickeln kann, ohne zu testen, weil er sofort, weil jede Änderung sofort sitzt und genau die Kundenanforderungen erfüllt. Aber wir sind nicht
Chuck Norris, wir sind normale Menschen. Wir müssen also, wir müssen testen, testen, testen. Und diese Tests so zu etablieren, dass ich Sachen ändern kann und ich alleine das Feedback bekomme, dass ich etwas, dass ich einen Fehler gemacht habe und nicht die Organisation. Das ist ja das Ziel von Continuous Integration. Das ist für mich das Ziel als Plattformingenieur, eine Plattform zur Verfügung zu stellen, die diese Feedback-Kultur, die diese fehlertolerante Kultur quasi erlaubt.
Ja, ja, ja. Ich meine, da fehlt natürlich dann auch noch der Aspekt, dass ja diese Tests ja auch geschrieben werden müssen, die dann auch genau darauf hinzeigen, dass die mir das Feedback geben. Also das braucht man natürlich dann auch noch dazu, die dann da drauf laufen. Deswegen postulieren wir ja auch Test-Driven Development. Also ich bin großer Fan von Test-Driven Development, also dass der Entwickler selber seine Unit-Tests schreibt. Am besten,
dass er seine Tests spezifiziert anhand der Anforderungen, bevor er entwickelt. Er soll ja Test-Driven entwickeln, weil dann entsteht eigentlich die beste Software und man kriegt ein Geschenk mit, nämlich der Test. Und der Test ist ja nicht dafür da, zu beweisen, dass das, was ich gerade programmiere, funktioniert. Weil so gut sind wir alle. Also wenn du mir eine Aufgabe gibst, schreib mir jetzt mal ein Skript, was irgendwie zwei Zahlen addiert, dann schreibe
ich dir das. Und das wird funktionieren. Aber wenn ich einen Test dafür schreibe und jetzt kommst du als nächstes und jetzt erweitere das Skript. Dann machen wir noch das und das und das. Dann sind meine Tests, die ich geschrieben habe, die spannen ein Testnetz. Und dieses Testnetz, das ist meine Fehlertoleranz. Weil wenn ich nämlich jetzt Fehler mache, wenn du mir neue Anforderungen gibst, weil die Wahrscheinlichkeit, dass ich mit neuen Anforderungen alle Features, die schon implementiert
sind, vor Augen habe und weiß, die müssen auch noch erfüllt werden. Das ist ja nicht der Fall. Irgendwann, du kennst nicht alle Features, du kannst nicht. So perfekt ist niemand. Wieder Chuck Norris. Und wenn du da dein Testnetz hast, dann schaffst du dir dein eigenes Sicherheitsnetz. Weil wenn du einen Fehler machst, dann siehst du, oh ja, ach Mist, stimmt. Klar, das habe ich kaputt gemacht. Der Test steht fehl. Und umso mehr Tests du hast, umso entspannter kannst du arbeiten,
umso ruhiger kannst du schlafen. Weil du weißt immer, nach ein paar Jahren hast du dann für deine, und so ist es ja, du entwickelst ja jahrelang eine Komponente weiter. Und dann hast du da tausende Unit Tests, die werden immer ausgeführt mit jeder Change, die müssen schnell sein, du brauchst fast Feedback und du kannst dir immer sicher sein. Und wenn du mal einen Bug trotzdem einbaust, dann fixt du ja diesen Bug. Und was machst du natürlich zuerst? Du schreibst zuerst einen Test,
um den Bug zu reproduzieren. Und das ist wieder ein Geschenk. Das ist keine Verschwendung, diesen Test zu schreiben. Weil dieser Test macht ja nur dein Testnetz enger. Bisschen enger, ja genau. Das macht es immer ein bisschen enger. Da werden immer Löcher drin sein. Da wird immer irgendwo was sein. Ich meine, keine Software ist bugfrei, würde ich jetzt behaupten. Aber umso enger das
Testnetz ist, umso geringer ist die Wahrscheinlichkeit, dass noch Bugs drin sind. Und umso wahrscheinlicher ist es, dass wenn du eine Änderung machst, du immer sicher sein kannst, dass du die alten Features nicht kaputt machst. Ja, da sind ein paar schöne Perspektivwechsel auch drin, die einfach helfen, das auch als Geschenk zu sehen, so wie du es sagst. Das finde ich total wertvoll. Jetzt von eurer Plattform her,
auch gerade im Embedded-Umfeld. Was sind denn so die Pfeiler, die so essenziell sind, die vielleicht auch mal ein bisschen anders sind als jetzt in einer anderen Softwareentwicklung? Was macht das da bei euch gerade besonders aus? Also bei uns ist ein großer Pfeiler CMake. Das ist ein Open Source Build System. Sehr mächtig, würde ich auch sagen, sehr reif. Es ist ein sehr altes Projekt, wird aber nach wie vor maintained.
Also ich bin ein totaler CMake-Fan. Das ist ein Pfeiler. Und der andere Pfeiler ist halt CI und Trunk-Based Development, also so ein bisschen unser Entwicklungsflow, dass wir halt sagen, wir arbeiten mit Git-Repositories, wir haben Protected Branches, wir arbeiten mit Branch Protection und man muss immer seine Änderungen durch ein Gate durchbringen. Das ist mein Eckpfeiler. Ein anderer Eckpfeiler natürlich, wenn wir über Gates reden, sind die Unit Tests. Da
setzen wir auf Google Test. Google Test, ein weiterer technischer Eckpfeiler, würde ich sagen. Ein super Framework. Ich liebe das total. Es ist ein bisschen schwierig, da reinzukommen, weil wenn man aus der Embedded-C-Welt kommt, Google Test ist C++. Es ist so ein bisschen so eine technische Hürde, da reinzukommen, aber es ist halt auch dementsprechend sehr mächtig, weil du kannst die komplette Macht vom objektorientierten C++ einsetzen und kannst so
fancy Sachen machen. Also man kommt sich vor, als ob man in der Java-Welt unterwegs ist oder Python, wo natürlich, was natürlich eine viel mächtigere Programmiersprache ist als vielleicht, Gott, hoffentlich hören jetzt nicht so C-Puristen zu, aber also Python und Java, würde ich sagen, ist schon mächtiger als C. Also von solchen Entwicklern wird ja eigentlich C ein bisschen belächelt, aber wenn man da ankommt mit Google Test und mit C++ als Testrunner, das ist schon
beeindruckend. Dann ein weiterer Test, ein weiterer Eckpfeiler ist, das ist mal ein Tool von uns, wir haben tatsächlich selber ein Tool geschrieben, das ist der Hammocking, schräger Name, wir wollten es erst Hammock nennen, das ist ein Python-Modul, ein Python-Package, was automatische Mockups
generiert. Das ist in der C-Entwicklung schon tricky, weil ziemlich viele Programmiersprachen, gerade die Objektorientierten, bieten das eigentlich in ihren Testframeworks von Haus aus an, dass du quasi dein Item an der Test freischneiden kannst, du hängst ja immer von externen Schnittstellen ab. Und die willst du ja nach Möglichkeit, diese Dependencies willst du ja lösen und dann vielleicht die Return Values von externen Schnittstellen willst du ja als Inputvektoren oder Outputvektoren
benutzen in deinem Unit Test. Und dafür haben wir einen automatischen, so eine Art Automocker haben wir das früher genannt, den haben wir Hammocking genannt, also Hammock ist die Hängematte und dann Mockups, also nach F'en, also man nennt ja klassisch so eine nachgemachten Schnittstellen, fürs Testen nennt man Mockups. Da sind wir sehr stolz drauf, weil da haben wir relativ schicken Hack in Python gemacht, ist Open Source, kann man sich von unserer, wir haben auch unsere Plattform
Open Source auf GitHub, kann man sich runterladen, kann man auch installieren. Auch sehr cool, dass ihr die Plattform auch so zur Verfügung stellt, also das ist ja auch, macht das auch nicht jeder, ne? Ne, wir sind da auch ein bisschen, wir sind da vielleicht auch ein bisschen speziell unterwegs, ja, also wir hatten damals gefragt, wir wollen ein bisschen was Open Source machen und unsere Chefs haben gesagt, ja macht, vielleicht ein bisschen schnell, aber ja, wir wollten was
Open Source machen, also wir hatten echt mal Lust drauf, was Open Source zu machen. Also ich meine, wir haben letztendlich so eine CMake Bildumgebung implementiert, die halt so ein bisschen die Software Product Line Engineering erlaubt, also die Varianten unterstützt, das kann CMake komischerweise von Hause aus nicht, so ein Varianten Handling und ja und dann halt ein bisschen, so Open Source Tools zusammengestrickt, ja, KConfig, CMake, ein bisschen PowerShell, ein bisschen Python und dann
halt unseren HammerKing und Google Test, das ist schon ein kleines mächtiges Werkzeug, das ist Open Source und das setzen wir halt auch in der Firma ein, entwickeln es aber Open Source weiter. Ja, spannend. Wenn ich so an Automobilbranche denke zum Beispiel, oder auch an so Steuergeräte, da hängt ja auch, je nach Klassifizierung vielleicht, auch irgendeine Reporting-Notwendigkeit dran, Revisionssicherheit von irgendwelchen Sachen, Archivierung, Dokumentation und so,
Pflichten, die man sieht. Habt ihr das da auch irgendwo mit integriert oder? Ja, wir haben, jetzt kommt ein weiterer, stimmt, ein weiterer Eckpfeiler, den ich vergessen habe. Gut, dass du diese Frage stellst. Also ein weiterer Eckpfeiler von unserer SPLE-Plattform ist Sphinx. Sphinx ist das Dokumentationstool der Python-Entwicklung. Also das ist ja letztendlich die Basis für Read the Docs. Also alle Dokumentation, die du eigentlich auf Read the Docs liest, ist mit
Sphinx generiert. Es ist ein sehr mächtiger Dokumentationsgenerator, basiert auf Restructured Text oder Markdown und das haben wir integriert. Also wir haben tatsächlich nicht nur Google Test als Testrunner, sondern wir haben auch verschiedene Sphinx-Extensions, in Sphinx heißt es Extension, es gibt sehr viele Sphinx-Extensions, die dir ermöglichen Requirements-Tracing,
Testspec-Generierung, automatische Testreports und Dokumente. Also wir haben tatsächlich so einen Dokumentengenerator mit integriert in die Plattform, die es uns ermöglicht, R-Space-konform, also R-Space ist das Stichwort, Dokumentation R-Space-konform für die Unit Construction zu generieren. Das wird auch genutzt, das wird auch von unseren Usern in der Firma benutzt, weil die natürlich auch gesagt haben, wir wollen Tracing haben zu Requirements, wir wollen die
Möglichkeit haben, Software-Requirements zu schreiben. Genau, das machen die und das Schöne daran ist, dass diese ganze Dokumentation, die sie schreiben, ist im Source-Code-Repository, beim Source-Code. Also bei jeder Komponente haben sie die Möglichkeit, einen Komponenten-Report zu generieren, der die Komponenten-Designspec beinhaltet, die Testspezifikation, also den Testcode, die Testspezifikation generieren wir aus dem Google Test, aus dem Google Test-Suite
und dann auch die Testergebnisse gleich mit dazu. Und da kann man sich quasi vom Requirement zum Testergebnis R-Space-konform durchführen. Das ist ein weiterer Eckstein. Super integriert alles. Ja, da sind wir auch sehr stolz drauf. Ich glaube, ich könnte auch sein. Auf jeden Fall würde ich jetzt, weil ich es so höre, auch unterschreiben. Wir sind vielleicht in fünf Jahren wieder hier, 2029, German Testing Day, Frankfurt. Ach, Mensch, Karsten, kannst du dich erinnern? Hier damals
unsere Podcast-Folge. Ja, damals, ich habe ja unsere Plattform vorgestellt. Was meinst du, in den fünf Jahren, was sind so die Highlights, die da jetzt noch kommen? Oder was wünschst du dir? Ja, ja, ja, ja, ja. Also mein Wunsch ist natürlich, dass unsere Plattform gelebt wird, genutzt wird, viel mehr als jetzt aktuell. Also wir wollen eigentlich im Laufe der nächsten zwei Jahre möglichst viele Projekte, die aktuell noch auf sehr alten Technologien aufsetzen beim
Markwart. Wir wollen das alles auf die SPLA-Plattform heben. Das ist unser Ziel. Also das hoffe ich, dass ich in fünf Jahren hier stehe und sagen kann, das war eine Erfolgsstory. Das haben wir gerockt. Die Zeichen sind gut. Die Akzeptanz der User ist auch hoch. Ja, und dann natürlich R-SPICE, was du gerade gesagt hast. Es ist ja nicht nur Unit Construction. Das ist ja das R-SPICE beschreibt das ganze V-Modell. Und eigentlich möchte ich in fünf Jahren das ganze V-Modell unterstützen,
soweit wie es für die Softwareentwicklung notwendig ist. Also das ganze Reporting auf der Seite. Wir wollen auch Hardware in the Loop, Software in the Loop, also Softwareintegrationstests, Systemintegrationstests wollen wir massiv unterstützen und auch mit unserer Plattform die Grundlage dafür stellen, dass das möglichst einfach gemacht werden kann. Da sehe ich mich so in fünf Jahren hoffentlich. Sehr cool. Also wir werden es überprüfen dann. Ja, ja, ich werde
berichten. Das ist jetzt natürlich dann auch on-air und alle haben es gehört und das muss jetzt dann auch gechallenged werden. Ja, okay, ja, ja, ja. Das muss ich also jedes Jahr mitberichten. Genau, musst du berichten. Noch eine Reportingstelle. Ja, mache ich gerne. Super, Carsten, vielen lieben Dank für die Einblicke. Ich fand es mega spannend, auch toll, dass ihr das als Open Source zur Verfügung stellt. Da kann man sich, pack mal die Links am besten
vielleicht auch rein. Ja, ich schicke dir noch die ganzen Links. Genau, dann haben wir die in den Show Notes auch. Das wird sicher für den einen oder anderen auch interessant. Dankeschön, ich wünsche dir gute Heimreise heute und schönen Ausklang jetzt noch und bis zum nächsten Mal. Ja, ich muss mich auch bedanken, Richard. Danke für die Gelegenheit, danke für die Einladung, hat richtig viel Spaß gemacht. Mir auch, sehr gerne. Super. Ciao. Ciao. Ciao.