Happy Quality, es ist wieder World Quality Week und da wollen wir Softwarequalität wieder mal so richtig abfeiern. Drum gibt es in dieser Woche wieder jeden Tag eine Spezialfolge zum Thema Testen Qualität und was sonst noch dazu gehört. Also lasst uns Software besser machen. Viel Spaß! Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritchie und habe hier eine Folge von den Software Quality Days 2024 aus Wien.
Bei mir zu Gast waren Hermann Friebel und Joshua Klaassen, mit denen ich über das Thema gesprochen habe, wie man Daten und Datenprozesse testen kann, welche Konzepte dafür zur Verfügung stehen und was man bei diesen Tests beachten muss. Viel Spaß bei der Folge! Hallo Hermann, hallo Joshua, schön, dass ihr da seid. Hallo Ritchie, danke, dass du uns hast. Wir sind ja hier auf den Software Quality Days, Tag 2, der Nachmittag. Habt ihr euren Vortrag schon gehabt oder kommt der noch?
Den haben wir schon gehalten. Der Tiefenentspann bei mir im Podcast, das ist ja toll. Ich habe mir ja so im Vorfeld ein bisschen Speaker und Themen durchgesehen, habe gesagt, wer könnte passen für den Podcast, interessantes Thema. Und bin ich bei eurem hängen geblieben, weil ihr das Thema Daten habt und Testdaten und Datenqualität. Und da habe ich gedacht, ach, das ist ja eh immer so ein Pain in Projekten. Dann lass uns mal drüber ein bisschen plaudern, was es da eigentlich gibt.
Und so sind wir jetzt heute hier. Ja, genau. Und da starte ich gleich mal rein. Was ist denn so? Aus eurer Sicht sind das so typische Probleme, die man so mit Daten hat, wo ihr sagt, okay, das taucht immer wieder auf. Ja, weil das Problem ist, na gut, du hast ja Datenfehler, das taucht oft viel zu spät auf. Du möchtest eigentlich für den Datenverarbeitungsprozess das sofort, eigentlich auch schon während der Entwicklung am besten testen.
Das Problem ist aber, auf die Daten technisch kann die IT-Abteilung, die Mitarbeiter super zugreifen, aber die haben halt nicht. Das Business-Know-how, dass sie den Daten, dass sie da Datenfehler erkennen können. Und dann läuft das praktisch halt ziemlich umständlich. Das heißt, die Fachabteilung denkt sich so Einzeltestfälle aus. Dafür kriegen sie dann die Daten und müssen das überprüfen.
Besser wäre aber, man könnte systematisch irgendwie Solle-Ergebnisse erzeugen und die dann komplett mit den Ist-Ergebnissen vergleichen. Und zwar so, dass möglichst alle Fälle abgedeckt sind. Das wird in der Praxis noch nicht richtig erreicht. Warum? Weil es da kein passendes Tooling gibt.
Da haben wir eine Methode und, ja gut, haben wir dann auch in ein Tool gegossen, aber vielleicht mal zur Methode, dass eben die Fachabteilung definiert, der fachliche Regeln, das muss sie ja sowieso machen, wie die Daten abgebildet werden. Da braucht man jetzt eine Methode, wie man sozusagen dafür auch die Testergebnisse, möglichst einfach bekommt, weil man möchte jetzt nicht eine große Implementierung anfangen. Und da gibt es Methodiken dafür.
Und dann kannst du hergehen, kannst praktisch auf, meinetwegen sogar auf dem Produktionsbestand, dann diese automatische Soll-Datengenerierung anwenden, kannst den ganzen Produktionsdatenbestand prüfen. Was wir aber da festgestellt haben in der Praxis, das deckt dann oftmals nur 70% der Fälle ab. Also du kriegst diese Abdeckung ja auch mit, weil du ja für die ganzen Fallunterscheidungen auch weißt, ob du da Daten hast dafür.
Und ja, wenn du dann ein Testdatenset baust, dann baust du ja nicht vielleicht eins mit 100 Millionen Datensätzen, wo die meisten immer gleich sind, sondern möglichst diese ganz verschiedenen Konstellationen. Da kannst du ja aus der Produktion, anonymisiert natürlich, die nehmen die 70% und dann musst du die noch anreichern um die 30% und dann hast du eine ziemlich weiche... Eine weitreichende Abdeckung.
Das heißt die 30% sind dann generierte, die ich dann zum Beispiel in Richtung Grenzwerte oder so führe oder Richtung Edge Cases oder... Dadurch, dass du bei der Methode der Soll-Datengenerierung Fälle unterscheidest, also allein schon durch die fachliche Logik, bilden sich auf ganz natürliche Art und Weise Äquivalenzklassen.
Und ja, und da für eine Fallunterscheidung, meinetwegen du hast dann noch den Fall und das Alter ist größer 90 und du hast keine, der größer, älter als 90 ist, dann gibt es da nichts dafür. Folglich weißt du nicht, ob dein Prüfling, wenn das eine relevante Unterscheidung ist, da auch funktioniert. Wenn dann in der Praxis später einer kommt, dann läuft der halt dann schief, wenn er schief läuft.
Das konnte ich vorher nicht testen, wenn ich nur die Produktionsdaten nehme oder nur die Fälle, die da vorkommen. Und das wird sehr pragmatisch umgegangen beim Test, also sehr einfach momentan, weil eben in dem Fachbereich halt die IT-Skills nicht da sind. Da macht man halt dann ein Tooling. Ja. Da macht man halt dann ein Tooling. Dass man einen Fachbereich auch näher an die Daten ranbringt. Das hat mehrere Vorteile.
Das eine ist, ich kann die Datenqualität besser sichern, aber auch dadurch, dass der Fachbereich halt die Daten besser kennt, auch die Weiterentwicklung der Datenprozesse. Und der IT- und Fachbereich sind dann auch mehr auf einer Wellenlänge, haben aber auch ganz klar so eine Schnittstelle, die aber nicht so trennend ist, wie das heute ist, sondern wo sie dann wirklich gemeinsam, kollaborieren. Idealerweise zusammen zum Beispiel auch so einen Datenvergleich mit Samt-Toleranzen
und so weiter generieren. Das heißt, nicht irgendwo so ein Dokument, da steht dann was, die IT hat jetzt auch den Test umgesetzt, hat sich auch wieder einen Fehler gemacht, sondern ich kann am Objekt Datenvergleich, wo der definiert ist, den kann der Fachbereich auch verstehen. Das darf halt nicht technisch ausgedrückt sein, es muss in irgendeiner Form visualisiert sein. Und das kann man, weil das sind einfach Standard-Patterns, die
man da immer hat beim Datentesten. Der Test heißt immer, ich muss ein Soll mit einem Ist vergleichen. Natürlich gibt es da unterschiedliche Arten. Das meiste, was vorkommt, ist tabellarische Daten. Das kannst du in jede Form in tabellarische Daten transformieren. Man kann aber auch sagen,
man vergleicht einfach XML-Dateien oder JSON-Dateien. Und das kann man halt in den Formen bringen, dass man mit Low-Code-Komponenten sowas auch viel einfacher, schneller macht, weil das sind ja Dinge, die kommen immer wieder vor. Und unsere Erfahrung bei Kunden ist, also bei sehr großen Bankkunden, die haben halt viele Abteilungen und die erfinden alle das Rad neu. Die machen dann alle selber irgendeinen Vergleich, machen selber irgendwie einen CSV-Überrieder und Überprüfer noch. Also
haben wir schon die Redundanz. Und dass ich es überhaupt machen muss, weil das ist eigentlich, ja, Textverarbeitung macht sich auch keiner selber. Und das wird so oft gebraucht. Dass man sich wundern muss, dass es sowas noch nicht gibt. Und das haben wir uns schon
lange gefragt und wir haben uns auch mit einem anderen Produkt dem schon angenähert. Also diese Methodik hatten wir da schon entwickelt, aber es hat noch gefehlt, dass das Ganze einfach visualisiert wird, sodass man dann auch viele Dinge mit wenigen Klicks machen kann, aber trotzdem halt die Freiheit hat, wenn es komplexer ist, diesen komplexen Fällen auch gerecht zu werden. Ohne dann immer gleich in die tiefe Programmiertasche zu gehen.
Ja, ja. Ich glaube, das ist ja einer der großen Punkte, die ja so die Schwierigkeit sind. Wir haben ja auf der Technik ganz viel miteinander verknüpfte Datentabellen, die ja jetzt nicht unbedingt das Business abdecken, also das darstellen, sondern das ist halt die technische Umsetzung. Und diese Aufbereitung fürs Business, um das auch besser zu verstehen und zu handeln. Ich glaube, da steckt ja viel Energie dann auch drinnen. Also viel Power, damit der Fachmann einfach auch die
Daten so sieht, wie er sie auch so sieht. Ja, ja. Also, das ist ja auch eine große Herausforderung, weil man ja auch immer so viel Energie hat, die ja verstehen kann. Genau. Also, du musst ja auch überlegen, wenn du was testest du wie? Es gibt ja durchaus Bereiche, die eine, also wenn du jetzt eine technische Transformation hast, das kann dann auch die IT testen in Verantwortung, weil sie das auch wirklich ja alles sicher weiß,
was da passiert. Aber wenn es eine Fachlogik ist, das kann eigentlich nur der Fachbereich richtig testen. Und interessanterweise stellt man da bei solchen Tests auch fest, dann hat man Abweichungen und dann kommt die Fachabteilung und sagt: "Okay, ja, da haben wir, stellen wir fest, also das ist zwar jetzt eine Abweichung, das ist falsch, aber das soll jetzt eigentlich auch falsch, wenn Sie genauer drüber überlegen." Und dann werden die Regeln dann wieder
verfeinert, weil das ist ja auch ein Fehler. Ich meine, die Implementierung kann entsprechend der Spezifikation richtig sein, aber wenn die Spezifikation nicht richtig ist, dann möchtest du auch Qualität reinbringen. Und wenn du da halt frühzeitig die Möglichkeit hast, dass Fachabteilung Ergebnisse sehen kann, was denn die definierte Logik denn jetzt für Ergebnisse liefert, dann können Sie sofort sehen: "Au nee, das kann nicht sein in dem Fall, da müssen wir, ah, da habe ich ja
Fallunterscheidung vergessen." Ansonsten läuft es halt durch und wird erst spät entdeckt. Und je später was entdeckt wird, umso mehr Aufwand produziert es. Mir fehlen da gerade ganz viele auch von Systemen, die ich so bei meinen Versicherungskunden zum Teil auch gesehen habe, die ja sehr komplex sind. Und ich habe ja auch schon mal gesehen, dass die Systeme, die ich so bei meinen Versicherungen gemacht habe, die sind sehr komplex, wo einfach dann, da gibt es dann
halt Fälle, an die keiner mehr denkt oder so. Und die tauchen dann in solchen Datenkonstellationen auf, aber sind vielleicht gar nicht so spezifiziert worden. Und in dem Moment kann man sie damit natürlich dann auch prüfen bzw. korrigieren und über die Regeln auch dann quasi richtig machen. Genau. Und wir haben festgestellt, wenn wir dann mit dieser Methode gekommen sind, da ist ein System, das ist schon ewig in Produktion, dann gibt es vielleicht doch
größere Probleme, sagt man, wenn man das systematisch testen möchte. Aber da haben wir noch viele, viele andere Abweichungen festgestellt. Es sind oft nicht viele Fälle dann, deswegen sind sie auch noch unentdeckt geblieben. Aber da kriegt man die halt dann auch. Also man kriegt eine deutlich bessere Testqualität hin. Und der andere Vorteil der Methodik ist, wenn du halt manuell das machen würdest, also mit manuellen Testfällen und machst das gediegen,
dass du für alle die Fälle einzelne Fälle kriegst. Der Aufwand ist letztendlich mehr, also du kriegst eigentlich mindestens so hoch die Testqualität, ist aber schlechter. Also du kriegst gar nicht so viele Fälle hin. Da hast du schon die Zeit verbraucht, in der du mit unserer Methodik da die Ergebnisse generiert hättest. Ja, verstehe. Du hast vorhin den Begriff der Datenprozesse gebracht. Was bedeutet denn das?
Weil das ist ja ein Begriff, den kenne ich aus dem Testen wenig. Was steckt da für dich drin? Ja, ich unterscheide zwischen Daten und Datenprozessen. Daten sind Daten, die ich einfach bekomme. Ich meine, wenn ich kriege von irgendjemandem Kundendaten, die kann ich eigentlich nur die Datenqualität prüfen. Also es sollen lebende Personen sein, Geburtsdatum 1810. Dann sagt man,
das ist unwahrscheinlich, dass der noch lebt. Das kann irgendwie nicht stimmen. Wenn ich aber, sagen wir mal so, man hat ja im Unternehmen Datenverarbeitungen, da habe ich ja die fachliche Spezifikation, wie die Daten transformiert werden sollen. Ich habe konkrete Inputdaten und dann kann ich ja sagen, sind meine Outputdaten entsprechend der fachlichen Spezifikation auch produziert worden? Das ist ja die Fragestellung. Deswegen testet man ja.
Und das ist sozusagen das Testen von Datenprozessen. Datenqualität ist eigentlich auch irgendwo ein Datenprozess. Da hat ein User irgendwo was eingegeben oder die Daten kommen halt, aber mir ist halt nicht bekannt, wie genau die Abbildungsvorschrift ist und was die Inputdaten waren. Und des folglich bin ich da, kann ich da halt nicht so gut testen. Also beim anderen kann ich ganz klar ein Soll bilden und das
vergleichen. Dann kann ich sagen, das ist richtig oder nicht richtig. Zumindestens gehen wir immer in Bezug auf eine Spezifikation. Es kann nicht immer noch sein, dass die Spezifikation nicht richtig ist. Wie sieht denn das in dem Umfeld aus? Also viele Unternehmen haben ja natürlich auch mehrere Systeme, eine sehr heterogene Landschaft, die mit unterschiedlichsten Daten arbeitet. Ist das was, was ihr da auch mit betrachtet oder ist ein Fokus eher auf ein System quasi?
Genau, also das ist eine große Stärke, die wir da, beziehungsweise das haben wir in der Vergangenheit oft festgestellt, dass es eben nicht nur ein Inputsystem gibt, sondern es gibt ganz viele. Die müssen irgendwie harmonisiert werden, diese Daten. Die müssen an eine zentrale Schnittstelle geliefert werden. Zum Beispiel eine Geldwäscheprüfung oder sowas muss auf irgendwelche Transaktionsdaten gemacht werden und dazu muss man
die Inputdaten aus den verschiedenen Liefersystemen zusammenbringen und an diese Schnittstelle liefern. Und diesen Prozess testen, können wir testen mit unseren Prinzipien.
Wenn ich so an Automatisierung denke oder an so Prüfungen, da ist eine Grundregel immer, dass man das System nicht nachimplementieren soll mit, also die Logik des Systems, weil das auch sehr fehleranfällig ist. Wenn ich jetzt wilde Rechnungen irgendwo nachbaue in einer Prüfung, um dann den Abgleich zu machen, wie löst ihr das auf? Und so weiter. Und das kann man sehr wohl effizient abbilden, weil das wirklich eins zu eins ist. Und da macht das auch Sinn.
Habe ich jetzt was ganz komplexes, eine Monte-Carlo-Simulation, dann werde ich mir irgendwo einmal verifizierte Soll-Ergebnisse irgendwo holen, meistens aus einer anderen Monte-Carlo-Simulation und vergleiche das dann für die konkreten Fälle und habe noch ein gewisses Epsilon-Abweichung. Man muss da natürlich adäquat rangehen.
Aber für die Masse, wenn man jetzt sagt, in so typischen Unternehmen, diese ganzen Business-Abbildungen, die kann man wirklich sehr, sehr gut testen, weil man einfach diese Logik abbilden kann. Und was man ja nicht macht, ist eine Doppelimplementierung, weil ich brauche mich nicht um Performance kümmern. Ich brauche auch sonstige Nebenbedingungen, sind egal. Das mache ich eben mit unserer Methode in diesem System. Da muss ich nur ein paar kleine SQL-Expressions im System machen.
Maximalfall machen. Und es gibt auch noch eine andere Möglichkeit, wie man das machen kann. Wichtig ist, dass es unabhängig von der Implementierung passiert. Die Implementierung macht viel und wir haben das in der Praxis. Die Erfahrung ist, wir haben unser Testergebnis sehr schnell. Wenn wir da am Tag was machen, dann ist die Implementierung mit mehr Leuten eine Woche oder zwei beschäftigt. Also kann man nicht von einer Doppelimplementierung sprechen.
Ist aber auch nicht, dass wir jetzt dann ganz, ganz viel mehr machen, sondern wir machen müssen. Ganz viel nicht machen. Wichtig ist zu verstehen, wir bauen nicht das ganze System nach. Wir nutzen die Spezifikation und machen ganz nah an der Spezifikation, bauen wir die Abbildungsvorschrift nach. Beziehungsweise nicht nur ganz nah an der Spezifikation, direkt mit der Spezifikation mit bilden wir die Abbildungsvorschrift nach. Und dann geht es auch nur darum.
Es geht nicht darum, wann genau was abzulaufen hat, sondern wir testen einfach nur das, was wir machen. Das Mapping sozusagen. Und nicht die Performance oder irgendwas. Und damit ist es keine Doppelimplementierung, weil wirklich einfach nur auf die Logik fokussiert wird.
Aber man hat trotzdem einen vollständigen Test für alle Daten, weil man hat 10 Millionen Datensätze und hat für alle 10 Millionen Datensätze ein generiertes Soll-Ergebnis, das man dann gegen das Ist-Ergebnis halten kann und hat dann vollständig getestet. Jede Zeile, jede Spalte. Aber in der Praxis wird man nicht immer gegen den vollen Bestand testen, das ist dann etwas, was man zur QS des Produktionsbestands machen kann.
Man baut sich da ein Testset, weil man möchte auch, dass es dann möglichst schnell durchläuft. Und es reicht ja alle Fallkonstellationen, einen Vertreter davon zu haben. Dafür hat man dieses Äquivalenzklassenprinzip, was sich bei uns auf natürliche Art und Weise ergibt. Du hast vorher gesagt, im Nenntatz habe ich das mit rausgehört, dass von der Methodik her auch häufig Toleranzen vorkommen. Hast du da einen Beispiele? Wo man sowas braucht?
Also für mich ist so ein Datenvergleich, da denke ich mir, ja, dort ist das Wohl. Du hast zum Beispiel in einem Handelssystem bei Banken hast du Cashflows, die werden generiert. Jetzt schrauben die so ein bisschen im Algorithmus und dann kann es sein, dass sowas um 1, 2 Cent abweicht plötzlich. Aber das ist egal.
Dann gibt es eben Schwellen, die werden dann gesagt, okay, das ist dann trotzdem richtig, weil die ja dann mit theoretischen Werten arbeiten, die werden nach einer Methodik ein bisschen verankert. Und es sind halt auch numerische Eigenschaften, die dazu führen, je nachdem, wie ich die Rechenoperation anwende. Im Prinzip theoretisch die gleiche Rechnung, es kommt aber trotzdem was anderes raus.
Und da können sich eben so Fehler hochschaukeln, eben in dem Bereich, wo ich es dann noch sehe, wo ich sage, okay, da bin ich noch zufrieden. Oder bei Textfeldern können das auch Groß-Kleinschreibung ist mir egal sein. Das kann auch eine Toleranz sein. Ja, klar. Das kann natürlich auch sein, ja. Daran habe ich gar nicht gedacht.
An Statistik gedacht, dass da irgendwo… Jetzt gibt es ja noch andere Daten auch noch, also nicht nur textuelle Daten, sondern auch in Richtung Grafiken oder solche, so Binärdaten oder sowas. Ist das auch ein Thema, das ihr da mit abdeckt? In unserer Umgebung so per se nicht. Aber es ist was Einfaches eigentlich, zwei Binärdateien zu haben. Also, wenn wir so eine Funktionalität bräuchten, hätten wir die relativ schnell.
Wenn du natürlich wissen willst, ob zwei Bilder ähnlich sind oder was die Differenz zwischen zwei Bildern ist, na gut, da fehlt mir ein bisschen jetzt der Anwendungsfall. Da könnte man sich natürlich Metriken überlegen, aber ich glaube, das ist theoretischer Natur, das bildet jetzt in unserer Businesswelt nicht die Rolle. Also, da gibt es sicherlich einen Anwendungsfall, aber wir sind eher in der, also wir kommen ja ursprünglich aus der Finanzwelt.
Und da hat man einfach die Probleme jetzt so noch nicht. Da können wir uns eher um numerische Wertungen kümmern. Jetzt ist es ja so, ihr macht ja dieses Mapping dann auch, was zu überregeln ist und wahrscheinlich dann auch eine gewisse Grundlogik ja auch drinnen sein kann, um diese Spezifikationen nachzubauen. Da ist ja dann vielleicht auch schon der Gedanke da oder die Überlegung, das auch mit als Teil der Spezifikation zu machen.
Ist das ein Fall, wo wir denken, ja, das ist ja auch ein Teil der Spezifikation zu machen? Oder ich denke, ja, da kann ich ja gleich vielleicht versuchen, auch in diesen Regeln ein bisschen mehr zu denken? Ganz genau richtig erkannt. Also, wir haben das auch in der Vergangenheit in Projekten so gemacht, dass dieses Regelwerk, das wir da aufgestellt haben, tatsächlich sogar die Fachfeinspezifikation ist.
Also, man hat eine Fachspezifikation, wo das ein bisschen im Text aufgeschrieben ist, was man in Poser aufgeschrieben ist, was man haben möchte. Aber man hat zusätzlich die Fachfeinspezifikation, wo wirklich detailliert in diesen Regelwerken, auch für einen Fachbereichsmitarbeiter, der jetzt nicht so ein tiefes technisches Verständnis hat, verständlich aufgeschrieben ist, wie jetzt da ein Mapping zum Beispiel zu funktionieren hat.
Also, da braucht man eigentlich gar kein technisches Verständnis, sondern nur ein natürliches Verständnis. Ja, verstehe. Also, wenn Vorname und Nachname nicht leer sind, dann bitte Vorname und Nachname kann man separat ausgeben. Wenn Vorname ausgefüllt ist, dann prüfe: Ist der Vorname ausgefüllt? Dann bitte nur den Vornamen ausgeben. Ist der Nachname ausgefüllt? Nur den Nachnamen. Und in allen anderen Fällen dann DQ Error ausgeben. So kann man sich so eine Regel vorstellen.
Und das verstehen die meisten. Das ist relativ simpel nachzuvollziehen, glaube ich. Ja, sehr gut. Jetzt habe ich natürlich noch eine Killerfrage, die ich immer stellen muss: KI. Ja. Habt ihr das? Also, denkt ihr in die Richtung? Oder merkt ihr, dass das gerade auch da bewegt zur Generierung auch und zur Überprüfung vielleicht oder um Dinge herauszufinden? Also, KI ist ja momentan jetzt gehypt wie damals im Big Data Bereich. Da gibt es viele Erwartungen dran oder auch Mythen darüber.
Und wer da technisch nicht so gut kennt, der kann das auch schlecht beurteilen. Es ist ja nicht so, dass die KI dann plötzlich alles von allein macht. Also, das ist ja auch eine Frage, die wir uns immer wieder stellen müssen. Also, was machen wir jetzt? Also, wir stellen uns mal vor. Also, wir wollen natürlich auch KI einsetzen. Werden das auch tun. Aber was kann die KI machen? Die kann praktisch einen Vorschlag machen: Wie mache ich das?
Und wenn jetzt eine KI meinetwegen sagt: Okay, ich schlage einen Test vor und generiert dann nur Code, dann muss ich ja, um das zu verifizieren, sagen: Muss ich ja auch Code können. Also, muss die KI das auch in einer anderen Form, also diese Visualisierung, die wir machen, die braucht man natürlich.
Und dann kann auch jemand, der jetzt nicht Coding-Experte ist, sozusagen beurteilen, und auch viel schneller beurteilen, ob das das ist, was er will, beziehungsweise sagen: Okay, das ist schon fast, was ich will. Und den Rest macht er dann zu Fuß korrigiert. Oder sagt der KI noch mal: Kannst du das und das noch mal abändern daran? Dazu muss man natürlich Modelle entwickeln.
Aber man hat auch noch die Schwierigkeit, da kannst du jetzt nicht dich zum Beispiel an Open Chat GPT in unserem Fall anschließen, weil das sensitive Daten sind von Unternehmen, die schieben das nicht ins Internet. Sollten sie besser nicht tun. Also, genau.
Man braucht da… Aber da wird die… Ist die Entwicklung auch so, dass es da immer effizientere Large Language Models und auch andere Models gibt, mit denen man dann solche Dinge machen kann, bis hin zu: Ja, ich kann eine Datenbank abfragen, ich sage einfach dem KI-System, was ich haben will. Und dann kann das KI-System wegen des SQL generieren. Und wir können zum Beispiel heute schon aus dem SQL eine visualisierte No-Code-Abfrage generieren.
Und dann hast du wieder dein Feedback und brauchst gar keine SQL-Generierung. Das ist dann grafisch schön als Raumschiff dargestellt mit so Blöcken, die genau das SQL repräsentieren. Und da schaffen wir eben wieder das, was wir am Anfang geschafft haben, die Kollaboration zwischen Business und IT, dass auch das Business nachvollziehen kann, was diese Abfrage jetzt macht, weil das einfach visuell verständlich dargestellt ist. Und sonst hat man halt nur das SQL. Da versteht man nicht so viel.
Das ist dann denen überlassen, die auch mit SQL sich mal befreien. Und das ist dann auch das, was wir jetzt mal beschäftigt haben. Also die KI wird die Arbeit nicht überflüssig machen, aber viel effizienter, sodass ich dann in der Hälfte der Zeit oder noch weniger mein Ergebnis habe. Oder bei manchen Sachen sogar viel schneller. Wenn ich sage, ja, machen wir mal die Fallunterscheidungen in Intervallen so und so, dann schreibt die KI das ja in Nullkommanichts hin.
Und das ist auch etwas, was eine KI kann. Wenn ich aber sage, so, ich habe, hier ist mein System, teste mal. Das ist völlig unabhängig, testet. Na gut, das ist, glaube ich, noch nicht in naher Zukunft. Ja, das ist eine KI.
Noch eine Sache, nämlich die kann man ja nicht nur für den Fall einsetzen, wie Hermann jetzt beschrieben hat, dass der einem Vorschläge fürs Testen macht, inhaltlich, sondern die KI kann ja auch als Co-Pilot sozusagen, wird ja auch teilweise schon genutzt, kann ja auch als Co-Pilot bei einem Tool helfen, dir Vorschläge zu machen, wie du dieses Tool jetzt zu verwenden hast oder was zu fragen. Wie funktioniert denn, ich möchte jetzt das und das. Wie kann ich das am besten machen?
Dann könnt ihr dir die KI da eben Vorschläge geben. Ja, ich denke, da wird es ja auch helfen. Und ich finde das ganz schön, dass ihr jetzt nochmal auf diesen Punkt gekommen seid, dass es ja auch einfach darum geht, dieses Verständnis zu schaffen zwischen IT und Business. Also diese Wechsel, bei der eben, manchmal, ich höre das im Projekt, manchmal, der Fachmann, der soll sich halt einfach das SQL anschauen. Da kriegt er ja sein Tool und dann kann er doch da selber diese Abfragen machen oder so.
Und die sitzen ja da vorher, die sagen, was soll ich da? Also das ist natürlich ganz eine andere Welt. Und es ist ja auch ein Transfer. Es ist ja das Business nicht eins zu eins abgedeckt in der Technik. Wobei man da sagen muss, der Fachmann versteht das nicht. Das wird immer weniger wahr. Also immer mehr Leute, gerade die zwischen Business und IT arbeiten, die Business-Analysten, die können immer besser. Also es gibt immer mehr Leute, die auch wirklich gut in SQL sind.
Aber selbst die, wenn die es visuell dargestellt kriegen, jeder Mensch, auch der härteste ITler, kann, wenn die Visualisierung gut ist, damit besser arbeiten, als wenn es einfach nur Code ist. Ja, ja, stimmt. Ja, genau. Außerdem, da gibt es ja auch ganz klare Gründe, warum. Bei SQL ist ziemlich lang zu tippen und mit Tools kriegst du es viel schneller hin. Wenn du möchtest, was weiß ich, von 100 Spalten nur 99, dann geht das in SQL nur so, dass du die 99 angibst. Ja, ja, genau.
Da kann man auch viel Text schreiben. In der GUI klickst du nur die eine Spalte weg und fertig. Ja, genau. Ja, super. Ich danke euch herzlich für diesen Einblick in die Welt der Datenqualität und der Datenprozesse. Ich fand das sehr spannend, da mal auch mit reinzutauchen, zu schauen, was da gerade so möglich geht. Ich wünsche euch noch eine tolle Restkonferenz heute. Der Nachmittag klingt ja aus. Ja, danke dir. Und dann eine gute Heimreise. Danke sehr.
Danke, Richie. Vielen Dank für die Möglichkeit. Alles Gute. Danke, ebenso. Danke, auch dir. Danke, auch dir. Danke, auch dir. Musik Untertitelung des ZDF, 2020