Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Let's celebrate quality. Diese Woche ist die World Quality Week und wir feiern mit mit dem Podcast. Darum gibt es diese Woche jeden Tag eine neue Folge, damit du mehr Inspiration, mehr Motivation und ein paar neue Impulse hast, um Qualität zu leben und zu feiern. Viel Spaß dabei. Diesmal bei mir Christian Schwarzer, Experte für Automotive Testen.
Das Thema war für mich besonders spannend, da ich in dem Bereich bis jetzt wenig Erfahrung habe und mal herausfinden wollte, was denn eigentlich so die Unterschiede sind, wenn man im Automotive Bereich testet, anstatt in ganz normalen Software Projekten. Wir haben uns über die Unterschiede unterhalten, welche Regulatorien greifen, wie Tests und Reviews ablaufen und welche Ausbildungen es in die Richtung gibt. Und jetzt viel Spaß bei der Folge. [Musik] Hallo Christian, schön, dass du da bist.
Hi Ritchie, danke, dass ich dabei sein darf. Es freut mich. Ja, sehr schön. Es freut mich auch, weil du hast uns ein ganz spannendes Thema mitgebracht, zu dem ich selber so ganz wenig Erfahrung nur habe. Und das finde ich ganz schön, weil da kann ich endlich mal alle Fragen stellen, die ich schon immer stellen wollte. Das freut mich. Und zwar geht es um Automotive Testen, also Testen in der Automobilbranche. Sage ich das richtig?
Ja, genau. Automotive oder Automobilbranche, genau, Testen im Automobilbereich. Da kenne ich mich aus, da bin ich seit Jahren unterwegs und bin bereit, heute ein paar Geschichten zu erzählen. Ja, sag mal, was macht denn das so besonders aus deiner Wahl? Du kennst ja vielleicht auch das klassische Software-Testen im Webumfeld ein bisschen. Ja, natürlich. Was macht denn Automotive dem Bereich so spannend oder so anders?
Da gibt es auf jeden Fall einige Herausforderungen, aber natürlich auch viele Chancen, gerade dann für uns als Tester in der Qualitätssicherung. Also ein Thema, das bei uns im Automobilumfeld auch immer mitschwingt, ist, dass wir immer auch die Hardware in irgendeiner Form auch mit an Bord haben. Also auch wenn wir klassische Software-Tester sind, müssen wir zumindest Grundlagen von der Hardware verstehen, auch Hardware-Kommunikation dann ein Stück weit prüfen.
Und natürlich kannst du dir wahrscheinlich vorstellen, ein Auto, das ist relativ groß, es ist sehr komplex, da ist unfassbar viel Software drin. Das heißt, es arbeiten auch unfassbar viele Leute und Firmen und Unternehmen daran. Und ja, die ganze Kommunikation ist sehr schwierig und deswegen gibt es da eben sehr viele Normen und Standards, die uns da ein bisschen helfen wollen, uns da in dieser Ecke voranzubringen.
Was natürlich dann aufwendig ist, alles nachzuverfolgen, aber man kommt natürlich mit ganz vielen Unternehmen von der ganzen Welt in Kontakt und lernt sehr, sehr, sehr viel, wenn man in dieser Branche unterwegs ist. Was definieren denn diese Standards? Hör ich da richtig raus, es ist schon ein reguliertes Umfeld, oder? Ja, es ist sehr reguliert sogar. Also für uns als Tester kann man eigentlich sagen, sie regulieren eigentlich fast alles.
Also es geht tatsächlich von den Prozessen, also welche Aktivitäten wir tun müssen, zu welche Dokumente erstellt werden müssen, zu welche Personen wo beteiligt sein müssen, also welche Rollen. Aber dann, wenn es in das Thema funktionale Sicherheit geht, also das heißt, wenn durch einen Softwarefehler in irgendeiner Form jemand verletzt werden könnte, das Stichwort funktionale Sicherheit, die sagen uns dann sogar, welche Testmethoden wir anwenden müssen, mindestens.
Allerdings sind diese Normen natürlich, kannst du dir vorstellen, ja sehr streng. Das heißt, in der Regel, wenn uns so eine Norm was vorschreibt, dann ist es schon sehr ausführlich, was wir tun müssen und in der Regel tun wir gar nicht mehr, als die Normen uns sagen, weil die Normen und Standards schon sehr, sehr, sehr ausführlich sind in diesem ganzen Bereich.
Und ist denn da noch irgendwie Raum, es fällt mir gerade, ist denn da noch viel Raum für Kreativität auch beim Testen? Also ich sage mal so Richtung exploratives Test oder so, kann man da solche Sachen überhaupt noch irgendwo unterbringen? Kann man, das ist spannenderweise sogar auch vorgeschrieben, dass man sowas tun muss. Also wir sind quasi gezwungen als Tester da auch hinten raus zu sein, eben explorativ, intuitiv, ja einfach rumspielen mit dem System, müssen wir tatsächlich auch tun.
Klingt etwas seltsam, wenn man sagt, man ist gezwungen kreativ zu sein, aber das haben wir am Ende auch noch. Nur sind natürlich am Anfang die ganzen Methoden, ob es jetzt Blackbox oder Whiteboxen, Coverage sind, da sind schon relativ strenge Methoden vorgegeben, über sehr, sehr viele Teststufen und da hat man dann erstmal eine sehr starke Grundlast für den Test.
Ja, verstehe. Wie sieht denn da so der Prozess üblicherweise aus? Ist das ein klassischer Testprozess oder wie, gerade auch wenn du sagst mit der Hardware zusammen oder wie ist denn da so der Ablauf oder auch wo im Entwicklungszyklus setzt man denn als Tester da auch mit ein? Sehr gut, ja. Also es gibt, vielleicht wenn man ganz oben anfängt, gibt es so einen Highlevel-Prozess, also man kann es fast gar nicht Prozess nennen, wir nennen es eher so den Systemlegungszyklus.
Also ganz am Anfang gibt es das Produkt nicht und die Idee von diesem Produkt gar nicht und ganz am Ende gibt es das Produkt nicht mehr und zwischendrin müssen wir uns dann Gedanken machen, was wollen wir entwickeln. Die Konzeption, dann eben die Entwicklungsphase und auch der Test, dann Produktion, Nutzung, Wartung und Außerbetriebnahme. Das sind so die sechs großen Phasen.
Da gibt es auch im Automobilumfeld, kannst du dir natürlich vorstellen, überall Leute, die da in allen Phasen beteiligt sind. Wir als Tester sind dann in der Entwicklungsphase, in der Regel 99% aller Tester werden da unterwegs sein und je nachdem wie man das dann auslegt, aber meistens hat man da dann auch ein klassisches V-Modell, was wir dann da drehen.
Unser V-Modell im Automobilumfeld ist jetzt nicht das klassische Software-V, wo wir nur vier Stufen haben, sondern wir haben dann in der Regel sieben, neun oder sogar noch mehr Stufen, wo wir dann ganz oben anfangen auf Fahrzeugebene, dann brechen wir es runter auf zum Beispiel Innenelektronik-Ebene, dann brechen wir es runter auf Steuergeräte-Ebene und dann brechen wir es runter auf die Software-Ebene.
Und je nachdem, wo man dann als Tester unterwegs ist, testet man dann im kleinen Teil dann die reine Software, also wirklich kleine Software-Komponenten, wie man es dann auch kennt. Oder man ist dann eben verantwortlich für einen Steuergerätetest oder dann auch für den Test im Verbund, wo man dann sich Prüfstände aufbauen muss.
Also man kann in allen Bereichen typisch unterwegs sein, es ist aber in diesen Prozessen auch immer vorgeschrieben, dass jemand in der Testerrolle auch auf der linken Seite vom V dabei sein muss, also Stichwort Review oder auch statische Analyse. Da muss immer jemand in der Rolle des Testers dabei sein. Das ist jetzt natürlich nicht nur eine Person, die dann alles macht.
Es gibt dann viele Leute, die dann eben überwiegend Reviews durchführen und dann ein paar Tests machen. Es gibt Leute, die nur Testfälle schreiben und die dann automatisierbar machen. Hängt natürlich sehr stark davon ab, wo man unterwegs ist, aber dieses Grundprinzip von V-Modell und ich nenne es jetzt mal normalen Entwicklungsprozess, den haben wir nach wie vor auch im Auto.
Ich verstehe. Wie kann ich mir das vorstellen, vom täglichen Doing, ist man da als Tester oder auch im Entwicklungsteam nur mit einer Sache beschäftigt, dass man jetzt so ein Steuergerät hat oder irgendwie das Bussystem sich anschaut oder die Integration oder switcht man da manchmal auch? Gibt es da auch so Teams, die machen mal ein bisschen da, ein bisschen dort und halten das so ein bisschen zusammen? Wie ist denn da so die Struktur?
Das Schöne in diesem Umfeld ist, je nachdem natürlich in welchem Unternehmen man ist, in welchem Bereich, man kann alles machen, was man will. Also ich war in verschiedenen Rollen unterwegs, wo ich dann ein Jahr nur am Fahrzeug, also im fast fertigen Fahrzeug Sachen getestet habe und man ist dann wirklich nur dafür verantwortlich. Es kommt eine neue Version von einem Steuergerät und man muss dann die Testfälle anpassen und die durchführen.
Gerade wenn man weiter unten eher Richtung Software-Ecke unterwegs ist, da macht man dann gerne die Unit-Tests, nennen wir das dann, das sind die Software-Komponenten-Tests und die Integrations-Tests und teilweise System-Tests. Und dann geht man mal an die Hardware drauf, also da ist man dann sehr viel unterwegs, gerade dann auch mit den Reviews, die man dann eben in der Regel dann auch noch mit erledigt, kann man dann auch wirklich vollumfänglich unterwegs sein.
Und dann wirklich eine Funktion von einer kleinen Software-Komponente von einer Unit fast bis zum fertigen Fahrzeug auch begleiten. Also das kann man sich dann sehr aussuchen, wenn man unterwegs ist. Okay, verstehe. Und es ist ja, sagen wir mal, die ganze Software-Welt seit 20, 25 Jahren unterwegs.
Agilität, DevOps, das muss alles, CI/CD, Tagbuchwerk, schnelles Listen und so. Wie ist denn da so, also gibt es so etwas auch bei euch oder ist das quasi, das geht alles gar nicht oder wo steht denn ihr da so im Schnitt? Also der Trend ist natürlich bei uns auch nicht vorbeigezogen. Wir sind da auch mit an Bord. Für uns ist es generell, für die großen Unternehmen ist das Stichwort safe, kennst du ja vielleicht auch, Scale Agile Framework.
Das ist das, was generell in der Branche versucht wird durchzusetzen. Man hat jetzt aber auch schon Ecken gefunden, wo es dann vielleicht besser funktioniert und wo es schlechter funktioniert. Also gerade wenn man dann wirklich das ganze Fahrzeug am Ende dann irgendwie mit vielen Hardware-Bauteilen und sonstiges machen will, da wird es dann mit dem agilen Ansatz relativ schwer, weil die Hardware-Entwicklung eben auch verhältnismäßig langsam ist.
Also man muss dann erstmal eine Hardware entwickeln, bis man dann mal einen Prototypen hat, ist man gerne mal bei acht bis zehn Wochen. Das ist jetzt mit den Sprint-basierten Ansätzen dann ein bisschen schwieriger machbar. Da müsste man dann quasi die Hardware-Entwicklung als irgendwie epic parallel rausziehen oder sonstiges. Also da gibt es viele Ansätze.
Gerade die Bereiche, die jetzt sehr serverlastig sind, wo viel im Backend passiert, wo dann die Software remote wieder auf das Fahrzeug geflasht wird. Also wenn es überwiegend softwareseitig ist, geht da sehr, sehr viel agil. Und da ist es auch super einsetzbar, sind auch sehr viele Unternehmen sehr zufrieden damit. Die Hardware-Entwicklung und ähnliche Bereiche, da wird es dann schon schwieriger, aber wird natürlich auch versucht durchzusetzen, weil die Vorteile klar auf der Hand liegen.
Ja, es ist natürlich durch diese Regulatorik und glaube ich auch die gewachsenen Strukturen und diese Hardware-Nähe ist es wahrscheinlich nicht so einfach. Aber ich habe verstanden, der Trend geht schon dahin und man versucht da auch agiler zu werden und die Dinge umzusetzen. Definitiv, also da gibt es auch viele Workshops und Überlegungen, wie man eben diese ganzen Dokumentenwelt dann auch in die agile Schiene mitziehen kann.
Und natürlich kann man ja die Dokumente, die erstellt werden müssen, kann man ja auch als Arbeitsprodukt im typischen Scrum oder Save auch wieder sehen. Das ist jetzt keine Dokumentation, die man halt mitziehen muss, sondern es ist halt wirklich ein Produkt, das dann ausgeliefert wird, wo dann auch wieder einen Wert schafft. Da gibt es also auch wieder einige Möglichkeiten, aber der Wandel ist noch nicht vollzogen, sage ich mal.
Ja, verstehe. Wenn man mal ein bisschen auf die Testmethoden schaut, gibt es da so gewisse Standards, dass man sagt, man nutzt jetzt diese IST-Kopie-Methoden oder du sagst, manchmal ist es auch vorgegeben. Oder gibt es da modellbasierte Ansätze oder wie ist denn da so die Lage? Das ist eine super Frage. Da gibt es eine weite Bandbreite von Sachen, die wir tun müssen. Also IST-QB ist auf jeden Fall auch relevant oder IST-QB-verwandte Methoden kann man es jetzt mal nennen.
Es gibt eben ein paar Ansätze. Sobald es sicherheitskritisch wird, ist es automatisch vorgeschrieben, was man mindestens tun muss. Viele sicherheitskritische Systeme überraschen einen auch, dass die wirklich sicherheitskritisch sind. Also sowas wie ein Scheibenwischer ist schon ein Hochrisikosystem jetzt mal. Nicht das allerkritischste, aber ein Scheibenwischer ist auch schon wichtig. Wenn der ausfällt und es regnet, dann fährt man in die Wand.
Und dann natürlich sowas wie ein Airbag oder sonstiges, die sind natürlich noch deutlich sicherheitskritischer. Und bei all diesen Systemen muss man dann eben die Wirkkette analysieren. Man versucht es maximal modular zu gestalten, dass man eben nicht so viele Nebeneffekte bekommt. Aber dann gibt es dann einfach Tabellen, wo dann drinsteht, ja, sobald jetzt zum Beispiel für den Scheibenwischer, man muss auf jeden Fall diese Blackbox-Methoden machen.
Also Äquivalenzklassen, Grenzwerte auf der Software-Unit-Ebene und man muss MCDC, Modified Condition Interstition Coverage, zum Beispiel, verwenden. Muss man machen. Und wenn man es nicht tut, dann, ja, wenn dann irgendwann mal was schief geht, dann kommt man in ganz, ganz, ganz große Probleme. Dann ist man quasi für jeden Schaden haftbar. Aber man kann es sich in diesen Tabellen auch ein Stück weit raussuchen.
Also es gibt dann viele Methoden und man muss dann, in der Regel ist die Formulierung, eine geeignete Kombination raussuchen. Und jetzt, um auf die Frage dann zurückzukommen, sowas wie Model-Based Testing, modellbasierte Ansätze, die sind dann häufig optional oder nur empfohlen. Also man kann es tun, man sollte es tun, aber man ist nicht verpflichtet, es zu tun.
Und dann gibt es immer so ein Team von Test-Manager, funktionale Sicherheitsmanager, die müssen sich dann am Anfang vom Projekt überlegen, was tun wir denn? Und das muss dann auch wieder dokumentiert werden. Alles, was nicht dokumentiert ist, hat nicht stattgefunden aus dem Automobilumfeld. Und wie sieht das in der Praxis aus, gerade mit modellbasierten Ansätzen? Werden die verwendet oder ist das, weil es optional ist, eh dann außen vor?
Also bei den sicherheitskritischen Anwendungen ist es jetzt überwiegend optional, würde ich sagen. Also da wird es eher oft rausgeworfen. Bei den Themen, die nicht sicherheitskritisch sind, da ist man dann auch ein bisschen freier. Da kann man dann die Methoden aussuchen, die man möchte, damit man im System, das ist dann auch eine Formulierung, "sicher genug" ist. Da wird dann immer mehr auf modellbasierte Ansätze geschaut. Aber es wird auch in allen Branchen und allen Bereichen ausprobiert.
Also von, ja, bei E-Fahrzeugen, das ganze Energiesystem wird modelliert und daraus automatisiert die Testfälle generiert. Aber auch teilweise sicherheitskritische Systeme, also ich war da auch in Bereichen dabei, die dann über Aktivitätsdiagramme oder Zustandsautomaten, also die sind am beliebtesten, würde ich sagen. Ja, verstehe. Jetzt hast du gerade ein spannendes Schlagwort, dieser Umstieg zur Elektromobilität.
Merkst du da, oder hast du vielleicht auch schon Projekte gehabt, so quasi in der klassischen Verbrennerwelt und in der E-Welt, ob sich da was auch ändert von den Testprozessen oder so von der Softwareentwicklung? Sehr gute Frage. Dafür muss ich jetzt nachdenken. Also ich würde sagen, in der klassischen Verbrennerwelt hat man einiges an Altlasten noch. Also die Verbrenner, die Software, die ist in der Regel schon älter, kann man sich vorstellen, vieles davon.
Und "never change a running system", wenn es mal zertifiziert ist und es läuft, dann ändert man viele Sachen nicht mehr. Und man schleppt da eben viele Altlasten mit, teilweise bei der Dokumentation, teilweise beim Code oder Sonstiges. Wenn man jetzt Neuentwicklungen macht mit Elektrofahrzeugen oder jetzt noch weiter geschaut, dann mit hochautonomen Fahren oder Sonstiges, das sind dann Neuentwicklungen. Und da nimmt man dann natürlich, ich nenne es jetzt mal die neuesten Methoden.
Und gerade in diesen Bereichen wird dann zum Beispiel modellbasiert sehr viel auch gemacht. Bei den, ja, jetzt ein Scheibenwischer, der ändert sich jetzt nicht mehr allzu sehr. In der Regel, da hat man dann den alten Code, da hat man dann vielleicht auch gar keine Modelle mehr. Und man wird jetzt nicht retrospektiv noch Modelle dazu erstellen, weil die müsste man dann ja auch wieder prüfen, auch wenn man dadurch dann eigentlich gar nicht mehr so einen großen Mehrwert hat.
Ja, verstehe, ja. Okay, das heißt also, für die neuen Sachen, da geht es dann auch so ein bisschen. Also, ist eigentlich total klar, also so wenn was läuft, so ein Modul auch so, die Zertifizierung, ich meine, das dauert wahrscheinlich auch alles lang und kostet viel Geld. Und wenn es läuft, warum neu machen?
Ja, also es gibt auch für diese Zertifizierungen oder für diese Abnahmen, jetzt Stichwort Kosten, so über den Daumen gepeilt, ein Produkt, wenn es quasi eine Risikostufe nach oben geht, wird der ganze Teil, das ganze Subsystem um Faktor zwei bis drei teurer im ganzen Entwicklungsprozess. Und es gibt dann mehrere Risikostufen. Airbag ist zum Beispiel die allerhöchste, die fünfte Risikostufe oder die vierte, ASIL-D nennen wir das.
Und das ist dann, ja, Faktor drei mal drei mal drei mal drei ist dann deutlich teurer. Und das will man dann natürlich nicht mehr anfassen, wenn man nicht muss. Ja, ja, ja, klar. Wie sieht es denn aus mit dem ganzen Thema der Testautomatisierung? Also jetzt in der Praxis, nutzt ihr das? Nutzt ihr das viel? Also auf Unit-Tests oder sowas? Ja, klar, aber so auch drüber. Habt ihr da viele Systeme im Einsatz, die euch da unterstützen? Oder wird da eher manuell getestet?
Da wird sehr, sehr viel automatisiert. Gerade so ein Fahrzeug, also die ganzen Unternehmen, die die Fahrzeuge herstellen, die setzen auch darauf, wenn du dir jetzt einen Neuwagen kaufst, du kannst dir deinen Neuwagen ja quasi zusammenstellen und es ist, dieses Fahrzeug gibt es nur ein einziges Mal auf der Welt.
Du hast ja eine Wahl zwischen 15 verschiedenen Scheinwerfern und 20 verschiedenen Innenlichtern und diese Kombination gibt es vielleicht nur ein einziges Mal auf der ganzen Welt von deinem Fahrzeug. Und prinzipiell müsste man diese individuelle Kombination ja testen. Macht man jetzt natürlich nicht für jede Kombination von diesen Abermilliarden oder noch deutlich mehr. Deswegen setzen wir enorm viel auf Testautomatisierung.
Auf Unit-Ebene oder auf Code-Ebene geht das natürlich sehr, sehr einfach. Aber auch wenn man dann höher kommt, wir bauen uns dann wirklich Prüfstände mit der Hardware, die die Umgebung so gut wie möglich darstellen, in der dann zum Beispiel das Steuergerät laufen wird und da versuchen wir dann auch, wenn möglich fast 100% aller Testfälle zu automatisieren.
Also die manuellen Tests sind, wenn man es schafft, eigentlich nur ganz oben am Fahrzeug, wenn es dann schon Richtung Fahrdynamik oder sonstige Sachen geht. Aber selbst da hat man natürlich auch schon wieder Prüfstände, wo man Sachen testen kann. Also man versucht hier enorm auf Testautomatisierung zu setzen.
Man hat dann 20 Prüfstände und die laufen Tag und Nacht und gerade auf Software-Seite wird dann auch viel ausgelagert irgendwo auf Server, die dann irgendwo stehen, die man sich dann einkauft und dann wird versucht, möglichst viel der Kombinatorik durchzutesten. Verstehe, ja. Okay. Ja, also schön, dass da ja auch so viel automatisiert ist. Es ist ja immer ein guter Faktor, weil das einfach den menschlichen Faktor rausnimmt,
der Wiederholung bei Regressionen und solche Sachen. Das ist ja auch total wichtig. Macht es natürlich auch spannender, wenn man nicht jeden Tag die gleichen Testfälle einfach durchführen muss, sondern an der Automatisierung arbeitet und die neuen Features voranbringt. Ja, genau. Es gibt ja seit einigen Jahren auch eine Zertifizierung zum Automotive-Tester vom German Testing Board quasi auch mit aufgelegt. Was ist denn da so der Inhalt? Oder kannst du uns da mal ein bisschen eindrücken?
Du kennst dich ja da auch mehr aus, was man da so lernt und was braucht man da? Ist das gut? Es schadet auf jeden Fall nicht. Also es ist vielleicht kurz so die Eckdaten. Es ist so ein Zweitageskurs in der Regel, wo man alle Begriffe, alle Normen mal so kennenlernt, die man so braucht aus der Sicht des Testers. Also es gibt dann eben verschiedene Normen und Standards. Die beiden wichtigsten oder die drei wichtigsten würde ich sagen, das eine ist Automotive SPICE.
Das ist diese Prozesslandschaft, von der ich vorhin gesprochen habe. Also welche Dokumente müssen wir erstellen? Wer muss wo dabei sein? Und da gibt es dann eben ein paar Testprozesse und Review-Prozesse. Die würden wir sich in diesem Kurs anschauen. Dann gibt es eben dieses ganze Thema der funktionalen Sicherheit. Also wie gehe ich damit um, wenn durch einen Softwarefehler jemand verletzt werden könnte?
Wie muss ich sowas testen? Diese Normen schauen wir uns dann auch aus der Testerperspektive an. Und es gibt dann noch einen dritten Standard, den nennen wir AUTOSAR. Das ist so die Kommunikationsschicht. Also wir versuchen quasi die ganze Kommunikation im Fahrzeug auf, ja alles auf AUTOSAR aufzustöpseln. Das kann man sich dann so ein bisschen vorstellen wie so eine Lego-Platte. Und obendrauf baut man dann die Softwareblöckchen und unten die Hardwareblöcke.
Und man kann immer alles austauschen und das schauen wir uns dann auch an. Okay, also das ist zwei Teile. Und ist das, basiert das auf dem Foundation-Level? Also braucht man den vorne weg? Also für die Prüfung ja, da wäre der nötig. Aber inhaltlich sind es tatsächlich überwiegend neue Themen. Also meine persönliche Empfehlung ist, wenn man jetzt aus dem Testerumfeld kommt und die Zertifizierung nicht machen will, dann kann man in diesen Kurs auch definitiv ohne den Foundation-Level rein.
Aber für die Zertifizierung ist es dann Pflicht, da ist der Foundation-Level für alles. Ja, das ist auch richtig. Ich meine, es schafft ja eine gute Grundlage auch an den ganzen Methoden und Begriffen und so. Das ist gerade, wenn man da neu einsteigt, auch essentiell. Definitiv, ja. Ja, Christian, das war doch ein mega Einblick für mich. Jetzt verstehe ich viel mehr, was so beim Automotive-Testen eigentlich so vor sich geht.
Wie gesagt, war bis jetzt für mich eine Blackbox und ich freue mich, dass ich da jetzt mal so reinschnuppern dürfte. Ich danke dir sehr für diese Einblicke. Das hat echt Spaß gemacht und mir viel gebracht. Und herzlichen Dank und wünsche dir heute noch einen schönen Tag und eine schöne Woche. Ja, klasse. Danke, dass ich dabei sein durfte. Bis zum nächsten Mal. Ciao, ciao. Gerne. Ciao. [Musik]