Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Ich bin euer Host Richie und für euch mit dem Qualitätsblick auf der OOP 2024 in München unterwegs. Heute habe ich schon fast Stammgäste hier im Podcast zu Gast, nämlich Marco80er und Gregor Endler. Vielleicht erinnert ihr euch noch an die Folge zu "Continuous Everything - brauchen wir denn das Ganze?" von der letzten OOP. Diesmal geht es um KI-Testen. Welche Fragen wissen wir
uns stellen? Was kann der Tester vom Data Scientist lernen und umgekehrt? Was ist eine typische Checkliste, die wir abarbeiten können, um KI zu testen? Und ist es wirklich so anders als normale Tests? Darüber haben wir uns unterhalten und da waren einige spannende Erkenntnisse für mich dabei. Und wie so oft an dieser Stelle freue ich mich sehr, wenn ihr mir Feedback sendet an podcast@software-testing.fm. Und wenn euch der Podcast gefällt, dann hinterlasst doch gerne
ein Like auf YouTube oder eine Bewertung bei Apple oder Spotify. Das hilft mir, den Qualitätsgedanken weiterzutragen. Und jetzt viel Spaß bei der Folge. Hallo Marco, hallo Gregor, schön, dass ihr da seid. Hallo Richie, schön, dass wir da sein können. Wieder mal eine OOP, wieder mal ihr als Gäste hier. Das ist ja schon fast schon Stammgäste jetzt hier im Podcast, könnte man fast sagen. Ja, zumindest jetzt zweimal in Folge.
Ja, genau. Wer weiß, was da noch kommt. Aber ihr seid natürlich auch sehr umtriebig mit Themen und beschäftigt euch ganz, ganz viel mit unterschiedlichen Sachen. Und ich schätze, das war beim ersten Mal auch so, wie ich eure Themen aus der Ehe gesteige, dann aber trotzdem auch tief rein und durchdringt die mal so richtig. Und das ist natürlich schon etwas, was ich dann auch für ein Podcast echt lohne. Und ich habe den im Abstract für die Konferenz hier habe ich
so durchgelesen und da stand so AI-Testing und da war ja AI-Testing. Das bewegt ja alle gerade, was und wie und warum und gibt es was für Perspektiven drauf. Und ihr habt da so einen schönen Beisatz dazu gehabt, die richtigen Fragen zu stellen. Und das fände ich schön. Dann haben wir gedacht, starten wir mal dazu. Was sind denn die falschen und die richtigen Fragen? Gibt es da überhaupt dann falsche Fragen? Kann ich es überhaupt, kann man es überhaupt testen?
Das ist vielleicht eine zumindest nicht hilfreichere Frage. Aber ist es falsch? Man kann sich sagen, mal stellen. Ich glaube, wir sollten da auch noch mal, dass wir die Lorbeeren nicht alleine ernten, erklären, wie wir da hingekommen sind. Wir standen ja letztes Jahr auch schon bei der OOP mit einem ähnlichen Vortrag, wo wir inzwischen ja auch paar Spielen ein bisschen verfluchen, weil letztes Jahr stand man da mit Determinismus ist doch kein
Thema, macht die Dinge halt deterministisch. Jetzt hat Greg rausgefummelt, nee, ist leider nicht so, seit Neuestem. Es werden Hightcases genommen und in den Fällen kann man sagen, ja passt so, ist so, ich kann es durchrechnen. Und jetzt relativ frisch ein paar relativ fiese Resultate, die das zu einem verhageln. Aber aufgrund von dem Vortrag letztes Jahr sind wir dann eben mit mehreren Leuten zusammengekommen, die teilweise auch bekannt sind, wie die Edix Schledebeck oder
Schladebeck, um den Namen richtig auszuprägen hoffe ich. Und haben dann mit sechs Leuten von verschiedenen Firmen so eine kleine Workgroup gemacht und haben eben gemeint, ey, kommen wir irgendwie, wenn wir unsere verschiedenen AI-Produkte anschauen, zu irgendwas gemeinsamen, wenn wir ans Testendenken. Und dann haben wir eben nach zwei Workshops gemerkt, okay, was wir definitiv machen können, ist eine gemeinsame Fragerliste. Das kriegen wir hin und da ist dann diese Frage,
schräge Checkliste entstanden, die wir eben dann gestern im Vortrag vorgestellt haben. Naja, also so kam das dann? Vielleicht auch, dass das eine relativ breit aufgestellte Gruppe war, da waren ein paar Teamleads dabei, Tester, Testerarchitekten, Data-Design-Testen, also einmal quer durch, um zu schauen, wie können die miteinander reden und kommen wir auf dieselben oder ähnliche Fragen und was die Basis ist. Ja, ja, ja. Es ist spannend, da würde ich gerne nochmal, und war das auch so divers,
der Fragenpool, der dann da rauskommt zuerst, bevor ihr den Fett eingedampft habt? Oder war das schon alles so ein ähnlicher Blick in die Richtung? Ich glaube, es gab ein paar Unsicherheiten oder Lücken auf beiden Seiten. Wir hatten gestern im Vortrag auch sowohl eine Folie, was sinnvoll, wenn die Tester sich noch anschauen und lernen und was die Data-Design-Testen sich noch anschauen
müssen und was sie lernen müssen. Deswegen würde ich sagen, es gab vielleicht ein paar, ja, Lücken ist vielleicht ein bisschen zu bösartig gesagt, ein paar Stellen, wo man sich gegenseitig sehr gut
helfen konnte. Ein paar Sachen waren ähnlich und ein paar Unsicherheiten einfach, die sich so auftun, weil man ja so speziell, wenn man das Wort AI verwendet, gleich ein irrsinnig riesengroßes Gebilde vor einem geistigen Auge hat und denkt, na ja, eine menschenähnliche Intelligenz, da brauche ich Psychologen, um die zu testen, kann ich technisch doch nichts machen und so und das dann runterzudampfen
auf was Hilfreiches. War so ein Ergebnis, würde ich sagen. Ich würde da gleich einmal dabei bleiben, also die Gaps, die die Tester haben und die Tester, die Tester-Data-Tests haben, was sind denn da so die zwei, drei Seite? Ich glaube, da ist das primäre Ding, du gehst mit einem anderen Fokus ran. Also der Data Scientist, wie der Greg immer so schön sagt, nehme ich mal den Data Scientist die Rolle, dass du
dann den Tester, dann schauen wir mal, ob das irgendeine hat. Also so wie ich das verstanden habe oder wie ich halt mit Greg arbeite, der Data Scientist, der geht da ja ran, der bekommt diese Problemstellung und will ein Modell entwickeln, das genau dieses Problem löst und dann, klar, geht man da mit mathematischen Methoden ran, sagt dann, ja, okay, mit diesen Werten kann ich das alles evaluieren und das Modell
funktioniert auch. Es ist aber halt nur ein Teil von dem System, das eine bestimmte Funktion erfüllen soll, um das System weiterzubringen und das kann halt beim Data Scientist verloren gehen und da kommt halt der Tester ins Spiel. Weiß nicht, ob du dann da mal deine Sicht der Dinge, um da mal ein bisschen hin und her zu schmalen.
Also ich möchte bestätigen, dass du das schön zusammengefasst hast, dass man eine gewisse Betriebsblindheit schnell mal entwickeln kann, im Sinne von, ja, jetzt habe ich das Modell, jetzt bin ich fertig mit meiner Arbeit und wie sich es dann einbaut in ein größeres System, ist halt dann schon wurscht, weil ich habe es ja evaluiert. Stimmt also. Von Tester-Seite aus muss man sich plötzlich mit einem
System rumschlagen, das mit statistischen Werten um sich wirft. Also ich weiß, mein System hat eine Korrektheit von 80 Prozent. Also nicht immer. Also weiß ich bei einem gewissen Input vielleicht auch nicht 100 Prozent was rauskommt und was bedeuten diese 80 Prozent für mich und welche anderen Zahlen muss ich so verstanden haben oder zumindest wissen, mit wem ich rede drüber, um das Ding dann
auch wirklich gut testen zu können. Also die, wir haben sie im Vortrag "Stats 101, 2, 3, 1" genannt, ist nützlich, wenn man als Tester eine Ahnung davon hat oder sich ein bisschen einlässt drin oder wenn man, das ist auch eine wichtige Sache, sich die Kollegen, die man hat, schnappt und mit ihnen redet. Also das Reden von Tester- und Data-Sign-Testen untereinander zusammen ist in unserer Meinung herrschendig furchtbar und herrschendig hilfreich.
Ich weiß es jetzt nicht so ultra signifikant, weil es ist immer besser, wenn alle Leute im Team miteinander reden. Das kann schon mit Tester müssen mit Devs reden, Devs mit Data-Sign-Tests und so weiter. Aber die Überschneidung in den Aktivitäten, die Tester ohnehin haben und Data-Sign-Testen auch haben, ist eine schöne Basis, eine schöne Gemeinsame.
Also kann man das gut vorstellen, weil also das heißt, hier ist es vielleicht schon nochmal anders, weil man einfach einen anderen Blick drauf haben muss. Bis jetzt sag ich so, ich hab meinen einen Testfall, den führ ich aus und dann weiß ich was raus. Und jetzt kann ich den Testfall nochmal durchführen und das geht halt und geht halt mal nicht. Und dann kommt halt Statistik ins Spiel, wo das viel mehr Gewicht bekommt. Das ist eine andere Denke, glaube ich.
Wobei, ich bin ja jemand, ich weiß nicht, ob das inzwischen die Altersmittel bei mir ist, die dazu schlägt. Ich hatte auch mal andere Meinungen, aber ich kann mich noch. In Deutschland gab es mal den Computer Club und die zwei Moderatoren haben dann immer bei neuen Sachen gemeint, ja das ist ja Alterwein in neuen Schläuchen.
Und vor allem jetzt bei dem Thema Statistik, wo ich ja auch hoffe, dass das gestern in dem Vortrag ein bisschen rauskam, so den Appell an die Tester überlegt mal, was ist denn wirklich neu. Und vor allem das jetzt, wo du meinst, mit der Statistik. Vor allem wenn wir jetzt an die Richtung Performance-Testing gehen, also Time-Behaviour-Testing, das hatten wir ja schon.
Also da stand ja jetzt auch nicht, also wenn du ein gutes Non-Functional-Requirement bezüglich Time-Behaviour hast, da steht da ja jetzt schon, in 95% der Fälle soll die Webseite in unter 300 Millisekunden ausgeliefert werden. Das heißt, ich musste für solche Testfälle ja eigentlich auch schon die Statistik kennen. Es wird halt wichtiger, weil jetzt habe ich ein System, das per Design sich so verhält, auch in der Funktionalität.
Aber eigentlich war es ja schon da, die Problemstellen. Ja, genau. Vielleicht drücken sich deswegen auch so viele von Performance-Testing und so, ein Happy Pass im Funktional, das ist dann einfach. Ja, aber wenn es schwierig wäre, könnte es jeder. Wenn es einfach wäre. Aber weil es schwierig ist, muss man halt ein bisschen Krips reinstecken.
Jetzt habt ihr in eurer Gruppe quasi dann so eine Art Checkliste erstellt. Da wollen wir wissen natürlich, was steckt da so drinnen? Was sind so Punkte, die ihr da rausgearbeitet habt? Okay, was ja schon erwähnt wurde, also aus der Testerperspektive war das erst, was sollte ich mir als Tester noch aneignen?
Da hat man jetzt gerade das Beispiel, stochastische Methoden, statistische Methoden werden halt umso wichtiger. Ich muss mir halt überlegen, was bedeutet das, wenn das Modell eben zu 80% - okay, ich hoffe, die sind ein bisschen besser als 80% - aber zu einem gewissen Prozentsatz eben nur das richtige oder den erwarteten Output liefert, den ich brauche. Solche Sachen.
Also eine der Fragen ist, also wir haben das dann in so einem Fragenkatalog. Was muss ich lernen, wo wir dann halt drin haben, solltest du dir mal Statistik nochmal anschauen? Oder wenn es geht auf jeden Fall nochmal kombinatorisches Testen, exploratives Testen, sehen wir, dass das in dem Umfeld auch immer, immer wichtiger wird. Ich meine, das ist jetzt schon wichtig. Aber mit solchen Systemen, es wird nicht unwichtiger, sagen wir es mal so.
Es wird definitiv immer mehr ein Skill, den man sich beibringen sollte, den man sich beilernen sollte. Was war noch bei Testern? Dass man sich überlegen sollte, wann mein System überhaupt sich deterministisch verhalten sollte.
Also das ist aber auch wieder eigentlich eine alte Fragestellung, wenn man bestimmte Systeme anschaut. Also diese Eventually Consistent Systeme, die hatten wir ja schon vor der KI. Und da musste ich ja meine Testfälle auch schon so schneiden, normalerweise, wenn ich so ein System habe, dass der das handeln kann.
Also dass man sich wirklich überlegt, wann muss mein System wirklich deterministisch sich verhalten oder ist es eigentlich gerade in dem Fall, den ich testen will, komplett egal. Das ist auch so ein Ding. Das man mal für einen Tester, dann für einen Data Scientist hat man noch.
Zum Beispiel die generellen Non-Functional Requirements, die man vielleicht eben nicht auf dem Schirm hat, wenn man zu starken Modellfokus hat, unter Umständen auch Laufzeit. Also während einer Probungsphase kann es für mich total in Ordnung sein, wenn ich vier Wochen lang in der Gegend rumtrainier, wenn ich ein Modell, um dann ein Ergebnis zu bekommen. Klappt das nachher in Production auch? Passt das zum Anwendungsfall? Passt das in den Gesamtsystem-Kontext? Und dieser Gesamtsystem-Kontext ist dann was, was die Tester eben sehr, sehr gut hier in der Technologie haben.
Dass die Tester eben sehr, sehr gut den Data Scientisten beibringen können, unserer Meinung nach. Und wo sie die Assumptions, die man getroffen hat, während man das Modell trainiert, so ein bisschen gegenchecken können und auf die spätere Anwendung speziell gegenchecken können.
Genau, also das sind so die Fragen, was man noch lernen muss, sollte, könnte. Dann haben wir noch welche, die personenbezogen sind. Wir haben so ein paar auf Teammitglieder bezogen, welche Fragen man sich stellen kann und dann welche fürs System.
Was wir im Vortrag bringen, um der Vollständigkeit halber die ersten zwei Fragen, die wir vorstellen, brauchen wir überhaupt noch Tester? Gute Frage, brauchen wir? Ich bin der Meinung, ja. Es gibt zwar Tool-Ersteller, die sagen dir was anderes vermutlich inzwischen.
Die Frage kann man ja dann jetzt als beantwortet gelten, was ein Jahr braucht. Ja, das machen wir dann auch zum Schluss, dass wir sagen, okay, Vollständigkeit halber Jahr. Die Frage kam mal auf in unserer Arbeitsgruppe, aber bitte einfach nicht mehr stellen. Wir brauchen Tester, wir brauchen Leute, die mit dem Fokus rangehen. Ist einfach so.
Wir hatten noch, welche Testing-Aktivitäten machen Data-Sign-Testen ohne Inschung? Genau. Weil gerade erstellen von Testdaten und so weiter ist was, was ich sowieso machen muss fürs Modell erstellen. Ja. Und das sind Dinge, wo ich eventuell direkt Datensätze produziere, die ich dann direkt fürs Testen hernehmen kann. Oder zumindest ein Wissen und ein Gefühl für das Ganze aufbauen, das dann nachher beim Generieren von Testdatensätzen helfen kann.
Genau. Dann wo wir bei der Richtung Datensätze sind, was auch eine Frage ist, wenn man herangeht, wie teste ich mein System, brauche ich ein Golden-Data-Set, haben wir das genannt fürs Testen, also Thema Testdaten. Aber da wird es auch wieder wichtig, mit dem Data-Sign-Test zu reden, weil der hat ja auch schon Trainingsdaten und da muss ich als Tester natürlich abklären, was hast denn du da gemacht, was hast denn du da für Daten genommen, was brauche ich noch?
Es kann ja sogar sein, dass ich überhaupt gar nicht meinen Test auf immer demselben Datensatz ausführen muss. Ist das überhaupt dann noch für mich ein Use-Case, den ich testen muss, ist das egal? Kann natürlich auch sein, dass ich sage, okay, nee, in meinem Test muss ich auch den Training vom Modell irgendwie sicherstellen. Dann sollte man sich natürlich mit dem Data-Sign-Test am besten einigen, okay, das ist mein Golden-Data-Set, das ist dein Golden-Data-Set.
Dann ein ganz wichtiger Punkt, was ich glaube ich auch oft vergessen wird, ist, wenn Modell-Updates kommen, also das System selber lernt durch irgendwelche Mechanismen, muss ich noch mal kleinere Data-Setze definieren, wo ich sage, okay, damit simuliere ich Updates, um sicherzustellen, dass das in die richtige Richtung geht. Verstehe ich das genau. Ist das zur Realität, wie es dann nachher laufen wird mit den Modell-Updates?
Das ist so eine wichtige Frage, die halt, wir kennen alle die Beispiele von Chatbots, die zwar in die Freiheit gelassen werden, aber dann sich in kürzester Zeit zu recht interessanten Persönlichkeiten entwickeln, wo ich vage zu behaupten, da wurde eben genau dieser Fall, wie verhält sich der unter diesen Update-Bedingungen, weil die haben wir selber dann weiter gelernt, wenn das vergessen wird, kann sowas natürlich passieren. Also die Frage stellt, brauche ich das für mein System? Also wir können dir da keine Antwort geben, es gibt halt einfach keine Silver Bullet.
Aber wenn es an das Testen da geht, solltest du dir halt mal die Frage stellen, brauche ich es überhaupt und brauche ich es vielleicht nicht nur für das initiale Setup von meinem Test, sondern auch muss ich Update-Tests sicherstellen und da dann eben noch kleinere Update-Test-Data-Sets machen, zum Beispiel.
Das ist auch wieder was, wo das miteinander reden persönlich viel bringt, weil ich glaube, man kann Data-Scientisten entweder überglücklich oder totunglücklich machen, wenn man eben Boundary-Conditions für die Daten nennt, die vorher nicht bedacht waren. Weil da auf neue Ideen zu kommen, macht ja automatisch das Training besser, wenn man durch die neuen Ideen vernünftigeres Training-Daten-Set bauen kann und das ist halt sowieso das Ziel, das man hat und der Anspruch, den man hat.
Oder totunglücklich, wenn das einem natürlich dann sagt, okay, Mist, mein Training-Datensatz war für ein Eimer. Wenn ich so ein Tester bin, auch ein bisschen Fragestellung in Richtung dieses Lernens, wie wichtig ist es denn für mich als Tester, dass ich dieses ganze KI-ML-Thema verstehe, dass ich weiß, was da passiert drinnen? Ich glaube, dass man eine riesen Menge blackboxen kann, weil letzter Instanz verstehen, was passiert, ist offenes Forschungsgewicht.
Explainable AI gibt es nicht umsonst, als nach wie vor nicht abgeschlossen gelöstes Problem. Und deswegen hat man gar nicht die Chance, wirklich immer alles zu verstehen. Man hat aber die Chance, es besser zu verstehen als am Anfang, wenn man sich eben zum Beispiel auch eine der Fragen stellt, welche Teile von meinem System sind denn von KI betroffen? Welche Teile nutzen KI? Und wo muss ich ein bisschen genauer hinschauen, was das bedeutet?
Und habe ich da ein Modell verwendet, das menschenlesbar ist zum Beispiel? Ist es einfach ein Entscheidungsbaum, das Modell, das da rausprutzelt, dann kann ich es, je nachdem wie breit der alt wird, noch manuell durchgehen? Sind es tiefe neuronale Netze mit so vielen Schichten, dass die Formeln 800 Seiten füllen würden, dann wird es wahrscheinlich schwierig, aber für jeden. Ja, also ich bin da auch der Meinung, dass ist es ein interessantes Gebiet und ist es schön, dass man sich das anschaut?
Ja, ich lese da auch gerne drüber an. Sehe ich es als notwendigen Skill für einen Tester, dass er tiefgreifendes Wissen eigentlich über den Job vom Data Scientist hat? Glaube ich nicht, weil deswegen sind es ja auch zwei verschiedene Rollen. Also wenn ich beide Rollen bedienen muss, weil die Firma so klein ist, dann vielleicht wäre es nicht schlecht, beides zu lernen. Aber typischerweise in unseren Organisationen gibt es ja eben die getrennten Rollen, auch mit getrennen Personen dann.
Das sind verschiedene Skillsets. Was natürlich die Schrittstelle ist, und da sind wir wieder bei dem, was sollte ich lernen, ist halt der Output der Modelle. Also jetzt habe ich halt was in meinem System, das per Definition mir halt was mit bestimmten Wahrscheinlichkeiten ausspuckt. Und das sollte ich natürlich verstehen können. Das ist ja vielleicht wichtig für meinen Test.
Also das beeinflusst ja mein Testdesign, meine Teststrategie. Das ist auch eine unserer Dinge, wo wir sagen, ok, das solltest du dir überlegen. Wo ist denn überhaupt KI in deinem System? Um das besser bewerten zu können, wie gründlich ich das auch teste zum Beispiel, also wie viel Testaufwand schmeiße ich da drauf? Hängt ja davon alles ab. Da muss ich ja wissen, was habe ich da eigentlich, was sagt mir der Output?
Und wo ist das eigentlich in meinem System, wie viel Impact hat das auf mein Gesamtsystem? Aber dass man da jetzt versteht, was ist der Unterschied zwischen Machine Learning, zwischen Deep Learning und sonst irgendwas, ist nice to know. Er grinst schon, weil ich weiß es anscheinend nicht. All good? Sehe ich nicht. Das ist was, was jeder gerne lernen will, weil es halt gerade aktuell ist, weil man gerne mitreden will.
Aber ich glaube nicht, dass das eine mandatory Voraussetzung jetzt als Testeskill ist. Ich glaube, dass es nützlich ist, wenn man einen kleinen Ausschnitt, die Basics, anschneidet, und zwar deswegen, weil man dann ein bisschen Gespür dafür kriegt, an welchen Stellen man nachfragen muss. Und das geht auch wieder in beide Richtungen. Also das ist die Stats 101 für die Tester, um ein bisschen zu wissen, ok, da steht zwar jetzt 99,9 Prozent Accuracy drauf, aber was bedeutet das genau?
Und reicht das für den Anwendungszweck oder für den Data-Scientisten, hey, ich habe zwar jetzt ein Modell generiert, aber bin ich mir denn hundertprozentig sicher, dass das zum Zeit der Anwendung im Gesamtsystem passt. Und da so ein bisschen einen Blick auf die Domäne der anderen Personen zu haben, ist hilfreich, um die eigenen Blindspots zu erkennen.
Ich glaube, viele Tester stehen ja so vor der Fragestellung, wie teste ich denn das jetzt eigentlich? Bis jetzt habe ich irgendwo meine Anforderungen, dann habe ich mein Testobjekt irgendwo, dann schreibe ich meine 15 Testfälle, schlechtesten Fall in Excel, besten Fall in irgendein Tool oder so, ein bisschen was mit Automatis. Und da habe ich aber so meinen Kosmos, in dem ich mich wohlfühle.
Und jetzt sagt jemand, du musst hier diese KI testen. Und ich weiß, jeder Testfall, der schreibt, der ist jetzt aus seinem klassischen Verständnis gar nicht so, wie kann ich mich denn dem annähern? Habt ihr da so einen Tipp? Ich glaube, viele stehen so mit einer Schockstarre davor. Also ich könnte jetzt fies sein und fragen, was ist denn anders? Also nur weil du jetzt ein KI-System hast, hast du ja hoffentlich keine Requirements.
Also das ist natürlich auch, was wir im Vortrag sagen. Also vom Prinzip her, wir nehmen schon an, dass du vernünftige Requirements hast. Und dass die Requirements dir auch sagen, was das System machen soll. Wir gehen auch davon aus, dass nach wie vor das System eine vernünftige Architektur usw. hat. Dass du auch als Tester weißt, okay, was sind meine Subsysteme, meine Systeme, auf was muss ich aufpassen, was sind die einzelnen Komponenten. Das geht ja nicht weg.
Das heißt, jetzt haben wir die KI in irgendeiner Komponente in unserem System. Und wenn wir ehrlich sind, was ändert sich? Es ändert sich halt prima der Output von dem Ding. Also die Komponente hat jetzt kein API mehr, wo ich sage, ich schmeiße A rein und bekomme B zurück, sondern ich bekomme jetzt B zurück mit einer Wahrscheinlichkeit von X Prozent.
Oder mit einer gewissen anderen Sache vielleicht noch, Accuracy und Precision und die ganzen Sachen. Also ein Haufen Statistik, die dahinter hängt, die ich verstehen muss. Aber ich schon meine, ich versuche da immer das Mapping auf das zu machen, was wir als Tester-Skillset schon haben. Wir hatten das schon in der Vergangenheit.
Wie gesagt, wir hatten früher schon nicht-deterministische Systeme. Also jetzt bei Microservices zum Beispiel ist ja dann irgendwann dieses Eventual Consistent wieder hochgekommen, wie erwähnt. Es gab dann andere Sachen, wo ich früher auch schon mit Wahrscheinlichkeiten die Sachen zurückbekommen habe. Performance, also Time-Bi-Aware-Testing, wenn ich es richtig mache. Habe ich mich ja auch schon mit Statistik rumgeschlagen. Da ist meine fiese Gegenfrage, wie habt ihr denn das bis jetzt gemacht?
Weil, wenn du das Transferwissen anwendest, ist es nicht sehr viel anders. Weil du kannst ja das Modell in der Tiefe gar nicht testen, weil das macht ja der Data Scientist. Du bekommst da typischerweise das fertige Modell. Deswegen musst du mit dem reden, was hast denn du schon gemacht? Welche Testfälle muss ich noch machen?
Und in der Aalfall, also jetzt wirklich in heile Welt, die wir natürlich wissen, dass die nirgendwo existiert, weil sonst hätten wir ja auch überall Einhörner rumrennen und so. Schau dir deine Requirements an und mach wieder deine ganz normalen Testmethodiken, die du da brauchst. Was sind meine Funktionalen-Tests? Muss ich irgendwelche Grenzwerte beachten?
Habe ich irgendwelche Äquivalenzpartitionen, die ich da identifizieren kann? Ich meine, das sind ja auch zum Beispiel bei den ganzen Sachen sehr oft Klassifizierungsprobleme. Wir schmeißen ein Bild rein, ist es eine Katze oder ein Hund? Zu 90 Prozent sollte das dann da rauskommen und so weiter und so fort. Das sind ja Sachen, die ich relativ leicht in den Tests abbilden kann. Also meiner Meinung nach.
Ja, es ist ein schönes Bild drauf, dass man das quasi schön noch transferieren kann. Ich glaube, da fehlt viel in der Kreativität oder so. Einfach viel Angst davor. Was die Schockstabe unter Umständen auflösen kann, ist, sich die Frage zu stellen, ist es vielleicht doch ein deterministisches System, das ich habe. Oder zumindest in Einschränkungen deterministisch.
Ändert es vielleicht nur den Output auf denselben Input, wenn ich das Modell neu trainiere? Okay, wie oft passiert denn das? Einmal im halben Jahr? Okay, cool. Man kann wahrscheinlich feste Input-Output-Paare von Testdaten generieren oder definieren und damit das System testen. Man muss halt dann rechtzeitig vor dem nächsten Modellrelease mir nochmal den Gedanken machen, passt das noch?
Und dafür, ich weiß ja, wo meine Blindspots sind mittlerweile, frage ich halt wieder die Person, die für das Model-Update zuständig ist. Wenn es nicht deterministisch ist, auch dann frage ich die Person, weil dann sind wir bei der Stelle, wo wir sagen, okay, wie oft muss ich denn jetzt diesen Testfall ausfüllen, damit ich mir statistisch sicher sein kann, dass die Annahmen, die wir haben, erfüllt sind. Aber im Wesentlichen ist das dann auch nur ein Öftermacher von dem Ganzen.
Ja, stimmt. Ihr habt jetzt diese Checkliste mit diesen Fragen. Was ist denn für euch so, könnt ihr nur eine Sache fragen oder nur eine Sache rausnehmen? Was würdet ihr denn da rausziehen? Ich glaube, das ist die nächste Frage. Ich glaube, darf jeder eine eigene raussuchen, weil ich glaube, der Greg hat da eine andere Sicht an das, als ich.
Das dürfte. Also wenn es dann an die konkreten Fragen sind und ich hoffe, dass die Leute wissen, gibt es bei der OP eigentlich die Slides zum Download? Ich hoffe. Ansonsten können wir das ja, kann man die bei euch, die können ja Kontaktieren besser machen. Genau, das sind ja dann unsere Kontaktdaten rein.
Also für mich glaube ich als Tester, wo ich das sehe, ist diese Frage, ist es der Deserment-Magnistik-System? Die ist die wichtigste in der Ansicht, weil die unglaublich viel Einfluss auf meine Testsstrategie hat. Weil wenn ich sage, das ist ein Deterministisches System, habe ich de facto, ist es mir egal, ob da KI, Machine Learning, lineare Regression, irgendwas dahinter ist.
Wenn das Ding Deterministisch ist, habe ich funktionale Requirements und ich habe halt eine Subkomponente, die macht halt ihren Job mit einem KI-System oder KI-Komponente hinter. Das, das KI ist, muss mir egal sein als Tester, weil es muss ich immer gleich verhalten. Wenn das schon mal geklärt ist, kann ich schon mal ganz locker durchatmen, weil eigentlich hat sich gar nichts mehr geändert. Ja, genau.
Und von der Seite ist es klar, ich schließe mich an. Das ist auch meine Lieblingsfrage, weil das, wie du sagst, irrsinnige Auswirkungen hat. Also ich kann es relativ einfach machen, wenn ich weiß, es ist Deterministisch. Und wenn ich weiß, es ist nicht Deterministisch, dann habe ich auch erst mal einen relativ klaren Plan, was zu tun ist. Oder ich kann Leute fragen, hey, kann man es Deterministisch machen oder unter welchen Umständen? Es gibt ja das Resultat, das ich angesprochen hatte.
Da ging es darum, dass es auf unterschiedlichen Rechnerarchitekturen dummerweise non-Deterministisch werden kann, obwohl das Modell fix ist. Also wenn ich in sowas reinrutsche, dann muss ich mir Fragen stellen, wo läuft denn das System dann? Und ist die Hardware konstant? Welche Algorithmen laufen bei Matrix-Operationen in der GPU? Da wird es tatsächlich dann ein bisschen unangenehm.
Aber andererseits, außer ich weiß, wo das Ding laufen wird, vielleicht läuft es ja on-prem. Vielleicht ist es ja fixer Hardware. Vielleicht weiß ich ja, okay, ich brauche gar keine GPU-Beschleunigung, das ist alles Single-Core-CPU, keine Race-Conditions zwischen den CPUs und so weiter und so fort. Und dann kann ich mich wieder auf einen Deterministischer Rennfall zurückziehen. Und deswegen steckt da einfach irrsinnig viel drin und das ist sehr interessant.
Total wichtige Weiche am Anfang, das zu klären für sich. Und ich glaube, das ist oft unklar. Man hört da nur dieses wabelnde KI, AI, irgendwas muss ich da testen, aber so gar nicht wissen, worum es da geht und wo kann ich die Grenzen da ziehen.
Genau. Und wie gesagt, vielleicht nimmt es einem ein bisschen die Angst, wenn man das so merkt, okay, ich beurteile jetzt, ich habe nicht die KI zu testen, sondern erstmal schaue ich mir an, okay, reduziert sich es auf die Frage zwischen Determinismus und Nondeterminismus für mich erstmal und dann habe ich so schön die Weide in Konker vielleicht in einem Bereich, den ich kleiner anfassen kann als das große Ganze auf einmal.
Super. Vielen lieben Dank euch beiden. Das fand ich einen super Einstieg wieder mal in das Thema von sich, von seiner quasi einfachen Tester-Sicht und Data-Sicht draufzuschauen. Wir werden eure Kontaktdaten natürlich in den Show Notes haben. Das heißt, wenn jemand diese Checkliste, die Fragen haben will, dann kann er euch einfach anschreiben oder wir verlieben die Slides irgendwie.
Super gerne. Und wenn jemand von den Hörern die Checkliste verwendet und neue Fragen findet oder welche von den Fragen doof findet oder so, dann würden wir uns irrsinnig über E-Mails freuen, weil wie gesagt, das ist aus Workshops, aus einer Zusammenarbeit mit einer Menge Leuten entstanden. Und wenn man da deine Hörer noch dafür gebrauchen kann, da noch ein bisschen mehr reinzuziehen, ist das natürlich super.
Super Aufruf. Also ihr habt das alle gehört. Also meldet euch mit euren Erkenntnissen aus den Fragen, mit euren Feedback zu den Fragen. Das finde ich eine schöne Sache. Ich danke euch schön, dass ihr hier wart. Ich wünsche euch noch ganz viel Spaß auf der OP. Wir sehen uns spätestens bei den Software Quality Days in Wien. Bin ich ja. Da bist du, genau. German Testing Day. Bin ich auch. Hab ich gestern erfahren. Bin ich auch. Und wir? Wir sehen uns dann irgendwie wieder wahrscheinlich.
Ich wünsche euch alles Gute und bis bald. Super, danke dir. Ciao. SWR 2020 Herr L見lZY los!