Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und freue mich wieder eine Folge vom German Testing Day 2024 dabei zu haben. Bei mir zu Gast Michael Fischlein, mit dem ich über das Thema KI und Testdesign gesprochen
habe. Der eine oder andere kann sich vielleicht noch dunkel an die Zeit erinnern, wo man Testmethoden gelernt hat, aber nutzt man die gerade auch wirklich immer im täglichen (Klammer auf, ich hoffe schon, Klammer zu) Wie KI hier unterstützen kann, damit wir zu einem besseren Testentwurf kommen, hört ihr in dieser Folge. Viel Spaß dabei! Hallo Michael, schön, dass du da bist. Hallo! Hier am German Testing Day 2024 in Frankfurt. Gerade die Eröffnung gewesen, jetzt geht es so
los in den ersten Tracks. Eineinhalb Tage super Input, viel Fachlichkeit, viel Netzwerken hier heute Abend, wenn wir ein tolles Event haben. Freue ich mich auch schon drauf, aber vorher machen wir noch eine coole Podcast-Folge. Ich habe vorher die App-Strikes durchgelesen, wer so spiegt und was so Themen sind und du hast einen recht knackigen Titel gehabt. Endlich mal ein bisschen Intelligenz in der Qualitätssicherung. Das erkläre ich dir jetzt mal.
Das ist gar nicht so einfach, das so auf den direkten Punkt zu bringen. Ich hatte eigentlich November vor eineinhalb Jahren auch angefangen mit so Chachibiti, war ja der Hype, alle haben probiert. Angefangen von meiner Spielleidenschaft, Fantasy-Rollenspieler und Dinge auszuprobieren, Geschichten zu schreiben, Ideen aufzubauen, Konzepte zu bauen. Da habe ich mich dann halt mal mit beschäftigt, wie man das so umsetzen kann im Testing. Jetzt kommt so ein bisschen
die zweite Welt dazu. Ich bin ja für das ganze Trainingsthema auch bei Sogeti verantwortlich, also auch die Ausbildung der Mitarbeiter als L&D-Koordinator und halte selber seit über zehn Jahren Trainings. Das Schöne ist, wenn man hauptsächlich Trainings hält, dann sieht man ganz ganz viele Unternehmen von sehr tief drinnen. Man kriegt neue Leute mit, man kriegt erfahrene Tester, Testmanager, die sagen, ich mache schon seit zehn, 20 Jahren den Beruf und jetzt mache ich
mal mein Zertifikat und allem. Und dann ist es erstaunlich, was man denen alles noch bei einem Foundation-Level-Schulungslehrgang Neues erzählt. Also die Äquivalenzklasse, das Thema haben sie vielleicht schon mal kapiert, aber den Namen kennen sie nicht. Grenzwerte, da war mal was und alles, was danach kommt an den riesigen Testdesignmethoden. Das hat mich dann fasziniert, was ich heute Menschen erlebe, die testen, die Erfahrung haben, die das in Firmen propagieren, die dort
verantwortlich sind. Und es kommt wahnsinnig viel aus dem Bauch heraus. Also Testing aus dem Bauch, das, was ich jetzt meine, Testdesign, Testdaten, Recryme-Ingenieur, das läuft halt alles so. Haben
wir schon immer so gemacht, habe ich eine Erfahrung dazu, ist ja wunderbar. Und dann habe ich halt mal angefangen, mich mit solchen Systemen, also damals JetGP T35, jetzt Co-Pilot, was halt alles so da rumfliegt, also alle Systeme, die überhaupt nicht aufs Testen in irgendeiner Art und Weise trainiert sind, sondern Language-Modelle, die halt Language-Modelle, die irgendwelche Dinge, nicht zufallsmäßig, sondern statistisch auswerten und überlegen, was könnte das nächste relevante
Wort sein. Und dann habe ich halt mal so Dinge angefangen wie, schreib mir mal Use Cases, schreib mir mal Akzeptanzkriterien, schreib mir mal ausführlich Akzeptanzkriterien, gib mir doch mal die Grenzwerte davon, gib mir mal Wertebereich, Äquivalenzklassen. Und ich habe festgestellt, die machen das relativ gut, nicht fehlerlos. Da ist jede Menge Mist, Halluzinationen dabei,
gar keine Frage, aber es kommen doch erstaunlich gute Ergebnisse raus. Vor allem, wenn ich mir dann anschaue, ich mache auch ab und zu mal TPIs, also Test Plus Improvements in Firmen, und dann sieht man ja, was machen die denn wirklich. Also ja, es gibt irgendwo einen Ordner und darunter ist ein Pfeil, da steht Testkonzept drin, aber da ist der Loch im Ipsum noch nicht ausgegraut teilweise.
Ja, also sovon ist es halt da, weil es sein muss, aber ist nichts Sinnvolles drin. Und dann war ich echt erstaunt, wie schnell ich Antworten bekomme von den Systemen, die vielleicht nur per ETRU-Regel 80 Prozent richtig sind. Aber wenn ich das von Fachleuten mir geben lasse und die Aufgabe stelle, dann kriege ich auch nur was zurück, was 80, 90 Prozent richtig ist, braucht dafür aber ein, zwei Tage. Und das war für mich so ein bisschen der Punkt, wo ich gesagt habe, na ja, das ist
vielleicht spannend, sich das mal zu überlegen. Und deswegen werde ich morgen im Vortrag, der kommt ja erst dieser Podcast nach dem Vortrag. Ja, ja, genau. Werden wir so ein bisschen das Spielchen machen, mal ein paar Leute aufstehen lassen, wer was kann, wer was gemacht hat. Und ich habe den schon mal gehalten vorher. Es war erstaunlich,
am Anfang, wer hat ein Zertifikat? Da steht dann so ziemlich alles auf. Und wenn man da ein bisschen abfragt, wer hat davon schon mal was gehört, wer kann es, wer wendet es an, ist die Menge der Leute, die sich setzen. Und ich sehe halt heute jetzt die spannende Situation, dass ich eben diese
Situation, ich stehe vor so einem Problem. Ich als Tester muss jetzt irgendwas machen und da hat vielleicht irgendjemand noch gesagt, verwend da mal einen Zustandsautomaten oder mach da mal Äquivalenzklassengrenzwerte, volle Kombinatorik, was auch immer, Parallel Testing, gibt es ja alle möglichen Begriffe. Erstens macht das schon wieder gar keiner und zweitens, die meisten wissen dann gar nicht, was sie tun sollen. Und dann steht das weiße Blatt Papier und die Angst vor dem weißen
Blatt kennen wir alle. Und ganz ehrlich, wenn ich das jetzt irgendeinem Chat-System gebe, wie gesagt, Co-Pilot oder was auch immer, dann kriege ich was raus innerhalb von 30, 40 Sekunden. Wenn ich noch ein bisschen die Prompts optimiere und nochmal nachfrage, dann habe ich in zwei, drei Minuten ein Konzept, ein Test-Design da stehen, wo ich sagen muss,
habe ich selten in real life beim Kunden gesehen. Und das ist so die Idee dieses Vortrags, um den Leuten mal bewusst zu machen, was da eigentlich gerade passiert, was da gerade möglich ist. Jetzt muss ich sagen, haben wir natürlich von meiner Homebase von Sogeti auch noch das Ganze, sind wir gerade dabei, am Bauen und auch dann irgendwann mal so am Vermarkten, dass wir wirklich ein System haben, das auf Testing trainiert ist. Also nicht allgemein, sondern jetzt mal wirklich
nur konzentriert auf Testing. Und die ersten Sachen, die ich mir da anschauen konnte, waren dann schon erstaunlich gut, weil das System versteht mich jetzt. Und das ist natürlich toll. Und jetzt kommen natürlich die ganzen psychologischen oder auch soziologischen Themen mit rein. Was heißt das für meinen zukünftigen Beruf? Werde ich noch gebraucht?
Habe ich Angst jetzt um diese Zukunft? Wird meine Software jetzt vielleicht wirklich besser? Also auch dieses Thema Shift-Left, also kriegen wir Fehler vielleicht früher raus aus dem System, weil uns solche Systeme helfen können? Das ist, glaube ich, ein ganz spannendes Thema und das macht gerade Spaß zu diskutieren, den Ausdruck zu haben. Warum glaubst du denn, werden denn diese Test-Design-Methoden, du sagst ja selber, wir lernen die ja alle, also jeder macht irgendwie
den Foundation-Level, wenn er mit Testen anfängt oder irgend so was. Und da gibt es, da übt man das ja sogar, Exzellenzklassen, Grenzwert, Entscheidungsterrain, Zustand, das sind ja quasi auch Prüfungsfragen und man hat quasi die Übungsdings. Warum findet das den Weg in die Praxis nicht rein? Warum verwenden das die Tester dann nicht, sondern machen dann wieder nur Testfälle aus ihrem Bauch raus? Na ja, sind wir mal ganz ehrlich, also ich halte die Foundation-Level sehr
häufig. Der Anteil an den Test-Design-Techniken üben und dieses Intensivieren, das ist überschaubar. Also bei vier Tagen hat man dann einen Tag, einen halben Tag, wo man sich diese Themen anguckt. Das ist wieder, man muss danach eigentlich, das haben wir auch schon mit Kunden gemacht, wo wir gesagt haben, wir machen die Schulung zwar, aber wir haben dann auch noch einen Mentor noch bei euch sitzen, der euch nicht die Arbeit abnimmt, der euch aber immer wieder triggert und quasi euch
hilft, diese erste Hürde zu gehen. Weil natürlich, sobald ich heute anfange, mir ein reales Projekt anzugucken, das ist meist ein bisschen komplizierter als der Bankautomat, als der Kolaautomat, als die Kaffeemaschine, also die üblichen Beispiele, die man hat. Und wir wissen das selber, wenn ich eine Entscheidungstabelle mache, 2 hoch N. Wenn ich jetzt fünf Bedingungen habe, dann ist es 2 hoch 5, das handle ich noch. Wenn das 20 Bedingungen sind, dann ist das eine riesen Tabelle,
dann muss ich schon - also da kriegen viele Angst. So ist das Gefühl, ach, dann mache ich halt doch nur mal schnell so und so. Ich habe ja jetzt nicht die Zeit. Es ist halt diese Invest, die man fahren muss. Das kenne ich von mir selber. Ich habe auch lange gebraucht, bis ich das so gefühlt aus dem FF, die meisten Sachen, auch jede Menge Sachen, die ich nicht kann.
Aber man hat es halt viel geübt. Und wenn wir jetzt heute gerade in die agile Welt gucken, das ist ja der nächste Aspekt, der da reinkommt, heißt es jetzt auf einmal, ja wir schreiben ja gar nichts mehr auf, wir sollen nichts mehr dokumentieren, also alles falsch verstanden. Aber dann fange ich auch an, ja, ich muss ja schnell sein, ich muss ja schnell testen. Und dann muss mir aber auch so ein Testdesign quasi aus dem - ja,
das muss ich mir aus den Ärmeln schütteln können. Das muss ich nicht erst sagen, ja, ich habe da mal was gehört, ich lese da mal nach, ich probiere mal aus. Und davor haben viele Angst. Und dann gibt es ja den Ausweg, nennen wir es mal so, des explorativen Testens. Da mache ich es einfach halt nebenher. Wobei da auch, wenn man sich exploratives Testen genau anschaut, wäre es ja wichtig, dass man Testdesignmethoden beherrscht, dass man bewusst Äquivalenzklassen,
bewusst Grenzwerte, Entscheidungsquellen halt implizit macht. Aber weißt du selber, glaube ich, bei jedem Thema, was du anfängst zwischen "Ich habe es mal gezeigt bekommen, ich habe den ersten 1, 2 Sachen gemacht, ich habe früher Tennis gespielt, Fußball gespielt, ich weiß noch wie, ich habe meinen Trainer gehasst, der mich eineinhalb Stunden lang die Rückhand Longline hat spielen lassen. Das war so das Lästige. Aber dann lernt der Körper. Aber das
ist aufwendig. Und das haben wir heute oftmals in den Projekten eben nicht. Wir wollen kurz, wir wollen schnell was machen, wir haben keine Zeit dafür. Und dann passiert das halt. Und es muss natürlich auch irgendwer diesen Auftrag bringen. Also wenn ich mir heute viele Testmanager anschaue, die auch die Advanced Level Testmanager-Schulung gemacht haben, ja das Zertifikat
haben sie. Wissen ist nochmal ein anderes Thema. Das ist, glaube ich, da. Und jetzt haben wir halt den Vorteil, diese Lücke, dieses Gap, das wird jetzt von der künstlichen Intelligenz relativ entspannt geschlossen. Nur ausbildungsseitig habe ich jetzt das Problem, irgendjemand muss danach das Ergebnis bewerten. Weil ich kann ja die Ergebnisse, die mir eine KI heute liefert, also ein AI-System, das ist nicht schlecht, aber das ist nicht fehlerlos. Und jetzt brauche ich
halt jemanden, der das sehen kann. Jetzt sind wir wieder in der alten Diskussion, also meine Trainerkollegen, von Sogeti, wir stehen da und sagen, ja klar, ist doch logisch, da ist ein Fehler, da ist ein Fehler, das passt nicht. Weil wir machen das halt seit 10, 20 Jahren. Ich sehe es halt. Aber jetzt mein Junior-Consultant, der das Foundation Level gerade hinter sich gebracht hat und ich zeige ihm eine komplexere Thematik, der sieht das nicht, ist auch okay. Aber wir müssen
diese Lücke irgendwo schaffen, dass die Leute diese Bewertungsfähigkeit haben. Das wird, glaube ich, eine Herausforderung. Ja, also man muss dann doch ja die Methoden ja auch wieder beherrschen, damit man das auch bewerten kann, was denn da eigentlich rauskommt. Wie machst du das oder wie argumentierst du denn, das ist ja auch eine Frage, die ich auch immer wieder im Alltag mitbekomme, so wenn ich jetzt ein bisschen rumteste, da finde ich ja auch Fehler und dann
sind wir schnell fertig und dann passt das. Wie argumentierst du, dass man so systematische Methoden, was wirklich der Nutzen ist für den Tester, den er dann auch kauft? Auch wieder sehr schwierige Antwort, weil es ein bisschen von den Systemen abhängt. Also wenn ich gerade beim Kunden bin, der schon jetzt seit etlicher Zeit seine Tests macht, also sein Produkt rausbringt, muss ich ja ganz klar sagen, bist du mit der Qualität, die du auslieferst zum Kunden zufrieden?
Bist du mit dem Timing zufrieden? Also lieferst du rechtzeitig aus und alles? Ganz ehrlich, wenn er das mit Ja beantwortet, dann muss ich sagen, macht er alles richtig. Es kann ja nämlich auch sein, dass er einfach ein, zwei Tester, Testerinnen hat, die ein derartiges Gespür haben. Also die haben ja quasi die, das sind eine reale Intelligenz, die haben einfach ein Bauchgefühl, ein wahnsinniges Verständnis für die Software, die wissen, was los ist, die finden das auch.
Wenn ich aber diesen Kunden habe, der dann sagt, ja, also wir liefern immer aus, aber danach wird es heiß. Na ja, dann wäre halt die erste Analyse, warum wird es heiß, was für Fehler hast und wo könnte ich die Fehler finden? Da sind wir in der ganzen Diskussion dann von eben diesem Shift-Left, wo hätte ich die Fehler denn finden können? Es ist ja nicht nur das Testen. Also viele nehmen
ja dieses dynamische Testen als Testen an. Es fängt ja viel früher an. Das ist beim Requirements Engineering, die Requirements zu überprüfen, Reviews zu machen, Workthrough, was es alles gibt, Pairing, diese ganzen, also die Fehler gar nicht ins System reinzubringen. Und da muss ich dann natürlich sagen, das ist halt der Punkt, der erste Part ist Analyse, wo kommen die Fehler her? Und dann muss ich mir da anschauen, was passiert, habe ich Grenzwertprobleme? Das ist für mich die
erste Frage, habe ich die überhaupt mal gescheit beschrieben? Das kennen wir ja auch. Da sind dann irgendwelche Werte drin, wo man sagt, ist das jetzt ein größer, größer, gleich oder wo geht es hin? Und das Zweite ist natürlich, wurde es richtig umgesetzt? Und dann fangen wir halt an mit der Diskussion, ja, wollen wir denn eine Absicherung von den Grenzwerten haben, dann müssen wir die Grenzwerte beim Testdesign erheben. Wir haben Kunden gehabt, die haben zigtausende Testfälle
gehabt. Dann haben wir es analysiert mit dem Kunden und haben festgestellt, von den zigtausenden Testfällen kannst du mehr als die Hälfte wegschmeißen, weil das sind einfach aus Äquivalenzklassensicht einfach Duplikate. Das ist zwar ein anderer Wert, aber der ist halt aus der gleichen Äquivalenzklasse, also die sind gleich. Dafür hast du ganz viele andere Bereiche gar nicht getestet. Und dann muss man es halt wirklich beispielhaft mit den Leuten aufgehen. Und es muss
gefühlt schon so ein bisschen schmerzter sein. Die meisten sagen, ja, aber das kostet ja Geld, das ist ja aufwendig. Ja, wenn alles gut läuft, was soll ich demjenigen raten? Also das ist, das kannst du, ich gehe unwahrscheinlich gerne in die Beispiel von Küchen oder ich esse gerne, ich koche gerne, ich backe gerne. Das siehst du ja auch bei einem Koch. Es gibt Köche,
die müssen rezeptgenau kochen, also die müssen wirklich alles abwiegen. Und es gibt Köche, die haben einfach so viel Erfahrung, die nehmen halt das, was da ist, und am Schluss ist es lecker. Das funktioniert aber nur, wenn derjenige oder diejenige Person sehr, sehr, sehr viel Know-how hat. Und da sind wir uns einig, weil die Diskussion fahren wir ja auch mit Kunden, auch intern. Ich kann einen Testmanager nicht innerhalb einer Woche von, ich habe keine Ahnung
zu dem Thema, zu erfahrenen Testmanager bauen. Ich kann ihn ein Zertifikat schreiben lassen, er übersteht es wahrscheinlich, aber ich kriege nicht dazu, dass er dieses, dieser Abgeklärt, diesen Know-how, da kommt ja auch dann solche anderen Sachen wie soziale Intelligenz dazu. Ja, also wir sind ja auf ganz vielen Bereichen Dinge, die gar nichts mit der Logik zu tun haben, mathematischen Logik, sondern Verständnis, wie läuft denn der Prozess, hat die Entwicklung
kapiert, was sie tut? Ich habe gerade mit einem Teilnehmer hier gesprochen, der mir erzählt, ja, unsere Entwickler schreiben Unitests, aber die sind völlig für die Katz. Ja, wenn der nur gelernt hat, er muss ein Unitest schreiben, aber nicht aufpasst, was er da tut, dann bringt es einem halt nichts. Und das muss man dann natürlich mit den Leuten,
das muss man verstehen, da muss man die Wege, die Prozesse kennen, Socializing, Netzwerken. Da ist so viele Sachen, die halt noch jenseits dieser reinen, ich sage mal, Testdesignkenntnisse haben. Wenn du dir so diese Testdesignmethoden, die Klassiker anschaust, welche würdest du denn sagen, aus deiner Erfahrung raus, ist denn die, die am meisten nutzbringend ist? Also natürlich hat jede ihren Vor- und Nachteil, aber gibt es eine, wo du sagst, die kann man eigentlich immer
irgendwo verwenden? Ja gut, ich meine wirklich so die Barsachen, wir hatten es jetzt schon ein paar Mal gehabt, also Grenzwerte sind einfach immer ein Punkt, weil Grenzwerte gehen halt schief. Wir haben in der Schulung so ein kleines Beispiel, wo halt der klassische Satz entsteht, das kürzeste Brett, was im Baumarkt im System eingegeben werden kann, liegt zwischen einem Meter und fünf Meter. Das ist der Satz "zwischendrinnen". Wenn ich jetzt "zwischen" mir
angucke, heißt "zwischen" natürlich, die Grenzen sind nicht mehr dabei. Also würde ich ja sagen, 1,01 und 4,99 Meter ist natürlich dämlich. Aber da habe ich schon den ersten Punkt, es wird halt textuell beschrieben und dann kommen halt seltsame Dinge raus. Das ist der erste Aspekt und das zweite, was einfach die Menge natürlich runterbringt, ist wirklich auch die zweite simple Methode, sind die Grenzklassen, weil ich mir einfach bewusst werden muss, dass ich nicht jeden
Wert testen muss, sondern ich muss die Wertebereiche kennen. Ich habe bei Sogeti ein paar hundert Einstellungsgespräche gemacht für München damals, wo ich Technical Manager war und ich habe immer nur die Frage gestellt, die sollen mir für eine ganz einfache Herangehensweise erklären, welche Testdaten sie nutzen. Und da ging es nur darum, dass im Bereich von geschlossenen Intervallen 9 bis 99 machen sollten. Und ich habe dann aufgeschrieben am Flipchart und da gab es Leute,
die sagten, ja, 1, 2, 3, 4 und dann 9. Und ich habe dann teilweise bis 100 geschrieben. Die haben nicht mehr gemerkt, dass das völlig irrsinnig ist. Es ist also wirklich ein kleiner Teil nur gewesen, da gesagt, ja, wir müssen da drunter was, da drinnen, da drüber was und so weiter. Und das sind so die Sachen, wo ich sage, wenn man das mal kapiert hat, das hilft einem dann auch eben zum explorativen Testen. Dass man sich dann Gedanken macht, welche Preiskategorie, ich brauche die
Preise, die Preise, die Preise, ich muss das so und so kombinieren. Also das kann man auch implizit sehr, sehr gut nutzen. Ja, und dann die ganzen Klassiker natürlich, wie gesagt, zustandsbasierter Test. Wenn ich halt Zustände im System habe, also Ticketing-System, das ist einfach zu visualisieren und es ist einfach zu verstehen. Und ich kann es halt, mir geht es darum, es sollen ja keine komplexen Dinge sein. Ja, ich brauche keine Rocket Science. Aber die
einfachen Sachen, die man auch hands-on dann machen kann. Weil mein Herz schlägt ja in der agilen Welt und ich will nicht, dass einer in der agilen Welt jetzt sagt, ich muss da jetzt erst mal drei Wochen Testdesign machen. Das ist ja völlig absurd. Zeit hat man ja da auch nicht. Haben wir nicht. Aber dass man schnelle, einfache Methoden nutzt, um das zu tun. Und dass man das natürlich auch, jetzt sind wir wieder beim Testmanager, dass man das als Testmanager auch den Leuten beibringt.
Dass man, wenn man keinen Testmanager hat, weil man ein agiles Team hat und sagt, wir brauchen keine Testmanager, ist ja okay, wir sind unser Team selber. Dass aber auch da jemand drin ist, der die Ideen bringt, der sagt, lass uns das so und so machen, lass uns nachvollziehbar machen. Dass es nicht der Zufall ist, wenn du das testest, testest du die Sachen so, wenn ich das teste, teste ich so. Beim einen kommt was Gutes raus, beim anderen halt nicht.
Ja, nicht personenabhängig sein. Das sind so die Dinge, wo ich sage, da kannst du. Und das können die einfachen Sachen sein. Jetzt hast du ja vorher gesagt, du hast dich ja auch mit GenAI und diesen Sachen beschäftigt, die dich da unterstützen, die auch gute Ergebnisse gebracht haben. Was würdest du denn sagen, wenn jetzt jemand, der hört jetzt gerade den Podcast, denkt sich, oh ja, ich kann mich erinnern, Äquivalenzklassentest, das hatte ich auch
mal gelernt. Ich würde mir das jetzt auch gerne mal mit KI anschauen, um da wieder auch mein Wissen zu vertiefen und zu schauen, wie kann mir das da helfen. Was wäre denn so, was würdest du sagen, ist das so der Einstieg? Reden. Also, rede mit den Systemen. Das sind Chat-Systeme, die verstehen das. Ich meine, es hilft bei dem - es gibt jetzt die ganz tollen Begriffe, das Prompt Engineers und alle, kann man hochtrabeln, kann man sagen, rede mit dem Ding so,
wie du mit einem anderen Personen reden würdest. Da darf auch gerne ein Bitte drin sein, man muss man das nicht weglassen. Da darf man sagen, schreib mir bitte für diesen und diesen Zustand mal die Äquivalenzklassen raus. Also, ich wäre morgen, wenn es live funktioniert, ist immer die Frage, muss man gucken, aber ich werde morgen solche Sachen machen wie, angefangen, schreib mir mal ein, ich bin ein Versicherungsunternehmen und ich möchte jetzt
Neukunden anlegen. Welche Variablen, welche Felder habe ich alles, wie sind die attributiert? Ja, und dann liefert mir das System schon mal die ersten Ideen. Dann kann ich so ein bisschen weiter mitnehmen, ich möchte da mehr, da weniger. Und dann habe ich ja schon meine Variablen. Also, jetzt bauen wir da mal Äquivalenzklassen draus und dann macht er das eigentlich mal.
Also, wirklich so wie ein Gesprächspartner. Man kann das auch gerne im Dreieck machen, wenn man sagt, ich habe da noch einen Kollegen und dann setze ich mich hin und dann lassen uns beide mal quasi eine dritte Person noch an den Tisch nehmen, also die KI, und ausprobieren und immer ein bisschen reizen. Und für mich ist ja dann der spannende Teil, deswegen nutze ich es auch gerne in Schulungen, also auch in der Foundation Level Schulung, wenn wir Zeit haben
und sagen, komm, wir machen da mal mit. Wenn Leute dann sagen, ja, aber das ist falsch. Sag ich, ja, genau, du hast gerade was gelernt. Ich habe ja gesagt, der macht nicht alles richtig, aber wenn du den Fehler erkennst, 100 Prozent. Also, man kann das auch selber, um sich einfach nochmal zu trainieren. Ich habe auch schon mal irgendwelche Requirements, die ich nehmen dürfte. Das ist ja jetzt wieder auch ein Thema Security, du darfst ja nicht einfach
Kundendaten da reinjagen. Aber ich meine, ganz ehrlich, wenn ich ein Shopsystem bei einem Kunden bin, der ein Shopsystem macht und ich mir dem jetzt ein Requirement dazu mal hernehme und gucke, dass da kein Name drinsteht und jetzt ist es, wir reden nicht von dem innovativsten, nagelneuesten Shopsystem mit ganz neuen Funktionen, dann nehme ich mir einfach mal das Ding und mache wirklich, schreib mir dazu bitte die Equivalenzklassen raus, Copy, Paste,
und dann habe ich das und dann sehe ich ja schon was. Ich hatte bei einem, den Kunden kann ich natürlich nicht nennen, aber bei einem Kunden aus dem Automobilbereich, der dann mal gesagt hat, ja Mensch, das ist doch toll, aber die können ja das Neue alle nicht. Machen wir jetzt übrigens, muss ich sagen, nicht auf 3.5, sondern in dem Fall auf Co-Pilot. Sag du mal, was machst du? Sag ich, ja, also es geht um hier eine Rückfahrthematik und Absicherungssystem und hat also alle Fachbegriffe,
die da drin sind, und ich sage, schreib mal mit. Er sagt, ja, der sollte es mal designen, da sollen wir mal Anforderungen schreiben. Ich sage, klick. Und dann rattert der die Anforderungen runter. Der Kollege saß da in der Schule und sagt, dafür habe ich jetzt eine Woche Arbeit investiert. Woher weiß der das eigentlich? Das ist eigentlich nichts Offizielles. Co-Pilot bietet ja unten dann die Links. Das waren die internen Seiten des Herstellers, die dort aufgelistet
wurden als Quellenangaben. Der Hersteller selber hat diese Informationen schon verbreitet. Wie gesagt, das waren so die Punkte. Da kann man jetzt Testfälle draus schreiben. Dann war ich so, damit ist die Arbeit, die ich nächste Woche machen wollte, auch schon fast erledigt. Hier ist nicht ganz richtig, da fehlen noch die und die Punkte, also genau diese Details. Also, kannst du mir das mal schicken? Also, dieses Spielerische, das ist für mich das Wichtige.
Als Spiel sehen, wirklich mal ein bisschen rumprobieren, ausprobieren. Wie gesagt, mein Einstieg in dieses ganze Thema waren Fantasy-Rollenspiele. Wer meinen Vortrag morgens sieht, der sieht auch ein kleines Bild dann. Ich baue gerne Klemmbausteine. Da gibt es einen Klemmbaustein, das ist ein wunderbarer alter Turm, der an der Piste ist.
Ich liebe Cthulhu, das ist ein Fantasy-Rollenspielsystem aus den 1920ern. Dann bin ich wieder hier und habe gesagt, hey, komm, lass uns doch mal gemeinsam ein Abenteuer schreiben. Da habe ich mir diesem Chat-System ein Abenteuer geschrieben und einfach dadurch überhaupt mal
kennengelernt, was heißt denn Prompt Engineering? Weil mir das runterlesen oder, ja, es ist toll, ja, aber ausprobieren, spielen und zu merken, was heißt denn das, wenn ich in die Facette gehe, wenn ich die Facette reinbringe, wenn ich sage, agiere als diese Rolle, diese Rolle, dann reagiert das System halt anders da. Wie gesagt, ab und zu völlig blödsinnig.
Ja, das sagst du, was schön ist. Also, dieses Spielen und Herumprobieren, ich glaube, das ist das, was wir jetzt gerade auch machen können und sollen, damit wir einfach da auch ein Gefühl dafür bekommen und auch das zu nutzen lernen als eigenen kleinen Assistenten oder Co-Pilot oder wie auch immer, um einfach auch da bessere Tests zu machen und bessere Tests zu schreiben. Michael, jetzt 2029, wir treffen uns hier am German Testing Day. Ich sage, ach cool,
komm, lass uns noch eine Folge machen, wie haben wir damals so gesprochen. Da haben wir damals, wenn wir da an den Schenkelklopfen stehen, da muss ich mich noch erinnern, damals manuelles Testdesign. Wie werden wir es denn in fünf Jahren machen?
Gute Frage. Wenn ich das wüsste, würde ich Aktien kaufen. Ich sage mal so, im Endeffekt hat sich das gezeigt momentan, was wir aus vielen dieser Sachen, also wenn ich an November von vor zwei Jahren zurückdenke, also eineinhalb Jahren, wie dieser Hype war und auf einmal alles und es wird in zwei Tagen alles anders da sein. Erst hat sich viel geändert. Es hat sich wieder dieser Garden Hype Cycle, den wir haben, hat sich jetzt wieder ein bisschen eingeschwungen,
ist jetzt halt State of the Art in vielen Punkten. Das wird auch wieder nochmal einen Hype geben. Da werden Dinge passieren, da werden neue Schritte. Das hat ja, wie gesagt, das finde ich sehr stark mit den Rechenleistungen, mit dem, was wir haben, an Methoden natürlich zu tun und das wird sich weiterentwickeln. Wir haben, das wird auch nicht stoppen. Also die Idee, dass einer sagt,
das interessiert mich nicht, weil, nee, das ist da, das wird passieren. Ich denke mal, wir werden viel von den, von den wirklichen Basisarbeiten, die werden wir definitiv loswerden. Aber woran ich noch nicht so ganz glaube, sind diese Systeme, die ja auch schon propagiert werden, die einfach aufgrund einer kurzen Idee alles machen. Ich glaube, es kommt immer noch darauf an, dass man es richtig formuliert. Also da sind wir eben genau wieder bei requirements engineer,
Anforderungen. Also das einfach den Systemen bewusst zu machen, was man will und dann halt mit dem gesunden Menschen dann drüber schauen. Kann ja auch letztendlich alle Filme, die es irgendwie in dieser Branche, also nicht jetzt IT-Branche, sondern in Zukunftsbranche mit künstlicher Intelligenz geht. Es ist immer dieser gesunde Menschenverstand, der da nochmal drüber muss. Aber dazu muss ich halt Know-how aufbauen. Also das wird, glaube ich, immer sein. Ich weiß
nicht, wie wir es in Zukunft machen werden, dass wir das Know-how bekommen. Also ich hatte auf einer Konferenz vor letztem, letztes Jahr, kam da mal die Diskussion, naja, heute gibt es Compiler. Wer weiß denn, wie ein Compiler funktioniert von uns? Keiner. Aber faktisch ist er da. Irgendwer hat ihn auch mal programmiert, irgendwer entwickelt ihn auch fort und das Ding funktioniert. Es hinterfragt keiner mehr, wie es geht. Aber jeder verlässt sich darauf, dass es das Richtige macht.
Und so was kann ich mir durchaus vorstellen, dass es halt auch da kommt. Die Frage ist nur, wie weit sollten wir, und jetzt wird es dann aber philosophisch und ethisch, wie weit sollten wir das Thema zulassen? Also da gibt es, glaube ich, Leute, die sich viel mehr damit beschäftigen. Ich habe auch morgen für den Vortrag schon mal gleich als Spoiler dann voraus gesagt, ich kümmere mich nicht um Ethik, ich kümmere mich nicht um solche Themen. Das ist ein Fass,
das ist riesengroß, da wage ich mich nicht ran. Aber abgesehen davon sind halt ganz viele Aspekte, die wir uns anschauen müssen, die in fünf Jahren mit Sicherheit spannend sind. Also ich nehme die Einladung jetzt schon gerne an für fünf Jahre. Ich bin mal gespannt, was da rauskommt. Genau. Super. Michael, vielen lieben Dank hier für die Rede und Antwort am German Testing Day. Ich wünsche dir noch ganz viel Spaß hier auf der Konferenz, heute beim Abendevent und natürlich
morgen bei deinem Vortrag auch noch. Vielen Dank. Danke. Tschau. Tschüss. [MUSIK]