Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Ich bin dein Host Ritschi und habe wieder eine Folge vom QS-Tag 2023 aus Frankfurt mit im Gepäck. Meine heutigen Gesprächspartner sind Patrick Olcher von der Union Investment und Danny Tamp von UBS Heiner. Mit ihnen spreche ich über das Thema Testdatenmanagement, denn Patrick hat in seinem Unternehmen Testdatenmanagement ganz neu gedacht und umgebaut, da die alte Testdatenverwaltung
mehr schlecht als recht funktioniert hat. Wie sowas systemübergreifend über viele Systeme mit einigen Stakeholdern funktionieren kann, das besprechen wir in dieser Folge. Wenn dir dieser Podcast gefällt, freue ich mich sehr über ein Like oder eine Bewertung auf den üblichen Plattformen und natürlich über Feedback an mich an [email protected].
Und jetzt viel Spaß bei der Folge. Hallo, schön, dass ihr da seid. Ja, es freut mich, das Thema Testdaten, Testdatenmanagement, das ist ja ein heißes Thema, was ja ganz viele Unternehmen bewegt. Das kenne ich aus meiner eigenen Projekterfahrung heraus und wir sind ja hier am QS-Tag und ihr habt ja hier auch einen Vortrag zu dem Thema, weil du speziell ja in einem Projekt oder in deinem Unternehmen das Thema auch angegangen seid, es besser
zu machen. Und ja, da wollen wir uns mal ein bisschen unterhalten darüber, wie das denn so geklappt hat und was da so die Konzepte waren, die da auch dahinter stehen. Genau, ich würde sagen, da starten wir ganz locker, flockig einfach rein. Was war denn bei euch so die Herausforderung oder in welchem Kontext hattet ihr denn so eure Themen mit Testdaten?
Ja, vielleicht sogar noch einen Schritt davor, die Wichtigkeit von Testdaten. Ich habe ja oder man macht ja immer wieder die Erfahrung, wenn man über Testen oder Testmanagement spricht, dann spricht man immer eben von den Methoden, von den Tools in Richtung Automatisierung und die Testdaten sind aber nun mal die fundamentale Basis. Das heißt, wenn die falsch sind, dann sind auch im Zweifel meine Testergebnisse hinfällig oder nicht richtig aussagekräftig.
Gestartet ist das Ganze, ja, Thema bei mir so vor vielen, vielen Jahren, wo wir ein doch sehr stark parametrisierbares System hatten und da aber diverse Abweichungen zwischen dem produktiven System und dem System waren. Irgendwann habe ich dann auch gesagt, naja, also es ist irgendwie schwierig. Wir testen hier, aber diese Parameter haben ja auch diverse Auswirkungen. Wie könnt ihr denn überhaupt sicherstellen, dass wenn man sowas hier macht, dass das Ergebnis
in Produktion ist, wenn man das dann weiterspendet. Und ja, das war jetzt sozusagen so der kleine Anfang. Dann kamen natürlich so Themen wie, irgendwann musste man Umgebungen aufbauen und das war dann eben mein Themenschwerpunkt. Heißt jetzt noch nicht mal, dass man die Daten
hinstellen, aber die bestehenden mit frischen Daten zu versehen. Ja, und da kommt man auch natürlich je nach System und auch je nach Datenmenge ziemlich schnell an bestimmte Grenzen, Herausforderungen, sei es performancemäßig, sei es Laufzeiten, manuelle Fehler, die dann passieren einfach bei den Überträgen, ja, bei den Bereitstellungen. Und das hat sich
dann noch weiterentwickelt. Dann kam ja Thema Anforderungen. Wir bräuchten ja irgendwelche Daten aus Produktion, dann Fehler nachzustellen und idealerweise ist es dann natürlich einfacher, einen bestehenden Fehlerfall zu kopieren, wie das in der Testumgebung irgendwie nachzustellen,
was meistens dann tatsächlich nicht klappt. Ja, und dann war direkt das nächste Thema, nämlich wir können nicht einfach in irgendwelche anderen Umgebungen hin und her schieben, sondern da gibt es ja bestimmte Anforderungen aus diversen Kreisen, die entsprechend auch abgedeckt werden müssen. Und erst mal hatten wir all diese Problemstellungen dann so mit eigenen
Möglichkeiten und Ressourcen gelöst. Das brachte aber natürlich die Folgeprobleme, weil dann hatten wir irgendwie fünf, sechs verschiedene Werkzeuge und die Pflege war aufwendig, geringere Veränderungen im Zielsystem brachten doch relativ viel Anpassungsnotwendigkeit in den ganzen Systemen. Ein weiterer Punkt war, da gab es auch eine gewisse Redundanz. Die ersten Werkzeuge haben dann zwei, drei Werkzeuge doch relativ ähnlich funktioniert,
aber dann doch anders. Nicht, weil es durch uns so gewollt war, sondern einfach, weil die technischen Rahmenbedingungen das so erforderlich machten, das so ein bisschen zu doppeln. Und da kam der Gedanke, das muss ja irgendwie anders laufen. Und dann haben wir uns so ein bisschen am Markt umgeschaut und sind dann eben auf die UBS Heiner aufmerksam geworden.
Kannst du noch ein bisschen uns abholen, so in die Richtung, also von deiner Branche und in welches System, so dieses Konglomerat ist, wo das Problem eigentlich vorherrscht mit den Testdaten? Ja gut, Branche ist Union Investment, Kapitalenlagegesellschaft und wir haben unser Kernbestandsführungssystem. Das ist ein Datenbankmanagementsystem und dann gibt es ja noch angrenzende Systeme, logischerweise wie es so ist, sei es ein Data Warehouse, sei es irgendwelche Hilfsdatenbanken,
die für bestimmte Abläufe notwendig sind. Und man muss auch dazu sagen, also die Systeme, die wir selbst entwickelt haben, die waren halt primär fürs Kernsystem. Man hatte immer so dieses Gap, naja, die anderen Systeme, entweder hatte man sich dort auch selbst was gestrickt oder man hat eben, ja, da, also zum Beispiel die Daten über mehrere Systeme
hinweg konnte man nicht vernünftig übertragen. Ist einfach so. Hat auch Unzulänglichkeiten, denen man dann natürlich auch nochmal begegnen wollte und konnte. Also ja auch ganz schön viel wahrscheinlich mit Inkonsistenzen dann einfach mit der Zeit zu tun, dass die Systeme dann auch auseinanderlaufen, ne?
Genau, aber auch sogar innerhalb eines Systems. Das ist so der nächste Einsatzgebiet sozusagen, wo ich ja da Ideen habe, dass wir dann letztendlich Dateninkonsistenzen aufdecken bei uns im System, weil klar, in regelmäßigen Zyklen möglichst viele Systeme beladen, neu aufbauen, aber dazwischen kann es ja trotzdem zu Inkonsistenzen kommen. Die sind ja, solange sie nicht wehtun,
auch vielleicht nicht so wichtig, ja, können vernachlässigt werden. Aber es gibt durchaus Bereiche, wo diese Inkonsistenzen tatsächlich zu irgendwelchen Programmabbrüchen führen, weil das Programm erwartet irgendwelche Einträge in Tabelle A und B und es sind aber nur welche in A vorhanden, weil B wird, keine Ahnung, manuell gelöscht, verändert, wie auch immer. Und das sind dann, ja, also man kriegt es ja auch nicht adressiert, ne, hallo, ich
habe hier gerade inkonsistente Daten irgendwie verursacht. Vielleicht weiß es das Programm oder die Person, die das verursacht hat, ja im Zweifel gar nicht. Und da kann man nur mit solchen Gegenwirkungen sagen, okay, das ist die Definition von konsistent und wenn nicht, was machst du dann? Ja gut, im Zweifel löscht du halt eben den kompletten Datensatz. Das ist immer noch besser, wie diese inkonsistenten Sachen.
Und dann seid ihr auf die Suche gegangen, was war denn so die, sagen wir mal, die Kernanforderungen, die ihr quasi mit so einem neuen Konzept oder mit so einem System erfüllt haben wolltet? Ja gut, die Kernanforderungen waren auf jeden Fall einmal, dass man das unterschiedliche
Datenmanagement-System unterstützt. Zum anderen, dass man die Möglichkeit hat, dass die User möglichst viel selbst machen können, weil es gibt statt heute oder gab es bisher gewisse Aktivitäten, die einfach nur durch eine zentrale Gruppe ausgeführt werden konnten, sei es aufgrund von Komplexität, aufgrund von Rechten oder diverser Natur. Und dass wir auch in
der Anwendung eben das Applikationsmodell als solches abbilden können. Sprich, ich kann mir dann, ja, Baustein-mäßig, sagen, Kunde, Vertrag, Umsätze, wie auch immer, nachselektiv, was ich denn alles haben möchte, berücksichtigen möchte und kann so dann entsprechend auf die Daten zugehen. Plus der eine Schmerz, den wir dann eben bei unserem Datenmanagement-System hatten, eine gewisse Wiederverwendbarkeit von den erzeugten Modulen,
was auch immer. Man hatte ja zu dem Zeitpunkt noch nicht so eine Idee, was es ist, aber die Wiederverwendbarkeit. Also die Sachen, die man dann einmal beschrieben hat, sei es zum Beispiel so ein Datenmodell, Applikationsmodell oder auch eine Methode, wie ich zum Beispiel so einen Namen anonymisiere, das möchte ich ja nicht für jedes System oder Datenmanagement-System dann nochmal neu definieren. Verstehe. Vielleicht eine Frage an dich, weil ihr ja der Hersteller
des Tools, des Frameworks auch seid. Also ist das quasi, kann ich mir das vorstellen, wie so eine Modellierung über Systemgrenzen hinweg. Also ich baue quasi einfach quasi eine Level drüber, nochmal meine Einzelsysteme auf, sag da ist dieses Datenbanksystem, da ist das, das hängt dann so zusammen oder wie, kann ich mir das vorstellen?
Genau, so ist das bei uns. Man kann diese einzelnen Module zusammenbauen und modellieren und was da jetzt für eine Datenbank letztendlich dahinterhängt, das ist dann erstmal egal.
Das kann man irgendwo einmal definieren, dass jetzt in dem Fall liegt das Datenbank jetzt hier und im anderen Fall liegt es woanders und das ist dann so eine Umgebung, die dann definiert wird und die kann man einfach nochmal eine Schicht oben drüber, so dass die Endanwender, die sehen davon überhaupt nicht, die sehen, können ihre Daten bestellen und dazwischen liegt dann eben die Schicht, die das alles beschreibt und unten irgendwo liegt dann die
Datenbank. Das ist eine spannende Aussage, das ist meine Daten bestellen. Also quasi das klassische System, so wie ich es verstanden habe, da wird halt dann, da machen Tools, die spielen dann halt irgendwelche Datensätze rein, die man vielleicht kennt oder auch nicht, also oder sich aufbauen mit der Zeit oder dann Dumps oder sonst irgendwas sind. Was verstehst du unter Daten bestellen? Oder was ist das
Konzept dahinter? Ja, das Konzept ist einfach, dass Tester oder Endanwender in dem Fall eine Weboberfläche haben, wie in einem Onlineshop im Prinzip.
Da können sie vorgeben, welche Daten werden gebraucht. Ich brauche jetzt einen bestimmten Kunden oder ein Konto oder ich kann dann einfach mitgeben, Kondonummer oder was ich dann haben möchte, vielleicht noch zwei, drei andere Bedingungen, von wo ich, nach wo ich die Daten bewegen will und dann kann ich auch bestellen klicken und dann werden im Hintergrund die ganzen Prozesse eingestoßen, die dann die Daten in der Quelle lesen, anonymisieren,
ins Brief schreiben und so weiter. Aber den Inhalt dieses Shops, das habt ihr dann definiert? Also wie ihr das braucht? Also wir definieren, wie anonymisiert wird, was anonymisiert wird, in welchen Tabellen. Wir definieren, welche Shops oder Aufgaben
dann sozusagen den Endanwendern zur Verfügung stehen. Wir definieren auch, wer was tun darf, also selbst ausführen über einen Request senden, über Bereiche, die einem bestimmten Personenkreis von vornherein vorbehalten sind, haben wir solche Unterscheidungen dann getroffen und natürlich gewinnt es dann immer mehr an Komplexität, was man damit halt tun kann. Der einfachste Fall ist, ich weiß, ich habe jetzt einen Kundenstamm oder einen Depotstamm
irgendwie kaputt gemacht oder der ist eben inkonsistent. Ich habe es wie auch immer aufgedeckt, könnte jetzt hergehen, wähle die Umgebung aus, wo ich es gefunden habe, sage "Lauf los" und
dann ist er halt eben nach kurzer Zeit dann entsprechend gelöscht. Der nächste Punkt ist ein einfaches Hin- und Herkopieren, entweder zwischen den Umgebungen, weil ich eben zwischen einzelnen Teststufen arbeite und dann unterschiedliche Teststufen, dann unterschiedliche Testumgebungen habe oder einen Produktionsfehler nachstellen möchte, dann ziehe ich mir das Ganze natürlich eben aus der Produktion und auch da habe ich eine Maske, die hat dann genau drei Felder,
also Quellumgebung, Zielumgebung und das, was ich dann übertragen möchte. Also entweder direkt eine konkrete Nummer, die ich dann vorgebe oder man könnte es sogar soweit ausbauen, dass man Subselect oder sowas da reinsetzt. Und die komplexeren Sachen, wo dann eben nur einem bestimmten Benutzerkreis zugewiesen sind, sind so Sachen wie eben so ein Refresh einer
kompletten Umgebung. Das ist dann natürlich einmal vom Ablauf her viel komplexer, weil dann haben wir eben nicht nur ein, zwei Schritte, sondern eben acht, die aufeinander folgen und jedes dieser Schritte greift dann irgendwie 20 bis 300 Tabellen zu und dann ist natürlich auch klar, dass da nur
wenige Leute das machen dürfen. Aber nichtsdestotrotz, bisher war das zum Beispiel manuelle Prozessbremse in der Gruppe und jetzt wollen wir das, also haben das jetzt umgestellt in der Endphase, Testphase, dass ich das praktisch mit einem Klick sage, die und die Umgebung bitte jetzt neu beladen und dann läuft es los. Im Zweifel auch am Wochenende, weil man das ja auch schedulen kann. Und weil es ja
einfach die Zeit dann braucht manchmal. Also mancher Aufbau von so einer Testdaten, das ist ja nicht so ein schneller Copy, sondern wenn das mehr Daten sind, dann dauert das ja auch vielleicht ein paar Stunden oder so. Ist so, da werden ja je nach Tabelle auch in zweistelligen Millionen Bereich Datensätze übertragen und die Anwendung ist ja per JDBC, also letztendlich ist es ja, technisch gesagt, ein Insert in die Datenbank und ein Insert von eben 60 Millionen dauert halt.
Genau, von daher hat das dann auch gute Gründe, warum es dann eben zu Randzeiten laufen sollte. Wie habt ihr denn da so die Konsistenz hergestellt? Ich stelle mir das ein bisschen in meiner Welt vor, wenn ihr beginnt das zu modellieren in dem Tool, diese verschiedenen Systeme und dann weiß ich, wenn ich hier was anlege, dann muss ich auch hier was anlegen, weil das muss ja zusammenpassen. Das ist ja quasi ein Nachbauen auch gewisserweise der Logik, die schon da ist im Echtsystem. Wo
eine Kunde angelegt wird, wird auch irgendwie ein Konto angelegt, keine Ahnung. Und wenn das in verschiedenen Systemen gepflegt wird, das muss ja hier noch einmal nachgebaut werden. Und ich stelle mir das hackelig vor, dass man dann nämlich immer wieder auf Fehler auch stößt, die man gar nicht so bedacht hat oder sowas. Wie war da eure Erfahrung? Also zum einen haben wir ja ein bisschen von unserem Vorsystem machen müssen. Das heißt, wir haben da auf einer gewissen Erfahrung aufgesetzt.
Im Zuge des Proof of Concept haben wir dann praktisch das genommen, was wir hatten und dann rein migriert und ziemlich wenige Anpassungen, ich glaube zwei, drei Fehler in Anführungszeichen, wo wir da so gefunden haben. Und dann war es auch dann im Zielsystem abgebildet. Aber das ist ja jetzt die Ausgangsbasis. Von dieser Ausgangsbasis kann man für meine Augen besser machen. Weil momentan habe ich ja so ein Monolith und das sind dann irgendwie 300 Tabellen, die gehören zusammen,
aber das ist jetzt noch nicht nach Kunden und nach bestimmten Bereichen aufgeteilt. Aber man macht es dann einfach eben stückweise. Ich meine, hier habe ich ja meinen gesicherten Stand, mit dem ich jetzt arbeiten kann und parallel bauen wir uns eben kleinere Inseln, also kleinere Applikationsmodelle, die ich aber jeweils miteinander auch verbinden kann, sofern das
fachlich sinnvoll ist. Und der Betrieb ist da so gesehen möglich und dieser Übergang zu den korrespondierenden Systemen, also andere Datenmanagementsysteme, die dann auch Daten haben, das ist letztendlich einfach immer an genau einem Punkt gibt es ein. Das heißt, je nach Ordnungsbegriff, wenn ich irgendwie den Kunden habe und eine Kundennummer und habe im CRM-System auf Basis der Kundennummer dann weitere Kundendaten, dann ist das genau die Kopplung der Bausteine
der Applikationsmodelle dann miteinander verbindet. Nichtsdestotrotz kann ich auch im CRM das Applikationsmodell separat nutzen. Also ich muss nicht immer gesamthaft das betrachten. Ich kann sehr gut sagen, teste ich irgendwie auf einer niedrigeren Teststufe nur in dem einen System, also lasse ich die anderen erstmal weg. Also die Freiheit hat man. Und das ist halt einfach unheimlich stark davon abhängig, wie und was man dann halt eben in dem Tool definiert.
Wenn ich so drauf schaue, auf die Systemlandschaft, also habt ihr das Ziel, die quasi komplett da drinnen zu haben, beziehungsweise ist es schon so weit oder ob das die Hälfte der Systeme oder mal die Kern und ein paar drumherum? Ne, also gut, das Ziel, ich weiß gar nicht, ob wir jetzt so ein Fertigziel haben. Ganz im Gegenteil. Wir merken immer wieder, wenn man die Software nutzt und da kommen ganz neue Ideen, ganz neue Möglichkeiten, die man für sich entdeckt. Von daher, also meiner
Ansicht nach werden wir da nie diesen Fertigstatus erreicht haben. Finde ich aber auch gut so. Dafür ist es ja da. Und so der Fahrplan. Also erstmal haben wir uns auf unser Bestandsführungssystem konzentriert und wollten da die alten Lösungen weitestgehend ablösen. Weil das ist ja das, was eigentlich primär so unser Ziel war. So dass wir sagen können, ok, da läuft alles drüber, ich muss die Sachen nicht doppelt und dreifach pflegen, also eine gesunde Basis
schaffen. Dann haben wir natürlich mit dem System auch hinreichend Erfahrung zu dem Zeitpunkt gesammelt und gehen dann eben sukzessive jetzt an weitere Systeme, wo wir sagen, wir haben es ja schon gekoppelt, aber POC ist ja so ein bisschen noch quick and dirty, dass es überhaupt funktioniert. Das heißt, jetzt können wir das Ganze nochmal angehen und nochmal so die gängigen Umsysteme erstmal einfach anbinden. Und dann liegt es natürlich
auch so ein bisschen am Endanwender, wie sehr man das Ganze dann noch zerbröselt. Also wenn ich jetzt zum Beispiel von diesen 300 Tabellen spreche, die könnte ich sicherlich auf irgendwelche sechs Einheiten a) irgendwas aufteilen und könnte idealerweise sagen, wenn ich dann so ein Bestandteil für den Kunden, die Umsatzdaten, Vertragsdaten und ja, keine Ahnung, irgendwas anderes will ich halt nicht. Auch so könnte man das aufziehen.
Die Frage ist dann aber natürlich, ist es einfach dann nur noch Ideologie, sehr ungewähr, oder brauchen die Anwender das wirklich? Damit wird es so ein bisschen in diese Richtung dann gehen und schauen, wie sehr sich das dann noch erweitert. Da möchte ich schon noch einmal konkret nachfragen, weil wenn du jetzt, also es klingt ja quasi jetzt, der Transformationsweg ist ja schon gut fortgeschritten. Ihr habt quasi
schon viel von eurem Ursprungsschmerz geheilt damit, muss man sozusagen. Was ist denn so für dich oder für euch so der nächste Schritt, den ihr damit gehen wollt? So eine Richtung, wo ihr sagt, da wollen wir nächstes Jahr, weiß ich nicht, den Pflock einschlagen und … Der nächste Schritt, den wir gehen wollen, also wollen wir das, was wir jetzt mit unserem
Bestandsführungssystem noch nicht finalisiert haben, finalisieren. Das heißt dann auch, dass eben manuelle Prozesse abgelöst werden, also vorständig abgelöst werden, neben den Sachen, die jetzt schon teilweise abgelöst sind. Und wir möchten das in die Breite streuen. Das heißt, bisher war es so, dass wir eine gewisse Anzahl, so 20, 30 friendly User in
dem System hatten. Auch schon die User, die das sehr häufig nutzen und ausgiebig. Aber unser Ziel ist es natürlich, dass in der Organisation viel weiter zu kommen, dass viel mehr Leute die Möglichkeit haben, das zu nutzen. Das heißt, das ist einer der nächsten Schritte, plus eben die Anbindung der sogar auf den Folien dann aufgeführten Systeme, die dann Bestandsführungssysteme einbremsen. Okay, also die nächsten Systeme dazuholen.
Ja, ja, genau. Also wir wollen definitiv ja mindestens noch andere anbinden. Einen vierten Kandidaten haben wir sogar, der auch gerne angebunden werden möchte. Der war jetzt bei dem Vortrag sozusagen noch nicht mal aufgeführt. Hängt natürlich aber auch ein bisschen so an Sourcen, teilweise Budget, je nachdem, ob die Datenbankmanagementsysteme schon lizenziert sind oder nicht, ist da auch noch ein Thema. Von daher, das sind ein paar Faktoren, die
da letztendlich rein spielen. Von daher ist es schwierig zu sagen, ja, Q1/24 haben wir es geschafft, so sind wir jetzt. Aber so der Fahrplan für 24 ist dann genau der. Du hast gerade noch die friendly User angesprochen, die quasi jetzt gerade das nutzen oder auch quasi die wahrscheinlich sind, die damals den größten Schmerz hatten damit. Oder mit auf Gammelschutz kamen. Genau, genau. Fragt ihr wahrscheinlich auch bei denen ja das Feedback ab. Wie läuft das jetzt für
euch? Was ist denn da so das, was ihr so hört quasi von den Stakeholdern, die diese Dinge dann nutzen sollen? Also ja, natürlich Fragen stellen. Das ist natürlich auch ganz wichtig und ja, fürs Produkt erheblich und für die Akzeptanz dessen. Und also allein die Tatsache, dass sie jetzt diverse Sachen selbst machen können oder dass sie jetzt Sachen haben, die vorher gar nicht zur Verfügung standen. Also zum Beispiel so ein Löschen von Einzeldepots
hatten wir früher nicht. Entweder wurde die Umgebung komplett neu aufgebaut, dann war halt alles wieder frisch da. Aber so ein Löschen von einzelnen Sachen war nicht möglich, weil da gab es einfach die Funktion für nicht. Und dann haben wir gesagt, gut, da es eh regelmäßig aufgebaut wird, lassen wir es erst mal so sein. Das heißt, wir haben jetzt die Möglichkeit selbst ohne irgendwelche Anfragen, ohne andere kontaktieren zu müssen, klicken sie sich dadurch. Wie gesagt, drei Ver-
-k-Button so sinngemäß. Also auch denkbar einfach in der Bedienung. Sie sehen nicht, was alles da drinnen dran steht. Und mit, ich sag mal, dem einfachsten Ablauf wird gefühlt jeder Bereich der Software durchlaufen. Und dann haben sie die Daten so, wie sie wollen. Und das ist bisher auf sehr positive Resonanz geblieben. Super, sehr schön. Ich finde es total schön, weil ich bin in vielen Unternehmen und Testdaten sind dort immer ein großes Thema, gerade wenn es um System übergreifend geht. Und
ich finde es total toll, wenn es da jetzt auch Lösungen gibt. Gerade auch eine von euch, die funktioniert, was man hört, gerade in so einem Umfeld, wo es einfach auch viel Datenmischmasch gibt, wo es Produktivdaten gibt. Also da auch Konzepte zu fahren, die dann auch den Testern und den Fachbereichen oder wer auch immer helfen, dann auch selber mit den Daten umzugehen. Das finde ich super. Ja, vielen herzlichen Dank für diesen Einblick.
Das fand ich ganz spannend. Hat mir selber wieder mal ein bisschen einen neuen Blick auch eröffnet da drauf. Wir kennen uns ja schon länger. Wir haben ja schon ein paar Mal auch gesprochen. Aber es jetzt einmal auch von Anwenderseite, das zu hören, finde ich ganz toll. Ich danke euch für das Gespräch und wünsche euch noch ganz viel Spaß hier am QS-Tag. Ja, sehr gerne. Danke. Danke schön. Ciao. Ciao. Ich freue mich!