Ja hallo ihr Freunde des gepflegten Software-Testings und der Software-Qualität. Ich freue mich, dass ihr hier seid zu einer neuen Folge vom Podcast Software-Testing. Ein bisschen anderes Intro heute, aber ich gedacht, wir machen jetzt mal eine Spezialfolge. Einfach mal ganz locker vloggig. Und ich habe euch ja in den letzten Monaten immer wieder dazu aufgerufen, mir Feedback zu geben, zum Podcast, zu Fragen, die euch beschäftigen, die aus der täglichen Arbeit kommen oder auch zu
mir oder zu Speakern, Tipps, Tricks und Tricks, alles mir zu schicken. Und das habe ich jetzt mal ein bisschen aufbereitet und habe gedacht, das passt doch jetzt gut zu diesem Sommerstart. Wenn der Sommer jetzt mal endlich da ist, mal auf ein paar von diesen Fragen einzugehen. Und einige kamen doppelt und ähnlich und die habe ich dann ein bisschen zusammengefasst und die
möchte ich jetzt gerne mal mit euch durchgehen. Und hier auch gleich nochmal der Aufruf, wenn ihr weiter Fragen habt, wenn ihr tolle Speaker kennt, tolle Themen, die vorgestellt werden müssen hier im Podcast, die sich rund um Software-Qualität, Software-Entwicklung, Software-Testing drehen, dann immer her damit. Und so würde ich sagen, ich nehme noch einen Schluck und dann starten wir da. Hurtig mal hinein. Die Laura, die hat mir geschrieben, vielen Dank für die vielen
unterschiedlichen Themen im Podcast. Meine Frage ist, welche Trends im Bereich Software-Testing sollten Tester im Auge behalten? Ja, da gibt es natürlich eine ganze Menge gerade, die wir uns anschauen müssen als Tester. Das eine ist natürlich das große Thema KI und das ist natürlich jetzt in aller Munde. Da haben wir die großen zwei Punkte. Zum einen, wie testen wir überhaupt KI und zum anderen, wie kann uns KI beim Testen unterstützen? Und ich sage jetzt sagen, wie man KI testet,
das ist auch noch eine recht junge Profession. Es gibt ja dazu zum Beispiel das tolle Buch hier von Röttger und Runze "Basiswissen KI testen". Da könnt ihr mal reinschauen. Die war noch bei mir im Podcast. Da kann man mal ein paar Folgen zurückgehen. Da seht ihr diese Folge. Und für mich ist so hängengeblieben aus dem ganzen Kontext immer eine große Frage, nämlich die wir uns eigentlich in der Softwareentwicklung immer stellen müssen. Was bedeutet eigentlich für
uns Qualität? Und gerade wenn wir jetzt eine KI testen wollen, da müssen wir natürlich schauen, was heißt denn eigentlich Qualität in dem Sinne dort? Das klassische Verständnis, vielleicht dass wir Tester mitbringen, so hier Testfall rein, das kommt raus, klappt da vielleicht nicht, brauchen wir andere Methoden, statistische Methoden, alles Mögliche, die wir uns da anschauen. Und das ist halt auch ein sehr junges Feld. Mit klassischer Software, da konnten wir uns
jetzt jahrzehntelang darauf einstellen, wie wir die testen. Bei KI, da müssen wir jetzt mal schauen, wie wir damit umgehen. Und es gibt ja gute Ansätze. Und ich denke, da sollte man auf jeden Fall als Tester ein Auge drauf halten. Man muss jetzt kein KI-Experte sein. Man wird sich natürlich gerade gut bezahlt, wenn du so einen Job hast. Aber ganz generell so ein bisschen eine Idee davon haben sollte man auf jeden Fall, wenn man im Bereich Softwareentwicklung tätig ist. Ich
glaube, das kann jetzt gerade nicht schaden. Und zum anderen, das KI-Nutzen. Wie nutzt du es für dich für die Testfälle? Hast du dir selber schon irgendwas zusammengepromptet? Gibt es irgendwelche
Tools, die du nutzen kannst, die dir da helfen, KI mitzunutzen? Da möchte ich auch immer so gerne mal einen kleinen Gedanken mit reingeben, weil ich wurde in den letzten Wochen sehr häufig eingeladen zu Workshops in Unternehmen, wo ich gesagt habe, ja komm Richi, hilf uns mal hier, wir wollen jetzt KI nutzen für Testing, weil da ist jetzt gerade Budget da, weil wir jetzt einen KI-Budgettopf haben. Und was kann man denn damit tun? Und im Endeffekt, ich schaue da gerne mal von
draußen drauf, KI ist halt ein Tool und das können wir irgendwie nutzen. Aber die Frage ist, was wollen wir denn eigentlich für ein Problem damit lösen? Wenn es ein Problem gibt, das ich mit KI lösen kann, dann her damit, dann wollen wir das auch machen. Nur sich da jetzt irgendwelche Tools zu installieren und die bringen gar keinen Nutzen, bringt gar nichts. Also ist natürlich auch schön mit Copilot und solchen Sachen rumzuspielen, das hilft mir jetzt beim
Entwickeln und da bin ich besser und werde schneller dadurch, dann ist es okay. Wenn das im Endeffekt gar nichts bringt und diese Bewertung müssen wir einfach immer wieder machen bei den Werkzeugen, die wir verwenden, dann kann man es auch lassen. Und ich denke genauso im Testing, da müssen wir einfach darauf schauen, was kann uns KI da wirklich an Problemen auch lösen? Kann man vielleicht besser die Anforderungen verstehen oder die vollständiger
machen? Können wir irgendwelche Spezifikationen damit vielleicht besser abarbeiten? Können wir bessere Testfälle erstellen? Können wir was in Richtung Automatisierung machen? Dann ist das alles legitim. Also da sollten wir auf jeden Fall drauf schauen. Damit geht natürlich einher. Zweites Thema, was für Tester auch auf jeden Fall relevant ist in der nächsten Zeit und
eh schon immer das Thema Testdaten. Das ist natürlich jetzt auch unter KI-Gesichtspunkten mal quasi neu zu sehen, aber Testdatenmanagement, da tun sich viele Unternehmen auch recht schwer. Gibt es auch ein paar Lösungsansätze dafür, auch ein paar Ideen dazu, hatten wir auch schon hier im Podcast, aber ich glaube, das Thema wird uns in Zukunft noch mehr beschäftigen. Also Testdatenspezies
werden auf jeden Fall gut noch gebraucht in den nächsten Jahren. Und was auch noch ein bisschen mehr dazu kommt, ist, ich glaube, das ist so stark durch die jetzt auch durch die ganzen regulatorischen Vorgaben in den nächsten Jahren gegeben, Cyber Resilience Act, Usability, Barrierefreiheitsplan, was war nächstes Jahr, dass wir uns einfach auch dieses ganze Thema Qualität
noch mehr ganzheitlicher anschauen müssen. Ich bin ja eh der Meinung, die Zeit ist vorbei, dass wir hier quasi, da sitzt der Entwickler und da sitzt der Tester und selbst wenn die agil in einem Team sitzen und sich dann, dann schiebt der eine das rüber und der andere testet, so funktioniert es ja heute nicht mehr. Das muss ja quasi viel integraler auch gedacht werden. Und
das trifft natürlich auch die ganzen nicht-funktionalen Tests. Wenn ich jetzt am Schluss einen Pen-Test mache oder einen Performance-Test oder einen Usability-Test und dann finde ich da irgendwelche Probleme, wissen wir ja alle, dann kann ich mal wieder das große Rad zurückdrehen, muss vielleicht anschauen, ist mein Framework überhaupt das richtige, was habe ich denn, mache ich denn gerade in meiner Architektur, also all diese Dinge,
die dann quasi ein großes Fass aufmachen. Und ich glaube, dieser Gedanke, auch genau diese nicht-funktionalen Themen bei Design zu denken, das heißt schon vorne mitzudenken, was hat denn das für Auswirkungen, das bleibt uns nicht erspart in Zukunft. Und da können wir als Tester natürlich noch viel mehr im Blick auch drauf helfen. Und das betrifft nicht nur diese externen Qualitätsmerkmale nach außen, sondern auch die nach innen. Was bedeutet das für unsere
Wartbarkeit? Wie können wir die vielleicht schaffen? Weil wir wollen natürlich auch die Software weiterentwickeln. Wir haben ja jetzt schon in vielen Unternehmen Probleme, dass wir 10, 20, 30 Jahre alte Software da haben, die irgendwie noch betrieben wird und technische Schuldenberge da hin und her geschoben werden, ohne wirklich eine Lösung. Und das wäre natürlich
schön, wenn wir das zumindest für zukünftige Software auch heilen könnten. Also das sind, glaube ich, Trends, wo man als Tester auf jeden Fall hinschauen sollte in die Zukunft und sich da so ein bisschen aufschlauen. Also man muss jetzt nicht ausrasten deswegen, aber sollte sich da auf jeden Fall mal ein bisschen beschäftigen. Ja, dann schreibt der Michael, ich höre deinen Podcast jede Woche beim Joggen, das finde ich ausgezeichnet. Also ich kriege immer wieder das
Feedback beim Joggen, beim Kochen interessanterweise und beim Autofahren. Also da passt der Podcast anscheinend ganz gut hin. Würde mich auch interessieren, wo hört ihr den Podcast? Schreibt mir das mal. Was mich mal interessieren würde, was sind die häufigsten Fehler, die du bei Unternehmen in Bezug auf Software-Testing beobachtest? Ja, also es gibt so ein paar
Klassiker. Das eine ist, so gar keine Strategie zu haben. Also ich sage mal, man muss ja jetzt nicht ein 40-seitiges Testkonzept schreiben, aber man sollte sich schon mal Gedanken machen, was sind denn meine Teststufen, meine Testarten? Was mache ich in Richtung Testautomatisierung? Wie sieht es mit statischer Analyse aus, mit Reviews und welche Testmethoden nutze ich? So, da hat man mal so eine grobe Checkliste, wo man für jedes Ding mal entscheiden kann, ja, brauche ich das
jetzt gerade bei mir im Projekt oder brauche ich es nicht? Nicht jedes Projekt braucht einen allumfänglichen Integrationstest. Nicht jedes braucht vielleicht einen vollautomatisierten UI-Test. Ich kann die Dinge auch irgendwie anders lösen, aber ich muss mir auch mal Gedanken dazu machen. Und diese Gedanken dazu, auch mit einem risikobasierten Blick da drauf, ja, das fehlt halt häufig. Ich meine, für mich gut, ich komme da meistens hin, wenn es irgendwo ein bisschen
auch im Argen ist, aber das ist es einfach nicht. Und gerade was so die Testmethoden angeht, ich sehe sehr häufig, es gibt sehr viele Testfälle in einem Projekt, sei es Unit-Tests oder System-Tests oder fachliche sonstige Tests, auch eine ganze Menge, die vielleicht sogar automatisiert ist, aber die Qualität der Tests, also da kann man schon noch besser werden. Also wie sieht denn eigentlich ein guter Testfall aus? Ich glaube, wir haben da ein bisschen das Problem, dass wir bei
Unit-Tests immer noch gerne diesen Abdeckungsmaßen nachlaufen. Das heißt, 80 Prozent Codeabdeckung ist ganz wichtig, aber ob ich vielleicht auch weitere Testfälle mit anderen Werten brauche, die vielleicht gar nicht meine Abdeckung erhöhen, aber einfach bessere Testfälle, werden diese Gedanken fehlen dann manchmal. Und ich glaube, das ist auch schon wieder das Thema, wie können die ganzen Protagonisten in einem Team auch denn zusammenspielen und gemeinsam ihr Wissen
nutzen, um hier gute Tests zu schreiben. Dann natürlich das Thema der Quick Wins. Ich habe es hier schon ein paar Mal gesagt, auch in dem Podcast, statische Analyse ist für mich ein No-Brainer.
Die Dinge einfach, diese Tools zu nutzen. Ich meine, das ist ein Automat. Wir wollen jetzt überall KI verwenden, aber wir haben hier mit diesen Tools seit Jahren einen quasi einfertigen, automatischen Reviewer für unseren Code, für unsere Dokumente, die Input liefern, mit denen wir arbeiten können, um technische Schulden abzubauen, um diesen ganzen Wumms auch besser zu machen. Und die Ausrede, ja, da wirft er aber so viel raus, der findet den Fehler.
Also natürlich, da muss man dann irgendwie mal auch ran und das Ganze auch bearbeiten, aber da kann man sich auch eine Strategie überlegen, wo das vielleicht nicht so schmerzhaft ist. Man muss sich da jetzt nicht unbedingt ein Ja darin verkriechen und nur diese Fehler beheben. Also man kann das auch neben dem Tagesgeschäft ganz gut oder besser gesagt da rein integrieren.
Ja, was haben wir noch an Fragen? Hier die Yvonne schreibt, mit welchen Fähigkeiten und Kenntnissen sollten Software-Tester sich heute ausstatten, um auf die Zukunft eingestellt zu sein? Naja, das hat man oben schon ein bisschen im Fachlichen, aber ich denke, gerade als qualitätsbewusster Mensch, softwarequalitätsbewusster Mensch, wir werden in den Projekten immer mehr
dahin kommen, dass das Team auch besser miteinander funktionieren muss. Sag mal, die erste Idee von Agilität unter Anführungszeichen war ja, wir machen hier zu den, in diese Dev-Teams jetzt auch noch einen Tester rein, der saß dann da rum, hat dann irgendwie am Sprintende dann noch seine, die Software hingeklatscht bekommen und dann da irgendwas
herum getestet und wenn er Fehler gefunden hat, dann ist das Review geplatzt. Also das, das funktioniert ja heute nicht mehr und ich glaube, mit den ganzen Anforderungen, die wir als Team, als Mensch, als Softwareentwickler, als Business-Analyst, als Product-Owner, als Software-Tester, als Testautomatisierer, was auch immer zu tun haben ist, das können wir nur im Team gemeinschaftlich losen und ich glaube, da fängt auch erst dieser
agile Gedanke an, nämlich wie schaffen wir es als Team wirklich Performance auf die Straße zu bringen und gemeinsam an den Dingen zu arbeiten und ich glaube, wenn ich mich, wenn ich mir Teams heute anschaue, die super funktionieren, dann geht es ganz stark auch immer um die ganzen Soft- und Social Skills, das heißt, wie kommuniziere ich miteinander, wie transparent bin ich miteinander, wie kann ich in einem guten Pair-Programming, Pair-Testing zusammen mit den anderen Teilnehmern
im Team einfach gut arbeiten, um Wissen zu verbreiten, um als Tester vielleicht auch anzufangen, ein bisschen Software zu entwickeln und zu coden, als Softwareentwickler nicht zu sagen, ich entwickle und dann teste ich, sondern auch quasi da mehr dieses Qualitätsbewusstsein ins Leben zu lassen und das ist ein Weg, den ein Team geht und jeder Einzelne in dem Team und ich glaube, da müssen wir hin und wir können natürlich von der Testing-Qualitätsseite da auch ganz viel
Einfluss drauf nehmen, dass das gut funktioniert, denn was ich in meiner Historie gelernt habe, der Software-Tester früher war auch immer der, der häufig, der sehr viel Ahnung über das ganze Produkt hatte, weil er musste und der auch alle Leute kannte, weil er immer alle Fragen musste,
wie denn irgendwas zu funktionieren hat. Also war er sehr stark so in diesem Spannungsfeld von allen, vom Projektleiter, vom Product Owner, was auch immer das da für Rollen gibt, der Tester war immer da so in diesem Netz irgendwo drinnen und ich glaube, das prädestiniert quasi uns in der Rolle auch, da auch Einfluss drauf zu nehmen, die Qualität ganzheitlich zu steigern und mal aus diesem Silo des Testings da auch rauszugehen und sagen, Qualität im Projekt,
das fängt vorne irgendwo an bei den Anforderungen und nicht nur darum, dass ich die jetzt ein bisschen review und sage, die müssen besser sein, so was kann ich konstruktiv da auch wirklich beitragen, mit meinem Wissen auch die Dinge schon zu verbessern, den Entwicklern zu helfen, ihre Prüfungen in der IDE anzupassen oder dann gleiche, ähnliche Code-Basis zu schaffen. Ich glaube, das ist so ein gemeinsamer Weg, den wir künftig gehen müssen. Da geht es einfach viel
mehr um die Skills, die ich mittlerweile habe, als jetzt um die Rolle, die ich inne habe. Und ich glaube, in die Richtung, da können wir auch alle ein bisschen lernen, dieses kooperative Zusammenarbeiten, die Transparenz zu schaffen, sich auf Experimente einzulassen und nicht gleich zu sagen, die funktioniert aber nicht, haben wir noch nie so gemacht, diesen berühmten Dreiklang,
den es da gibt. Also da glaube ich, da kann man machen, weil ich glaube schon, dass wir künftig einfach auch Qualität viel ganzheitlicher denken müssen und so gesehen die Profession vielleicht des Testings gar nicht mehr so im Vordergrund ist, sondern es geht einfach im Endeffekt, einen geilen Scheiß zu machen, eine coole Software rauszubringen als Team und da gehört halt Qualität
dazu, Haken dran und jeder bringt seinen Beitrag dazu. Also so gesehen ist da glaube ich schon eine Entwicklung drinnen und da kann man als Tester natürlich dann auch mal schauen, wie sind denn meine Softskills, wie kommuniziere ich denn, bin ich denn eher so der Elfenbeinkommunizierer und schicke da meine Fehler-Tickets im Jira schön hin und her und versuche das da alles zu dokumentieren oder gehe ich auch mal mit den Kollegen einfach mal Kaffee trinken und sage, komm, schauen wir uns
das mal gemeinsam schnell an und können wir das mal besprechen, kannst du mir das erklären und ich zeige dir da, was mir da aufgefallen ist. Also da kann man natürlich auch viel schöner ran. Aber ich glaube, da können wir für die Zukunft noch besser aufstellen. Ja, dann hat mir der Andreas
geschrieben, welche Geschichte aus deiner Praxis hat dich besonders geprägt? Ja, die Frage habe ich mir ein bisschen überlegen, weil ich habe sehr viele schöne Geschichten, da könnte ich so, könnte ich mal ein Testing-Geschichtenbuch schreiben, aber ich weiß nicht, ob das so spannend ist, aber mich würde es interessieren, was mir da noch so einfällt. Ja, also ich erinnere mich an ein Team, das war echt so ein Paradebeispiel, das war aus der Finanzbranche ein Team und die haben
angefangen, wir machen jetzt agil. Und da war schon mal die erste Frage, was machen wir jetzt mit dem Test-Team? Und dann hat man halt so einen Tester genommen und den da mit reingepackt und der saß dann da auch so seinen Sprint rum und hat dann versucht Testfälle zu schreiben in so einem alten, großen Test-Management-Tool, hat dann seine manuellen Testfälle geschrieben, parallel, also während die Entwickler entwickelt haben, die haben so eine User-Story nach der anderen
durchgeübt und der hat versucht, immer irgendwie die Testfälle zu schreiben. Das hat natürlich alles vorne und hinten überhaupt nicht funktioniert und wir haben es dann geschafft, über Retrospektiven und über auch die gemeinsame Arbeit, das Team immer mehr in mehr Kommunikation in den Austausch zu bringen und ich habe das so leicht begleitet als Quality-Coach,
habe immer versucht, da auch ein paar Impulse reinzugeben. Und aus diesem "Jeder für sich macht so sein agiles Ding" wurde da immer mehr Team draus und man hat so richtig gemerkt, wie es auf einmal was gebracht hat, wo man gemerkt hat, dass auf einmal ein Softwareentwickler im Team auch über Qualität nachdenkt, überlegt, wie könnte man denn das später automatisieren oder warum muss das eigentlich erst später automatisiert werden, warum kann ich das nicht gleich automatisieren,
warum kann ich das nicht gleich ich umsetzen. Ich hole mal hier jemanden mit Testkompetenz,
den ich ja habe im Team dazu und wir setzen das um. Und der Tester, der aus der reinen Fachlichkeit kam, der dann da so mit reingerutscht ist, der hat sich angefangen, mit der ganzen Technik auseinanderzusetzen und hat quasi angefangen, hier auch zu skripten, die Testautomatisierung mit aufzubauen, auch auf den sich die Unit-Tests anzuschauen und da Feedback zu geben, wo man die vielleicht besser machen könnte, wo man testmethodisch noch ein bisschen rangehen könnte.
Und das lief, das hat sich so schön entwickelt über die Monate und eines Tages kam ich in das Büro und das war ein echter Highlight, da habe ich einen Softwareentwickler und diesen Tester so beim Pair-Testing-Programming entdeckt. Die saßen beide wirklich an einem Rechner, selbst organisiert, also ich habe die da nicht angeleitet dazu, also die haben das dann wirklich dann für sich entschieden, mal komm, wir machen mal jetzt hier einen Vormittag zusammen, wo wir
uns die Themen anschauen. Und das fand ich mega, weil man auch gemerkt hat, dass es allen auf einmal viel mehr Spaß macht, dass diese Trennung nicht mehr so da ist, dass keiner dem anderen was Böses will. Das war ein richtig schönes Erlebnis, das war sicher eins der Highlights, wo ich mir gedacht habe, ja, es ist Licht am Ende des Tunnels und wir können es auch besser, als wir es heute einfach tun. Ja, der Andreas, der fragt noch, mich würde mal ganz was Persönliches interessieren, was macht dir
im Job am meisten Spaß, wie sieht denn dein Alltag aus? Ja, das ist ganz spannend, weil ich wurde letztens, als ich mit dem Podcast auf einer Konferenz war, da kam ich so mit zwei, drei Leuten ins Gespräch und die haben gedacht, der Podcast ist mein Job. Und das habe ich gesagt, naja, nicht ganz, Podcast, das macht mir total viel Spaß und Freude, euch hier die ganzen Experten vorzustellen und ganz viele Interviews zu führen und Wissen in die Welt zu bekommen, um das mit
wie einfach im Endeffekt bessere Qualität und bessere Software schreiben. Es geht ja, wie habt ihr gemerkt, im Podcast auch weit über das Thema Testing raus, wir gucken uns ja auch ganz andere Sachen an. Also ich würde jetzt mal sagen, mittlerweile ist es eher ein Software Engineering Podcast. Aber in dem Gespräch kam eben für mich raus, ja, nee, also es ist die Wahrnehmung
vielleicht, dass ich den Podcast hauptberuflich mache, aber nein, das ist ein Hobby von mir. Und ich bin in meiner Funktion als Berater oder als Coach und Mentor sehr stark in Unternehmen drinnen, die ich begleite, schon seit vielen Jahren. Ich mache ja Software Testing, Software Qualität seit,
weiß ich nicht, 25 Jahren jetzt. Und ich mag es einfach, und das ist das, was mir so Freude macht, einfach ein Team zu begleiten, so wie ich das vorher erzählt habe, hin, wie können die das denn besser machen, wie kriegen die denn das hin, dass sie ihre Testprozesse gut aufsetzen,
dass sie die Entwicklungsprozesse gut aufsetzen, dass wir so ein CI/CD gut zum Laufen kriegen. Und das ganze Machen ist schon mal schön, aber wenn es dann noch so Klick macht, wenn du dann quasi ein Daily hast oder irgendeine Retro oder ein Review, wo du merkst, ja, jetzt ist der Knoten aufgegangen und ich das irgendwie unterstützen konnte, das gibt mir total Spaß und Freude. Und das ist auch für mich der Grund, warum ich meinen beruflichen Ansatz auch
ein bisschen verändert habe. Ich war viele Jahre der klassische Fachberater, bin da hingekommen und gesagt, so, ich erzähle euch jetzt, wie es funktioniert. Und die haben alle gesagt, kannst mich gern haben, ich höre eh nicht auf dich. Und dann habe ich überlegt, ja,
das kann ja so nicht sein. Und dann ist natürlich auch eher dieser coachende Charakter reinkommen, dieses Mentoring, mehr zuzuhören, mehr zu schauen, wo kann ich Impulse reingeben, wo kann ich mit Fragen vielleicht auch Themen adressieren und ins Team mit hineinbekommen.
Und das ist im Prinzip das, was ich heute auch ganz stark mache. Das heißt, ich begleite Teams meistens nicht so, dass ich fulltime daneben sitze und Händchen halte, sondern dass wir in der Woche ein, zwei Termine haben, wo wir einfach zusammenkommen, schauen, was steht gerade an diesen Themen an, wo kann ich einen Impuls reingeben, wo kann man vielleicht eine Verbesserung aufbauen oder sowas und das dann über die Woche auch wieder laufen lasse und dann da einfach begleite und
wir uns so quasi von Woche zu Woche hochschrauben. Ich nenne das dann Mentoring, weil ich natürlich schon fachlichen Input mit reingebe, aber eben nicht nur hier irgendwie den schlauen Bär mache, sondern einfach auch schaue, was ist denn schon da, was kann man nutzen, wo ist vor allem ein
sinnvoller Hebel. Unter uns, es gibt natürlich viele Managers, die sagen, wir müssen jetzt alle Tests oder Automatisierung machen, aber das ist manchmal gar nicht der Punkt, wo man wirklich dem Team so gut helfen kann, wenn man sagt, okay, jetzt kaufen wir noch vielleicht ein tolles Tool oder nehmen uns irgendeinen Open Source und das ist jetzt so, damit ist die Welt heile. Manchmal sind die Probleme ganz andere. Vielleicht auch noch mal der Punkt zurück zur
KI von vorher. Also das kann schon viele Sachen lösen, nur bei den Workshops, wo ich da auch gesagt habe, die Probleme bei den Testteams oder bei den Entwicklungsteams, die stecken meistens ganz woanders und da stecken viele noch eher in anderen Problemen, als dass da jetzt KI eine Lösung sein könnte. Eher macht das vielleicht noch schlimmer, vielleicht das noch als Gedanke
für euch mit. Ja und das Zweite, was mir total viel Spaß macht, was ich selber auch in meiner Laufbahn total genossen habe und jetzt auch wieder mit anbiete, sind sogenannte Mastermind-Gruppen. Was bedeutet das? Quasi eine feste Gruppe von fünf, sechs Menschen, die quasi weiterkommen
wollen in dem Bereich. Also zum Beispiel jetzt ein Testmanager oder ein Freelancer, der im Bereich Testautomatisierung ist oder ein Tester, die so die täglichen Herausforderungen haben und wirklich hier so einen vertrauten Kreis zu schaffen, wo man sich alle zwei Wochen bis vier Wochen mal trifft, quasi dann über einen längeren Zeitraum zu einem fixen Zeitpunkt, sich da zusammenkommt und sehr strukturiert die Themen durchgeht, jeder so seine Herausforderungen auch
in die Gruppe reingibt und man gemeinsam Lösungen sucht. Das erfordert natürlich ein unfassbares Maß an Vertrauen und dementsprechend NDAs und diese ganzen Dinge, weil man da schon natürlich auch sehr hart mit seinen Themen reingehen kann und das sind ganz unterschiedliche Themen, die in
diesen Gruppen dann rauskommen. Zum einen kommt man irgendwie fachlich nicht vielleicht weiter mit der ganzen Testmethodik, andere haben wieder ein Problem, dass sie vielleicht persönlich unter einfach Burnout auch leiden oder echt total gestresst sind und nicht wissen, wie sie das
kommunizieren können und so. Aber diese Gruppe bleibt fix über drei bis sechs Monate, die meisten bestehen dann sogar noch länger und man unterstützt sich gegenseitig auch im Vorwärtskommen und das ist etwas, was mir total viel Freude macht, gerade in dem Umfeld von Softwarequalität und Softwareentwicklung hier noch einmal Menschen zusammenzubringen, die einfach auch gut passen und wo man sagen kann, okay, da kann man gemeinsam auch auf dem Weg weitergehen. Das sind die Sachen, die mir Spaß
machen. Ich arbeite einfach gern mit Menschen und natürlich hier der Podcast und ich mache auch rundherum noch etwas in der Community und vielleicht ist da jetzt auch noch der Aufruf, ihr wisst ja vielleicht, ich bin beim German Testing Magazine in der Redaktion, wir freuen uns auch immer dort über ganz tolle Beiträge, über Abstracts, die wir veröffentlichen können.
Das heißt, wenn du mal einen Artikel schreiben willst, dann schick den da noch einfach mal rüber, wir schauen mal, ob wir den da irgendwo unterbringen, auch thematisch, wenn es passt, Antworten auf die Call for Paper, die es da gibt und zudem bin ich ja im Board vom German Testing Day. Das heißt, auch dort freuen wir uns immer über großartige Einreichungen, spannende Geschichten, Erfahrungen, die ihr in Projekten macht und natürlich auch hier für den Podcast.
Also, ich glaube, zum dritten Mal jetzt hier der Aufruf, wenn ihr spannende Themen, es ist nicht so, dass mein Backlog nicht voll ist. Also, ich habe Folgen und Anfragen, sehr viele, aber ich möchte natürlich auch etwas bringen, was euch auch einen Wert hat und da geht es mir natürlich auch ganz darum, dass es Erfahrungsgeschichten sind, dass vielleicht auch mal ein bisschen technischere Sachen sind. Solche Sachen würde mich noch interessieren,
hier auch zu bringen. Das heißt, kommt doch gerne auf mich zu, schreibt mir doch einfach mal an podcast@software-testing.fm und schreibt mir da eure Fragen, eure Wünsche, Anregungen oder was ihr sonst noch wollt, nur dadurch kann ich besser werden. "Feedback ist das Frühstück der Champions", hat mir mal ein Mentor gesagt und so gesehen brauche ich euer Feedback,
um auch den Podcast weiter gestalten zu können. Und vielleicht auch, wenn ihr so Fragen habt, so wie heute hier, wo ihr sagt, das ist was Konkretes, was ich vielleicht mal in dem Podcast beantwortet haben möchte, weil das vielleicht andere auch noch interessieren kann, dann schreibt mir doch auch einfach diese Fragen und ich schaue mal, ich sammle das dann immer so ein bisschen zusammen. Manchmal schreibe ich auch direkt eine Antwort, wenn mir was einfällt und dann nehme ich
es dann trotzdem noch hier auf. Freue ich mich sehr, wenn ihr mir schreibt. Ja, und mit der nächsten Folge geht es wieder ganz normal weiter. Ich weiß gerade nicht, was die nächste ist, aber sie wird genial. Ja, habt viel Spaß, eine schöne Woche und bis bald, euer Host Ritschi. Ciao, ciao! *Musik*