Software Testing & Qualität - Testautomatisierung, KI & Agilität

Software Testing & Qualität - Testautomatisierung, KI & Agilität

By Richard Seidl - Experte für Software-Entwicklung und TestautomatisierungBusinessTechnologyEducationHow ToManagement
Download on the App Store

Software Testing & Qualität - Testautomatisierung, KI & Agilität episodes

  • Kubernetes-Lasttests: Erst Fragen sammeln, dann messen - Stephan Schwarz
    Jedes System hat ein Bottleneck. Die Frage ist, ob du es kennst oder dein Kunde es findet

    Ein Lasttest ohne Frage dahinter ist verschwendete Lebenszeit, sagt Stephan Schwarz, und genau darüber spreche ich mit ihm: Lasttests in Kubernetes-Umgebungen, die eine Risikofrage beantworten und eine Entscheidung vorbereiten. Stephan erklärt, warum Dev, Ops und QA dafür an einen Tisch müssen: Kein Team allein weiß, wie sich die Software unter Last verhält. Wir reden über Laborsetups, in denen Autoscaling und Load Balancing erst mal zurückgefahren werden, über Lastgeneratoren wie k6 oder Locust und über seinen ersten Test 2018, bei dem der limitierende Faktor sein eigenes Notebook war. Und darüber, dass jedes System ein Bottleneck hat, auch wenn es noch keiner gefunden hat.

    „Wenn ich nicht teste mein Produkt, dann macht es mein Kunde.“ - Stephan Schwarz

    Stephan Schwarz ist Senior DevOps Consultant bei der iits-consulting GmbH und beschäftigt sich schwerpunktmäßig mit der Entwicklung und dem Betrieb Kubernetes-basierter Plattformen.

    Dabei interessiert ihn nicht nur die technische Umsetzung, sondern vor allem die Frage, wie Plattformen, Anwendungen und Prozesse gestaltet sein müssen, damit sie zu den Menschen passen, die sie entwickeln, nutzen und betreiben. Themen wie Performance- und Lasttests betrachtet er deshalb nicht als isolierte Aufgabe eines Test- oder Betriebsteams, sondern als Teil gemeinsamer Verantwortung für zuverlässige Software.

    Sein Ziel ist es, Nachhaltigkeit und Pragmatismus miteinander zu verbinden und Lösungen zu bauen, die langfristig funktionieren – ohne dass ihre Nutzer, Entwickler oder Betreiber anschließend therapeutische Unterstützung brauchen.

    Highlights:

    • Ein Lasttest ohne vorher formulierte Frage ist laut Stephan Schwarz verschwendete Lebenszeit, weil am Ende keine Entscheidung über ein Risiko daraus folgt.
    • In jedem System steckt ein Bottleneck, und nach dem Beheben wartet das nächste; Lasttests in Kubernetes-Umgebungen zeigen, welches gerade limitiert.
    • CPU und RAM sind selten die Ursache von Performance-Problemen in Kubernetes, häufiger fehlerhaftes Caching, ein externer OIDC-Provider, Datenbanken, Session-Handling oder Firewalls.
    • Viele Teams setzen Requests und Limits für ihre Container gar nicht oder nicht valide, weil ohne Lasttest niemand weiß, wie sich die Software unter Last verhält.
    • Lasttests in der CI/CD-Pipeline sind die Kür. Für infrastrukturlastige Projekte reicht zunächst ein Ende-zu-Ende-Smoke-Test, der Latenzmetriken als Testergebnis mitschreibt.
    • Weitere Links zur Episode:

      • Sessionize-Speakerprofil
      • Medium-Blog
      • iits-consulting GmbH
      • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

        Danke an die Community-Partner des Podcasts:

        25 min
      • Hardware-in-the-Loop: Kernel-Test am echten Gerät - Markus Napierkowski
        Wer die Testmaschine reserviert hat, dem funkt kein Kollege mehr dazwischen

        Ob ein Kernel auf jeder CPU-Generation läuft, zeigt erst die echte Hardware. Genau dafür hat Markus Napierkowski mit seinem Team ein Hardware-in-the-Loop-Framework gebaut, das seit zwei Monaten Open Source auf GitHub liegt, und darüber spreche ich mit ihm auf der TACON in Leipzig. Entwickler und CI reservieren sich dieselben Testmaschinen über eine REST API, sauber initialisiert, als stünden sie neben dem Schreibtisch. An jeder Maschine hängt ein Raspberry Pi für USB, HDMI und serielle Konsole, eine neue Hardware ist auf der Softwareseite fünf Zeilen Code im Nix-Repository. Mich hat vor allem gefreut, dass hier jemand ein über Jahre gewachsenes Werkzeug zurück an die Community gibt.

        „Ich kann mir als Entwickler jetzt eine Hardware reservieren und sie benutzen, als würde sie neben meinem Tisch stehen.“ - Markus Napierkowski

        Markus Napierkowski hat Informatik in Dresden studiert und ist seit neun Jahren bei Cyberus Technology tätig. Angefangen hat er als Software Engineer mit der Entwicklung von Produkten auf Basis von Microkernels. Seitdem hat er an unterschiedlichsten Themen gearbeitet, von Virtualisierungstechnologie in Rust und Performance-Benchmarks über den Aufbau der internen Testautomatisierungs-Infrastruktur bis hin zur Beratung rund um Nix, NixOS und moderne Entwicklungsprozesse.

        Heute ist Markus Head of Test Automation and CI bei Cyberus. Sein Fokus liegt auf Entwicklungsmethodik und Testautomatisierung sowie darauf, Partner bei der Verbesserung und Automatisierung ihres Software Development Lifecycles zu unterstützen.

        Highlights:

        • Auf allen CPU-Generationen muss ein Kernel laufen, deshalb besteht ein plattformspezifisches Image seinen finalen Abnahmetest nur mit Hardware-in-the-Loop auf dem echten Gerät.
        • Der Knackpunkt beim Hardware-in-the-Loop-Test ist der saubere Ausgangszustand, den das Framework herstellt, indem es jedes reservierte Gerät vom USB-Stick mit dem passenden Image bootet.
        • Warten auf die Pipeline nach jedem Push kostet Zeit, darum reservieren Entwickler die Maschine für einen HIL-Test selbst und geben sie danach an die CI zurück.
        • Jede Testmaschine hängt an einem Raspberry Pi für USB-Simulation, HDMI-Ausgabe und serielle Konsole; ein weiteres Gerät kostet softwareseitig etwa fünf Zeilen Code.
        • HIL Testing läuft in der GitLab CI vor oder nach jedem Pull Request mit und liefert jeden Testfall als JUnit XML Artefakt.
        • Weitere Links zur Episode:

          • Cyberus Technology
          • Announcing HWaaS: Open-Source Hardware-in-the-Loop Test Automation
          • HWaaS on GitHub
          • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

            Danke an die Community-Partner des Podcasts:

            21 min
          • Mutation Coverage: Warum volle Abdeckung nichts beweist - Julius Mischok
            Wenn dein Agent die Unit-Tests schreibt, wer prüft dann, ob sie wirklich etwas taugen?

            Was taugen Tests, die 100 Prozent Coverage liefern, aber keine einzige Assertion enthalten? Mit Julius Mischok spreche ich über Mutation Testing: Ein Tool baut absichtlich Fehler in den Produktionscode ein, dreht Bedingungen um oder setzt Rückgabewerte auf Standardwerte und prüft dann, ob die Tests anschlagen. Bleiben sie grün, hat die Mutation überlebt und der Test ist wenig wert. Julius erklärt, warum diese alte Idee gerade jetzt zurückkommt, wo Agenten massenhaft Tests schreiben, die kaum jemand wirklich in der Tiefe liest.

            „Wenn der Test danach noch grün ist, ist es verkehrt, weil dann ist der Test schlecht." - Julius Mischok

            Julius Mischok ist Gründer und Geschäftsführer der Mischok GmbH. Mit seinem Team setzt er Softwareprojekte um, die für die mittelständischen Kunden geschäftskritisch sind. Seine Erfahrung aus mehr als 20 Jahren Softwareentwicklung gibt er als Speaker, Autor von Fachartikeln und als Dozent in der Mischok ACADEMY weiter.

            Highlights:

            • Mutation Testing baut absichtlich Fehler in den Produktionscode ein: Bleibt ein Test danach grün, ist er wertlos, weil er den eingebauten Fehler nicht erkannt hat.
            • Hohe Code Coverage beweist wenig, denn wer alle Assertions entfernt, behält dieselbe Coverage, obwohl die Tests den Code nur noch durchlaufen und nichts mehr prüfen.
            • Mutation Coverage misst den Anteil gekillter Mutationen an allen möglichen Mutationen und liefert damit eine deutlich stärkere Qualitätsmetrik als reine Code Coverage.
            • Mutation Testing verlangt isolierte, stabile Tests, weil das Tool sie in beliebiger Reihenfolge wiederholt ausführt und schon eine Abhängigkeit zwischen Tests das Verfahren scheitern lässt.
            • Agenten, die Unit-Tests schreiben, machen Mutation Testing wieder relevant: Ein wöchentlicher Schedule Job oder ein Lauf zum Sprintende zeigt, ob die generierten Tests tatsächlich Fehler finden.
            • Weitere Links zur Episode:

              • Mischok GmbH auf YouTube
              • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

                Danke an die Community-Partner des Podcasts:

                20 min
              • Wie man Regeln und Skills baut, damit Agenten sich erinnern - Benedikt Stemmildt
                Warum Codex den Code von Claude reviewt und was das mit Qualität zu tun hat

                Wer schreibt noch selbst Code, wenn Agenten das in Minuten erledigen? Mit Benedikt Stemmildt spreche ich darüber, wie Qualität entsteht, wenn nicht mehr Menschen, sondern Agenten die Hauptarbeit am Code übernehmen. Wir reden darüber, warum der entscheidende Unterschied nicht im Modell liegt, sondern darin, ob man am System arbeitet oder im System: Hooks, Regeln, Skills und automatische Architektur-Reviews als Feedbackschleifen, die den Agenten genau so anlernen, wie man einen neuen Kollegen einarbeitet. Benedikt zeigt, wie er Testpyramide, Contract-Tests, Performance-Budgets und Accessibility-Prüfungen direkt in diesen Prozess einbaut, und warum er Codex den Code von Claude reviewen lässt.

                „Ich arbeite viel mehr am System als im System." - Benedikt Stemmildt

                Benedikt Stemmildt ist seit seiner Kindheit Technologe. Seit zwanzig Jahren geht es ihm um eine Sache: dass Entwickler Spaß an ihrer Arbeit haben. Er war Entwickler, Architekt und CIO, bevor er hackers&wizards mitgegründet hat. Dort unterstützt er Engineering-Teams dabei, ihre Software Factory zu bauen. Er ist Program Chair der code.talks in Hamburg und kuratiert die CASE in Berlin, die erste Konferenz für Agentic Software Engineering in Deutschland. Seit 2014 bringt er bei der Hacker School Kindern das Programmieren bei. Im November erscheint sein Buch "Building the Software Factory" bei Packt, zusammen mit Alex Merced.

                Highlights:

                • Wer am System arbeitet statt im System, gibt Agenten Regeln, Hooks und Skills mit auf den Weg, statt jeden generierten Code manuell zu reviewen.
                • Agent-Hooks feuern deterministisch bei bestimmten Events, zum Beispiel nach jeder Frontend-Änderung ein Accessibility-Check, sodass der Agent sofortiges Feedback bekommt, bevor er weitermacht.
                • Nicht-Determinismus in KI-Agenten ist kein reines Risiko: Ein Modell erkennt flaky Tests als Symptom, wo ein deterministischer Test nur "rot" meldet.
                • Zwei Modelle gegeneinander zu nutzen, etwa Claude als Implementierer und Codex als detailgetreuen Reviewer, ergibt qualitativ mehr als jedes Modell allein.
                • Weitere Links zur Episode:

                  • hackers&wizards
                  • CASE Konferenz
                  • code.talks
                  • Buch: Building the Software Factory
                  • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

                    Danke an die Community-Partner des Podcasts:

                    42 min
                  • KI-generierter Code: Qualitätssicherung muss mitwachsen - Benjamin Hummel
                    Mehr Code bedeutet mehr Fehler – warum KI das Qualitätsproblem verschärft

                    Mehr Code, mehr Fehler: Mit Benjamin Hummel spreche ich darüber, was passiert, wenn KI-Agenten Code produzieren schneller als Teams ihn prüfen können. Wir reden über die Illusion, dass Qualitätssicherung ein Bottleneck ist, den man einfach wegoptimiert, und was das für Systeme bedeutet, die in der echten Welt laufen.

                    „Wenn ich doppelt so viel Code schreibe, habe ich statistisch doppelt so viele Fehler." - Benjamin Hummel

                    Dr. Benjamin Hummel hat im Bereich Software Engineering promoviert und zu den Themen Softwarequalität und -wartbarkeit geforscht und publiziert. Seit über 20 Jahren entwickelt er aktiv Methoden und Werkzeuge für die Qualitätsverbesserung von großen Softwaresystemen. Als Mitgründer und CTO der CQSE GmbH verantwortet er seit über 10 Jahren die Entwicklung und den Betrieb der Software-Intelligence-Plattform Teamscale.

                    Highlights:

                    • Wer doppelt so viel Code produziert, hat statistisch doppelt so viele Fehler: KI-gestützte Codegenerierung vergrößert das Qualitätsproblem, statt es zu lösen.
                    • KI-gestützte Code-Reviews liefern laut Studien nur rund 30 Prozent verwertbare Kommentare; der Rest ist irrelevant oder aktiv schädlich für das System.
                    • Ein KI-Review kostet im Vergleich zur statischen Analyse etwa den Faktor 1000 mehr, weil teure Sprachmodelle für jede Prüfung aufgerufen werden müssen.
                    • Ohne gezielte Gegenmaßnahmen erodiert die innere Qualität eines Softwaresystems messbar, wenn KI-Agenten unbeaufsichtigt Code erzeugen und verändern.
                    • Manche Entwickler schreiben einzelne Features bewusst wieder von Hand, um ihre Programmierfähigkeiten nicht durch reines Code-Review zu verlieren.
                    • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

                      Danke an die Community-Partner des Podcasts:

                      36 min
                    • ISTQB-Boards im DACH-Raum: Ein Backoffice für alle drei - Andrea Kränzlein
                      Was Tester von außen betrachtet wirklich auffällig anders machen

                      Wer steckt eigentlich hinter den Testing Boards, wenn die Tester gerade nicht hinschauen? Mit Andrea Kränzlein spreche ich darüber, was es bedeutet, als Backoffice die drei deutschsprachigen ISTQB-Vertretungen am Laufen zu halten, und zwar seit mittlerweile 20 Jahren beim German Testing Board, plus jeweils über einem Jahrzehnt für das Austrian und das Swiss Testing Board. Andrea ist keine Testerin, und gerade das macht ihren Blick auf unsere Community sointeressant. Sie erzählt, wie sie ihr erstes Meeting mit lauter schweigenden Laptopnutzern erlebt hat, was eine Kuhdose mit Timeboxing zu tun hat und wie sich Deutsche, Österreicher und Schweizer in ihrer Boardarbeit liebevoll karikiert unterscheiden. Vielleicht hast Du dann ja Lust, selbst in den Boards mitzuarbeiten :-)

                      „Wir haben alle irgendwann mal angefangen. Und wir haben nicht mit 100% angefangen." - Andrea Kränzlein

                      Andrea Kränzlein gründete vor 30 Jahren OFFICE-MANAGEMENT mit einer klaren Vision: Unternehmen im Office-Bereich professionell zu entlasten und ihnen den Rücken für ihr Kerngeschäft freizuhalten. Das Zauberwort damals wie heute: Outsourcing.

                      Was als klare Idee begann, ist über drei Jahrzehnte zu einem branchenunabhängigen und vielseitigen Leistungsspektrum gewachsen. Dabei verbindet sie langjährige Erfahrung mit einem ausgeprägten Gespür für individuelle Anforderungen, zuverlässige Strukturen und effiziente Lösungen.

                      Ein besonderer Schwerpunkt hat sich im IT-Umfeld entwickelt. Seit mehr als 10 bis hin zu 20 Jahren vertrauen die ISTQB Boards aus Deutschland (GTB), Österreich (ATB) und der Schweiz (STB) auf ihre Unterstützung. Langjährige Geschäftsbeziehungen wie diese stehen für das, was OFFICE-MANAGEMENT auszeichnet: Verlässlichkeit, Kompetenz und nachhaltige Zusammenarbeit.

                      30 Jahre Erfahrung bedeuten eben mehr als nur Zeit: sie bedeuten Vertrauen, gewachsene Partnerschaften und die Fähigkeit, immer genau dort zu unterstützen, wo professionelle Entlastung gebraucht wird.

                      Highlights:

                      • Die drei deutschsprachigen ISTQB-Boards (GTB, ATB, STB) werden ausschließlich von Ehrenamtlichen getragen, die neben einem Vollzeitjob Lehrpläne reviewen, Prüfungsfragen erstellen und den Standard voranbringen.
                      • Ein gemeinsames Backoffice für alle drei DACH-Boards bringt konkrete Synergieeffekte: Akkreditierungen liegen in einer Hand, und aufwändige Abstimmungen zwischen den Boards entfallen.
                      • Neue Mitglieder starten nie bei 100 Prozent Leistung, trotzdem brauchen die Boards dringend jüngere Kräfte, weil einige Positionen seit langer Zeit mit denselben Personen besetzt sind.
                      • Schweiz, Österreich und Deutschland unterscheiden sich im Board-Alltag spürbar: Die Schweiz entscheidet langsam, aber dann verlässlich; Österreich bringt Wiener Kaffeehauscharme mit; Deutschland arbeitet sachlich und detailversessen.
                      • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

                        Danke an die Community-Partner des Podcasts:

                        27 min
                      • Quality Sprint: Wie ein Workshop Qualitätsprobleme löst - Pia Wiedermayer, Roman Kirchmeier
                        Warum die Testabteilung allein nie das Qualitätsproblem lösen wird.

                        Hartnäckige Qualitätsprobleme, an denen Unternehmen seit Jahren kauen, löst man nicht mit einem 15-seitigen Assessment-Dokument. Mit Pia Wiedermayer und Roman Kirchmeier spreche ich über das Format "Quality Sprint": ein kompakter Workshop-Tag, bei dem alle Betroffenen an einem Tisch sitzen, in strukturierten Interviews zuhören, was die anderen wirklich beschäftigt, und am Ende konkrete Schritte definieren, die tatsächlich im eigenen Wirkungsbereich liegen. Was mich dabei besonders beschäftigt: die Interviews finden bewusst in der großen Runde statt, denn oft genug merken alle erst dabei, dass sie eigentlich über dasselbe Problem reden. Wie der Transfer danach klappt und warum das Follow-up mindestens so wichtig ist wie der Workshop-Tag selbst, erzählen Pia und Roman aus ihrer gemeinsamen Erfahrung mit den Quality Elevators.

                        Wir werden nicht die Welt bewegen in einem Tag, aber wir haben dann konkrete drei, vier Steps, die wir mitnehmen." - Pia Wiedermayer, Roman Kirchmeier

                        Pia Wiedermayer arbeitet als Organisationsentwicklerin und IT-Strategin an der Schnittstelle von Produkt und Technik, wobei sie als zertifizierte Business- und Team-Coachin auf tiefgehende systemische Wertearbeit setzt. Roman Kirchmeier bringt über 15 Jahre Erfahrung im Leadership von Qualitätsteams sowie tiefe Expertise in Performance Engineering und Observability ein.

                        Gemeinsam mit drei weiteren Qualitäts-Expert:innen bilden sie das Kollektiv der Quality Elevators und unterstützen Unternehmen dabei, den lähmenden Wartungsmodus zu verlassen und kontinuierliche Lieferfähigkeit zu etablieren. In ihrem kollaborativen Quality Sprint Workshop brechen sie operative Silos zwischen IT, Business und Produkt auf, um in nur einem Tag glasklare Muster offenzulegen und messbare Action Items abzuleiten. Technologie ist für sie kein reiner Selbstzweck, sondern das Fundament für menschlichen und unternehmerischen Erfolg. So vereinen Roman und Pia “Hard Facts” und “Soft Systems” zu einem unschlagbaren Fundament für echte, nachhaltige Software- und Prozessqualität.

                        Highlights:

                        • Ein Quality Sprint funktioniert nur, wenn alle betroffenen Stakeholder am Tisch sitzen: Tester, Entwickler, PO, Betrieb und andere, denn wer fehlt, hält sein Problem für unsichtbar.
                        • Die Interviews im Quality Sprint laufen öffentlich in der Gruppe: Eine Rolle spricht, der Rest hört zu, ohne zu kommentieren, damit Silodenken sichtbar wird, bevor es diskutiert wird.
                        • In 95 Prozent der Fälle decken die gesammelten Pain Points der verschiedenen Rollen denselben Kernschmerz auf, auch wenn jede Gruppe ihn anders benennt.
                        • Konkrete Action Items brauchen eine benannte Person, die sie treibt, und einen festen Nachfolgetermin ein bis zwei Wochen später, sonst verschwinden sie im Alltag.
                        • Weitere Links zur Episode:

                          • Quality Elevators
                          • Itacama
                          • Holistic Quality
                          • Pia Wiedermayer
                          • Selementrix
                          • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

                            Danke an die Community-Partner des Podcasts:

                            27 min
                          • Warum vollständige Coverage keine Fehlerfreiheit garantiert - Roger Butenuth
                            Wenn die Coverage stimmt und der Fehler trotzdem drin steckt

                            Kann man mit 100% Branch Coverage wirklich sicherstellen, dass Code fehlerfrei ist? Mit Roger Butenuth spreche ich darüber, was passiert, wenn man dieses Ziel konsequent verfolgt, und zwar nicht als theoretische Übung, sondern an einem echten, selbst geschriebenen Interpreter für eine Lisp-ähnliche Sprache. Roger erzählt, welche peinlichen Fehler er dabei entdeckt hat, darunter eine handfeste Sicherheitslücke an einer Stelle, die er für zu trivial hielt, um dort einen Bug zu vermuten. Und trotzdem blieb am Ende noch ein Bug übrig, der erst beim Advent of Code auftauchte.

                            „Man macht Fehler an Stellen, wo man denkt, nein, das ist zu trivial, da ist kein Fehler." - Roger Butenuth

                            Dr. Roger Butenuth arbeitet seit 2012 bei der codecentric AG mit den Schwerpunkten Integration und Architektur. Weiterhin interessieren ihn Themen rund um Performance und Parallelität.

                            Highlights:

                            • 100% Branch Coverage schützt nicht vor allen Fehlern: Ein Off-by-One-Fehler in einer kopierten Methode überlebte die vollständige Testabdeckung, weil nur null und ein Schleifendurchlauf getestet wurden, nicht mehrere.
                            • Eine Sicherheitslücke in der Authentifizierung, ein Variablenname statt zwei verglichen, fand Roger Butenuth nur, weil Branch Coverage alle drei Zweige einer zusammengesetzten Bedingung erzwingt, nicht bloß die Zeile.
                            • Testbarkeit entsteht durch Codeänderungen: Dependency Injection und klare Interfaces ermöglichten es, I/O-Fehler und Standard-Output kontrolliert im Test auszulösen, ohne Hardware-Grenzen zu treffen.
                            • Konsequentes Don't Repeat Yourself, erzwungen durch den Testaufwand für kopierte Zweizeiler, verbessert Lesbarkeit und Wartbarkeit, weil Änderungen nur noch an einer Stelle nötig sind.
                            • Eine Coverage-Metrik als Vorgabe funktioniert nicht, weil Entwickler jede messbare Schwelle erfüllen können, ohne sinnvolle Assertions zu schreiben, was die Aussagekraft der Zahl auf null senkt.
                            • Weitere Links zur Episode:

                              • FPL-Sourcecode
                              • GitHub
                              • Xing
                              • Stack Overflow
                              • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

                                Danke an die Community-Partner des Podcasts:

                                20 min
                              • KI als Tester: Mit LLM as a Judge Sprachmodelle prüfen - Anupam Krishnamurthy
                                Nicht-Determinismus ist kein Bug – bei LLMs ist er das Design

                                Wer automatisiert testet, baut auf Determinismus, auf Konsistenz, auf klare Erwartungen. Mit Anupam Krishnamurthy spreche ich darüber, warum genau das bei LLMs nicht funktioniert und was wir stattdessen brauchen. Wir gehen der Frage nach, wie man einen Chatbot testet, der nie zweimal die gleiche Antwort gibt, warum ein LLM ein anderes LLM beurteilen kann und wo das an seine Grenzen stößt. Anupam erklärt, wie RAG-Systeme sich in Retrieval und Generation zerlegen lassen, und warum die meisten Fehler im Retrieval stecken.

                                „Die meisten Probleme liegen im Retrieval." - Anupam Krishnamurthy

                                Anupam Krishnamurthy ist Head of AI Testing bei der TestSolutions GmbH, wo er die Bemühungen des Unternehmens leitet, beim Testen im Zeitalter von KI-gestützter Softwareentwicklung an der Spitze zu bleiben. Er ist Mitgründer der BeyondQuality-Community und Co-Host des dazugehörigen Podcasts.

                                Anupam ist ein Manager, der zum Softwareentwickler wurde — ein bunter Karriereweg, der ihn zu den Grundlagen zurückführte. Er begann als Maschinenbauingenieur, der in Indiens Raumfahrtprogramm Satelliten zusammenbaute, machte einen MBA, arbeitete als Strategieberater und stellte dann fest, dass ihm Programmieren mehr Spaß macht als PowerPoint. Zuvor war er als Test-Automation-Engineer und als freiberuflicher Berater tätig und half seinen Kunden, qualitativ hochwertige Software schneller auszuliefern.

                                Ursprünglich aus Bangalore, Indien, und mittlerweile in Berlin zu Hause, findet man ihn in seiner Freizeit vertieft in eine Partie Online-Schach, beim Langstreckenlauf mit einem History-Podcast im Ohr oder beim Blues-Spielen auf seiner Akustikgitarre.

                                Highlights:

                                • Nicht-Determinismus ist bei LLMs kein Bug, sondern ein Designmerkmal: Wer das wie Flakiness behandelt und ausschließt, testet am System vorbei.
                                • Bei RAG-Systemen stecken die meisten Fehler im Retrieval, nicht in der Generierung: Ein korrekt gefüttertes LLM liefert verlässlich brauchbare Antworten.
                                • Der LLM-as-Judge-Ansatz erreicht laut Studien 80 bis 85 Prozent Übereinstimmung mit menschlichen Urteilen, was dem Übereinstimmungsniveau zwischen zwei Menschen entspricht.
                                • Qualitätsgates für LLM-Tests brauchen Akzeptanzschwellen statt Binär-Urteilen: Ein Grenzwert von 80 bis 85 Prozent ersetzt das klassische Rot-Grün-Prinzip.
                                • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

                                  Danke an die Community-Partner des Podcasts:

                                  23 min
                                • Resilienz in Softwareprojekten: Trends statt Einzelwerte - Anna Melbinger
                                  Warum Bugtrends mehr aussagen als jeder einzelne Bug

                                  Was können wir von Bakterien und Motten lernen, um besser mit Unsicherheit umzugehen? Mit Anna Melbinger spreche ich darüber, wie Strategien aus der Natur auf Softwareprojekte und Projektmanagement übertragbar sind. Anna bringt einen ungewöhnlichen Hintergrund mit: Jahre in der Wissenschaft, Physik studiert, biologische Fragestellungen mit Mathematik bearbeitet, und heute im IT-Projektgeschäft. Wir reden darüber, warum Stillstand keine Robustheit erzeugt, warum Bug-Trends oft aussagekräftiger sind als einzelne Bugs, und wann es sich lohnt, bewusst einen Schritt zu tun, der nicht direkt zum Ziel führt, nur um Wissen zu gewinnen. Am Ende landet das Gespräch bei Karl Popper und der Frage, ob das aktive Suchen nach Widerlegung eigentlich die ehrlichste Methode ist, mit komplexen Entscheidungen umzugehen.

                                  „Manchmal lohnt es sich bewusst innezuhalten. Schritte zu tun, nur um Wissen zu generieren." - Anna Melbinger

                                  Bevor Anna Melbinger in die IT wechselte, forschte sie viele Jahre als biologische Physikerin an komplexen Systemen – unter anderem an der LMU München, am Institut Pasteur in Paris und an der UC San Diego. Dort beschäftigte sie sich mit der Frage, wie biologische Systeme unter Unsicherheit funktionieren, Entscheidungen treffen und robust bleiben.

                                  Heute arbeitet sie seit über zehn Jahren im IT-Projektmanagement und begleitet anspruchsvolle Digitalisierungs- und Transformationsprojekte. Immer wieder erkennt sie dabei überraschende Parallelen zwischen Projektarbeit und biologischen Mechanismen.

                                  In ihren Vorträgen verbindet sie wissenschaftliche Tiefe mit praktischer Erfahrung – und zeigt, warum Orientierung, Anpassung und Robustheit oft wichtiger sind als perfekte Planung.

                                  Highlights:

                                  • Bug-Trends liefern mehr Steuerungsinformation als einzelne Bugs, weil sie zeigen, ob ein System gerade abbaut oder sich erholt, ohne dass man jedem Einzelfall hinterherlaufen muss.
                                  • Stillstand als Robustheitsstrategie funktioniert nicht: Wer ein System einfriert statt es anzupassen, verbraucht seine Ressourcen am Ort und verliert langfristig.
                                  • Bewusstes Abweichen vom direkten Weg, zum Beispiel ein 90-Grad-Schritt wie bei Motten auf Partnersuche, optimiert nicht die Effizienz, sondern die Qualität der Information und führt schneller zum Ziel.
                                  • Hypothesen sind nur dann nützlich, wenn das Ziel ist, sie zu falsifizieren: Wer aktiv nach Widerlegung sucht, schneidet ganze Entscheidungsäste ab, statt sich durch den Baum durchzuarbeiten.
                                  • 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

                                    Danke an die Community-Partner des Podcasts:Alliance for Qualification | ASQF | Austrian Testing Board | dpunkt.verlag | German Testing Board | German Testing Day | GI Fachgruppe TAV | Heise | HANSER Verlag | ISTQB | iSQI GmbH | oop | QS-TAG | SIGS-DATACOM | skillsclub | Swiss Testing Board | TACON Credits: Sound | Grafik

                                    19 min

                                  About Software Testing & Qualität - Testautomatisierung, KI & Agilität

                                  From the publisher's feed

                                  Software-Projekte werden komplexer - wie behältst du die Kontrolle?