# Richard Seidl: Vollständige Inhalte (llms-full.txt) > Diese Datei enthält den vollständigen Inhalt der wichtigsten Seiten und > der neuesten Blog-Artikel und Podcast-Episoden von richard-seidl.com. > Sprache: Deutsch. Letzte 20 Artikel und Episoden eingeschlossen. > Strukturierter Überblick: https://www.richard-seidl.com/de/llms.txt Richard Seidl ist Keynote Speaker, Autor, Coach und Berater mit Schwerpunkt digitale Transformation, Software-Qualität, KI und Testautomatisierung. Motto: "Qualität ist eine Haltung." Ausgezeichnet mit dem Deutschen Preis für Software-Qualität (DPSQ) 2025. ## Kern-Landingpages ### Keynote Speaker Digitalisierung URL: https://www.richard-seidl.com/de/keynote-speaker-digitalisierung/ Richard Seidl als Keynote Speaker zu Digitalisierung, Software-Qualität und KI. Vorträge für Konferenzen, Unternehmensevents und Fachtagungen. --- ### Academy: ISTQB & Trainings URL: https://www.richard-seidl.com/de/academy/ Trainingsprogramme und Zertifizierungskurse. ISTQB Foundation Level, GenAI Tester, Practical Tester. Praxisnah, erfahrungsbasiert. --- ### Coaching & Beratung URL: https://www.richard-seidl.com/de/coaching/ Coaching und Beratung für agile Transformation, digitalen Wandel und Software-Qualität. Individuell, pragmatisch, nachhaltig. --- ### Executive Coaching URL: https://www.richard-seidl.com/de/executive-coaching/ Executive Coaching für Führungskräfte in der Technologie. CEOs, CTOs, Bereichsleiter, die Verantwortung tragen und Klarheit brauchen. --- ### Über Richard Seidl URL: https://www.richard-seidl.com/de/ueber-mich/ 25+ Jahre IT-Praxis, DPSQ 2025, 8 Fachbücher. Software-Qualitätscoach, Keynote Speaker, ISTQB-Trainer und Autor. ## Kernthemen (Volltexte) ### Was ist ein Unit Test? Definition, Beispiel und Praxis URL: https://www.richard-seidl.com/de/unittest/ Ein Unit Test, auch Modultest genannt, prüft isoliert die kleinste testbare Einheit. Mit Codebeispiel, Mocking und Abgrenzung zum Integrationstest. Was ist ein Unit Test? Ein Unit Test prüft das kleinste testbare Stück Code, eine Funktion, eine Methode oder eine Klasse, isoliert vom Rest des Systems. Entwicklerinnen und Entwickler schreiben ihn parallel zum Code, er läuft meist in Millisekunden und meldet nach jeder Änderung, ob dieses Stück noch funktioniert. Ein einfaches Beispiel: berechneRabatt(100) muss 10 liefern. Ob die Anforderung hinter dem Code richtig verstanden ist, beantwortet allerdings auch die grünste Testsuite nicht. Das ISTQB-Glossar führt den Begriff als eigenen Eintrag und definiert den Unit-Test als “Teststufe mit dem Schwerpunkt auf der Bewertung des kleinsten isoliert testbaren Codeteils”. Im Lehrplan heißt dieselbe Stufe Komponententest, mit dem Zusatz “auch Unittest genannt”, ältere Literatur spricht vom Modultest. In meinen 25 Jahren Projektarbeit hat sich trotzdem der englische Begriff gehalten; an ein Team, das diese Stufe anders nannte, kann ich mich nicht erinnern. Unit Testing, also das Schreiben und Ausführen solcher Tests, ist der früheste Zeitpunkt, an dem ein Test neuen Code ausführen kann. Der ISTQB-Lehrplan zählt “Frühes Testen spart Zeit und Geld” zu seinen sieben Grundsätzen. Einen Bug, den ein Unit-Test aufdeckt, findet die Entwicklerin meist schnell, weil er nah am Code sitzt. Im Systemtest muss ihn erst jemand durch mehrere Schichten zurückverfolgen. Dazu kommt ein zweiter Nutzen: Unit-Tests halten den Code änderbar, weil sie nach jeder Änderung in Sekunden zeigen, ob das bestehende Verhalten noch stimmt. Und sie verraten einiges über das Design. Fällt der Satz “Das kann man nicht unit-testen”, hat der Code meist zu viele Abhängigkeiten, zu große Einheiten oder zu enge Kopplung. Brauchen die Tests lange, lohnt ebenfalls ein zweiter Blick auf den Schnitt der Einheiten. Wie sieht das im Code aus? Ein Beispiel Angenommen, ein Onlineshop gewährt auf jede Bestellung 10 Prozent Rabatt. Die Funktion berechneRabatt(bestellwert) soll bei 100 Euro Bestellwert 10 liefern, bei einer leeren Bestellung 0, und negative Werte soll sie zurückweisen. Ein Unit-Test ruft sie mit genau diesen Eingaben auf und vergleicht das Ergebnis mit dem erwarteten Wert. In TypeScript mit dem Framework Vitest sieht das so aus: import { describe, it, expect } from "vitest"; import { berechneRabatt } from "./preise"; describe("berechneRabatt", () => { it("liefert 10 Prozent des Bestellwerts", () => { expect(berechneRabatt(100)).toBe(10); }); it("liefert 0 bei leerer Bestellung", () => { expect(berechneRabatt(0)).toBe(0); }); it("weist einen negativen Bestellwert zurück", () => { expect(() => berechneRabatt(-1)).toThrow(); }); }); Der erste Test deckt den Standardfall ab, der zweite den Grenzwert bei null, der dritte eine Eingabe außerhalb der Spezifikation. Alle drei folgen in knapper Form dem Muster Arrange, Act, Assert: Die Eingabe steht direkt im Aufruf, der Aufruf ist das Act, expect() das Assert. Im dritten Test fallen Act und Assert in eine Zeile, weil schon der Aufruf eine Ausnahme werfen muss. Aus einer Funktion mit echter Logik entstehen so meist drei bis fünf Testfälle. Mit JUnit in Java oder pytest in Python bleibt der Aufbau derselbe. Wer schreibt die Tests? In der Regel die Entwicklerinnen und Entwickler, und zwar für ihren eigenen Code. So steht es auch im ISTQB-Lehrplan Foundation Level: Komponententests führen normalerweise Entwickler in ihrer Entwicklungsumgebung durch. Niemand kennt die innere Logik einer Einheit besser als die Person, die sie geschrieben hat, und die Tests sollen stehen, bevor die Änderung in die gemeinsame Codebasis wandert. Testerinnen und Tester schreiben Unit-Tests selten selbst. Schärfer machen können sie sie trotzdem, denn Grenzwerte, Äquivalenzklassen und Negativfälle sind Testentwurfswissen. Wenn jemand mit diesem Blick die Unit-Tests durchsieht, fallen fehlende Randfälle deutlich früher auf. Was ist der Unterschied zwischen Unit- und Integrationstests? Der Unit-Test prüft eine Einheit für sich, der Integrationstest das Zusammenspiel mehrerer Einheiten über ihre Schnittstellen. Damit die Isolation gelingt, ersetzen Stubs und Mocks die Abhängigkeiten und simulieren die Aufrufe und Antworten der Nachbarkomponenten. Ein Test ohne diese Isolation führt die Abhängigkeiten mit aus, ein Fehlschlag kann dann aus jeder von ihnen stammen. | Unit-Test | Integrationstest Testobjekt | einzelne Funktion, Klasse oder Modul | Zusammenspiel mehrerer Komponenten Fokus | innere Logik der Einheit | Schnittstellen und Datenaustausch Abhängigkeiten | durch Stubs und Mocks ersetzt | real oder teilweise simuliert Testbasis | Komponentenspezifikation, Entwurf, Code | Architektur, Schnittstellenbeschreibungen Typische Fehler | Berechnungen, Grenzwerte, Ausnahmefälle | Datenformate, Aufrufsequenzen, Fehlerweitergabe Laufzeit | Millisekunden bis Sekunden | spürbar langsamer Verantwortung | Entwicklung | Entwicklung, auf höheren Ebenen auch Testteams Im ISTQB-Modell schließt der Komponentenintegrationstest direkt an und nimmt sich die Schnittstellen und Interaktionen zwischen den Einheiten vor. Inkompatible Datenformate oder falsche Aufrufreihenfolgen fallen erst dort auf. Von der Testbasis zum Testfall Bevor der erste Test entsteht, stehen drei Entscheidungen an: worauf er sich stützt, welche Testfälle er braucht und wo er mit welchen Daten läuft. In klassischen Projekten landen diese Entscheidungen in einem Stufentestkonzept für den Unit-Test. Agile Teams halten sie meist in ihrer Definition of Done fest. Testbasis Zur Testbasis gehört alles, was die Einheit beschreibt: Details aus Design oder Architektur, Teile einer User Story oder Anforderung, manchmal Komponentenspezifikationen oder Modelle. Für strukturorientierte Testfälle und die Zweigüberdeckung kommt der Sourcecode selbst dazu. Testfälle ableiten Auf dieser Stufe greifen die strukturierten Testentwurfsverfahren besonders gut: Äquivalenzklassenbildung, Grenzwertanalyse und Entscheidungstabellen, dazu kombinatorische Verfahren wie Pairwise oder der Klassifikationsbaum. Wertebereiche, Datentypen und Bedingungen sind hier viel konkreter als im System- oder Abnahmetest, das erleichtert die Ableitung. Ein Testfall ist nach ISTQB eine Menge aus Vorbedingungen, Eingaben, Aktionen (falls anwendbar), erwarteten Ergebnissen und Nachbedingungen, entwickelt auf Basis von Testbedingungen. Im Unit-Test passt er meist in eine einzige Testmethode. Die meiste Aufmerksamkeit verdienen die Negativtests, denn genau dort sitzen die Fehler, die später teuer werden. Ein Unit-Test, der nur den Standardfall prüft, sagt wenig darüber, wie die Einheit mit korrupten Daten, Grenzwerten oder Parametern außerhalb der Spezifikation umgeht. Umgebung und Daten Unit-Tests laufen meist an zwei Orten: in der Entwicklungsumgebung, schnell und ohne Umstände, und auf dem Build-Server oder in der CI-Pipeline bei jedem Commit. Testtreiber, Stubs und Mocks vertreten die aufrufenden und aufgerufenen Klassen. Die Daten bleiben überschaubar, weil jeder Test nur einen Aspekt abdeckt; sie liegen direkt bei den Testfällen oder in einem gemeinsamen Repository. In größeren Projekten hilft ein Testdatengenerator bei Grenzfällen, die von Hand mühsam zu pflegen wären. Wann wird Testen auf Unit-Ebene schwierig? Einen einzelnen Unit-Test zu schreiben ist nicht schwer, mit einem Framework sind es wenige Zeilen. Schwierig wird es, wenn der Code nicht dafür gebaut ist. Eine Klasse, die selbst eine Datenbankverbindung öffnet, die Systemzeit liest und einen Webservice aufruft, lässt sich erst isolieren, wenn sich ihr Design ändert. Die zweite Hürde ist Legacy-Code. Ohne bestehende Tests ist jedes Refactoring, das den Code testbar machen soll, selbst ein Risiko; viele Teams beginnen deshalb mit Tests rund um die Stellen, die sie als Nächstes ändern müssen. Die dritte Hürde ist Urteilsvermögen: Welche Fälle zählen, wie viel wird gemockt, und prüft ein Test Verhalten oder spiegelt er nur die Implementierung? Bei der ersten dieser Fragen helfen Testentwurfsverfahren, denn Äquivalenzklassen und Grenzwertanalyse beantworten systematisch, welche Fälle eine Einheit braucht. Was macht einen guten Unit-Test aus? Ein guter Unit-Test ist schnell, unabhängig von anderen Tests, jederzeit mit demselben Ergebnis wiederholbar und wertet sich selbst aus: Er wird grün oder rot, ohne dass jemand Logdateien deuten muss. In der Clean-Code-Community heißen diese Eigenschaften FIRST-Prinzipien (Fast, Independent, Repeatable, Self-validating, Timely). Dazu kommt Lesbarkeit. Ein guter Unit-Test prüft einen Aspekt, trägt einen Namen, der sagt, was er erwartet, und folgt dem Aufbau Arrange, Act, Assert. So geschriebene Tests dokumentieren nebenbei, wie eine Klasse gedacht ist. Mocking mit Augenmaß Mocking ersetzt die Abhängigkeiten einer Einheit durch simulierte Objekte, damit der Test isoliert und schnell läuft. Das ISTQB fasst solche Ersatzkomponenten unter dem Begriff Testdouble zusammen und unterscheidet mehrere Arten: Ein Platzhalter (Stub) gibt vordefinierte Antworten, ein Mock simuliert das erwartete Verhalten der Komponente während des Tests. Statt der echten Datenbank liefert ein Stub zum Beispiel einen festen Kundendatensatz; der Mock eines Webservice kann zusätzlich prüfen, ob die Einheit ihn wie erwartet aufgerufen hat. Sinnvoll sind Testdoubles, wenn eine Abhängigkeit langsam ist, nicht verfügbar oder schwer in einen definierten Zustand zu bringen. Meine Faustregel: mocken, was langsam oder extern ist, und echte Objekte überall dort verwenden, wo sie schnell und deterministisch sind. Ein Test, der jede Abhängigkeit ersetzt, prüft vor allem, ob simuliertes Verhalten korrekt durchgereicht wird, und sagt wenig über die eigene Logik der Einheit. Test zuerst: Test Driven Development Unit-Tests entstehen am besten parallel zum Code oder davor, spätestens aber, bevor die Änderung in die gemeinsame Codebasis wandert. Auf “später” verschobene Tests schreibt kaum jemand mehr, denn der Aufwand wächst, sobald die Details der Einheit nicht mehr präsent sind. Test Driven Development (TDD) dreht die Reihenfolge ganz um: Test schreiben, scheitern sehen, gerade so viel Code schreiben, dass er besteht, dann aufräumen. Dieser Rhythmus macht den Code von Anfang an testbar, und das sieht man der Architektur an. TDD verlangt allerdings Disziplin und funktioniert am besten bei Logik mit klarer Spezifikation. Wenn die Prozentzahl zum Ziel wird Codeüberdeckung zeigt, wie viel des Sourcecodes die Tests durchlaufen, gemessen etwa als Anweisungs- oder Zweigüberdeckung. Viele Teams machen daraus ein Endekriterium oder einen Punkt der Definition of Done: “Unit-Tests müssen 80 Prozent Codeüberdeckung erreichen.” Die Zahl lässt sich dann mit möglichst einfachen Tests treiben, Sonderfälle und Negativtests fallen weg, weil sie die Prozentzahl kaum bewegen. Hundert Prozent Überdeckung mit schwachen Tests sind weniger wert als siebzig Prozent mit guten. Als Diagnosewerkzeug taugt die Überdeckung, weil sie zeigt, welche Bereiche kein Test berührt, über die Qualität der Tests sagt sie dagegen wenig. Automatisch bei jedem Commit: Frameworks und CI-Pipeline Auf keiner anderen Teststufe ist Automatisierung so selbstverständlich wie hier, denn ein Unit-Test ist dafür gemacht, bei jeder Codeänderung in Sekunden mitzulaufen. Eine Einheit im Debugger durchzugehen findet vielleicht einen Fehler, hinterlässt aber keinen Test, der beim nächsten Commit wieder läuft. Ein Unittest-Framework liefert dafür das Gerüst: Es organisiert die Testfälle, führt sie aus und meldet die Ergebnisse. Für alle gängigen Sprachen gibt es etablierte Frameworks: JUnit für Java, pytest für Python, NUnit für .NET, Jest oder Vitest für JavaScript und TypeScript. In der CI-Pipeline läuft das Framework als Build-Schritt bei jedem Commit oder Pull Request, etwa in GitHub Actions, GitLab CI oder Jenkins, und ein fehlgeschlagener Test bricht den Build ab. Damit das trägt, braucht es kurze Laufzeiten (Minuten, nicht Stunden), einen lesbaren Testreport und die Regel, dass ein roter Build sofort repariert wird. Agile Teams sind darauf am stärksten angewiesen. Wer alle zwei Wochen liefert, kann nicht vor jedem Release das ganze Produkt von Hand nachprüfen. Die Testpyramide bildet das ab. Mike Cohns ursprüngliches Modell kennt drei Schichten, Unit-Tests an der Basis, Service-Tests in der Mitte und UI-Tests an der Spitze; eine verbreitete Variante nennt sie Unit-, Integrations- und End-to-End-Tests. In beiden liegen unten viele kleine, schnelle, isolierte Tests und oben wenige langsame, die große Teile der Funktionalität prüfen. Wann sich der Aufwand nicht lohnt Jede Einheit mit eigener Logik braucht Unit-Tests. Ausnahmen sind trivialer Code ohne solche Logik, etwa reine Getter und Setter, Wegwerf-Prototypen und Bereiche, in denen das Risiko im Zusammenspiel liegt, etwa reine Konfiguration oder UI-Layout. Ein Sonderfall ist explorative Arbeit an einem unklaren Problem. Dort kann es sinnvoll sein, mit den Tests zu warten, bis die Struktur steht. Drei Probleme, die ich immer wieder sehe In Projekten treffe ich immer wieder auf dieselben drei Probleme: - Negativtests und Sonderfälle fehlen. Die Unit-Tests zeigen dann nur, dass der Standardfall funktioniert, aber nicht, was bei korrupten Daten oder Parametern außerhalb der Spezifikation passiert. - Unit-Tests entstehen gar nicht erst. Zu Beginn geht das gut: Die Software ist überschaubar, alles läuft, der Fortschritt sieht großartig aus. Im Hintergrund wächst aber ein technischer Schuldenberg, der sich später nur mühsam abtragen lässt. - Tests gelten als eigene Aufgabe. “Ich bin fertig, ich muss nur noch Tests schreiben” zeigt, dass das Team Unit-Tests als Anhängsel sieht. In den Teams, die ich am besten arbeiten sehe, ist eine Aufgabe erst fertig, wenn auch ihre Tests stehen, und diese Haltung führt zu deutlich besseren Ergebnissen. Was eine grüne Testsuite nicht zeigt Unit-Tests prüfen, ob eine Einheit tut, was ihr Entwickler beabsichtigt hat. Ob diese Absicht fachlich richtig war, prüfen sie nicht: Ein Missverständnis in den Anforderungen wandert ungehindert in Code und Test. Das fangen erst die höheren Teststufen und der Abgleich mit den Anforderungen auf, und auch das Zusammenspiel der Einheiten überlassen Unit-Tests dem Integrationstest. Aus der Praxis Der Unit-Test ist für mich die wichtigste aller Teststufen. Auf ihn schaue ich zuerst, wenn ich ein neues Beratungsprojekt beginne, denn hier sehe ich, wie stabil eine Anwendung ist. Ein Mindestmaß an Unit-Tests haben die meisten Teams inzwischen, mehr als auf jeder anderen Stufe, und auf keiner anderen Stufe gewinnt ein Projekt mit so wenig Aufwand so viel. Bei der Umsetzung hakt es trotzdem oft: Der Fokus liegt auf der Abdeckungszahl, oder Tests zu schreiben gilt als lästige Pflicht. --- ### Systemtest: Definition, Abgrenzung und Automatisierung URL: https://www.richard-seidl.com/de/systemtest/ Der Systemtest prüft das ganze System gegen seine Anforderungen. Abgrenzung zu Integrations- und Abnahmetest, Testumgebung und Automatisierung. Was ist der Systemtest? Der Systemtest ist die Teststufe, auf der ein vollständiges, integriertes System gegen seine spezifizierten Anforderungen geprüft wird. Das ISTQB-Glossar definiert ihn als Teststufe mit dem Schwerpunkt zu verifizieren, dass ein System als Ganzes die spezifizierten Anforderungen erfüllt. Testobjekt ist damit das ganze Produkt statt einer Komponente oder einer Schnittstelle: sein funktionales Verhalten in Ende-zu-Ende-Abläufen und seine nicht-funktionalen Qualitätsmerkmale wie Performance, Sicherheit und Gebrauchstauglichkeit. Weil die Spezifikation die Testbasis ist, steht meist das beobachtbare Verhalten an den Systemgrenzen im Mittelpunkt. Black-Box-Verfahren passen zu diesem Ziel und sind auf dieser Stufe verbreitet, vorgeschrieben sind sie nicht. Wo Strukturwissen oder White-Box-Verfahren dem Testziel dienen, setzen Tester sie ebenso ein. Der Wechsel vom einzelnen Baustein zum Gesamtsystem ändert, was ein Test finden kann. Komponenten- und Integrationstests betrachten kleinere Testobjekte und deren Zusammenspiel. Der Systemtest bewertet das Gesamtverhalten so, wie Anwender und angebundene Systeme es erleben, und auf dieser Ebene wird eine andere Klasse von Fehlern sichtbar. Wo verläuft die Grenze zu Integrations-, Systemintegrations- und Abnahmetest? Der ISTQB Foundation Level (Version 4.0) beschreibt fünf Teststufen: Komponententest, Komponentenintegrationstest, Systemtest, Systemintegrationstest und Abnahmetest. Der Systemtest steht nach der Integration der Komponenten und vor der Abnahme. Die Stufen unterscheiden sich durch Testobjekt, Testziele, Testbasis, typische Fehler und Verantwortlichkeiten; eine feste zeitliche Reihenfolge sind sie nicht, in iterativen Projekten überlappen sie sich. Nach unten verläuft die Grenze zum Integrationstest. Der Komponentenintegrationstest prüft, wie Komponenten und Teilsysteme über ihre Schnittstellen zusammenarbeiten; er bewertet kein vollständiges System gegen fachliche Anforderungen. Nach oben verläuft sie zum Abnahmetest, der aus Sicht der Auftraggeber oder Endbenutzer beurteilt, ob das System für den beabsichtigten Einsatz taugt. Der Systemtest beantwortet, ob das Team das System richtig gebaut hat, der Abnahmetest, ob es das richtige System gebaut hat. Die Verbindung zu anderen Systemen und externen Diensten gehört in den Systemintegrationstest. Wer die Systemintegration testen will, braucht eine Umgebung, die der Betriebsumgebung nahekommt, und meist andere Beteiligte, weil mehrere Systeme und Teams im Spiel sind. Daraus folgt auch die Frage nach der Verantwortung für den Systemtest selbst. Laut Lehrplan kann ein unabhängiges Testteam ihn durchführen, weil Tester, die den Code nicht geschrieben haben, andere Annahmen mitbringen und andere Fehler finden als die Autoren. Ob das die richtige Besetzung ist, richtet sich nach Risiko, Entwicklungsmodell und Projektkontext. Funktionale und nicht-funktionale Ziele Der Systemtest verfolgt drei Ziele zugleich. Er verifiziert, dass das System die spezifizierten funktionalen Anforderungen erfüllt: Geschäftsprozesse, Benutzerszenarien und die Regeln dahinter. Er deckt Fehler auf, die sich erst auf Systemebene zeigen, weil jede Komponente für sich arbeitet und erst ihr Zusammenspiel im Gesamtkontext scheitert. Und er bewertet nicht-funktionale Qualitätsmerkmale, die ein vollständiges System oder eine repräsentative Umgebung brauchen: Performance unter Last, Zuverlässigkeit über lange Laufzeiten, Sicherheit und die Gebrauchstauglichkeit vollständiger Arbeitsabläufe. Die funktionale Seite teilt sich in Tests der Geschäftslogik und der Abläufe gegen die Anforderungen, Regressionstests, die nach Änderungen das bestehende Verhalten absichern, und Smoke-Tests als schnelle Prüfung der Grundfunktionen nach jedem Deployment. Zur nicht-funktionalen Seite gehören Performance- und Lasttests, Stresstests, Sicherheitstests, Usability-Tests und Zuverlässigkeitstests. Viele dieser Merkmale lassen sich auch auf niedrigeren Teststufen untersuchen, mit anderem Fokus. Antwortzeiten über den ganzen Ablauf, systemweite Zuverlässigkeit oder die Bedienbarkeit eines kompletten Arbeitsablaufs brauchen das ganze System, und in einem engen Zeitplan sind sie meist die ersten Tests, die ein Projekt verschiebt. Testbasis: Anforderungen, Geschäftsprozesse, Akzeptanzkriterien Die Testbasis bilden vor allem die funktionalen und nicht-funktionalen Anforderungen, ergänzt um User Stories, Geschäftsprozesse, Anwenderdokumentation und Akzeptanzkriterien. Fehlt eine strukturierte Anforderungsbasis oder ist sie lückenhaft, helfen Anwender und Fachabteilungen als Quelle weiter. Bei Systemablösungen und Migrationen taugt sogar das Altsystem als Testorakel, gegen das das Team das neue Verhalten abgleicht. Die Qualität dieser Testbasis schlägt direkt auf die Qualität der Testfälle durch. Vage Formulierungen wie “Das System muss performant sein” oder “Die Applikation sollte leicht zu bedienen sein” lassen sich nicht in konkrete, prüfbare Testfälle übersetzen. Frühe Testfallerstellung zahlt sich deshalb doppelt aus: Sie zwingt dazu, die Anforderungen zu konkretisieren, bevor die erste Zeile Code entsteht, und sie gibt den Entwicklern ein Zielbild, solange sie noch Zeit haben, es zu nutzen. Die Verfolgbarkeit verbindet die Testbasis mit den Ergebnissen. Jede Anforderung verweist auf mindestens einen Testfall, jeder Testfall auf die Anforderung, die er prüft. Liegen Anforderungen in einem Werkzeug und Testergebnisse in einem anderen, ohne diese Verknüpfung, kann niemand zeigen, welche Anforderungen einen ausgeführten Test haben und welche keinen, und die Anforderungsüberdeckung wird vor jedem Release zur Handarbeit. Testfälle aus Spezifikation und Erfahrung Für den Systemtest hat sich eine Kombination aus zwei Ansätzen bewährt. Sie ergänzen einander und gleichen ihre jeweiligen Schwächen aus. Die spezifikationsbasierte Testfallerstellung stützt sich auf systematische Black-Box-Verfahren. Äquivalenzklassenbildung und Grenzwertanalyse leiten Testfälle effizient aus den Anforderungen ab und sichern die nötige Breite der Abdeckung. Entscheidungstabellen bringen Ordnung in komplexe Geschäftslogik mit vielen Bedingungskombinationen. Zustandsübergangstests modellieren Systeme, die verschiedene Zustände durchlaufen, und prüfen die Übergänge dazwischen. Die erfahrungsbasierte Testfallerstellung ergänzt diesen strukturierten Kern. Kein Anforderungsdokument bildet ein System vollständig ab; zwischen der ursprünglichen Idee und der aufgeschriebenen Anforderung entsteht immer ein Transferverlust. Erfahrene Tester füllen diese Lücken: Sie kennen typische Fehlermuster, nehmen kritische Randfälle aus der Praxis vorweg und denken die Erwartungen künftiger Anwender mit. Das wichtigste Werkzeug dafür ist das explorative Testen. Es findet die Fehler, an denen strukturierte Testfälle vorbeilaufen. Ein typischer Systemtestfall ist ein Ende-zu-Ende-Szenario, keine einzelne Funktion: Ein Kunde legt eine Bestellung an, bezahlt, bekommt die Bestätigung, und Rechnung und Lagerbestand ändern sich entsprechend. Der spezifikationsbasierte Teil deckt die gültigen und ungültigen Pfade durch dieses Szenario ab, die Grenzwerte von Mengen und Preisen und die Entscheidungstabelle hinter den Rabattregeln. Der erfahrungsbasierte Teil fragt, was passiert, wenn der Zahlungsdienst mittendrin in einen Timeout läuft, wenn dieselbe Bestellung zweimal ankommt oder wenn die Browser-Sitzung zwischen zwei Schritten abläuft. Welche Testdaten und Testumgebung braucht ein Systemtest? Die Testumgebung gehört zu den zentralen Herausforderungen dieser Stufe. Für eine belastbare Aussage muss sie der Produktivumgebung möglichst nahekommen. Am stärksten gilt das für nicht-funktionale Tests: Ein Performancetest auf einer deutlich schwächeren Umgebung liefert Messwerte, die sich nicht auf die Produktion übertragen lassen. Im schlimmsten Fall erzeugen sie eine falsche Sicherheit. Virtualisierung und Cloud-Infrastruktur machen das deutlich billiger. Liegt die Produktivumgebung als parametrisierte virtuelle Maschine oder als Container-Konfiguration vor, kann das Team sie für den Systemtest zu vertretbaren Kosten replizieren. Infrastructure as Code macht die Konfiguration versionierbar, reproduzierbar und nachvollziehbar. Der ISTQB-Lehrplan lässt Simulationen von Teilsystemen zu, wo die echten nicht verfügbar sind; je näher der Rest der Umgebung an der Produktion liegt, desto weniger verzerren diese Simulationen das Ergebnis. Die Testdaten werden ab dieser Stufe deutlich anspruchsvoller. Unit- und Integrationstests kommen meist mit überschaubaren, lokal definierten Datensets aus. Systemtests brauchen häufig komplexere Konstellationen: Verträge mit Historie, über mehrere Domänenobjekte verknüpfte Datensätze, Daten, die ein paar Jahre echten Betrieb hinter sich haben. Zwei Quellen haben sich etabliert. Echte Daten stammen als Abzug aus produktiven Systemen und werden anonymisiert, sobald personenbezogene Daten im Spiel sind. Sie sind praxisnah und decken mitunter Konstellationen ab, die niemand in Anforderungen oder Testfällen vorgesehen hat. Synthetisch erzeugte Daten entstehen gezielt für Grenzfälle und Sondersituationen: Geburtstage am 29. Februar, Postleitzahlen mit führender Null, maximale Feldlängen. Das sind die Kombinationen, die in Produktivdaten selten vollständig vorkommen, weshalb die meisten Systemtest-Suiten beide Quellen brauchen. Werkzeuge: GUI, API und Testmanagement Das Werkzeug richtet sich nach der geprüften Schnittstelle. Für GUI-Anwendungen steuern Playwright, Selenium oder Cypress die Anwendung so, wie ein Benutzer es täte; auf API-Ebene schicken REST-assured, Postman oder Karate die Anfragen und prüfen die Antworten. Testmanagement-Werkzeuge unterstützen Planung, Testfallverwaltung und Fehlerdokumentation: eigenständige wie TestRail oder Jira in Kombination mit Erweiterungen wie Xray. Ein strukturiertes Fehlermanagement ist auf Systemebene besonders wichtig. Fehler haben hier oft systemübergreifende Ursachen, an einem gescheiterten Szenario können mehrere Teams beteiligt sein, und die Kommunikation zwischen Tester, Entwickler und Fachbereich braucht einen Verantwortlichen, meist den Testmanager oder die Person, die den Test auf dieser Stufe leitet. Im Werkzeug steht, wer welche Fehlerwirkung analysiert hat und welche Korrektur dazu gehört. Was davon lässt sich automatisieren, was bleibt Handarbeit? Automatisiert wird, was wiederholt läuft, manuell bleibt, was Urteilsvermögen braucht. Regressionstests, die in jedem Release-Zyklus erneut laufen, sind die ersten Kandidaten, und auf Systemebene gibt es sie in zwei Formen. API-Tests prüfen die Geschäftslogik unterhalb der Oberfläche; sie sind günstiger zu bauen, schneller in der Ausführung und weniger anfällig. GUI-Tests decken die Wege ab, die ein Benutzer tatsächlich geht. Lange galten sie als fragil und wartungsintensiv. Playwright und vergleichbare Frameworks warten automatisch auf Elemente und wiederholen Prüfungen, bis sie erfüllt sind oder die Zeit abläuft; damit fällt der größte Teil der Timing-Probleme weg, die GUI-Tests unzuverlässig gemacht haben. Der Pflegeaufwand bei einer sich ändernden Oberfläche bleibt, deshalb trägt eine kleine Zahl gut gewählter GUI-Szenarien weiter als eine große. Die Testpyramide gilt auch innerhalb dieser Stufe: viele automatisierte API-Prüfungen, weniger automatisierte GUI-Szenarien und ein manueller Anteil, der absichtlich manuell bleibt. Exploratives Testen, Usability-Bewertungen und jedes Szenario, das eine subjektive Benutzererfahrung beurteilt, bleiben bei Menschen, weil der Wert in dem liegt, was dem Tester unterwegs auffällt, und ein Skript nur prüft, was man ihm aufgetragen hat. Agile Projekte: Die Ziele bleiben, der Rhythmus ändert sich Das Modell der Teststufen ist älter als die agilen Vorgehensmodelle, und Scrum-Teams ignorieren es deshalb oft. Die Ziele des Systemtests gelten im agilen Umfeld trotzdem: Das Team bewertet das Gesamtverhalten gegen die relevanten Anforderungen, bereitet Testdaten vor und hält eine geeignete Testumgebung bereit. Welche Techniken, Rollen und Grade von Unabhängigkeit dafür sinnvoll sind, entscheidet das Team in seinem Kontext. Der Rhythmus ändert sich: Systemtests laufen innerhalb eines Sprints gegen das Inkrement, kontinuierlich in einer geeigneten Umgebung mit jedem Merge oder in eigenen Validierungszyklen vor einem Release. Die Testpyramide liefert dazu die ergänzende Perspektive: Teams setzen komplexe Ende-zu-Ende-Tests selektiv und gezielt ein, als Ergänzung solider Komponenten- und Integrationstests, nie als deren Ersatz. Welche Fehler zeigen sich erst auf Systemebene? Bestimmte Fehler werden erst sichtbar, wenn das ganze System läuft: - Funktionale Abweichungen zwischen Anforderung und Systemverhalten, die auf den niedrigeren Teststufen nicht erkennbar waren. - Nicht-funktionale Mängel wie Performance-Engpässe unter Last, Speicherlecks bei langer Laufzeit oder Timeouts bei komplexen Transaktionen. - Datenkonsistenzprobleme, die erst bei realistischen Datenvolumina auftreten. - Fehlerhafte Grenzwert- und Fehlerbehandlung bei ungültiger Eingabe oder unerwarteten Zuständen. - Verhalten unter Ausnahmebedingungen, etwa bei fehlender Netzwerkverbindung, Systemüberlastung oder fehlerhaften Daten aus externen Quellen. In der Praxis legt der Systemtest damit häufig die Lücken der unteren Teststufen offen. Instabiles oder inkonsistentes Verhalten auf Systemebene deutet fast immer auf zu dünne Komponenten- oder Integrationstests hin. Diese Befunde kommen spät und kosten mehr, als derselbe Fehler zwei Stufen früher gekostet hätte, und das ist das stärkste Argument dafür, die anderen Teststufen nicht zu überspringen. Was diese Stufe nicht zeigen kann Der wesentliche Nachteil folgt aus der Größe des Testobjekts: Ein ausreichend vollständiges System und eine geeignete Umgebung stehen meist später bereit als einzelne Komponenten. Testfälle, Testdaten und Umgebungen lassen sich trotzdem früh vorbereiten, idealerweise parallel zur Anforderungsanalyse, damit der Entwurf fertig ist, wenn der erste Testlauf beginnt. Für interne Qualitätsattribute wie Codekomplexität, Wartbarkeit oder die Testabdeckung des Quellcodes ist diese Stufe ebenfalls das falsche Mittel. Diese Aspekte gehören zu den unteren Teststufen und verlangen andere Werkzeuge und andere Metriken. Aus der Praxis In vielen Projekten, die ich begleitet habe, ist der Systemtest die erste Teststufe, auf der überhaupt ernsthaft getestet wird. Das macht ihn wertvoll, und es macht ihn zum Sammelbecken für Qualitätsprobleme, die man viel früher hätte finden können. Die Befunde sind richtig und wichtig. Nur steigen die Kosten für ihre Behebung mit jeder Teststufe, die das Projekt vorher übersprungen hat, und im Systemtest kommt diese Rechnung an. Das Buch, das ich mit Harry Sneed und Manfred Baumgartner zu dieser Teststufe geschrieben habe, “Der Systemtest” (Hanser, 3. Auflage 2011), steht in der Literaturliste des deutschen ISTQB-Lehrplans Foundation Level (v4.0.2, Abschnitt 7.4, deutschsprachige Bücher). --- ### Teststufen: was jede Stufe prüft und wer sie verantwortet URL: https://www.richard-seidl.com/de/teststufen/ Teststufen gliedern die Qualitätssicherung in unterschiedliche Phasen mit jeweils eigener Zielsetzung. Welche Stufen es gibt und welche Testbasis sie brauchen. Was sind Teststufen? Teststufen beschreiben unterschiedliche Phasen im Testprozess, jede mit einer eigenen Zielsetzung. Sie folgen nicht einfach aufeinander, sondern nehmen jeweils einen anderen Aspekt des Softwaresystems in den Blick: Jede Stufe hat eigene Testziele, eigene Testobjekte, eine eigene Testbasis und einen typischen Kreis von Fehlerzuständen, den sie aufdeckt. Und zwar genau deshalb, weil die Fehler dort entstehen. Die Grundidee ist pragmatisch: Ein früh gefundener Fehler ist billiger als ein spät entdeckter. Jede Teststufe ist so angelegt, dass sie Fehler auf der Ebene einfängt, auf der sie üblicherweise entstehen. Bugs innerhalb einer Komponente zeigen sich im Komponententest. Probleme zwischen Komponenten werden im Komponenten-Integrationstest sichtbar, während der System-Integrationstest die Schnittstellen zu anderen Systemen und externen Services prüft. Systemfehler und nicht-funktionale Mängel gehören in den Systemtest. Und ob das System am Ende wirklich das leistet, was der Auftraggeber braucht, klärt der Abnahmetest. Die Teststufen ergänzen einander, ohne dass jedes Projekt sie zwingend in einer starren Reihenfolge durchlaufen muss. Teststufen sind aber auch ein Planungswerkzeug, und in dieser zweiten Funktion werden sie gerne unterschätzt. Wer zu Projektbeginn festlegt, welche Stufen wie bespielt werden, schafft Klarheit über Ressourcen, Verantwortlichkeiten und Testziele, bevor die erste Zeile Code existiert. Die Diskussion über Teststufen zwingt ein Team, vier Fragen auszusprechen: Was wird getestet? Von wem? Auf welcher Grundlage? Zu welchem Zeitpunkt? Genau diese Fragen bleiben sonst offen, bis es unbequem wird, sie zu beantworten. Die fünf Teststufen Die fünf Teststufen Kette der fünf Teststufen von links nach rechts: Komponententest (Testobjekt Klassen und Funktionen, verantwortlich Entwicklung), Komponenten-Integrationstest (Testobjekt Module und Services, verantwortlich häufig Entwicklung), Systemtest (Testobjekt Gesamtsystem, verantwortlich Testteam), System-Integrationstest (Testobjekt externe Systeme, verantwortlich Testteam mit Integrations- und Betriebsteams), Abnahmetest (Testobjekt System aus Nutzersicht, verantwortlich Auftraggeber und Endnutzer). ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Die folgende Einteilung in fünf Stufen hat sich als gemeinsame Landkarte weitgehend durchgesetzt, unter anderem nutzt sie der ISTQB Foundation Level. Verbindlich ist sie nicht: Teams können Stufen zusammenlegen, weglassen oder eigene definieren. Komponententest Der Komponententest, auch Unit-Test oder Modultest genannt, prüft einzelne Softwarekomponenten isoliert vom Rest des Systems. Testobjekte sind Klassen, Funktionen, Module oder andere abgrenzbare Einheiten. Die Testbasis bilden Komponentenspezifikationen, Entwurfsmodelle und der Sourcecode selbst. Typische Fehlerzustände dieser Stufe entstehen in der inneren Logik einer Einheit: falsche Algorithmen, unsaubere Grenzwertbehandlung, fehlerhafte Berechnungen, unbehandelte Ausnahmefälle. Verantwortlich sind in aller Regel die Entwicklerinnen und Entwickler selbst, unterstützt von Testframeworks wie JUnit für Java, pytest für Python oder NUnit für .NET. Damit eine Komponente wirklich isoliert betrachtet werden kann, ersetzen Stub- und Mock-Objekte ihre externen Abhängigkeiten. An dieser Isolation hängt die ganze Aussagekraft: Läuft ein Test nicht isoliert, prüft er immer auch die Abhängigkeiten mit, und dann lässt sich nicht mehr sagen, wo ein Fehler wirklich sitzt. Der Komponententest ist die schnellste und günstigste Stufe. Ein Bug, der hier gefunden wird, kostet nur einen Bruchteil dessen, was er im Systemtest oder gar in Produktion verursacht hätte. Komponenten-Integrationstest Der Komponenten-Integrationstest prüft die Schnittstellen und Interaktionen zwischen integrierten Komponenten innerhalb eines Systems. Er betrachtet also genau den Bereich, in dem einzeln funktionierende Bausteine unerwartet aneinander scheitern. Testobjekte sind beispielsweise gemeinsam arbeitende Klassen, Module, Services oder Subsysteme. Die Testbasis bilden Softwarearchitektur, Komponentenspezifikationen, Schnittstellenbeschreibungen und API-Dokumentationen. Typische Fehlerzustände sind falsch übergebene Daten, fehlerhafte Aufrufsequenzen, inkompatible Datenformate und eine Fehlerbehandlung, die über Komponentengrenzen hinweg nicht mehr greift. Verantwortet wird diese Stufe häufig von der Entwicklung und sie lässt sich gut in Continuous-Integration-Pipelines automatisieren. Bewährt hat sich ein inkrementelles Vorgehen: erst die kleinsten sinnvollen Gruppen integrieren und prüfen, dann den Umfang schrittweise erweitern. Systemtest Der Systemtest betrachtet das vollständig integrierte System als Ganzes und prüft es gegen seine spezifizierten Anforderungen. Er ist die umfassendste Stufe innerhalb der softwareentwickelnden Organisation und die letzte, bevor das System die Hände seiner Erbauer verlässt. Die Testbasis umfasst Systemspezifikationen, Anforderungsdokumente, Risikobewertungen und Use Cases. Geprüft werden funktionale und nicht-funktionale Anforderungen gleichermaßen: Performance, Sicherheit, Zuverlässigkeit, Usability und Kompatibilität gehören alle auf diese Ebene. Systemtests werden häufig von einem Testteam durchgeführt, das teilweise oder vollständig unabhängig von der Entwicklung arbeitet. Ein anderer Blickwinkel kann andere Fehler finden und Annahmen hinterfragen. Der konkrete Unabhängigkeitsgrad ist aber keine Eigenschaft der Teststufe selbst: Er richtet sich nach Risiko, Entwicklungsmodell und Projektkontext; auch Entwicklungsteams können Systemtests durchführen. System-Integrationstest Der System-Integrationstest prüft die Schnittstellen und Interaktionen zwischen dem getesteten System und anderen Systemen oder externen Services. Dazu gehören beispielsweise Zahlungsdienste, Identity Provider, Partner-APIs, Hardware-Schnittstellen und gemeinsam genutzte Datenplattformen. Im Unterschied zum Komponenten-Integrationstest liegt der Fokus damit außerhalb der Grenzen des einzelnen Systems. Als Testbasis dienen Systemarchitektur, systemübergreifende Schnittstellenverträge, Protokollspezifikationen, Datenflussmodelle und End-to-End-Abläufe. Typische Fehlerzustände sind inkompatible Protokolle oder Datenformate, fehlerhafte Authentifizierung, falsche Aufrufreihenfolgen sowie unzureichende Behandlung von Timeouts und Ausfällen. Die Durchführung liegt häufig bei Testteams in Zusammenarbeit mit Integrations-, Betriebs- und externen Partnerteams. Dafür werden geeignete Testumgebungen oder realistische Service-Simulationen benötigt. Abnahmetest Der Abnahmetest klärt, ob das System für seinen beabsichtigten Einsatz geeignet ist. Durchgeführt wird er typischerweise vom Auftraggeber, von den Fachbereichen oder von echten Nutzerinnen und Nutzern. Ziel ist die formale Bestätigung, dass das System die vereinbarten Anforderungen erfüllt. Die Testbasis bilden Nutzeranforderungen, Verträge, Abnahmekriterien und regulatorische Vorgaben. Der Abnahmetest kommt in mehreren Ausprägungen vor: als Benutzerakzeptanztest (UAT), bei dem reale Anwender das System unter realistischen Bedingungen erproben, als Betriebsabnahmetest, als Alpha- und Beta-Test sowie als regulatorischer Abnahmetest in sicherheitskritischen Bereichen. Der Abnahmetest stellt eine grundsätzlich andere Frage als der Systemtest. Der Systemtest fragt: “Funktioniert das System wie spezifiziert?” Der Abnahmetest fragt: “Ist das System das, was wir wirklich brauchen?” Der Unterschied wirkt subtil, hat aber handfeste Konsequenzen. Ein System kann sämtliche Systemtests bestehen und trotzdem an der Abnahme scheitern, wenn die Spezifikation die tatsächlichen Bedürfnisse der Nutzer nicht eingefangen hat. Wer beide Fragen verwechselt, hält am Ende eine korrekt gebaute Lösung für ein falsch verstandenes Problem in den Händen. Testbasis je Teststufe Jede Teststufe braucht eine eigene Grundlage, aus der sich ihre Testfälle ableiten lassen: Teststufe | Testbasis Komponententest | Komponentenspezifikation, Entwurf, Sourcecode Komponenten-Integrationstest | Softwarearchitektur, Komponentenspezifikation, interne Schnittstellen- und API-Dokumentation Systemtest | Systemspezifikation, Anforderungsdokumente, Use Cases, Risikoliste System-Integrationstest | Systemarchitektur, systemübergreifende Schnittstellenverträge, Protokolle, Datenflussmodelle Abnahmetest | Nutzeranforderungen, Verträge, Abnahmekriterien, regulatorische Vorgaben Diese saubere Trennung verhindert einen Fehler, der in der Praxis erstaunlich verbreitet ist: Systemtestfälle aus dem Code abzuleiten statt aus den Anforderungen. Wer seine Testfälle aus dem Code gewinnt, beschreibt nur, was das System ohnehin tut. Er bestätigt sich selbst, statt zu prüfen, ob das System das Richtige tut. Erst Tests, die aus den Anforderungen entstehen, messen das System an seinem beabsichtigten Nutzen und nicht an seiner eigenen Implementierung. Teststufen im V-Modell und in agilen Projekten Teststufen im V-Modell Zwei-Spalten-Leiter mit fünf Zeilen. Links die Entwicklungsphasen Nutzeranforderungen, Systemarchitektur, Systemspezifikation, Softwarearchitektur und Komponentenspezifikation. Rechts, auf gleicher Zeilenhöhe, die korrespondierenden Teststufen Abnahmetest, System-Integrationstest, Systemtest, Komponenten-Integrationstest und Komponententest. Horizontale Linien verbinden jede Entwicklungsphase mit ihrer Teststufe; das Paar Systemspezifikation und Systemtest ist hervorgehoben. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Das V-Modell ordnet jeder Entwicklungsphase eine Testphase zu und macht damit die Korrespondenz zwischen Bauen und Prüfen sichtbar. Komponentenspezifikation und Komponententest liegen auf einer Ebene, Systemspezifikation und Systemtest stehen sich gegenüber. Aus dieser Symmetrie folgt vor allem eine Einsicht: Testaktivitäten müssen früh geplant werden. Die Testbasis für den Systemtest entsteht in dem Moment, in dem die Systemspezifikation geschrieben wird. Nicht erst, wenn die Implementierung abgeschlossen ist. In agilen Projekten laufen die Teststufen nicht mehr sequenziell. Sie überlappen und verlaufen parallel, ohne dass das zugrunde liegende Konzept dadurch an Gültigkeit verliert. Komponenten- und Komponenten-Integrationstests laufen automatisiert in der CI-Pipeline. Systemtests finden in Staging-Umgebungen statt, oft mehrfach pro Sprint. System-Integrationstests prüfen dort oder in eigenen Integrationsumgebungen die externen Schnittstellen und systemübergreifenden Abläufe. Abnahmetests geschehen in Sprint-Reviews oder in eigenen Validierungszyklen. Verschoben haben sich also die zeitliche Abfolge und die organisatorischen Grenzen, nicht die Stufen selbst. Shift-Left heißt in diesem Zusammenhang: Testaktivitäten früher im Entwicklungsprozess ansetzen. Systemtestfälle also dann schreiben, wenn die Anforderungen entstehen, nicht erst, wenn die Implementierung fertig ist. Das setzt allerdings voraus, dass Tester und Testteams früh in die Anforderungsarbeit eingebunden werden, statt am Ende der Kette auf fertige Artefakte zu warten. Die Testpyramide als Ergänzung Die Testpyramide nach Mike Cohn beschreibt eine andere Dimension als die Teststufen: die angestrebte Verteilung automatisierter Tests. Unten viele schnelle Unit-Tests, in der Mitte Service- und API-Integrationstests, oben wenige, langsame UI-Tests. Die Pyramide ist damit kein Gegenentwurf zu den Teststufen, sondern ein Automatisierungsmodell, das eine ganz eigene Frage beantwortet. In der Praxis ergänzen sich beide Modelle, weil sie unterschiedliche Entscheidungen unterstützen. Die Teststufen legen fest, was auf welcher Ebene geprüft wird und wer die Verantwortung dafür trägt. Die Testpyramide gibt Orientierung, wie Automatisierungsinvestitionen zu priorisieren sind: viele stabile, schnelle Tests in den unteren Stufen, wenige, aber sorgfältig ausgewählte in den oberen. Wer die beiden verwechselt oder gegeneinander ausspielt, verliert am Ende die Stärke beider. Am wertvollsten ist die Pyramide übrigens als Diskussionswerkzeug. Wenn ein Team sie für das eigene System durchspielt, wird sichtbar, welche Tests auf welcher Ebene laufen und warum. Die Ebenen sind dabei Inspiration, keine Vorgabe: Jedes Team schneidet sie so, wie es zum eigenen System passt. Und es muss am Ende auch keine Pyramide herauskommen. Wenn eine andere Verteilung sinnvoller ist, dann ist die andere Verteilung die richtige. Wechselwirkungen: Teststufen und Testarten Qualitätsmerkmale je Teststufe: eine Schwerpunktmatrix Schwerpunktmatrix der fünf ISTQB-Teststufen gegen vier Qualitätsmerkmale (Funktionalität, Performance, Sicherheit, Usability) mit drei Ausprägungsstufen statt einer Ja/Nein-Zuordnung: Schwerpunkt, punktuell oder selten geprüft. Komponententest hat Schwerpunkt auf Funktionalität, punktuelle Prüfung von Performance und Sicherheit, seltene Usability-Prüfung. Komponenten-Integrationstest hat Schwerpunkt auf Funktionalität und Sicherheit, punktuelle Performance, seltene Usability. Systemtest hat auf allen vier Merkmalen Schwerpunkt. System-Integrationstest hat Schwerpunkt auf Funktionalität, Performance und Sicherheit, punktuelle Usability. Abnahmetest hat Schwerpunkt auf Funktionalität und Usability, punktuelle Performance und Sicherheit. Alle vier Merkmale lassen sich grundsätzlich auf jeder Teststufe prüfen, die Matrix zeigt nur, wo der übliche Fokus liegt, keine Ausschlussliste. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Teststufen und Testarten sind zwei unabhängige Dimensionen, die sich kreuzen, statt sich zu ersetzen. Alle Testarten lassen sich auf allen Teststufen anwenden. Was sich von Stufe zu Stufe ändert, ist nicht das Ob, sondern die Ausprägung. Auf Komponentenebene fragt Performance: Wie lange braucht eine einzelne Funktion unter Last? Auf Systemebene: Wie verhält sich das Gesamtsystem unter realistischen Lastprofilen? Dieselbe Eigenschaft, ganz unterschiedliche Fragen. Eine Präzisierung gehört dazu: Testarten im engeren Sinn sind der funktionale Test, der nicht-funktionale Test, der Black-Box-Test und der White-Box-Test. Performance, Sicherheit und Usability sind Qualitätsmerkmale nach ISO 25010, die der nicht-funktionale Test prüft, also eine Ebene darunter. Für die Planung ist genau diese Merkmals-Ebene die nützliche, deshalb arbeitet die Schwerpunktmatrix in der Grafik mit ihr. Sie ist eine Schwerpunkttabelle, keine Zulässigkeitstabelle: Sie zeigt, wo ein Qualitätsmerkmal üblicherweise seinen Hauptfokus hat, nicht wo es allein geprüft werden darf. Wer die Matrix als Verbotsliste liest, baut sich genau die Lücken ein, die sie aufdecken soll. Ein Sicherheitsproblem, das im Komponententest auffallen könnte, wartet sonst bis zum Systemtest. Und ein Performanceproblem, das in der Architektur wurzelt, lässt sich nach dem Systemtest kaum noch wirtschaftlich beheben. Als Schwerpunkttabelle gelesen, leistet die Matrix dagegen genau das, was ein Planungswerkzeug soll: Sie macht sichtbar, wo welches Merkmal wie intensiv geprüft wird, und erzwingt die Gespräche früh, die man sonst erst unter Zeitdruck führt. Aus der Praxis In Projekten, die ich begleite, ist die Teststufen-Matrix oft der erste gemeinsame Schritt. Nicht, weil das Modell irgendjemanden überraschen würde. Der Wert liegt im Gespräch: Kaum liegt die Matrix auf dem Tisch, wird sichtbar, welche Teststufen tatsächlich nicht stattfinden und warum. Diese Klarheit entsteht, bevor das Projekt richtig losläuft. Und genau dann ist sie am meisten wert. --- ### Testmanagement: Definition, Aufgaben und Prozess URL: https://www.richard-seidl.com/de/testmanagement/ Testmanagement plant, steuert und schließt Testaktivitäten ab. Dazu die Aufgaben des Testmanagers, der Testprozess und Metriken mit Aussagekraft. Was ist Testmanagement? Testmanagement umfasst die Konzeptionierung, Zeitplanung, Schätzung, Überwachung, Berichterstattung, Steuerung und den Abschluss von Testaktivitäten. Diese Aufzählung beschreibt mehr als eine Rolle mit einem Titel auf der Visitenkarte. Sie umreißt eine Funktion, die dafür sorgt, dass Testaktivitäten zielgerichtet, ressourceneffizient und nachvollziehbar ablaufen, statt sich in gut gemeinter Betriebsamkeit zu verlieren. Ohne Testmanagement entsteht kein reproduzierbarer Prozess. Die Folgen sind in vielen Projekten mit bloßem Auge zu besichtigen: Tests werden ad hoc ausgeführt, Ergebnisse lassen sich nicht vergleichen, Risiken bleiben unkontrolliert. Und am Ende des Projekts weiß niemand mit Bestimmtheit zu sagen, was eigentlich getestet wurde und was nicht. Genau hier setzt Testmanagement an: Es schafft die Grundlage, auf der fundierte Qualitätsentscheidungen überhaupt erst möglich werden, statt Bauchgefühl gegen Termindruck antreten zu lassen. Welche Kernaufgaben hat das Testmanagement? Die Aufgaben des Testmanagements umspannen den gesamten Testprozess, von der ersten Planungsidee bis zum formalen Abschluss: - Planen: Testumfang, Teststrategie, Zeitplan und Ressourcenbedarf festlegen. - Schätzen: Testaufwand realistisch einschätzen, auf Basis von Erfahrungswerten, Projektgröße und Risikoanalyse. - Organisieren: Die Testorganisation aufbauen: Teams aufstellen, Rollen klären, Werkzeuge auswählen, Testumgebungen bereitstellen. - Überwachen: Testfortschritt kontinuierlich verfolgen und Abweichungen früh erkennen. - Steuern: Bei Abweichungen vom Plan eingreifen und Maßnahmen einleiten. - Kommunizieren: Stakeholder regelmäßig über Teststand, Risiken und Qualitätssignale informieren. - Abschließen: Testaktivitäten formal beenden, Erfahrungen dokumentieren, Lessons Learned festhalten. So sauber sich diese Aufgaben aufzählen lassen, so wenig laufen sie in der Praxis nacheinander ab. Überwachung und Steuerung sind Daueraufgaben, solange der Testprozess läuft. Auch die Planung ist kein einmaliges Ereignis zu Projektbeginn. Sie wird fortgeschrieben, sobald die Wirklichkeit vom Plan abweicht, und das passiert in jedem Projekt. Testprozess: Was das Management in jedem Schritt steuert Der Testmanagement-Prozess liegt als Steuerungsschicht über dem eigentlichen Testprozess. Den beschreibt der ISTQB-Lehrplan mit sieben Aktivitäten: Testplanung, Testüberwachung und Teststeuerung, Testanalyse, Testentwurf, Testrealisierung, Testdurchführung und Testabschluss. Das Management ist an jeder dieser Aktivitäten beteiligt, an manchen federführend, an anderen nur mit Prioritäten und Rahmen. Planung und Abschluss gehören dem Testmanagement vollständig. Hier entstehen Testkonzept, Aufwandsschätzung und die Eingangs- und Endekriterien, im Projektalltag meist Ein- und Ausstiegskriterien genannt. Am Ende stehen Testabschlussbericht und Lessons Learned. Überwachung und Steuerung laufen parallel zu allem anderen, vom ersten bis zum letzten Tag. Testanalyse, Testentwurf, Testrealisierung und Testdurchführung sind die fachliche Arbeit des Testteams. Das Management sorgt dort für Prioritäten, Testumgebung und Testdaten und dafür, dass die Testbasis rechtzeitig vorliegt. In der Praxis läuft das selten als Kette ab. Iterationen drehen den Prozess alle zwei Wochen einmal durch, Teststufen überlappen sich, und ein Befund aus der Durchführung ändert die Planung der nächsten Runde. Aus Managementsicht ist der Testprozess deshalb ein Kreislauf mit festen Berichtspunkten. Welche Fragen muss ein Testkonzept beantworten? Das Testkonzept, im ISTQB-Glossar der deutsche Begriff für den Test Plan, ist das Dokument, an dem sich die Steuerung ausrichtet. Es hält fest, was getestet wird, wie es getestet wird, mit welchen Ressourcen und in welchem Zeitrahmen. Ein brauchbares Testkonzept beantwortet zumindest die folgenden Fragen: - Was ist der Testumfang, und was ist explizit ausgeschlossen? - Welche Teststufen werden durchgeführt? - Welche Eingangs- und Endekriterien gelten? - Wer ist für welche Testaktivitäten verantwortlich? - Welche Testdaten, Testumgebungen und Werkzeuge werden benötigt? - Wie wird mit Risiken umgegangen? Zur Testplanung gehört auch die Schätzung des Aufwands. Sie stützt sich auf Erfahrungswerte aus vergleichbaren Projekten, auf die Komplexität der zu testenden Systeme und auf die Ergebnisse der Risikoanalyse. Methoden wie die Dreipunkt-Schätzung oder die Function-Point-Analyse helfen, daraus realistische Werte abzuleiten. Statt einer Zahl, die vor allem den Terminwünschen gefällt. Ein Fehler begegnet einem dabei besonders häufig: das Testkonzept einmal schreiben und danach nie wieder anfassen. Testkonzepte müssen leben. Ändert sich der Projektumfang, verschieben sich Ressourcen oder tauchen unerwartete Risiken auf, muss das Konzept angepasst werden. Sonst verliert es seine Funktion. Ein veraltetes Testkonzept ist kein Steuerungsdokument mehr, sondern Archiv. Und niemand steuert ein Projekt aus dem Archiv heraus. Risiko entscheidet über den Testaufwand Die Teststrategie beschreibt das grundsätzliche Vorgehen auf übergeordneter Ebene. Sie legt fest, welche Teststufen zum Einsatz kommen, welche Testarten relevant sind, wie mit Risiken umgegangen wird und wo die Schwerpunkte liegen. Während das Testkonzept projektspezifisch bleibt, kann eine Teststrategie durchaus organisationsweit gelten und so von Projekt zu Projekt einen gemeinsamen Rahmen vorgeben. Gutes Testmanagement ist risikobasiert, aus einem einfachen Grund: Nicht jede Funktion trägt dasselbe Risiko, und nicht jedes Risiko rechtfertigt denselben Testaufwand. Die Risikoanalyse betrachtet zwei Dimensionen: die Eintrittswahrscheinlichkeit eines Fehlers und die Auswirkung, wenn er tatsächlich auftritt. Funktionen, bei denen beides hoch ausfällt, werden intensiver getestet. Bereiche mit geringem Risiko erhalten bewusst weniger Aufwand. Wichtig dabei: Risikobasiertes Testen ist keine Rechtfertigung, Qualitätssicherung stillschweigend zu kürzen. Es ist eine Methode, Testressourcen dort zu bündeln, wo sie den größten Nutzen bringen. Das gelingt nur, wenn Risiken explizit identifiziert, bewertet und dokumentiert werden. Nicht bloß im Kopf des Testmanagers herumspuken. Testüberwachung, Teststeuerung und Berichte Testmonitoring bedeutet, den laufenden Testprozess zu beobachten und fortwährend mit dem Plan abzugleichen. Teststeuerung bedeutet, bei Abweichungen tatsächlich einzugreifen. Beides läuft über die gesamte Dauer des Testprozesses. Gesteuert wird zum Beispiel, indem das Team Ressourcen neu verteilt, Testprioritäten an das aktuelle Risikobild anpasst oder Testziele nachjustiert, wenn sich Anforderungen geändert haben. Dazu gehört auch, die Eingangskriterien für spätere Teststufen zu prüfen, bevor man in sie hineinläuft. Reporting macht den Teststand für die Stakeholder transparent. Ein guter Statusbericht enthält den aktuellen Testfortschritt, die gefundenen und offenen Fehler nach Schweregrad, die Risikoabdeckung, die Abweichungen vom Plan und eine klare Einschätzung der Qualitätslage. Ein Statusbericht, der über Monate nur grüne Ampeln zeigt, verdient Misstrauen. Entweder hat das Projekt keine Risiken, oder der Bericht lässt sie weg. Zwei Berichte lohnt es sich auseinanderzuhalten. Der Testfortschrittsbericht, im Alltag meist Statusbericht genannt, erscheint regelmäßig während des Testens und zeigt Stand, Abweichungen und Risiken zum Stichtag. Der Testabschlussbericht entsteht einmal, am Ende einer Teststufe, einer Iteration oder eines Releases. Er fasst zusammen, was getestet wurde, was offen bleibt, welche Fehler ungelöst sind und welche Lehren das Projekt mitnimmt. Das Testprotokoll liegt eine Ebene darunter. Es ist die Rohaufzeichnung der Durchführung: welcher Testfall wann mit welchem Ergebnis lief. Berichte verdichten diese Protokolle für Leser, die nicht jeden Testfall kennen. Welche Metriken zählen, und welche täuschen? Metriken machen den Testprozess messbar und geben Diskussionen einen gemeinsamen Bezugspunkt. Zu den wichtigen Metriken im Testmanagement zählen: - Testfall-Fortschritt: geplante gegen ausgeführte gegen bestandene Testfälle. - Fehler-Metriken: gefundene Fehler nach Schweregrad, Verhältnis gefundener zu behobenen Fehlern, Alterung offener Fehler. Diese Zahlen zeigen, wie schnell der Rückstand abgebaut wird, nicht wie gut die Tests sind. - Testüberdeckung: Anforderungsüberdeckung, Code-Überdeckung bei automatisierten Tests. Die Anforderungsüberdeckung setzt Verfolgbarkeit voraus: Jede Anforderung verweist auf mindestens einen Testfall, jeder Testfall auf die Anforderung, die er prüft. - Testeffektivität: Fehler pro ausgeführtem Testfall, Fehlerfindungsrate (Anteil der im Test gefundenen Fehler an allen später bekannt gewordenen). - Risikoabdeckung: Anteil der identifizierten Risiken, die durch Testaktivitäten adressiert werden. So nützlich diese Zahlen sind: Sie bleiben Indikatoren und werden nie zu Wahrheiten. Eine hohe Testüberdeckung bedeutet nicht, dass alle kritischen Szenarien geprüft wurden. Und eine geringe Fehleranzahl kann zweierlei heißen: Die Software ist gut, oder die Tests sind zu schwach, um etwas zu finden. Metriken müssen deshalb immer im Kontext gelesen werden, nie isoliert. Eine Zahl ohne die Geschichte dahinter führt schneller in die Irre, als sie Orientierung gibt. Agile Teams ohne Testmanager-Rolle: Wer managt das Testen? In agilen Umgebungen verteilen sich die klassischen Testmanagement-Aufgaben auf mehrere Schultern, denn das Scrum-Modell kennt keine explizite Testmanager-Rolle. Die Planung findet im Sprint Planning statt, Retrospektiven treten an die Stelle formaler Lessons-Learned-Sitzungen. Beim Daily Scrum lohnt eine Präzisierung: Es ist ein 15-Minuten-Event der Developers, in dem sie den Fortschritt zum Sprint Goal prüfen und bei Bedarf das Sprint Backlog anpassen. Ein Berichtstermin für Testkennzahlen ist es nicht. Blockierende Testbefunde werden dort natürlich sichtbar, aber das eigentliche Testmonitoring läuft daneben, über Dashboards und die Absprachen im Team. Daraus folgt nicht, dass Testmanagement in agilen Projekten überflüssig würde. Nur, dass seine Aufgaben anders zugeschnitten sind. Wer in agilen Teams Testmanagement verantwortet, braucht deshalb vor allem drei Fähigkeiten: ohne formale Hierarchie koordinieren, über Team-Silos hinweg kommunizieren und Qualitätsrisiken sichtbar machen, solange sie noch Risiken sind und keine Incidents. Werkzeuge wie Azure DevOps oder Jira in Kombination mit Erweiterungen wie Xray unterstützen die Verwaltung von Testfällen und Fehlern in iterativen Projekten. Aber sie ersetzen das Denken nicht. Sie schaffen Transparenz, die in schnellen Iterationszyklen anders kaum herzustellen wäre. Und genau diese Transparenz ist es, die aus Werkzeugen einen Nutzen macht. Typische Stolperfallen Einige Fehler tauchen im Testmanagement mit einer gewissen Regelmäßigkeit auf, unabhängig von Branche und Projektgröße. Zu später Testeinstieg: Beginnt die Testplanung erst, wenn die Implementierung bereits läuft, fehlt die Testbasis für die frühen Teststufen. Komponenten werden übergeben, bevor überhaupt Testfälle existieren. Das erzeugt Zeitdruck ausgerechnet in den Phasen, in denen gründliches Testen den größten Unterschied machen würde. Fehlende Endekriterien: Ohne klare Kriterien dafür, wann der Test abgeschlossen ist, wird einfach weitergetestet, bis die Zeit abläuft. Das ist kein Prozess, das ist Improvisation. Endekriterien gehören an den Anfang des Projekts, nicht in die Woche vor dem Release. Metriken als Ziel: Sobald Testteams für hohe Testfallzahlen optimieren statt für Fehleraufdeckung, verlieren ihre Metriken den Sinn. Viele flache Tests, die wenig finden, sind kein Qualitätsmerkmal. Sie sind eine gut aussehende Kennzahl ohne Substanz. Isoliertes Testteam: Test als reines Kontrollgremium am Ende der Prozesskette findet Fehler zu spät und zu teuer. Testmanagement muss in den Entwicklungsprozess integriert sein, mit Testern im Refinement und in der Planung. Als nachgelagerter Filter fängt es nur noch auf, was vorher niemand angeschaut hat. Werkzeug vor Prozess: Erst die Testmanagement-Software kaufen, dann den eigenen Ablauf daran anpassen. Jira mit Xray oder Zephyr, Azure DevOps und ähnliche Werkzeuge verwalten Testfälle, Fehler und Berichte. Den Prozess, den sie verwalten sollen, liefern sie nicht mit. Wer keinen hat, bekommt mit der Lizenz eine aufgeräumtere Form von Unordnung. Aus der Praxis Was ich in Projekten immer wieder sehe, ist weniger ein Mangel an Dokumenten als ein Mangel an Gebrauch: Das Testkonzept existiert, aber niemand schaut mehr hinein. Die Teststrategie wurde im Kick-off präsentiert und seither nie wieder angefasst. Metriken werden brav erhoben, aber nie diskutiert. Das alles ist kein Testmanagement, das ist Dokumentenproduktion. Und dieser Unterschied entscheidet darüber, ob die Arbeit Wirkung entfaltet oder nur Ablage füllt. --- ### Integrationstest: Schnittstellen in der Software prüfen URL: https://www.richard-seidl.com/de/integrationstest/ Der Integrationstest in der Softwareentwicklung prüft, ob Komponenten korrekt zusammenarbeiten. Strategien, Herausforderungen und typische Fehlermuster. Was ist der Integrationstest? Der Integrationstest ist die Teststufe mit dem Schwerpunkt auf dem Zusammenwirken zwischen Komponenten oder Systemen. Üblich ist die Unterscheidung zwischen dem Komponenten-Integrationstest und dem System-Integrationstest. In der Praxis ist der Begriff noch weiter gefasst: Integriert werden Module und Klassen ebenso wie Services, Schichten, Subsysteme oder ganze Systeme unterschiedlicher Hersteller. Schnittstellen sind in verteilten und serviceorientierten Systemen die häufigste Fehlerquelle. Komponenten, die isoliert einwandfrei funktionieren, versagen genau an ihren Grenzen, weil dort Annahmen aufeinandertreffen, die nie gemeinsam geprüft wurden. Der Integrationstest macht diese Schwachstellen sichtbar, bevor sie sich auf Systemebene zu schwer lokalisierbaren Fehlern auswachsen. Einordnung in die Teststufen Komponenten-Integrationstest versus System-Integrationstest Abgrenzungsschema mit zwei Ebenen: Innerhalb des Systems prüft der Komponenten-Integrationstest das Zusammenspiel von Modulen, Klassen oder Schichten. Zwischen Systemen prüft der System-Integrationstest die Zusammenarbeit mehrerer eigenständiger Systeme über Schnittstellen und Datenaustausch. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. In der klassischen Teststufenstruktur steht der Integrationstest zwischen dem Komponenten- und dem Systemtest. Er setzt voraus, dass mindestens zwei Teile des Systems existieren und sich verbinden lassen, und er schließt genau dort an, wo der Komponententest endet: Nicht mehr die einzelne Einheit steht im Fokus, sondern ihre Wechselwirkung mit den anderen Teilen. Diese Abgrenzung ist in der Praxis nicht immer trennscharf, weshalb die Unterscheidung zwischen zwei Varianten hilft. Der Komponenten-Integrationstest prüft das Zusammenspiel von Modulen, Klassen oder Schichten innerhalb desselben Systems. Der System-Integrationstest prüft die Zusammenarbeit mehrerer eigenständiger Systeme über Schnittstellen und Datenaustausch. Beide unterscheiden sich erheblich in Testumgebung, Testdaten und Verantwortlichkeiten. Wer diese Unterschiede ignoriert, produziert Reibung im Projekt. Wie ein Integrationstest konkret aussieht, hängt deshalb stark vom Kontext ab. Ein Team, das Module innerhalb einer Codebasis integriert, testet in der Entwicklungsumgebung, mit lokalen Testdaten und kurzen Feedback-Schleifen. Wer dagegen das eigene System an das eines anderen Herstellers anbindet, braucht eine gemeinsame Testumgebung, abgestimmte Testdaten und Termine, an denen beide Seiten bereitstehen. Das ist kein methodischer Unterschied, sondern ein organisatorischer, und er verändert Aufwand und Ablauf grundlegend. Dazu kommt die Frage der Verantwortung. Innerhalb eines Teams ist klar, wer den Test schreibt und wer den Fehler behebt. An der Grenze zwischen zwei Systemen ist es das oft nicht: Jede Seite testet bis zur eigenen Schnittstelle, und für das Zusammenspiel dazwischen fühlt sich niemand zuständig. Solche Fragen müssen geklärt sein, bevor der erste Testfall entsteht. Sonst entscheidet der Zufall, was geprüft wird. Ziele und Qualitätsmerkmale Ziel des Integrationstests ist es, das korrekte Zusammenspiel der Teile über Schnittstellen und Workflows nachzuweisen. Die Kernfragen sind einfach zu stellen und oft schwer zu beantworten: Sind die ausgetauschten Daten korrekt? Stimmen ihre Strukturen? Werden Fehler korrekt behandelt und weitergegeben? Zum Integrationstest gehören auch die nicht-funktionalen Aspekte. Wie schnell läuft der Datenaustausch, wie viel Last verträgt die Kopplung, wie robust bleibt die Verbindung bei Kommunikationsfehlern oder Timeouts? Diese Fragen werden auf der Integrationsebene häufig ausgelassen. Später tauchen sie als schwer diagnostizierbare Probleme auf Systemebene wieder auf, und dann muss ihre Ursache mühsam zurückverfolgt werden. Integrationsstrategien Integrationsstrategien im Vergleich Vergleich dreier Integrationsstrategien anhand von Baumdiagrammen: Big-Bang integriert alle Komponenten gleichzeitig ohne Reihenfolge. Top-Down integriert von der obersten Schicht abwärts und ersetzt fehlende Unterkomponenten durch Stubs. Bottom-Up integriert von den untersten Komponenten aufwärts und ersetzt fehlende aufrufende Komponenten durch Treiber. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Die Wahl der Integrationsstrategie entscheidet unmittelbar darüber, wie schnell Fehler gefunden werden und wie aufwändig ihre Lokalisation wird. Der Big-Bang-Ansatz integriert alle Komponenten gleichzeitig und prüft anschließend das Gesamtgefüge. Er ist einfach zu planen, aber schwer zu debuggen: Schlägt ein Test fehl, lässt sich die Ursache im komplett verschalteten System nur mühsam eingrenzen. Inkrementelle Strategien sind ihm daher in aller Regel vorzuziehen. Beim Top-Down-Ansatz beginnt die Integration bei der obersten Schicht und arbeitet sich nach unten vor; noch fehlende Unterkomponenten werden durch Stubs ersetzt. Beim Bottom-Up-Ansatz startet man bei den niedrigsten Komponenten und baut nach oben auf; fehlende aufrufende Komponenten simulieren Treiber. Beide Varianten erleichtern die Fehlerlokalisation erheblich, denn die Ursache eines neuen Fehlers ist immer zuerst in der zuletzt integrierten Komponente zu suchen. Gerade in modernen Microservice-Architekturen ist eine klare Integrationsstrategie oft unverzichtbar. Die Dienste kommunizieren über Netzwerkgrenzen hinweg, und schon der Ausfall oder die Verzögerung eines einzelnen Dienstes kann das Verhalten des Gesamtsystems verändern. Testbasis Als Testbasis für den Integrationstest dienen alle Informationen, die das Zusammenspiel der Einzelteile beschreiben: Schnittstellenspezifikationen, Sequenzdiagramme, Anwendungsfälle und API-Dokumentationen, ergänzt um die relevanten Architekturentwürfe und Entwurfsmuster. Auch die nicht-funktionalen Anforderungen an die Schnittstellen gehören zur Testbasis. Reaktionszeiten, Durchsatz und Fehlertoleranz bei Verbindungsabbrüchen müssen explizit spezifiziert und ebenso explizit getestet werden. Offene oder vage Schnittstellenspezifikationen sind hier ein häufiger Risikofaktor: Auf ihrer Grundlage werden Fehler unbemerkt von Komponente zu Komponente weitergereicht, und die spätere Fehlersuche fällt entsprechend aufwändig aus. Testfallableitung Für die Testfallerstellung eignen sich die bewährten strukturierten Entwurfsverfahren: Äquivalenzklassenbildung und Grenzwertanalyse auf Basis der Schnittstellenspezifikationen, Entscheidungstabellen für komplexe Kombinationen von Aufrufparametern, der zustandsbasierte Test für zustandsbehaftete Protokolle und Sessions. Besondere Aufmerksamkeit verdienen die Negativtests: Testfälle mit ungültigen Datenformaten, fehlenden Pflichtfeldern, falsch codierten Zeichensätzen, leeren Antworten oder Verbindungsfehlern. Genau diese Fälle bringen Schnittstellen und Workflows regelmäßig zu Fall. Ein robustes Fehlerhandling an den Grenzen entsteht nicht von selbst, es muss explizit getestet werden. Bei der Testfallerstellung werden zwangsläufig Lücken in der Schnittstellenspezifikation sichtbar. Diese gehören zeitnah mit Architekten, Entwicklern oder den fachlichen Bereichen geklärt, bevor auf Basis falscher Annahmen Tests entstehen, die anschließend das Falsche prüfen. Platzhalter für fehlende Komponenten Test-Doubles: Stub, Treiber und Mock Positionsschema der Test-Doubles um eine zu testende Komponente in der Mitte: Der Stub darunter simuliert die aufgerufene Komponente mit definierten Antworten. Der Treiber darüber simuliert die aufrufende Komponente und stößt den Ablauf an. Der Mock ist eine Erweiterung des Stubs, die zusätzlich mit einem Prüf-Symbol markiert, dass Interaktionen kontrolliert werden. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Bei inkrementellen Integrationsstrategien sind noch nicht alle Komponenten verfügbar. Genau diese Lücken füllen sogenannte Test-Doubles: Platzhalter, die das Verhalten der fehlenden Teile nachbilden. Stubs simulieren aufgerufene Komponenten mit definierten Antworten und erlauben so das Testen von der Aufruferseite, ohne dass die echte Komponente schon existiert. Treiber simulieren umgekehrt die aufrufenden Komponenten und stoßen den zu testenden Ablauf an. Mocks gehen einen Schritt weiter: Sie prüfen zusätzlich, ob die Interaktionen korrekt stattgefunden haben, ob also die richtige Methode mit den richtigen Parametern aufgerufen wurde. Test-Doubles ermöglichen unabhängiges Testen, ohne auf die vollständige Entwicklung aller Beteiligten warten zu müssen. Sie wollen allerdings gepflegt werden. Ein Stub, dessen Verhalten von der echten Komponente abweicht, verfälscht die Testergebnisse und wiegt das Team in falscher Sicherheit. Contract Testing ist eine Methode, die genau das verhindern soll. Testumgebung Die Testumgebung für Integrationstests ist aufwändiger aufzubauen als für Komponententests. Für Komponenten-Integrationstests reicht oft noch die Entwicklungsumgebung. Für System-Integrationstests wird dagegen eine dedizierte Testumgebung notwendig, die alle beteiligten Systeme umfasst. Ein wichtiger Aspekt dabei ist das Monitoring. Wer die Kommunikation zwischen den Teilen analysieren will, braucht Werkzeuge, die den Datenfluss sichtbar machen: Logging, verteiltes Tracing, API-Monitoring. Zu beachten ist allerdings, dass Monitoring-Werkzeuge selbst die Laufzeit beeinflussen können. Bei Performanzmessungen an Schnittstellen wird das relevant. Testdaten Das Testdatenmanagement orientiert sich an der jeweiligen Integrationsebene. Für Komponenten-Integrationstests lassen sich die Testdaten ähnlich wie bei Unit-Tests lokal definieren. Für System-Integrationstests gelten dieselben Anforderungen wie für den Systemtest: realistische, vollständige Datenkonstellationen, die den tatsächlichen Datenaustausch zwischen den Systemen abbilden. Entscheidend ist, dass die Testdaten die Schnittstellen in allen Varianten abdecken: gültige Daten, ungültige Daten, Grenzwerte, Sonderfälle. Und sie müssen gezielt jene Daten enthalten, die Fehler provozieren. Nur so lässt sich die Fehlerbehandlung überhaupt auf die Probe stellen. API-Testing als Kernwerkzeug REST- und GraphQL-APIs sind heute die verbreitetste Form von Schnittstellen, und Werkzeuge wie Postman, REST-assured oder Karate ermöglichen automatisierte Tests direkt auf dieser Ebene. Sie prüfen Datenformate, HTTP-Statuscodes, Fehlerverhalten und Antwortzeiten unmittelbar an der Schnittstelle, ohne den Umweg über eine Benutzeroberfläche. API-Tests sind wartungsärmer als GUI-Tests, liefern schnelle Rückmeldung und lassen sich sauber in CI/CD-Pipelines integrieren. Für serviceorientierte und Microservice-Architekturen sind sie deshalb der primäre Ansatz für den Integrationstest. Das Contract Testing erweitert diesen Ansatz um einen entscheidenden Gedanken. Werkzeuge wie Pact definieren Verträge zwischen dem Consumer und dem Provider einer Schnittstelle, und diese Verträge lassen sich unabhängig von der Gegenseite prüfen, ohne dass beide Systeme ständig echt integriert vorliegen müssen. Das ist besonders wertvoll, wenn mehrere Teams unabhängig voneinander entwickeln und trotzdem sicherstellen müssen, dass ihre Schnittstellen kompatibel bleiben. Testautomatisierung im Integrationstest Bei entwicklungsnahen Integrationstests ist die Automatisierung ein Selbstläufer. Für Komponenten-Integrationstests steht eine Fülle an Frameworks bereit, die sich direkt in den Build-Prozess integrieren lassen, von JUnit über TestNG und pytest bis Jest. Die Tests laufen bei jedem Commit und geben sofortige Rückmeldung. Aufwändiger wird es auf den höheren Integrationsebenen. Sollen zwei eigenständige Systeme automatisiert zusammen getestet werden und unterscheiden sie sich technologisch, steigt der Implementierungsaufwand erheblich. Hier lohnt eine klare Priorisierung: Welche Schnittstellen sind kritisch, welche Fehlerklassen haben die größten Auswirkungen? Genau diese sind die ersten Kandidaten für die Automatisierung. Integrationstest in agilen Projekten Integrationstests sind in agilen Projekten besonders wichtig und werden trotzdem oft vernachlässigt. Die Testpyramide weist ihnen einen eigenen Bereich zu, zwischen den Unit-Tests an der Basis und den System- oder UI-Tests an der Spitze. Schnelle, stabile Integrationstests auf API-Ebene sind der effektivste Weg, um Robustheit im Kleinen wie im Großen sicherzustellen. In den Microservice-Architekturen, die in agilen Teams häufig entstehen, stellt sich die Frage nach dem Integrationstest besonders dringend. Weil die Dienste über Netzwerkgrenzen kommunizieren, kann jede Änderung an einem Dienst Abhängigkeiten in anderen Diensten brechen. Automatisierte Integrations- und Contract-Tests sind hier neben dem Deployment-Prozess selbst die wichtigste Sicherheitslinie. Typische Fehlerklassen und Risiken Bestimmte Fehler werden typischerweise erst im Integrationstest sichtbar: - Falsche oder inkompatible Datenformate an Schnittstellen, etwa unterschiedliche Datumsformate, fehlende Pflichtfelder oder falsche Zeichenkodierung. - Fehlende oder fehlerhafte Fehlerbehandlung bei Kommunikationsfehlern, Timeouts oder unerwarteten HTTP-Statuscodes. - Race Conditions bei asynchroner Kommunikation, die nur unter Last oder bei bestimmten Timings auftreten. - Datenkonsistenzprobleme zwischen Subsystemen nach Teilausfällen oder fehlgeschlagenen Transaktionen. - Sicherheitslücken an Schnittstellen, etwa fehlende Authentifizierung, fehlende Autorisierungsprüfungen oder die unverschlüsselte Übertragung sensitiver Daten. Das größte Risiko ist allerdings ein organisatorisches: dass es gar keine Integrationstests gibt. In vielen Projekten existieren Unit- und Systemtests, während die Integrationsebene schlicht fehlt. Und wo Integration doch getestet wird, ist häufig unklar, wer die Verantwortung trägt: dieses System, jenes System oder das Team, das die Schnittstelle definiert hat. Ohne klare Ownership passiert erfahrungsgemäß genau eins: nichts. Grenzen des Ansatzes Integrationstests prüfen, ob die Teile korrekt zusammenspielen. Die fachliche Korrektheit des Gesamtsystems gegen die Anforderungen weisen sie nicht nach, das ist Aufgabe des Systemtests. Ebenso wenig ersetzen sie die soliden Komponententests unter sich oder den Systemtest über sich. Sie ergänzen beide, ohne eines von beiden überflüssig zu machen. In hochverteilten Systemen mit vielen asynchronen Kommunikationswegen stoßen die klassischen Integrationstests zudem an ihre Grenzen. Hier ergänzt das Chaos Engineering, also das gezielte Einschleusen von Fehlern in laufende Systeme, den klassischen Ansatz um eine Perspektive, die sich vorab kaum vollständig durchspezifizieren lässt. Aus der Praxis Integrationstests werden in der Praxis häufig zu lange aufgeschoben oder ganz weggelassen. Die Ursache ist meist eine Mischung aus unklaren Verantwortlichkeiten und dem spürbaren Aufwand für die Testumgebung. Tritt dann ein Problem an einer Schnittstelle auf, beginnt eine aufwändige Fehlersuche über System- und Teamgrenzen hinweg. Am Ende wird sie deutlich teurer als der Integrationstest, den man sich vorher gespart hat. --- ### Abnahmetest und Akzeptanztest: Definition, Formen, Ablauf URL: https://www.richard-seidl.com/de/abnahmetest/ Abnahmetest, auch Akzeptanztest: Der Auftraggeber prüft vor dem Go-live, ob die Software einsatzbereit ist. Formen, Abnahmekriterien und Ablauf. Was der Abnahmetest prüft, und wer ihn durchführt Der Abnahmetest (englisch acceptance testing) ist die letzte Teststufe vor der Inbetriebnahme einer Software. Er klärt, ob das System für den beabsichtigten Einsatz geeignet ist. Technisch orientierte Teststufen wie der Systemtest prüfen aus Herstellersicht gegen Spezifikationen. Maßgeblich ist hier die Sicht derjenigen, die das System später bezahlen, betreiben oder täglich bedienen. Im Abnahmetest entscheidet sich, ob ein System abgenommen wird. Gegenüber den vorgelagerten Teststufen wechselt der Blickwinkel. Der Hersteller hat beurteilt, ob das System korrekt gebaut wurde. Jetzt beurteilt der Auftraggeber, ob das Richtige gebaut wurde. In der Theorie ist der Ablauf schnell erzählt: Der Kunde testet, nickt zufrieden, der Vertrag gilt als erfüllt, alle sind glücklich. Die Praxis sieht oft anders aus. Abstürze, unklare Bedienung, Funktionen, die fehlen oder anders umgesetzt wurden als gedacht. Statt Zufriedenheit stehen dann Diskussionen im Raum, was ursprünglich wie gemeint war. Der Abnahmetest ist der Moment, in dem sich zeigt, ob die Monate davor gut genutzt wurden. Abnahmetest und Akzeptanztest: Begriffe klären Abnahmetest und Akzeptanztest im Vergleich Venn-Diagramm mit zwei sich überschneidenden Kreisen: Der Abnahmetest betont die formale, oft vertragliche Dimension, der Akzeptanztest betont die Nutzerperspektive. In der Schnittmenge steht, dass beide Begriffe im deutschsprachigen Raum häufig synonym verwendet werden. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Die Begriffe Abnahmetest und Akzeptanztest werden im deutschsprachigen Raum synonym verwendet. Der Abnahmetest trägt eine formale, oft vertragliche Dimension: Sein Ergebnis entscheidet, ob eine Vereinbarung zwischen Auftraggeber und Auftragnehmer als erfüllt gilt. Ein bestandener Abnahmetest kann Zahlungsmeilensteine auslösen, den Übergang in die Wartungsphase einleiten oder den Go-live freigeben. Beide Wörter meinen dieselbe Teststufe. Das ISTQB-Glossar führt sie als Abnahmetest, die zugehörigen Kriterien heißen im Lehrplan Akzeptanzkriterien. Welches Wort ein Team wählt, ändert nichts am Prüfauftrag. Ein Projekt, das Abnahme rein vertraglich denkt, riskiert ein System, das formal abgenommen und im Alltag trotzdem umgangen wird. Welche Formen gibt es, vom Benutzerakzeptanztest bis zum Beta-Test? Der ISTQB-Lehrplan Foundation Level nennt sechs Hauptformen: Benutzerabnahmetest, betrieblicher Abnahmetest, vertraglicher Abnahmetest, regulatorischer Abnahmetest, Alpha-Test und Beta-Test. In den meisten Projekten tragen die ersten beiden das Gewicht. Benutzerakzeptanztest (User Acceptance Testing, UAT), im ISTQB-Lehrplan Benutzerabnahmetest genannt, ist in meinen Projekten die häufigste Form. Repräsentative Endbenutzer testen die Software in Szenarien, die ihrem späteren Arbeitsalltag entsprechen. Das Ziel ist die praktische Tauglichkeit aus Nutzersicht; die technische Vollständigkeit war Aufgabe des Systemtests. Bestanden ist der Test, wenn die Endbenutzer bestätigen, dass sie ihre Arbeit mit der Software erledigen können. Betrieblicher Abnahmetest (Operational Acceptance Testing, OAT) prüft die Betriebstauglichkeit aus Sicht des IT-Betriebs: Backup und Recovery, Monitoring, Wartbarkeit, Performance unter Last und die korrekte Integration in die Betriebsinfrastruktur. Projekte vergessen OAT häufig. Weil es kein fachliches Testen ist, fühlt sich auf Fachseite niemand zuständig, und seine Prüfungen rutschen oft bis in den Livebetrieb. Vertraglicher Abnahmetest (Contract Acceptance Testing) stellt sicher, dass alle vertraglich vereinbarten Anforderungen erfüllt sind. Das Ergebnis hat unmittelbaren Bezug zu den Vertragsbestandteilen und den vereinbarten Abnahmekriterien. Die vertragliche Präzision der Anforderungen wiegt hier deshalb mehr als anderswo. Regulatorischer Abnahmetest findet in regulierten Branchen statt: Medizintechnik, Automotive, Luftfahrt, Finanzwesen. Bevor ein System dort in Betrieb gehen darf, müssen Normen und Nachweispflichten erfüllt sein. Die Abnahme erfolgt nicht allein durch den Kunden, sondern auch durch Behörden oder Zertifizierungsstellen. Alpha- und Beta-Testing sind Sonderformen für Produktsoftware. Alpha-Tests finden beim Hersteller mit einer kontrollierten Gruppe statt, Beta-Tests geben die Software an ausgewählte externe Nutzer in deren realer Umgebung. Beide sind weniger formalisiert als klassische Abnahmetests. Dafür liefern sie Signale zur Marktfähigkeit eines Produkts, die sich aus einer kontrollierten Testumgebung heraus kaum gewinnen lassen. Testbasis und Testziele Die Testbasis für den Abnahmetest sind die fachlichen Vorgaben des Auftraggebers oder Anwenders: Geschäftsprozesse, User Stories, Epics und Anwendungsfälle. Bei Migrationen kann auch die Dokumentation oder Bedienungsanleitung des Altsystems als Testbasis dienen. Oft ist das bewährte System der genaueste vorhandene Beleg dafür, wie sich das neue verhalten soll. Ziel des Abnahmetests ist zu prüfen, ob die funktionalen und nicht-funktionalen Anforderungen aus Kundensicht erfüllt sind. Der Auftraggeber entscheidet, ob seine Konzepte so umgesetzt wurden, wie er sie sich vorgestellt hat. Das Ergebnis ist die finale Abnahme: Das Projekt endet oder geht in die Wartung über, Zahlungsflüsse werden ausgelöst, Schulungen und Produktivsetzung folgen. Auch die nicht-funktionalen Anforderungen gehören zum Abnahmeumfang. Die Abnahme prüft Performance, Usability, Sicherheit und Verfügbarkeit vor dem Go-live, mit derselben Art von Kriterien wie die Funktionen. Wie legt man gute Abnahmekriterien fest? Auftraggeber und Auftragnehmer legen die Abnahmekriterien vor dem Test fest. Sie beschreiben messbar, unter welchen Bedingungen die Software als abnahmefähig gilt. Fehlende oder vage Kriterien sind eine zuverlässige Quelle für Konflikte zwischen Auftraggeber und Auftragnehmer. „Die Software muss benutzerfreundlich sein“ taugt nicht als Abnahmekriterium, weil niemand es prüfen kann. „Alle Kernprozesse aus der vereinbarten Prozessliste müssen fehlerfrei ausführbar sein“ taugt. Ein gutes Abnahmekriterium ist konkret, nachprüfbar und eindeutig formuliert. Zum Aufschreiben haben sich zwei Formate durchgesetzt, der ISTQB-Lehrplan Foundation Level nennt beide. Szenarioorientierte Kriterien folgen dem Gegeben/Wenn/Dann-Muster aus BDD und beschreiben einen Ablauf. Regelorientierte Kriterien sind eine Prüfliste oder eine Tabelle, die Eingaben erwarteten Ausgaben zuordnet. Zu jedem Kriterium gehört dann mindestens ein Testfall, positiv und negativ, und jeder Testfall nennt das Kriterium, das er abdeckt. Im Abnahmemeeting lässt sich das Ergebnis dann Kriterium für Kriterium durchgehen. Weil das Ergebnis des Abnahmetests so weitreichende Konsequenzen hat, kann es bei unklaren Kriterien heiß hergehen. Die Luft in manchen Abnahmemeetings ist spürbar dick, wenn Auftraggeber und Auftragnehmer unterschiedliche Vorstellungen davon haben, was als bestanden gilt. Das ließe sich vermeiden: Kriterien früh und gemeinsam erarbeiten, statt sie erst im Streitfall zu interpretieren. Welche Testumgebung braucht die Abnahme? Das Testobjekt ist das integrierte Gesamtsystem, so wie es in Produktion laufen wird. Schnittstellen zu anderen Systemen sind bereits verbunden und aktiv. Die Applikation wird von außen getestet, genau so, wie die Nutzer sie später täglich bedienen werden. Eine belastbare Aussage zum Testergebnis gibt es nur, wenn die Tests in der finalen Infrastruktur des Kunden oder in einer vollständig produktionsnahen Umgebung stattfinden. Nur dort lassen sich Inkompatibilitäten und Seiteneffekte ausschließen, die in einer abweichenden Testumgebung unsichtbar bleiben. Wird ein System zum ersten Mal produktiv gesetzt, wird gelegentlich sogar die künftige Produktivumgebung direkt für die Abnahmetests genutzt. Virtualisierungs- und Container-Technologien haben die Bereitstellung solcher Umgebungen erheblich vereinfacht und einen guten Teil des früheren Aufwands aufgelöst. Wer erstellt die Testfälle für die Abnahme? Fachliche Anforderungen liegen häufig in Textform vor. Aus diesen Texten sinnvolle Testfälle abzuleiten ist keine triviale Aufgabe. Schon gar nicht, wenn die Tester Fachbereichsexperten oder Endbenutzer sind, die keine Erfahrung mit strukturiertem Testen mitbringen. Methoden wie Äquivalenzklassenbildung oder Grenzwertanalyse sind Fachbereichsexperten in der Regel unbekannt. Ebenso das Wissen, wie man Testfälle dokumentiert, strukturiert und bewertet. Eine kurze Einführung zu Beginn der Abnahmetestaktivitäten zahlt sich hier spürbar aus. Ein paar Stunden Training können die Qualität der Tests eines ganzen Fachbereichs erheblich heben. Am tragfähigsten ist die Kombination beider Welten: strukturierte Testfallmethoden, verbunden mit erfahrungsbasierter Testfallerstellung, die die typischen Arbeitsszenarien der Nutzer abbildet. Der Fachbereich kennt seine Prozesse, die Tester kennen ihre Methoden. Gemeinsam decken sie die echten Arbeitsabläufe ab und die Grenzfälle, die erst strukturierte Verfahren sichtbar machen. Testdaten Die Testdaten für den Abnahmetest stellt der Auftraggeber bereit, oder er steuert sie zumindest. Anonymisierte Produktivdaten sind eine gute Wahl: Sie bilden realistische Szenarien ab und bringen die Eigenheiten echter Datenbestände mit, die sich künstlich nur schwer nachbauen lassen. Alternativ greift das Projekt auf das Testdatenmanagement aus dem Systemtest zurück. In jedem Fall müssen die Testdaten die spätere Anwenderperspektive so genau wie möglich abbilden. Wie läuft die Abnahme ab, von der Planung bis zur Abnahmeerklärung? Im klassischen Projekt ist die Abnahme eine Phase mit klarer Reihenfolge. Die Planung legt Umfang, Beteiligte, Termine, Umgebung und die Eingangskriterien fest: welche Teststufen abgeschlossen, welche Fehler behoben und welche Dokumente geliefert sein müssen, bevor die Abnahme beginnt. Die Vorbereitung umfasst die Abnahmekriterien, die daraus abgeleiteten Testfälle, die Testdaten und eine Einweisung der Fachtester. Die Durchführung folgt dem vereinbarten Testablauf: Jeder Testfall läuft gegen das integrierte Gesamtsystem, der Tester protokolliert das Ergebnis je Testfall und je Kriterium, und jede Abweichung wird ein Fehlerbericht mit Schweregrad. Der Abnahmebericht führt die Ergebnisse zusammen: was die Tester abgedeckt haben, welche Kriterien erfüllt sind, welche Fehler offen bleiben und wie schwer sie wiegen, und wo das Ergebnis von der Vereinbarung abweicht. Auf dieser Grundlage trifft der Auftraggeber die Abnahmeentscheidung. Drei Ausgänge sind üblich: abgenommen, abgenommen unter Vorbehalt (offene Fehler mit vereinbarten Fristen) oder abgelehnt mit festgelegtem Nachtest. Auftraggeber und Auftragnehmer dokumentieren und unterschreiben die Entscheidung, weil sie in der Regel Zahlung, Gewährleistungsfristen und die Übergabe an den Betrieb auslöst. Welche Schritte gelten und wie formal jeder davon ist, unterscheidet sich von Projekt zu Projekt. Regulierte Umgebungen und Festpreisverträge brauchen die volle Abfolge mit Unterschriften; ein internes Produkt kommt mit einer Demo, einer Checkliste und einer kurzen schriftlichen Notiz aus. Auch die Kurzform hält fest, wer welches Kriterium mit welchem Ergebnis geprüft hat. Automatisierung: Einmal am Ende oder in jedem Sprint? In klassischen Projekten läuft der Abnahmetest meist nur ein einziges Mal. Automatisierung lohnt sich dort selten, weil ein einzelner Durchlauf den Aufwand kaum wieder einspielt. In agilen Projekten laufen Akzeptanztests in jedem Sprint, mitunter täglich. Ohne Automatisierung schafft das Team diese Frequenz nicht. Behaviour-Driven Development (BDD) verbindet die fachlichen Akzeptanzkriterien direkt mit ausführbaren Tests: In Frameworks wie Cucumber oder Robot Framework formulieren Fachexperten die Kriterien in lesbarer Sprache, das Framework führt sie automatisiert aus. Fachliche Anforderung und ausführbarer Test stehen dann im selben Text und laufen nicht auseinander. Ein eigenes Abnahmetest-Tool braucht es selten: Testfälle, Ergebnisse und Fehler liegen im Testmanagement-Werkzeug des Projekts, automatisierte Akzeptanztests in einem BDD-Framework. Wie funktioniert die Abnahme in agilen Projekten? In Scrum und Kanban verschiebt sich die Abnahme auf die Sprint-Ebene. Zwei Dinge verwechseln Teams dabei gern: Die Definition of Done beschreibt den Qualitätszustand, den jedes Inkrement erreichen muss, und gilt für das ganze Produkt; der ISTQB-Lehrplan behandelt sie als agilen Namen für die Endekriterien. Die Akzeptanzkriterien beschreiben, was eine einzelne User Story fachlich leisten soll. Beides braucht man, aber das eine ersetzt das andere nicht. Teams, die abnahmetestgetrieben entwickeln (ATDD), schreiben die Abnahmetests vor der Umsetzung der Story; die Tests sind dann zugleich ausführbare Anforderungen. Kontinuierliches Feedback des Auftraggebers oder Product Owners ergänzt den klassischen Abnahmetest am Projektende und nimmt ihm den größten Teil der Last ab. Automatisierte Regressionstests sichern abgenommene Inkremente ab, und vertragliche, regulatorische und Release-Abnahmen bleiben als eigene manuelle Schritte bestehen. Der Sprint-Rhythmus hält den Abstand zwischen zwei Rückmeldungen klein, sodass der Auftraggeber Abweichungen innerhalb eines Sprints sieht. Woran scheitern Abnahmen in klassischen Projekten? In klassischen Projekten treten beim Abnahmetest immer wieder dieselben Schwierigkeiten auf. Nicht-funktionale Anforderungen wurden bis zur Abnahmephase nicht betrachtet und zeigen jetzt ihre Performance- oder Usability-Probleme. Lücken im Requirements Engineering kommen ausgerechnet hier zutage, mit maximalen Konsequenzen, weil kaum noch Zeit zum Nachbessern bleibt. Der Zeitdruck ist hoch, das Projekt soll bald abgeschlossen sein, die Reizbarkeit aller Beteiligten steigt entsprechend. Und den fachlichen Testern fehlen oft die Grundlagen des strukturierten Testens. Am meisten hilft gegen diese Probleme die frühe Einbindung. Je früher Auftraggeber und Endbenutzer im Entwicklungsprozess mitarbeiten, desto weniger Überraschungen bleiben für die Abnahme übrig. Das Agile Manifest macht diese Zusammenarbeit zum Prinzip: Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten. Aus der Praxis Abnahmetests verlaufen selten so entspannt, wie es die Theorie vermuten lässt. Es gibt Projekte, in denen die Abnahme aus drei Klicks besteht und per Handschlag besiegelt wird. Und es gibt Kunden, die für ihre Abnahmen professionelle Testcenter aufbauen. Die Bandbreite ist enorm, die Konsequenzen beider Extreme sind es ebenso. --- ### Testautomatisierung: Definition, Nutzen und Strategie URL: https://www.richard-seidl.com/de/testautomatisierung/ Testautomatisierung führt Tests maschinell aus und lohnt sich für häufige, stabile Funktionstests. Nutzen, Grenzen und was in die Strategie gehört. Was ist Testautomatisierung? Testautomatisierung (englisch: test automation) bezeichnet den Einsatz von Software, um Testaktivitäten maschinell auszuführen, die sonst ein Mensch von Hand erledigen müsste. Der ISTQB-Lehrplan für Testautomatisierungsentwickler (CTAL-TAE, Version 2.0) fasst darunter drei Aktivitäten: Werkzeuge steuern und Testsuiten für die Ausführung einrichten, Tests automatisiert ausführen, tatsächliche mit erwarteten Ergebnissen vergleichen. Die Testberichterstattung schließt der Lehrplan ausdrücklich ein. Automatisierung verkürzt die Rückmeldung an das Team, sichert bestehende Funktionalität nach jeder Änderung ab und macht Testkapazität frei für Aufgaben, die Urteilsvermögen brauchen: exploratives Testen, Usability-Bewertungen und die Entscheidung, was mit welcher Priorität geprüft wird. Diese Aufgaben bleiben Handarbeit. Manuelle Tests lassen sich deshalb nicht eins zu eins durch automatisierte ersetzen. Testautomatisierung läuft über die gesamte Lebensdauer der Software mit. Automatisierte Tests müssen gepflegt, angepasst und weiterentwickelt werden, sobald sich das System ändert, und jede fachliche oder technische Änderung wirkt unmittelbar auf die Testmittel zurück. Dieser Wartungsaufwand gehört von Anfang an in die Planung. Nutzen und Grenzen automatisierter Tests Der ISTQB Foundation Level (Version 4.0) zählt die Nutzen der Testautomatisierung in Kapitel 6.2 auf: Zeitersparnis bei sich wiederholender Arbeit, weniger menschliche Fehlhandlungen durch Konsistenz und Wiederholbarkeit, objektivere Messungen wie die Überdeckung, leichterer Zugang zu Testinformationen für Management und Berichte, kürzere Durchführungszeiten mit früherer Fehlererkennung und mehr Zeit für Tester, neue und intensivere Tests zu entwerfen. Im Projektalltag zeigt sich der größte Effekt bei der Wiederholbarkeit. Ein automatisierter Regressionstest läuft nach jeder Codeänderung, und genau das macht häufige Deployments möglich. Dazu kommt Geschwindigkeit: Eine Regressionssuite läuft maschinell deutlich schneller durch, als jedes Team sie von Hand schafft. Die Grenzen beschreibt dasselbe Kapitel als Risiken: unrealistische Erwartungen an das Werkzeug, unterschätzter Aufwand für Einführung und Pflege der Skripte, Automatisierung dort, wo manuelles Testen besser passt, und zu viel Vertrauen in das Werkzeug auf Kosten des eigenen kritischen Denkens. Ein automatisierter Test kann prüfen, ob ein Button klickbar ist. Ob die Oberfläche verständlich wirkt, kann er nicht beurteilen, weil er nur Ergebnisse vergleicht, die sich maschinell auswerten lassen. Usability, exploratives Testen und Risikoeinschätzung bleiben deshalb beim Menschen, und Tests, die sich häufig ändern, bleiben teure Kandidaten für die Umstellung. Welche Funktionstests lohnt es sich zu automatisieren? Nicht jeder Test ist ein guter Kandidat für Automatisierung; der Maßstab ist der Return on Investment. Als Faustregel eignet sich ein Funktionstest für die Automatisierung, wenn er häufig ausgeführt wird, stabile Anforderungen hat und über klar definierte Erwartungswerte verfügt. Prädestiniert sind Regressionstests, die absichern, dass bestehende Funktionalität durch neue Änderungen nicht beschädigt wird. Regressionstestsuiten laufen viele Male und wachsen mit jedem Release, weshalb der ISTQB-Lehrplan sie ausdrücklich als starke Kandidaten für die Automatisierung nennt. Smoke-Tests vor einem Deployment prüfen, ob ein System überhaupt lauffähig ist, bevor tiefere Tests folgen. Und datengetriebene Tests mit vielen Parametervariationen sind manuell kaum zu schaffen, automatisiert dagegen schnell und zuverlässig. Schlechte Kandidaten sind Tests, die sich häufig ändern, weil jedes neue Feature die Testlogik entwertet. Einmalige Tests, die nach einem Release nicht mehr gebraucht werden, amortisieren ihren Automatisierungsaufwand fast nie. Und Tests, die menschliches Urteil verlangen, ob etwas korrekt aussieht oder schlüssig wirkt, bleiben Handarbeit. Ob ein Test erst manuell läuft oder von Anfang an automatisiert entsteht, hängt vom Vorgehen ab. Wo Teams Test-first oder ATDD einsetzen, steht der automatisierte Test vor dem Feature. Wo ein Feature fachlich noch wackelt, lohnt es sich, es einmal von Hand in Aktion zu erleben, bevor man die Erwartung in Code gießt. Die Automatisierung kritischer Regressionstests gehört in beiden Fällen in die Definition of Done, damit sie nicht als optionale Nacharbeit unter Zeitdruck wegfällt. Welche Tests funktionieren nur automatisiert? Manche Tests sind ohne Automatisierung nicht durchführbar. Last- und Stresstests erfordern viele gleichzeitig agierende Benutzer, die kein Team aus Menschen simulieren kann. Zuverlässigkeitstests prüfen das Systemverhalten im Dauerbetrieb über Stunden oder Tage und liefern erst über die Zeit belastbare Aussagen. Security-Tests brauchen spezialisierte Werkzeuge, um Angriffsmuster überhaupt erzeugen zu können. Fuzzing etwa ist ohne Automatisierung sinnlos, weil erst die schiere Menge zufällig verfremdeter Eingaben die interessanten Fälle trifft. Beim Penetrationstest liegt es anders: Scans und Werkzeugketten laufen automatisiert, der eigentliche Test bleibt eine manuelle, explorative Arbeit, und die verwertbaren Befunde kommen aus Ideen des Testers, die kein Scanner erzeugt. Auch die Prüfung großer und komplexer Datenmengen ist manuell kaum leistbar. Wer die Datenintegrität in einem Data-Warehouse-System oder umfangreiche, hochkonditionale Transformationsregeln prüfen muss, kommt ohne Automatisierung nicht weit. Der manuelle Vergleich ist hier weder in vertretbarer Zeit noch fehlerfrei zu bewältigen. Eine weitere Domäne, in der Automatisierung klare Vorteile hat, ist der Aufbau und die Verwaltung von Testumgebungen für verschiedene Plattformen und Konfigurationen. Container-Technologien wie Docker fahren reproduzierbare Testumgebungen innerhalb von Sekunden hoch, virtuelle Maschinen in wenigen Minuten; beide bringen die Umgebung gezielt in einen definierten Zustand und verwerfen sie anschließend wieder. Was früher tagelange Handarbeit war, wird so zu einem beiläufigen Schritt in der Pipeline. Unit, API, End-to-End: Wie verteilt man automatisierte Tests? Die Testpyramide, die der ISTQB-Lehrplan auf Mike Cohn (2009) zurückführt, beschreibt das empfohlene Verhältnis der Testgruppen: Je höher die Ebene, desto gröber die Granularität, desto geringer die Isolation und desto länger die Durchführungszeit. Die breite Basis bilden viele schnelle Unit-Tests, die einzelne Softwarekomponenten isoliert prüfen. Weil sie auf der tiefsten Architekturebene ansetzen, laufen sie schnell und reagieren kaum auf Änderungen an der Benutzungsoberfläche. Darüber liegen die Integrationstests, die das Zusammenspiel von Komponenten und Diensten prüfen. API-Tests sind hier ein typischer Vertreter: Sie testen über öffentliche Schnittstellen, ohne die grafische Oberfläche einzubeziehen. Das macht sie deutlich wartungsfreundlicher als GUI-Tests, weil Layout- und Bedienänderungen sie nicht berühren. An der Spitze stehen die End-to-End-Tests über die grafische Benutzungsoberfläche. Sie prüfen das Gesamtsystem aus Nutzerperspektive und liefern das realistischste Bild, sind aber langsam, wartungsintensiv und anfällig für jede Oberflächenänderung. Deshalb sollten sie zahlenmäßig die kleinste Gruppe bilden, so wertvoll der einzelne Test auch sein mag. Für den Systemtest heißt das: Die automatisierten Regressionstests laufen bevorzugt über Schnittstellen, über die Oberfläche nur für die wenigen Abläufe, die sich nur aus Nutzersicht beurteilen lassen. Die Pyramide gibt eine Orientierung; die genaue Form hängt von der Architektur ab. Bei Microservice-Architekturen mit vielen Servicegrenzen verschiebt sich das Gewicht zu den Integrationstests, weil viele Fehler erst im Zusammenspiel der Dienste sichtbar werden. Was gehört in eine Test- und Automatisierungsstrategie? In den Projekten, die ich begleite, ist die häufigste Ursache für scheiternde Automatisierung die Wahl des Werkzeugs vor der Strategie. Teams entscheiden sich für ein Framework, weil es modern klingt oder weil ein Kollege gute Erfahrungen damit gemacht hat. Was automatisiert werden soll und wer die Tests langfristig pflegt, hat vorher niemand geklärt. Eine Test- und Automatisierungsstrategie beantwortet die Fragen, die sonst später und teurer zurückkommen: Welche Ziele verfolgt die Automatisierung, und woran misst das Team sie? Welche Teststufen und Testarten automatisiert das Team, welche bleiben manuell? Welche Testdaten braucht es, und woher kommen sie? Wie integrieren sich die automatisierten Tests in die CI/CD-Pipeline? Wer pflegt die Tests, wenn sich die Software ändert? Und welche Qualitätsstandards gelten für den Testcode selbst? Der CTAL-TAE ergänzt die Analyse des Systems unter Test: Welche Art von Anwendung liegt vor, welche Rollen und Fähigkeiten soll die Lösung unterstützen, welche Testdaten stehen in welcher Qualität bereit, und wie lange soll die Lösung leben? Das ISTQB-Glossar nennt das Ergebnis Testautomatisierungsstrategie: eine Beschreibung auf hoher Ebene, wie die langfristigen Ziele der Testautomatisierung unter gegebenen technologischen, organisatorischen und wirtschaftlichen Bedingungen erreicht werden. Testcode braucht dieselben Standards wie der Produktionscode, den er prüft: Versionskontrolle, Code-Reviews, saubere Struktur, verständliche Benennung. Der Lehrplan empfiehlt dafür die Clean-Code-Prinzipien, statische Analyse auch für den Testcode und Entwurfsmuster, wo sie Struktur bringen. Automatisiertes Chaos ist nur schnelleres Chaos, und die Rechnung dafür kommt als Wartungsaufwand und als Tests, denen niemand mehr traut. Agil, DevOps und Shift-Left In agilen Projekten gehört Testautomatisierung von Beginn an dazu. Der ISTQB-Lehrplan begründet das mit dem Regressionsrisiko: Agile Entwicklung rechnet mit Änderungen über das ganze Projekt und setzt deshalb auf leichtgewichtige Dokumentation und umfangreiche Testautomatisierung, die Regressionstests erleichtert. Ein Team, das erst nach mehreren Sprints damit anfängt, läuft einem Berg manueller Regressionstests hinterher, der mit jeder Iteration wächst. DevOps und kontinuierliches Testen setzen Testautomatisierung voraus: Tests laufen nach jedem Commit, und die CI/CD-Pipeline enthält Quality Gates, die einen Build nur weiterlassen, wenn die definierten Tests bestehen. Die Ausführung ist gestuft: Unit- und Komponententests im Build, Integrations- und API-Tests in der Integrationspipeline, Systemtests als letztes Gate vor dem Deployment, langsame End-to-End-Suiten nachgelagert, etwa im Nightly Build. Shift-Left bedeutet, Testaktivitäten früher in den Entwicklungsprozess zu verlagern. Test-Driven Development (TDD) ist die konsequenteste Ausprägung: Die Tests entstehen vor dem Produktionscode und geben die Spezifikation vor. ATDD (Acceptance Test Driven Development) überträgt diesen Gedanken auf die Akzeptanzkriterien und bindet die Fachbereichsexperten direkt in die Testspezifikation ein. So formulieren Fachbereich und Entwicklung die Erwartung von Anfang an gemeinsam. Der Lehrplan ordnet TDD, ATDD und BDD als Test-First-Ansätze ein, deren Tests später als automatisierte Regressionstests weiterlaufen. Wartbarkeit und instabile Tests Die größte Langzeitgefahr für eine Testsuite sind Flaky Tests: Tests, die ohne jede Codeänderung mal bestehen und mal fehlschlagen. Die Ursachen liegen in instabilen Testumgebungen, schlecht verwalteten Testdaten, Zeitabhängigkeiten oder fehlender Isolation zwischen den einzelnen Tests. Heimtückisch sind sie, weil sie kein klares Signal mehr geben. Flaky Tests untergraben das Vertrauen in die gesamte Suite. Sobald ein Team gelernt hat, dass ein fehlgeschlagener Test kein verlässlicher Hinweis auf einen echten Fehler ist, hört es auf, den Ergebnissen zu glauben. In diesem Moment hat die Automatisierung ihren Wert verloren, egal wie viele Tests sie umfasst. Ein Flaky Test gehört deshalb aus der Suite herausgenommen, sobald er als solcher erkannt ist. Erst danach folgen Ursachenanalyse und Behebung. Für GUI-Tests bewähren sich explizite Wartestrategien statt fester Timeouts sowie das Page-Object-Pattern, das die Oberflächenlogik kapselt und die Wartbarkeit spürbar verbessert. Insgesamt braucht Testautomatisierungscode dieselben Qualitätsmerkmale wie guter Produktionscode: wiederverwendbare Bausteine, klare Namenskonventionen, dokumentierte Vor- und Nachbedingungen. Ein gut strukturierter automatisierter Test ist lesbar genug, dass auch ein Tester ohne Entwicklungshintergrund versteht, was er eigentlich prüft. Werkzeugauswahl am eigenen System Für jede Teststufe und jeden Anwendungsfall gibt es spezialisierte Werkzeuge, und das eine Werkzeug, das alle Erfordernisse abdeckt, existiert in der Praxis nicht. Die Web-UI-Automatisierung dominieren Playwright, Selenium und Cypress, wobei Playwright in den letzten Jahren durch automatisches Warten und eine moderne API deutlich an Zuspruch gewonnen hat. Unit-Tests decken in den meisten Sprachen Standardframeworks ab: JUnit und TestNG für Java, pytest für Python, NUnit und xUnit für .NET. Diese Frameworks sind stabil, gut dokumentiert und tief in die gängigen CI/CD-Toolchains integriert. API-Tests lassen sich mit REST-assured, Karate oder Postman/Newman umsetzen, für Last- und Performance-Tests sind Gatling und k6 weit verbreitet, und BDD-Frameworks wie Cucumber oder Robot Framework verbinden die fachliche Anforderung mit dem technischen Test. Welches Werkzeug passt, hängt vom Technologie-Stack, den Fähigkeiten im Team und den Automatisierungszielen ab. Der CTAL-TAE empfiehlt für die Entscheidung eine Vergleichstabelle mit den Anforderungen in den Zeilen und den Kandidaten in den Spalten, und er nennt Low-Code- und No-Code-Lösungen als gangbare Option für Teams ohne Programmiererfahrung. Für Teams mit Programmierkenntnissen hilft ein Werkzeug in der Sprache des Systems unter Test, weil Entwickler und Tester dann gemeinsam Fehler im Automatisierungscode suchen. Der Wurm muss dem Fisch schmecken, nicht dem Angler: Ein Proof of Concept am eigenen System zeigt vor der Kaufentscheidung, ob ein Werkzeug mit den Eigenheiten der Anwendung zurechtkommt. Ein Werkzeug kann eine Technologie grundsätzlich unterstützen und trotzdem an einzelnen Bildschirmelementen einer realen Anwendung scheitern. Wie führt man Testautomatisierung ein? Testautomatisierung einzuführen ist ein Veränderungsprozess mit technischem Anteil. Die Erwartungen in Team und Management müssen von Anfang an realistisch sein: Automatisierung amortisiert sich, aber weder sofort noch auf Knopfdruck. Die Einführung läuft in drei Phasen. Im Pilotprojekt setzt das Team einen überschaubaren Testbereich mit ein oder zwei Werkzeugkandidaten um. Das Ziel ist Lerngewinn: Welches Werkzeug passt zum Stack? Welche Hürden tauchen in der Praxis auf, die in keiner Produktbeschreibung stehen? Welche Testfälle eignen sich wirklich für die Automatisierung? Der CTAL-TAE empfiehlt, schon den Piloten in das CI/CD-System einzubinden, weil Integrationsprobleme dann früh sichtbar werden, und nach dem Piloten den Aufwand gemeinsam mit dem Testmanagement zu bewerten, bevor die Entscheidung für Werkzeug und Strategie fällt. In der Anwendungsphase kommt die Automatisierung erstmals im echten Projektkontext zum Einsatz, begleitet von Coaching, das dem Team beim Aufbau der nötigen Fähigkeiten hilft. Metriken wie Testdurchlaufzeiten, Fehlerquoten und Wartungsaufwand machen den Fortschritt sichtbar und liefern die Zahlen, mit denen sich der Nutzen später belegen lässt. Im Roll-out wird die Automatisierung schließlich auf weitere Teams und Bereiche ausgedehnt, Prozesse werden angepasst, Standards dokumentiert und Schulungsprogramme aufgebaut. Das langfristige Ziel ist ein Team, das Automatisierung als selbstverständlichen Teil des Entwicklungs- und Testprozesses lebt und dafür keine externe Unterstützung mehr braucht. Aus der Praxis Automatisierungsprojekte scheitern selten an der Technik. Sie scheitern an unrealistischen Erwartungen, an fehlender Strategie, an mangelnder Wartungsdisziplin oder an einem Team, das seine eigenen Tests nicht mehr versteht. Die Technik ist am Ende meist das kleinste der Probleme. --- ### Testentwurfsverfahren: Black-Box-Testverfahren im Überblick URL: https://www.richard-seidl.com/de/testentwurfsverfahren/ Elf Testentwurfsverfahren im Überblick: Black-Box- und erfahrungsbasierte Testverfahren in vier Gruppen, mit Vergleichstabelle und Auswahlhilfe für die Praxis. Was sind Testentwurfsverfahren? Ein Testentwurfsverfahren (kurz: Testverfahren) ist ein strukturiertes Vorgehen, mit dem aus der Testbasis, also aus Anforderungen, Modellen, Regeln oder Erfahrungswissen, konkrete Testbedingungen und Testfälle abgeleitet werden. Der Weg vom Anforderungsdokument zum Testfall wird damit nachvollziehbar, wiederholbar und überprüfbar, statt vom Bauchgefühl der Person abzuhängen, die gerade testet. Warum der Aufwand? Aus drei Gründen. Wer systematisch ableitet, übersieht weniger; die Methode zwingt dazu, jeden Aspekt des Testobjekts einmal anzufassen. Wer systematisch ableitet, kann seine Auswahl verteidigen, gegenüber dem Product Owner genauso wie gegenüber einem Auditor. Und wer systematisch ableitet, hat ein Vokabular, mit dem sich das Team über den Testumfang verständigen kann, ohne aneinander vorbeizureden. Wie sich das anfühlt, zeigt jedes Refinement. Ein Tarifrechner in einer Bahn-App hängt von vier Parametern ab, jeder mit drei Ausprägungen: Ticketart, Kundenklasse, Buchungskanal, Reisetag, zusammen 81 Kombinationen. Jemand schlägt vor, “die wichtigsten Fälle” zu testen, und schon diskutiert das Team, welche das sind. Mit Pairwise Testing erübrigt sich die Debatte: Neun gezielt konstruierte Testfälle decken jede Paarung zweier Parameterwerte ab, und die Auswahl ist begründet statt verhandelt. Black-Box, White-Box und erfahrungsbasiert Black-Box, White-Box und erfahrungsbasiert Vergleichsschema dreier Testverfahren-Kategorien: Black-Box-Testverfahren leiten Testfälle aus Spezifikation und beobachtbarem Verhalten ab, der innere Aufbau bleibt außen vor. White-Box-Verfahren arbeiten mit der Code-Struktur, etwa Anweisungs- und Zweigüberdeckung. Erfahrungsbasierte Verfahren nutzen Wissen und Intuition der Tester. Ein Pfeil weist darauf hin, dass die meisten der elf vorgestellten Verfahren Black-Box-Verfahren sind. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Testverfahren lassen sich zunächst in drei Kategorien ordnen. Black-Box-Testverfahren leiten Testfälle aus der Spezifikation und dem beobachtbaren Verhalten ab; der innere Aufbau des Systems bleibt außen vor. White-Box-Verfahren arbeiten umgekehrt mit der Code-Struktur, etwa mit Anweisungs- und Zweigüberdeckung. Erfahrungsbasierte Verfahren nutzen das Wissen und die Intuition der Tester, um gezielt dort zu suchen, wo strukturierte Testfälle vorbeilaufen. Die meisten Verfahren auf dieser Seite sind Black-Box-Testverfahren: Sie brauchen Anforderungen, Regeln oder Modelle als Testbasis, keinen Quellcode. Genau deshalb funktionieren sie auf allen Teststufen, vom Komponententest bis zum Systemtest, und lassen sich früh vorbereiten, oft bevor die erste Zeile Code existiert. Die erfahrungsbasierten Verfahren ergänzen diesen strukturierten Kern. Ersetzen können sie ihn nicht, und umgekehrt gilt dasselbe. Für die Sortierung auf dieser Seite dient eine zweite, feinere Einteilung. Sie stammt aus dem Advanced-Level-Lehrplan für den Test Analyst und gruppiert die Verfahren nach ihrem Ausgangspunkt: Daten, Verhalten, Regeln oder Erfahrung. Die beiden Einteilungen schließen sich nicht aus, sie liegen quer zueinander. Fast alles, was hier folgt, ist Black-Box im Sinne der ersten Einteilung; was sich unterscheidet, ist die Frage, woraus die Testfälle entstehen. Ein Hinweis für alle, die auf eine Zertifizierung zusteuern: Im Foundation Level stecken davon Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellentest, Zustandsübergangstest und der checklistenbasierte Test. Kombinatorischer Test, Zufallstest, CRUD-Test, szenariobasierter Test, metamorpher Test und Massentest kommen erst im Advanced Level Test Analyst vor. Die vier Verfahrensgruppen Die vier Verfahrensgruppen Mindmap der vier Verfahrensgruppen der Testentwurfsverfahren: Datenbasierte Verfahren (Ausgangspunkt Daten) mit Wertebereichstest, Kombinatorischer Test und Zufallstest; Verhaltensbasierte Verfahren (Ausgangspunkt Verhalten) mit CRUD-Test, Zustandsübergangstest und Szenariobasiertem Test; Regelbasierte Verfahren (Ausgangspunkt Regeln) mit Entscheidungstabellentest und Metamorphem Test; Erfahrungsbasiertes Testen (Ausgangspunkt Erfahrung) mit Sitzungsbasiertem Test, Erfahrungsbasierten Checklisten und Massentest. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Elf Verfahren decken zusammen fast jede Testaufgabe ab. Was sie unterscheidet, ist ihr Ausgangspunkt: Daten, Verhalten, Regeln oder Erfahrung. Datenbasierte Verfahren Hier sind die Eingabewerte der Ausgangspunkt. Der Wertebereichstest verbindet Äquivalenzklassenbildung und Grenzwertanalyse und zielt auf die Stellen, an denen Eingabefehler tatsächlich sitzen: die Klassengrenzen mit ihren Off-by-one-Fehlern. Der kombinatorische Test, meist als Pairwise Testing angewendet, prüft das Zusammenspiel mehrerer Parameter mit einem Bruchteil der Vollkombination. Der Zufallstest generiert automatisch große Mengen an Eingaben und erschließt damit Eingaberäume, an denen manuelles Testen scheitert, etwa beim Fuzz-Testing und bei Property-based Tests. Verhaltensbasierte Verfahren Hier stehen Abläufe im Mittelpunkt, also Folgen von Aktionen. Der CRUD-Test geht alle Datenoperationen (Create, Read, Update, Delete) auf allen Entitäten mit allen Akteuren durch; seine Grundlage ist eine CRUD-Matrix, die vor allem Berechtigungslücken sichtbar macht. Der Zustandsübergangstest arbeitet mit formalen Zustandsmodellen und deckt Reihenfolge- und Statusfehler auf, mit klar definierten Überdeckungsmaßen. Der szenariobasierte Test folgt typischen Anwendungspfaden, von der User Story bis zum mehrstufigen Geschäftsprozess, und ist damit das Verfahren mit der größten Nähe zur Anwendersicht. Regelbasierte Verfahren Hier ist die Logik des Testobjekts der Ausgangspunkt. Der Entscheidungstabellentest schreibt Geschäftsregeln mit mehreren verknüpften Bedingungen als Tabelle auf: Jede Spalte ist eine Regel, jede Regel wird ein Testfall, keine Kombination bleibt undiskutiert. Der metamorphe Test (Metamorphic Testing) prüft Beziehungen zwischen Eingaben und Ausgaben und funktioniert damit auch dort, wo niemand das richtige Ergebnis kennt: bei Suchen, Empfehlungssystemen, numerischen Algorithmen und KI-Modellen. Erfahrungsbasiertes Testen Hier zählt, was Menschen sehen, die viel gesehen haben. Der sitzungsbasierte Test gibt explorativem Testen einen Rahmen: zeitlich begrenzte Sitzungen, eine Test-Charta als Auftrag, ein Debriefing am Ende. Erfahrungsbasierte Checklisten gießen das Wissen aus früheren Releases und Bug-Datenbanken in eine überschaubare Zahl fokussierter Prüfpunkte. Massentests verteilen das Testen auf viele parallele Tester und liefern echte Vielfalt an Geräten, Browsern und Bediengewohnheiten, bezahlt mit geringerer Reproduzierbarkeit. Die elf Verfahren im Vergleich Die elf Verfahren im Vergleich Vergleichstabelle der elf Testentwurfsverfahren, nach den vier Gruppen mit unterscheidbaren Musterbalken codiert: Wertebereichstest, Kombinatorischer Test und Zufallstest (datenbasiert); CRUD-Test, Zustandsübergangstest und Szenariobasierter Test (verhaltensbasiert); Entscheidungstabellentest und Metamorpher Test (regelbasiert); Sitzungsbasierter Test, Erfahrungsbasierte Checklisten und Massentest (erfahrungsbasiert). Je Verfahren sind Hauptanwendungsfall und typische Stärke genannt. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Verfahren | Gruppe | Hauptanwendungsfall | Typische Stärke Wertebereichstest | datenbasiert | Eingabevalidierung mit definierten Wertebereichen | findet Off-by-one-Fehler an Klassengrenzen Kombinatorischer Test | datenbasiert | mehrere zusammenwirkende Parameter | prüft Parameter-Wechselwirkungen mit wenigen Testfällen Zufallstest | datenbasiert | sehr große Eingaberäume, Robustheit, Fuzz-Testing | automatisierbar im großen Maßstab CRUD-Test | verhaltensbasiert | datengetriebene Systeme mit Entitäten und Akteuren | deckt Berechtigungslücken systematisch auf Zustandsübergangstest | verhaltensbasiert | Systeme mit klar definiertem Lebenszyklus | findet Reihenfolge- und Statusfehler, messbare Überdeckung Szenariobasierter Test | verhaltensbasiert | End-to-End-Tests, Abnahmetests, Geschäftsprozesse | größte Nähe zur Anwendersicht Entscheidungstabellentest | regelbasiert | Geschäftsregeln mit mehreren Bedingungen | lässt keine Bedingungs-Kombination undiskutiert Metamorpher Test | regelbasiert | Systeme mit Testorakel-Problem (Suche, KI, Numerik) | prüft Konsistenz, wo ein Soll-Ist-Vergleich fehlt Sitzungsbasierter Test | erfahrungsbasiert | explorative Untersuchung neuer Software | findet Bedien- und Wahrnehmungsfehler Erfahrungsbasierte Checklisten | erfahrungsbasiert | wiederkehrende Aufgaben wie Smoke-Tests | konserviert Erfahrungswissen in prüfbarer Form Massentest | erfahrungsbasiert | Endanwender-Software mit großer Gerätevielfalt | echte Vielfalt an Geräten und Bediengewohnheiten Wie wählt man das richtige Verfahren aus? Wie wählt man das richtige Verfahren aus? Entscheidungsbaum mit drei Leitfragen zur Verfahrensauswahl. Frage 1: Welche Risiken und Qualitätsmerkmale stehen auf dem Spiel, mit den Ästen hohe Risiken (mehrere sich ergänzende Verfahren) und niedrige Risiken (schlankere, oft erfahrungsbasierte Tests). Frage 2: Wie ist das Testobjekt beschaffen, mit vier Ästen: klare Wertebereiche führt zum Wertebereichstest, verknüpfte Geschäftsregeln führen zur Entscheidungstabelle, ein definierter Lebenszyklus führt zum Zustandsübergangstest, schwer vorhersagbare Ergebnisse ohne Soll-Ist-Vergleich führen zum metamorphen Test. Frage 3: Was geben Budget, Werkzeuge und Team-Erfahrung her, mit dem Hinweis, dass ein Verfahren ohne Werkzeug- und Team-Unterstützung Theorie bleibt. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Kein einzelnes Testverfahren leistet alles. Wer ausschließlich mit Äquivalenzklassen arbeitet, übersieht Zustandsfehler. Wer nur Szenarien testet, übersieht Sonderfälle in den Eingabewerten. Wer nur exploriert, übersieht systematische Logikfehler. Ein wirksames Testpaket entsteht erst aus der bewussten Kombination. Drei Fragen führen zur Auswahl. Die erste: Welche Risiken und Qualitätsmerkmale stehen auf dem Spiel? Hohe Risiken rechtfertigen mehrere sich ergänzende Verfahren, gerne mit überlappender Abdeckung; niedrige Risiken vertragen schlankere, oft erfahrungsbasierte Tests. Die zweite: Wie ist das Testobjekt beschaffen? Klare Wertebereiche sprechen für den Wertebereichstest, verknüpfte Geschäftsregeln für die Entscheidungstabelle, ein definierter Lebenszyklus für den Zustandsübergangstest, schwer vorhersagbare Ergebnisse für den metamorphen Test. Die dritte: Was geben Budget, Werkzeuge und Team-Erfahrung her? Ein Verfahren, das niemand beherrscht und kein Werkzeug unterstützt, bleibt Theorie, egal wie gut es passt. Als wiederholbarer Ablauf, etwa pro Release: - Risiken identifizieren. Welche Produktrisiken sind im Vorhaben relevant, mit welcher Risikostufe? - Qualitätsmerkmale zuordnen. Welche Merkmale sind betroffen, in welcher Tiefe? - Verfahrenskandidaten ableiten. Pro Risiko die Verfahren bestimmen, die strukturell passen. - Aufwand und Werkzeuge bewerten. Welche Kandidaten sind realistisch umsetzbar? - Kombinieren und festschreiben. Die gewählte Kombination samt Begründung im Testkonzept dokumentieren. Typische Fehler bei der Verfahrensauswahl Beispielhafte Risiko-Verfahren-Matrix Beispielhafte Risiko-Verfahren-Matrix mit vier Risiken als Zeilen (fehlerhafte Eingabegrenzen, widersprüchliche Geschäftsregeln, falsche Zustandsübergänge, fehlende Gerätevielfalt) und vier Verfahren als Spalten (Wertebereichstest, Entscheidungstabellentest, Zustandsübergangstest, Massentest). Ein Häkchen markiert, welches Verfahren welches Risiko abdeckt. Die letzte Zeile fehlende Gerätevielfalt hat kein Häkchen und macht sichtbar, welches Risiko noch ohne Verfahren dasteht. Die vier genannten Risiken sind illustrative Beispiele, keine feststehende Liste. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Zwei gegensätzliche Muster begegnen einem immer wieder. Das erste: das Lieblingsverfahren, angewendet auf alles. Wer jede Aufgabe mit demselben Werkzeug bearbeitet, produziert blinde Flecken genau dort, wo das Werkzeug nicht hinreicht. Das zweite: der Versuch, alles gleichzeitig zu machen. Wer sechs Verfahren parallel fährt, hält keines davon sauber durch. Drei oder vier passende Verfahren, konsequent angewendet, schlagen ein halbes Dutzend halbherzige. Ein wirksames Gegenmittel ist eine einfache Risiko-Verfahren-Matrix: Risiken in den Zeilen, gewählte Verfahren in den Spalten. Auf einen Blick zeigt sich, welches Risiko wodurch abgedeckt ist, welches Risiko noch ohne Verfahren dasteht, und welches Verfahren gar kein Risiko bedient. Das Letzte ist oft ein Hinweis auf Aufwand, den niemand braucht. Und die Auswahl gilt nicht für immer. Ob Geschäftsregeln, Schnittstellen, Sicherheit oder Gerätevielfalt im Vordergrund stehen, ändert sich von Release zu Release, und mit ihnen die passende Verfahrenskombination. Wer die Auswahl einmal trifft und dann mechanisch fortschreibt, verliert genau die Anpassungsfähigkeit, die den Wert der Verfahren ausmacht. Vertiefung Die fünf wichtigsten Verfahren sind hier im Detail beschrieben: Äquivalenzklassen und Grenzwertanalyse, Pairwise Testing, Zustandsübergangstest, Entscheidungstabellentest und Metamorphic Testing. Wer lieber hört statt liest: Im Podcast gibt es Gespräche zu Testentwurfsmethoden und zum Testentwurf mit KI. --- ### Äquivalenzklassen und Grenzwertanalyse: Der Wertebereichstest URL: https://www.richard-seidl.com/de/wertebereichstest/ Äquivalenzklassenbildung und Grenzwertanalyse im Softwaretest: Vorgehen in sechs Schritten, ON/OFF/IN/OUT-Punkte, Überdeckungskriterien und ein Beispiel. Was sind Äquivalenzklassen und Grenzwertanalyse? Äquivalenzklassenbildung und Grenzwertanalyse sind zwei eng verzahnte Black-Box-Testverfahren: Die Äquivalenzklassenbildung zerlegt den Eingabewertebereich in Klassen, die das System gleich behandeln soll, und die Grenzwertanalyse prüft gezielt die Übergänge zwischen diesen Klassen. Zusammen bilden sie das wohl meistgenutzte Gespann unter den Testentwurfsverfahren. Die Idee dahinter ist ökonomisch. Niemand kann ein Eingabefeld mit allen denkbaren Werten testen. Muss auch niemand: Wenn das System die Werte 12 und 19 nachweislich gleich behandelt, reicht einer von beiden als Repräsentant. Interessant wird es an den Rändern. Ob im Code ein Kleiner-Zeichen oder ein Kleiner-gleich steht, entscheidet sich genau am Grenzwert, nirgendwo sonst. Deshalb sitzen die berüchtigten Off-by-one-Fehler fast immer an Klassengrenzen. Wertebereichstest heißt die Weiterentwicklung dieser beiden Techniken auf Advanced-Niveau: dieselbe Grundidee, ergänzt um ein benanntes Punktart-Vokabular (ON, OFF, IN, OUT) und um explizite Überdeckungskriterien. Die Grundtechniken selbst gehören seit jeher zum Foundation Level. Eine Abgrenzung vorab, weil die Suchergebnisse zu diesem Begriff gerne in eine andere Disziplin führen: Äquivalenzklassen gibt es auch in der Mathematik. Dort zerlegt eine Äquivalenzrelation (reflexiv, symmetrisch, transitiv) eine Menge in disjunkte Teilmengen. Der Softwaretest hat sich die Grundidee geborgt, betreibt aber keine Beweisführung. Werte gelten als äquivalent, wenn die Spezifikation sagt, dass das System sie gleich behandeln soll. Wer die mathematische Äquivalenzrelation sucht, ist hier falsch; wer wissen will, wie man mit neun Testfällen ein Eingabefeld absichert, richtig. Wann ist das Verfahren geeignet? Der Wertebereichstest bietet sich an, sobald ein Eingabeparameter einen klar definierten Wertebereich hat: numerische Beträge, Mengen, Datumswerte, Auswahllisten, Längen von Zeichenketten. Auch fachliche Regeln mit Schwellwerten gehören dazu, etwa “Stornierung kostenlos bis 48 Stunden vor Anreise” oder “Frühbucherrabatt ab 60 Tagen Vorlauf”. Seine Stärke liegt bei Eingabevalidierungen und Berechnungslogiken, deren Entscheidungen an einzelnen Werten hängen. Wo dagegen mehrere separate Parameter zusammenwirken, reicht das Verfahren allein nicht aus; dort übernimmt der kombinatorische Test das Zusammenspiel der Parameter. Und wenn Schwellwerte in verknüpfte Geschäftsregeln eingebettet sind, lohnt der Blick auf den Entscheidungstabellentest. Vorgehen in sechs Schritten Vorgehen in sechs Schritten, Wertebereichstest Ablaufkette der sechs Schritte beim Wertebereichstest: Eingabeparameter identifizieren, Wertebereich bestimmen, Äquivalenzklassen bilden, Grenzen bestimmen, Punkte je Grenze festlegen, Testfälle ableiten. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Der Ablauf ist immer derselbe, nur Klassen, Grenzen und Werte ändern sich. Als Beispiel dient das Buchungsformular eines Hotels, in dem die Aufenthaltsdauer als ganze Zahl von 1 bis 28 Nächten zulässig ist. - Eingabeparameter identifizieren. Welche Parameter beeinflussen das zu testende Verhalten? Im Beispiel: das Feld für die Anzahl der Nächte. - Wertebereich bestimmen. Welche Werte sind laut Spezifikation zulässig? Im Beispiel: ganze Zahlen von 1 bis 28, beide einschließlich. - Äquivalenzklassen bilden. Gültige und ungültige Klassen trennen. Im Beispiel vier Klassen: gültig (1 bis 28), ungültig zu klein, ungültig zu groß, ungültig nicht-ganzzahlig (Buchstaben, Kommazahlen, leeres Feld). - Grenzen bestimmen. Pro Klasse die Grenzwerte markieren und festhalten, ob die Grenze zur Klasse gehört (geschlossen, etwa bei kleiner-gleich) oder nicht (offen, etwa bei kleiner). Im Beispiel sind beide Grenzen geschlossen: 1 und 28 sind gültige Werte. - Punkte je Grenze festlegen. Welcher Punkt wo liegt, hängt davon ab, ob die Grenze geschlossen oder offen ist. Bei geschlossener Grenze (die Grenze gehört zur Klasse) sitzt der ON-Punkt auf der Grenze und der OFF-Punkt direkt daneben außerhalb. Bei offener Grenze ist es umgekehrt: Der ON-Punkt ist der letzte Wert innerhalb der Klasse, der OFF-Punkt sitzt auf der Grenze. Der IN-Punkt ist ein typischer Wert mitten in der Klasse, der OUT-Punkt ein Wert außerhalb, der kein OFF-Punkt ist. Im Beispiel sind beide Grenzen geschlossen: ON-Punkte 1 und 28, OFF-Punkte 0 und 29, IN-Punkt 14, OUT-Punkte -3 und 90. - Testfälle ableiten. Aus den Punkten der gewählten Überdeckung entstehen die Testfälle, im Beispiel neun. Ein kompaktes Beispiel Zahlengerade Hotelbuchung, Wertebereichstest Zahlengerade zum Wertebereichstest am Beispiel einer Hotelbuchung mit zulässiger Aufenthaltsdauer von 1 bis 28 Nächten. Markierte Testpunkte: TF-4 bei -3 (OUT, ungültig zu klein), TF-2 bei 0 (OFF, ungültig zu klein), TF-1 bei 1 (ON, untere Grenze, gültig), TF-3 bei 14 (IN, gültig), TF-5 bei 28 (ON, obere Grenze, gültig), TF-6 bei 29 (OFF, ungültig zu groß), TF-7 bei 90 (OUT, ungültig zu groß). Zusätzlich abgesetzt: TF-8 und TF-9 für die nicht-numerische Klasse (Eingabe "xx" und leeres Feld), die sich nicht auf der Zahlengeraden abbilden lassen. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Das Hotel-Buchungsformular aus dem Vorgehen, komplett durchgespielt. Aufenthaltsdauer 1 bis 28 Nächte, alles andere soll eine verständliche Fehlermeldung auslösen: Testfall | Eingabe | Punktart | Erwartetes Verhalten TF-1 | 1 | ON-Punkt der unteren Grenze | Buchung möglich, 1 Nacht TF-2 | 0 | OFF-Punkt der unteren Grenze | Fehlermeldung “Mindestens 1 Nacht” TF-3 | 14 | IN-Punkt | Buchung möglich, 14 Nächte TF-4 | -3 | OUT-Punkt | Fehlermeldung “Mindestens 1 Nacht” TF-5 | 28 | ON-Punkt der oberen Grenze | Buchung möglich, 28 Nächte TF-6 | 29 | OFF-Punkt der oberen Grenze | Fehlermeldung “Maximal 28 Nächte” TF-7 | 90 | OUT-Punkt | Fehlermeldung “Maximal 28 Nächte” TF-8 | ”xx” | Vertreter der ungültigen Klasse “nicht-ganzzahlig” | Fehlermeldung “Bitte ganze Zahl eingeben” TF-9 | (leer) | Vertreter der ungültigen Klasse “nicht-ganzzahlig” | Fehlermeldung “Pflichtfeld” Die Eingaben “xx” und das leere Feld fallen aus dem Punkte-Raster heraus. Sie gehören zur ungültigen Klasse “nicht-ganzzahlig”, und die hat keine Ordnung, also auch keine Grenze, auf die sich ON und OFF beziehen könnten. Getestet werden sie trotzdem, als Vertreter ihrer Äquivalenzklasse. Nur eben nicht als Grenzwerte. Angenommen, im Testlauf liefert TF-2 statt der Validierungsmeldung einen technischen Serverfehler: Die 0 rutscht durch die Oberflächen-Prüfung und erst die Datenbank verweigert den Datensatz. Fachlich “nur” eine falsche Fehlermeldung, technisch ein Hinweis darauf, dass die Eingabevalidierung lückenhaft ist. Ein Test mit einem bequemen Wert aus der Mitte hätte davon nichts gezeigt. Überdeckung: vereinfacht oder zuverlässig Überdeckung vereinfacht oder zuverlässig, Wertebereichstest Dieselbe Zahlengerade wie beim Wertebereichstest-Beispiel, ergänzt um zwei Überdeckungsvarianten. Die vereinfachte Wertebereichsüberdeckung markiert nur die ON- und OFF-Punkte (TF-1, TF-2, TF-5, TF-6). Die zuverlässige Wertebereichsüberdeckung markiert zusätzlich die IN- und OUT-Punkte (TF-3, TF-4, TF-7). ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Zwei Überdeckungskriterien sind beim Wertebereichstest gebräuchlich. Die vereinfachte Wertebereichsüberdeckung verlangt pro Grenze einen ON- und einen OFF-Punkt; das deckt sich mit dem 2-Wert-Schema der Grenzwertanalyse aus dem Foundation Level. Die zuverlässige Wertebereichsüberdeckung fordert pro Grenze zusätzlich einen IN- und einen OUT-Punkt; sie kostet ein paar Testfälle mehr und findet dafür auch Fehler, die nicht direkt an der Grenze sitzen. Gerechnet wird jeweils als Anteil der getesteten an den geforderten Überdeckungselementen. Im Hotel-Beispiel: Die vier Grenzwert-Tests (TF-1, 2, 5, 6) bringen die vereinfachte Überdeckung auf 100 Prozent; für die zuverlässige braucht es zusätzlich IN- und OUT-Punkte, also TF-3, 4 und 7. Derselbe Wert darf dabei mehrere Rollen übernehmen: Die 14 zählt als IN-Punkt für beide Grenzen gleichzeitig, das spart einen Testfall. Für risikoarme Felder genügt die vereinfachte Variante, für geld- oder sicherheitsnahe Validierungen lohnt die zuverlässige. Stärken und Grenzen Die Stärke des Verfahrens: Es liefert mit wenigen Testfällen eine begründbare Abdeckung und zielt auf die häufigste Fehlerklasse bei Eingabevalidierungen, die verrutschte Grenze. Jede Eingabe hat eine benennbare Rolle, die Auswahl lässt sich dokumentieren und im Review verteidigen. Die Grenzen sind genauso klar. Das Verfahren steht und fällt mit der Annahme, dass alle Werte einer Klasse wirklich gleich behandelt werden. Die Implementierung hält sich aber nicht immer an diese Annahme: Ein unauffälliger Wert mitten in der gültigen Klasse kann trotzdem Sondereffekte auslösen, etwa weil er mit einer intern reservierten Konstante kollidiert. Für solche versteckten Sonderfälle braucht es ergänzend Zufallstests oder exploratives Testen. Und bei mehreren zusammenwirkenden Parametern prüft der Wertebereichstest zwar jede Grenze sauber, die Wechselwirkungen zwischen den Parametern aber nicht. Verwandte Verfahren Der kombinatorische Test setzt direkt auf der Äquivalenzklassenbildung auf: Pro Parameter werden erst die Klassen gebildet, dann deren Repräsentanten über Parameter hinweg kombiniert. Der Entscheidungstabellentest übernimmt, wenn Schwellwerte Teil verknüpfter Geschäftsregeln sind. Einen Überblick über alle elf Verfahren und ihre Auswahl gibt die Seite Testentwurfsverfahren. --- ### Pairwise Testing: Der kombinatorische Test URL: https://www.richard-seidl.com/de/kombinatorischer-test/ Pairwise Testing reduziert Testfälle drastisch: Statt aller Kombinationen wird jedes Parameterpaar einmal geprüft. Vorgehen, Beispiel und Überdeckungsstufen. Was ist Pairwise Testing? NIST/NASA-Spannweiten zu Fehlerursachen, Pairwise Testing Bereichsdiagramm der NIST- und NASA-Befunde zu Fehlerursachen in neun untersuchten Systemen (Kuhn/Wallace/Gallo 2004): Einzelwerte lösen je nach System zwischen 29 und 82 Prozent der Fehler aus, Paar-Interaktionen zwischen 47 und 97 Prozent, Dreier-Interaktionen zwischen 89 und 99 Prozent. Die Studie berichtet keine feste Kurve, die Bandbreite wird mit zunehmendem Interaktionsgrad enger, während der größte Zugewinn durchgängig beim Schritt von Einzelwerten zu Paaren liegt. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Pairwise Testing (deutsch: paarweises Testen, die wichtigste Spielart des kombinatorischen Tests) ist ein Testverfahren, das aus allen möglichen Wertekombinationen mehrerer Parameter eine kleine Testmenge auswählt, in der jede Paarung zweier Parameterwerte mindestens einmal vorkommt. Statt das komplette kartesische Produkt abzuarbeiten, wird das Zusammenspiel je zweier Parameter geprüft, und zwar garantiert für jedes Paar. Die Werkzeuge optimieren dabei kräftig, das theoretische Minimum treffen sie aber nicht zuverlässig; die Suche danach ist rechnerisch hart. Entscheidend ist die Garantie, nicht die letzte eingesparte Zeile. Warum das trägt, ist empirisch untersucht, wenn auch nicht so glatt, wie es oft dargestellt wird. Kuhn, Wallace und Gallo haben 2004 für NIST und die NASA die Fehlerdatenbanken von neun realen Systemen ausgewertet, vom medizinischen Embedded-Gerät über Webbrowser und HTTP-Server bis zu einer verteilten wissenschaftlichen Datenbank. Der gemeinsame Befund: Fast alle Fehler hängen an wenigen zusammenwirkenden Parametern. Die Zahlen dahinter gehen allerdings weit auseinander. Einzelne Parameterwerte lösten je nach System zwischen 29 und 82 Prozent der Fehler aus. Rechnet man Paar-Interaktionen dazu, liegt man zwischen 47 und 97 Prozent, bei Dreier-Interaktionen zwischen 89 und 99 Prozent. Die Studie berichtet nirgends eine feste Kurve, und die Autoren schreiben ausdrücklich, dass für eine Verallgemeinerung deutlich mehr Datensätze nötig wären. Für die Praxis bleibt trotzdem ein klarer Schluss: Der Sprung von Einzelwerten zu Paaren bringt in jedem untersuchten System den mit Abstand größten Zugewinn, der Schritt zu Dreier-Interaktionen deutlich weniger. Wo genau die eigenen Zahlen liegen, hängt vom System ab. Dass Pairwise der wirtschaftlichste Einstieg ist, gilt über alle neun. Der kombinatorische Test zählt zu den datenbasierten Testentwurfsverfahren. Über das Paar hinaus lässt er sich verallgemeinern: Bei der t-way-Überdeckung kommt jedes Tupel aus t Parameterwerten mindestens einmal vor, Pairwise ist der Fall t gleich 2. Wann ist das Verfahren geeignet? Überall dort, wo mehrere Parameter mit klar definierten Werten zusammenspielen und vollständiges Testen unwirtschaftlich wäre. Typische Felder: Konfigurationstests über Browser, Betriebssystem, Auflösung und Sprache; Geschäftsregeln mit mehreren Faktoren; Schnittstellen mit vielen optionalen Parametern; systematische Berechtigungstests. Voraussetzung ist, dass sich der Eingaberaum als endliche Liste von Parametern mit endlich vielen Werten beschreiben lässt. Kontinuierliche Wertebereiche werden vorab per Äquivalenzklassenbildung auf wenige Repräsentanten reduziert. Beide Verfahren greifen also ineinander: Der Wertebereichstest geht in die Tiefe einzelner Klassen und ihrer Grenzen, der kombinatorische Test in die Breite über mehrere Parameter. Der Spareffekt wächst mit der Parameterzahl. Bei zwei Parametern gibt es nichts zu holen, da ist die Vollkombination selbst klein. Ab drei Parametern mit mehreren Werten wird der Unterschied spürbar, ab vier Parametern liegt oft ein Faktor fünf bis zehn zwischen Vollkombination und Pairwise-Suite. Vorgehen in fünf Schritten - Parameter identifizieren. Welche Eingabeparameter beeinflussen das Verhalten gemeinsam? - Werte pro Parameter bestimmen. Bei kontinuierlichen Bereichen vorab durch Äquivalenzklassen reduzieren. - Interaktionsstufe wählen. Üblich ist Pairwise (t gleich 2); bei hoher Risikostufe oder bekannten Dreifach-Abhängigkeiten t gleich 3. - Testfallmenge erzeugen. Ein Werkzeug berechnet den optimierten Testsatz, der alle Paare abdeckt. - Ausführen und auswerten. Fällt bei Fehlerwirkungen ein bestimmtes Parameterpaar auf, deutet das auf einen Interaktionsfehler hin. Ein kompaktes Beispiel Pairwise-Matrix Mietwagen-Buchung Drei 3-mal-3-Pairwise-Matrizen für das Mietwagen-Beispiel, untereinander angeordnet, mit den Parametern Fahrzeugklasse (Kompakt, Kombi, SUV), Zahlungsart (Kreditkarte, PayPal, Rechnung) und Abholstation (Flughafen, Bahnhof, Innenstadt). Jede der drei möglichen Parameterpaarungen ist vollständig abgedeckt: Jede Zelle jeder Matrix trägt genau eine der neun Testfallnummern TF-1 bis TF-9. Kontrastiert mit der Vollkombination von 27 möglichen Kombinationen aller drei Parameter zusammen. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Die Buchungsstrecke eines Mietwagen-Portals hat drei Parameter mit je drei Werten: Fahrzeugklasse (Kompakt, Kombi, SUV), Zahlungsart (Kreditkarte, PayPal, Rechnung) und Abholstation (Flughafen, Bahnhof, Innenstadt). Die Vollkombination ergäbe 3 × 3 × 3 = 27 Testfälle. Eine paarweise optimierte Suite kommt mit neun aus: TF | Fahrzeugklasse | Zahlungsart | Abholstation 1 | Kompakt | Kreditkarte | Flughafen 2 | Kompakt | PayPal | Bahnhof 3 | Kompakt | Rechnung | Innenstadt 4 | Kombi | Kreditkarte | Bahnhof 5 | Kombi | PayPal | Innenstadt 6 | Kombi | Rechnung | Flughafen 7 | SUV | Kreditkarte | Innenstadt 8 | SUV | PayPal | Flughafen 9 | SUV | Rechnung | Bahnhof Nachzählen lohnt sich: Jede Fahrzeugklasse trifft jede Zahlungsart genau einmal, jede Zahlungsart jede Station, jede Klasse jede Station. Alle 27 Wertepaare sind abgedeckt, mit einem Drittel der Vollkombination. Angenommen, im Testlauf schlägt TF 6 fehl: Beim Kauf auf Rechnung mit Abholung am Flughafen unterbleibt die Bonitätsprüfung, die für Rechnungszahlung vorgeschrieben ist, weil die Flughafen-Station einen eigenen, älteren Checkout-Pfad nutzt. Das ist eine Interaktion aus genau zwei Werten (Rechnung und Flughafen), unabhängig von der Fahrzeugklasse. Solche Paar-Fehler findet die Pairwise-Suite nicht zufällig, sondern garantiert, denn das Paar kommt in mindestens einem Testfall vor. Überdeckung und Erfolgskriterien Testfallzahlen im Vergleich, kombinatorischer Test Balkenvergleich der drei Testfallzahlen im Mietwagen-Beispiel: Vollkombination 27 Testfälle, Pairwise-Überdeckung 9 Testfälle, Basisauswahlüberdeckung 7 Testfälle. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Zwei Kriterien ergänzen sich in der Praxis. Die Basisauswahlüberdeckung startet mit einem Basistestfall aus den repräsentativsten Werten und variiert dann je Parameter jeden weiteren Wert einzeln; im Mietwagen-Beispiel ergibt das 1 + (2 + 2 + 2) = 7 Testfälle. Sie stellt sicher, dass jeder Wert einmal vorkommt, sagt aber nichts über Wechselwirkungen. Die paarweise Überdeckung misst dagegen den Anteil der abgedeckten Wertepaare an allen möglichen; Ziel sind 100 Prozent. Was die Stufen konkret bedeuten, zeigt das Beispiel: Drei Testfälle reichen, um alle neun Einzelwerte einmal zu zeigen, decken aber höchstens neun der 27 Paare ab, also ein Drittel. Die Pairwise-Suite mit neun Testfällen erreicht alle 27 Paare und nebenbei neun der 27 Dreier-Kombinationen. Wer alle Dreier-Kombinationen will, landet bei drei Parametern zwangsläufig bei der Vollkombination, denn 3-way und Vollkombination fallen hier zusammen. Als Faustregel bewährt sich: Pairwise als Standard, plus gezielte Zusatztests für einzelne Kombinationen mit besonderem Risiko. Stärken und Grenzen Die Stärke liegt auf der Hand: garantierte Paar-Abdeckung bei einem Bruchteil des Aufwands, gut automatisierbar, und das Parameter-Modell lässt sich über Releases wiederverwenden. Kommt eine vierte Fahrzeugklasse dazu, wird das Modell um einen Wert erweitert und die Suite neu generiert, statt Testfälle von Hand nachzuziehen. Drei Grenzen gehören dazu. Erstens findet Pairwise keine Fehler, die ausschließlich aus dem Zusammenspiel von drei oder mehr Parametern entstehen; für bekannte Dreifach-Abhängigkeiten braucht es t gleich 3 oder gezielte Ergänzungen. Zweitens verlangen Constraints, also unzulässige Wertekombinationen (etwa: am Bahnhof keine SUV-Abholung), Werkzeugunterstützung, sonst enthält die Suite unausführbare Tests. Drittens ist die Paar-Überdeckung nur so gut wie die gewählten Repräsentanten; schlecht geschnittene Äquivalenzklassen bleiben schlecht, egal wie clever man sie kombiniert. Die Rechenarbeit übernehmen Werkzeuge: ACTS (frei, von NIST gepflegt), PICT (frei, von Microsoft) oder Hexawise (kommerziell). Pairwise-Suiten von Hand zu konstruieren ist heute nur noch als Fingerübung interessant. Verwandte Verfahren Der Wertebereichstest liefert die Vorarbeit: Er bildet pro Parameter die Äquivalenzklassen, deren Repräsentanten der kombinatorische Test dann verbindet. Lösen die Kombinationen klare Geschäftsregeln aus, ergänzt der Entscheidungstabellentest, weil er jede Regel explizit macht. Einen Überblick über alle elf Verfahren gibt die Seite Testentwurfsverfahren. --- ### Zustandsübergangstest: Lebenszyklen systematisch testen URL: https://www.richard-seidl.com/de/zustandsuebergangstest/ Der Zustandsübergangstest prüft Systeme mit Zuständen und Übergängen: Zustandsübergangstabelle, 0-Switch- und 1-Switch-Überdeckung, Vorgehen und Beispiel. Was ist der Zustandsübergangstest? Der Zustandsübergangstest ist ein verhaltensbasiertes Black-Box-Testverfahren, das Testfälle aus einem Zustandsmodell ableitet: aus der endlichen Menge der möglichen Zustände eines Systems, den Ereignissen, die Zustandswechsel auslösen, und den erlaubten Übergängen dazwischen. Dahinter steht eine einfache Beobachtung: Viele Systeme haben ein Gedächtnis. Dieselbe Aktion führt je nach Vorgeschichte zu unterschiedlichen Ergebnissen. Ein “Update starten” bedeutet etwas anderes, wenn das Gerät gerade im Normalbetrieb läuft, als wenn bereits eine Installation im Gang ist. Wer nur Eingaben testet und die Vorgeschichte ignoriert, testet an solchen Systemen vorbei. Gearbeitet wird mit dem Zustandsübergangsdiagramm oder der Zustandsübergangstabelle. Beide transportieren denselben Inhalt; die Tabelle führt pro Zeile einen erlaubten Übergang auf, mit aktuellem Zustand, auslösendem Ereignis, Folgezustand und optionaler Aktion. Daraus entstehen Testpfade, die einzelne Übergänge, Übergangsfolgen oder komplette Wege durch das System prüfen. Der Zustandsübergangstest gehört zum Standardrepertoire der Testentwurfsverfahren. Wann ist das Verfahren geeignet? Überall dort, wo Objekte oder Prozesse einen klaren Lebenszyklus durchlaufen: Bestell- und Reklamationsprozesse, Authentifizierungsabläufe (angemeldet, gesperrt, freigeschaltet), Firmware- und Gerätelebenszyklen, Genehmigungs-Workflows, Vertragsphasen. Ein praktischer Nebeneffekt: Enthalten die Anforderungen bereits ein Zustandsmodell, dient es direkt als Testbasis. Fehlt es, entsteht es während der Testanalyse, und dabei kommen regelmäßig Lücken in den Anforderungen ans Licht, lange bevor der erste Test läuft. Die Tabellenform erzwingt nämlich Vollständigkeit: Für jeden Zustand muss beantwortet werden, welche Ereignisse vorkommen können und was bei nicht spezifizierten Ereignissen passieren soll. Im Diagramm übersieht man einen fehlenden Pfeil leicht, in der Tabelle fällt die leere Zelle auf. Weniger geeignet ist das Verfahren für sehr große oder hochgradig parallele Zustandsräume. Laufen mehrere unabhängige Zustände gleichzeitig, etwa der Gerätezustand und der Zustand der Cloud-Verbindung, wächst der kombinierte Raum als Produkt der Einzelzustände. Dann hilft Hierarchisierung oder die Trennung in mehrere kleinere Maschinen. Kontinuierliche Größen wie Sensorwerte müssen vorab in Klassen abstrahiert werden. Vorgehen in fünf Schritten - Zustände identifizieren. Welche unterscheidbaren Zustände kann das Objekt einnehmen? - Ereignisse und Übergänge identifizieren. Welche Ereignisse lösen Zustandswechsel aus, welche Übergänge sind erlaubt? Ergebnis ist die Zustandsübergangstabelle. - Überdeckungsmaß wählen. Üblich sind Zustandsüberdeckung (jeder Zustand einmal besucht) und die N-Switch-Maße: 0-Switch testet jeden Übergang einmal, 1-Switch jede Abfolge von zwei Übergängen. - Testpfade ableiten. Pfade durch das Modell bilden, die die gewählten Überdeckungselemente abdecken. - Testfälle ausformulieren. Pro Pfad ein Testfall mit Anfangszustand, Ereignissequenz und erwarteten Zwischen- und Endzuständen. Ein kompaktes Beispiel Zustandsautomat Router-Firmware-Update Zustandsdiagramm der Router-Firmware mit fünf Zuständen (Betrieb, Download, Installation, Neustart, Rollback) und sieben beschrifteten Übergängen: Betrieb zu Download durch Update starten, Download zu Installation durch Paket vollständig, Download zurück zu Betrieb durch Verbindung abgebrochen, Installation zu Neustart durch Installation erfolgreich, Installation zu Rollback durch Prüfsumme falsch, Rollback zurück zu Betrieb durch Rollback abgeschlossen, Neustart zurück zu Betrieb durch System hochgefahren. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Übergangsbaum der drei Testpfade, Zustandsübergangstest Übergangsbaum der drei Testpfade für die 0-Switch-Überdeckung, von oben nach unten verzweigt vom gemeinsamen Startzustand Betrieb aus. TF-1 durchläuft Betrieb, Download, Installation, Neustart, zurück zu Betrieb mit dem Endergebnis Betrieb, neue Version aktiv. TF-2 durchläuft Betrieb, Download, zurück zu Betrieb mit dem Endergebnis Betrieb, Wiederholung eingeplant. TF-3 durchläuft Betrieb, Download, Installation, Rollback, zurück zu Betrieb mit dem Endergebnis Betrieb, alte Version, Störungsmeldung. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Das Firmware-Update eines Routers durchläuft fünf Zustände: Betrieb, Download, Installation, Neustart, Rollback. Sieben Übergänge sind spezifiziert: Aktueller Zustand | Ereignis | Folgezustand | Aktion Betrieb | Update starten | Download | Fortschritt anzeigen Download | Paket vollständig | Installation | Prüfsumme berechnen Download | Verbindung abgebrochen | Betrieb | Wiederholung einplanen Installation | Installation erfolgreich | Neustart | Neustart auslösen Installation | Prüfsumme falsch | Rollback | alte Version wiederherstellen Rollback | Rollback abgeschlossen | Betrieb | Störungsmeldung senden Neustart | System hochgefahren | Betrieb | neue Version aktivieren Für 0-Switch-Überdeckung reichen drei Pfade: TF | Sequenz | Erwarteter Endzustand 1 | Betrieb → Download → Installation → Neustart → Betrieb | Betrieb, neue Version aktiv 2 | Betrieb → Download → Verbindung abgebrochen → Betrieb | Betrieb, Wiederholung eingeplant 3 | Betrieb → Download → Installation → Prüfsumme falsch → Rollback → Betrieb | Betrieb, alte Version, Störungsmeldung Angenommen, TF 3 fällt durch: Das Rollback stellt die alte Version korrekt wieder her, aber die Störungsmeldung an das Monitoring bleibt aus. Der Zustandswechsel stimmt, die Aktion auf dem Übergang nicht. Ohne die explizite Aktionsspalte in der Tabelle wäre dieser halbe Fehler leicht als “funktioniert doch” durchgerutscht. Die Überdeckungsrechnung zu diesem Modell (5 Zustände, 7 Übergänge, 9 gültige Übergangspaare): Überdeckungsrechnung Router-Firmware-Modell Balkendiagramm der Überdeckungsrechnung für das Router-Firmware-Modell (5 Zustände, 7 Übergänge, 9 gültige Übergangspaare) in drei Testumfang-Gruppen. Nur Happy Path (TF-1): Zustandsüberdeckung 80 Prozent, 0-Switch 57 Prozent, 1-Switch 33 Prozent. Alle drei Pfade: Zustandsüberdeckung 100 Prozent, 0-Switch 100 Prozent, 1-Switch 67 Prozent. Plus ein langer Wiederholungspfad: alle drei Werte 100 Prozent. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Testumfang | Zustandsüberdeckung | 0-Switch | 1-Switch nur Happy Path (TF 1) | 4 von 5 = 80 % | 4 von 7 = 57 % | 3 von 9 = 33 % alle drei Pfade | 5 von 5 = 100 % | 7 von 7 = 100 % | 6 von 9 = 67 % plus ein langer Wiederholungspfad | 100 % | 100 % | 9 von 9 = 100 % Die drei fehlenden Übergangspaare betreffen alle denselben Fall: den erneuten Update-Start, nachdem das Gerät nach Abbruch, Rollback oder erfolgreichem Update in den Betrieb zurückgekehrt ist. Ein einziger langer Pfad, der mehrere Update-Versuche hintereinander fährt, schließt die Lücke. Genau solche Wiederholungen sind im Feld Alltag und im Testlabor chronisch untergetestet; die Rechnung macht das sichtbar, das Bauchgefühl nicht. Überdeckung und Erfolgskriterien 0-Switch-Überdeckung, Zustandsübergangstest Zustandsautomat der Router-Firmware mit fünf Zuständen (Betrieb, Download, Installation, Neustart, Rollback) und sieben gerichteten Übergängen: Betrieb zu Download durch Update starten, Download zu Installation durch Paket vollständig, Download zurück zu Betrieb durch Verbindung abgebrochen, Installation zu Neustart durch Installation erfolgreich, Installation zu Rollback durch Prüfsumme falsch, Rollback zurück zu Betrieb durch Rollback abgeschlossen, Neustart zurück zu Betrieb durch System hochgefahren. Alle sieben Übergänge sind hervorgehoben: Das ist die vollständige 0-Switch-Überdeckung, jeder Übergang wird mindestens einmal durchlaufen. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Vier Maße tragen die Praxis. Die Zustandsüberdeckung verlangt nur, dass jeder Zustand einmal aktiv war; sie ist das schwächste Kriterium. Die 0-Switch-Überdeckung verlangt jeden Übergang mindestens einmal, die 1-Switch-Überdeckung jedes Paar aufeinanderfolgender Übergänge. Für Modelle mit Schleifen kommt die Rundreiseüberdeckung dazu: Jede minimale Sequenz, die in einem Zustand beginnt und in demselben endet, wird einmal durchlaufen. Schleifen sind in Lebenszyklen typische Fehlerquellen, deshalb zahlt sich dieses Kriterium überproportional aus. Die Wahl folgt der Risikolage. Für risikoarme Abläufe reicht 0-Switch. Wo Folgefehler wehtun, etwa bei allem, was Geld bewegt oder Geräte im Feld betrifft, lohnt 1-Switch, weil sich viele Fehler erst in der Kombination zweier Übergänge zeigen. Stufen oberhalb von 2-Switch bleiben sicherheitskritischen Systemen vorbehalten; ihr Aufwand wächst exponentiell. Stärken und Grenzen Die Stärke des Verfahrens: Es macht Reihenfolge- und Statusabhängigkeiten systematisch sichtbar, deckt Übergangsfehler und nicht spezifizierte Ereignisse auf und liefert messbare Überdeckungskriterien, mit denen sich der Testumfang begründen lässt. Das Modell taugt nebenbei als Kommunikationsgrundlage mit Stakeholdern. Die Grenzen: Das System muss tatsächlich endlich viele, klar unterscheidbare Zustände haben. Sehr große und parallele Zustandsräume sprengen das Modell; kontinuierliche Werte brauchen Vorarbeit. Und wie jedes modellbasierte Verfahren prüft der Zustandsübergangstest nur, was im Modell steht. Ein unvollständiges Modell erzeugt vollständig wirkende Tests, das ist seine tückischste Schwäche. Ein Praxisrat noch: mit der Tabelle anfangen, nicht mit dem Diagramm. Die Tabelle ist textlich, versionierbar, leicht zu reviewen und werkzeuggestützt weiterverarbeitbar. Das hübsche Diagramm entsteht daraus als Visualisierung, nicht umgekehrt. Verwandte Verfahren Der CRUD-Test prüft Berechtigungen auf Datenoperationen, aber ohne Reihenfolgebezug; er ergänzt den Zustandsübergangstest bei datengetriebenen Systemen. Der szenariobasierte Test verfolgt Anwendungspfade ohne formales Zustandsmodell und passt, wenn die Anwendersicht wichtiger ist als die formale Überdeckung. Geht es um Regeln statt um Abläufe, ist der Entscheidungstabellentest das passende Werkzeug. Einen Überblick über alle elf Verfahren und ihre Auswahl gibt die Seite Testentwurfsverfahren. --- ### Entscheidungstabellentest: Geschäftsregeln vollständig prüfen URL: https://www.richard-seidl.com/de/entscheidungstabellentest/ Der Entscheidungstabellentest macht Geschäftsregeln explizit: Aufbau der Entscheidungstabelle, Reduktion, Prüfsummenverfahren und ein durchgerechnetes Beispiel. Was ist der Entscheidungstabellentest? Der Entscheidungstabellentest ist ein regelbasiertes Black-Box-Testverfahren für Logiken, deren Verhalten von einer Kombination mehrerer Bedingungen abhängt: Die Geschäftsregel wird als Entscheidungstabelle aufgeschrieben, und aus jeder Spalte dieser Tabelle entsteht ein Testfall. Die Entscheidungstabelle selbst ist eine Matrix. Oben stehen die Bedingungen, unten die Aktionen, und jede Spalte ist eine Regel: eine konkrete Bedingungs-Kombination mit den Aktionen, die daraus folgen sollen. Der Reiz dieser Form liegt in ihrer Unerbittlichkeit: Sobald die Regel als Tabelle vorliegt, hat jede denkbare Kombination eine Spalte, und jede Spalte erzwingt eine Antwort. Es gibt keinen Sonderfall mehr, über den einfach niemand nachgedacht hat. Das Verfahren prüft damit mehr als die Reaktion auf einzelne Bedingungen: Es prüft, ob jede Kombination die jeweils richtige Aktion auslöst. Genau da verstecken sich die Fehler, die stichprobenhaftes Testen übersieht: der Fall, in dem zwei Regeln gleichzeitig greifen sollten und nur eine es tut. Der Entscheidungstabellentest gehört zu den regelbasierten Testentwurfsverfahren. Wann ist das Verfahren geeignet? Überall dort, wo Geschäftsregeln mehrere Bedingungen verknüpfen: Tarif- und Rabattlogiken, Versicherungsprüfungen, Genehmigungsregeln, Berechtigungsprüfungen, Validierungen mit mehreren Feldern. In all diesen Fällen lässt sich das gewünschte Verhalten als Tabelle ausdrücken, was den Testentwurf erleichtert und oft auch die Anforderung selbst präzisiert. Bei einer oder zwei Bedingungen ist das Verfahren meist Overkill; da reichen direkte Testfälle oder eine Grenzwertanalyse. Ab drei Bedingungen wird es interessant, ab vier oder fünf praktisch unverzichtbar, weil dann niemand mehr alle Kombinationen im Kopf behält. Ein Nebeneffekt zeigt sich schon vor dem ersten Test: Beim Aufstellen der Tabelle kommen Widersprüche und Lücken in den Anforderungen ans Licht, widersprüchliche Regeln, fehlende Kombinationen, Bedingungen, die sich gegenseitig ausschließen. Die Tabelle wirkt als statisches Prüfinstrument für die Spezifikation selbst. Gut gepflegt überlebt sie mehrere Releases als verlässlichste Beschreibung der Regel, idealerweise gemeinsam mit Product Owner und Entwicklung gepflegt, direkt in der Anforderung oder als Anhang zur User Story. Vorgehen in fünf Schritten Vorgehen in fünf Schritten, Entscheidungstabellentest Ablaufkette der fünf Schritte beim Entscheidungstabellentest: Bedingungen identifizieren, Aktionen identifizieren, vollständige Tabelle aufstellen, Tabelle reduzieren, Testfälle ableiten. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. - Bedingungen identifizieren. Welche Bedingungen beeinflussen die Entscheidung? Jede wird binär oder als kleine Wertemenge formuliert. - Aktionen identifizieren. Welche Reaktionen kann das System zeigen? - Vollständige Tabelle aufstellen. Bei n binären Bedingungen entstehen 2 hoch n Spalten. - Tabelle reduzieren. Zwei Regeln lassen sich nur dann zusammenfassen, wenn sie dieselben Aktionen auslösen, sich in genau einer Bedingung unterscheiden und dabei alle Werte dieser Bedingung abdecken. Diese Bedingung wird dann mit “egal” markiert. Nicht erfüllbare Regeln vorher entfernen. - Testfälle ableiten. Pro Regel ein Testfall mit konkreten Werten und erwarteter Aktion; bei hoher Risikostufe auch mehrere pro reduzierter Regel. Ein kompaktes Beispiel Entscheidungstabelle Hausratversicherung, vor und nach der Reduktion Entscheidungstabelle der Hausratversicherung vor und nach der Reduktion, übereinander gestellt. Vorher: volle Tabelle mit acht Spalten aus allen Kombinationen der drei Bedingungen (Police aktiv, fristgerecht gemeldet, Schadenhöhe über Selbstbeteiligung). Nachher: reduzierte Tabelle mit vier Regeln R1 bis R4, egal-Werte hervorgehoben. R1 (Police nicht aktiv) deckt 4 der 8 Kombinationen ab und führt zur Ablehnung. R2 (Police aktiv, nicht fristgerecht gemeldet) deckt 2 Kombinationen ab und führt zur Ablehnung. R3 (Police aktiv, fristgerecht gemeldet, Schadenhöhe über Selbstbeteiligung) deckt 1 Kombination ab und führt zur Auszahlung. R4 (Police aktiv, fristgerecht gemeldet, Schadenhöhe nicht über Selbstbeteiligung) deckt 1 Kombination ab und führt zur Ablehnung. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Eine Hausratversicherung entscheidet über Leistungsanträge nach drei Bedingungen: Ist die Police zum Schadenzeitpunkt aktiv? Wurde der Schaden fristgerecht gemeldet? Liegt die Schadenhöhe über der Selbstbeteiligung? Drei binäre Bedingungen, also 2 × 2 × 2 = 8 Kombinationen. Die Reduktion bringt sie auf vier Regeln, denn eine inaktive Police führt immer zur Ablehnung, und bei aktiver Police entscheidet die verpasste Frist unabhängig von der Schadenhöhe: Bedingung / Regel | R1 | R2 | R3 | R4 Police zum Schadenzeitpunkt aktiv | nein | ja | ja | ja Schaden fristgerecht gemeldet | egal | nein | ja | ja Schadenhöhe über Selbstbeteiligung | egal | egal | ja | nein Aktion: Auszahlung anweisen (abzüglich Selbstbeteiligung) | nein | nein | ja | nein Aktion: Ablehnungsschreiben mit Begründung | ja | ja | nein | ja Die Kontrolle per Prüfsumme: R1 trägt zwei “egal”-Werte und deckt damit 2 hoch 2 = 4 Kombinationen ab, R2 mit einem “egal” deckt 2 ab, R3 und R4 je eine. Die Summe 4 + 2 + 1 + 1 = 8 entspricht genau den möglichen Kombinationen. Damit ist ein Warnsignal ausgeblieben, mehr nicht. Liegt die Summe zu hoch, überschneiden sich Regeln; liegt sie zu niedrig, fehlen Kombinationen. Stimmt sie, kann sich immer noch eine Lücke gegen eine gleich große Überlappung aufheben. Die Prüfsumme ist ein Rauchmelder, kein Beweis. Den Rest erledigt das inhaltliche Review der Tabelle. Vier Testfälle erreichen hier 100 Prozent Überdeckung. Angenommen, im Testlauf fällt R2 durch: Ein verspätet gemeldeter Schaden über der Selbstbeteiligung wird ausgezahlt statt abgelehnt. Die Ursache: Die Fristprüfung war nur im Kundenportal umgesetzt, nicht in der Schnittstelle, über die Makler Anträge einreichen. Ein klassischer Kombinationsfehler, den ein Test mit zwei, drei “typischen” Anträgen kaum je gefunden hätte, weil typische Anträge nun einmal fristgerecht kommen. Überdeckung und Erfolgskriterien Prüfsummen-Mosaik Hausratversicherung Mosaik aus acht Kästchen, das die acht möglichen Bedingungs-Kombinationen der Hausratversicherung zeigt und nach zugehöriger Regel mit unterscheidbaren Mustern gefüllt ist. Regel R1 deckt vier Kästchen ab, Regel R2 deckt zwei Kästchen ab, Regel R3 und Regel R4 decken je ein Kästchen ab. Die Summe von 4 plus 2 plus 1 plus 1 ergibt 8 und stimmt mit der Zahl aller möglichen Kombinationen überein. Das bestätigt die Prüfsumme, beweist aber für sich allein weder Lückenlosigkeit noch Überschneidungsfreiheit. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Die zentrale Metrik ist die Entscheidungstabellenüberdeckung, auch Spaltenüberdeckung genannt: der Anteil der ausgeführten an den erfüllbaren Spalten. Nicht erfüllbare Kombinationen, die logisch nie eintreten können, fallen aus dem Nenner heraus. Beim Review der Tabelle, am besten gemeinsam mit der Fachseite, haben sich vier Prüffragen bewährt: Führen überlappende Regeln zur selben Aktion (Konsistenz)? Gibt es Regeln, deren Bedingungs-Kombination nie eintreten kann (Durchführbarkeit)? Fehlt eine erfüllbare Kombination (Vollständigkeit)? Und bilden die Regeln das fachlich gewünschte Verhalten ab (Korrektheit)? Das Prüfsummenverfahren ergänzt das Review rechnerisch, ersetzt es aber nicht: Weicht die Prüfsumme von der Zahl der möglichen Kombinationen ab, gibt es sicher ein Problem. Stimmt sie, ist nur eine von mehreren Fehlerquellen ausgeschlossen. Stärken und Grenzen Die Stärke des Verfahrens ist seine Zwangsläufigkeit. Jede Kombination bekommt eine Spalte, jeder Sonderfall eine Antwort; Mehrdeutigkeiten, die im Fließtext einer Anforderung überleben, lösen sich in der Tabelle zwingend auf. Dazu kommt die Verständlichkeit: Eine Entscheidungstabelle ist in wenigen Minuten erklärt, auch der Fachseite. Die wichtigste Grenze ist das exponentielle Wachstum. Mit jeder zusätzlichen binären Bedingung verdoppelt sich die Tabelle; bei sieben Bedingungen stehen schon 128 Spalten auf dem Papier. Dann helfen Reduktion, Aufteilung in Teil-Tabellen pro Themenbereich oder die Kombination mit dem kombinatorischen Test für die Bedingungs-Permutationen; ab etwa fünf Bedingungen lohnt Werkzeugunterstützung. Eine zweite Falle sind nicht-binäre Bedingungen: Hat eine Bedingung drei oder mehr Werte, wächst die Tabelle entsprechend schneller. Solche Bedingungen werden explizit mit allen Werten modelliert oder in mehrere binäre zerlegt. Verwandte Verfahren Der Wertebereichstest prüft die einzelnen Schwellwerte, aus denen die Bedingungen bestehen; die Entscheidungstabelle prüft ihr Zusammenwirken. Bei sehr vielen Parametern mit reduzierten Wertelisten übernimmt der kombinatorische Test. Geht es um Abläufe statt um Regeln, ist der Zustandsübergangstest das passende Verfahren. Einen Überblick über alle elf Verfahren gibt die Seite Testentwurfsverfahren. --- ### Metamorphic Testing: Testen ohne Testorakel URL: https://www.richard-seidl.com/de/metamorpher-test/ Metamorphic Testing prüft Systeme ohne eindeutiges Testorakel über metamorphe Relationen: Konzept, Vorgehen, Beispiel Fahrplanauskunft und der Einsatz bei KI. Was ist Metamorphic Testing? Klassischer Test versus metamorpher Test Vergleichsschema von klassischem Test und metamorphem Test. Klassischer Test: eine Eingabe führt zu einem Ergebnis, das mit einem bekannten Soll-Wert verglichen wird. Metamorpher Test: zwei verwandte Eingaben A und B führen zu zwei Ergebnissen, die nicht gegen einen Soll-Wert, sondern in ihrer Beziehung zueinander geprüft werden, ganz ohne bekannten Soll-Wert. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Metamorphic Testing (deutsch: metamorpher Test) ist ein regelbasiertes Testverfahren, das Beziehungen zwischen mehreren Eingaben und ihren Ergebnissen prüft und damit auch dort funktioniert, wo ein eindeutiges Testorakel fehlt. Sein Werkzeug sind metamorphe Relationen: Eigenschaften, die zwischen verwandten Eingaben zwingend gelten müssen, ganz gleich, welches konkrete Ergebnis das System liefert. Das klingt abstrakter als es ist. Eine Fahrplanauskunft soll für dieselbe Strecke keine frühere Ankunft anbieten, wenn der gewünschte Abfahrtszeitpunkt nach hinten rückt. Welche Verbindung im Einzelfall die richtige ist, weiß bei einem tagesaktuellen Fahrplan niemand auswendig. Aber dass eine spätere Abfahrt nie zu einer früheren Ankunft führen kann, steht fest, denn jede Verbindung der späteren Suche stand auch der früheren zur Verfügung. Diese Beziehung ist eine metamorphe Relation. Verletzt das System sie, ist ein Fehler gefunden, ohne dass irgendjemand die “richtige” Verbindung kennen musste. Ein metamorpher Test besteht aus einem Quell-Testfall mit der ursprünglichen Eingabe und einem Folge-Testfall mit der transformierten Eingabe. Die Relation legt fest, wie sich die beiden Ergebnisse zueinander verhalten müssen: gleich, Teilmenge, Übermenge, nie kleiner. Halten die Ergebnisse die Relation ein, gilt der Testablauf als bestanden. Bei einem Fehlschlag klärt erst das Debugging, welcher der beteiligten Testfälle tatsächlich falsch gerechnet hat. Innerhalb der Testentwurfsverfahren gehört der metamorphe Test zu den regelbasierten Verfahren. Wann ist das Verfahren geeignet? Metamorphic Testing spielt seine Stärke überall dort aus, wo das Testorakel-Problem ausgeprägt ist: bei Such- und Auskunftssystemen, bei Empfehlungsdiensten, bei numerischen Berechnungen ohne unabhängige Referenz, bei Optimierungsalgorithmen, bei Renderings, Kompression und Verschlüsselung, und in besonderem Maß bei KI-Modellen. Überall, wo das gewünschte Ergebnis schwer vorhersagbar ist, aber Beziehungen zwischen mehreren Ergebnissen bestimmbar bleiben. Umgekehrt gilt: Wo ein eindeutiges Sollverhalten bekannt ist, bleibt der direkte Soll-Ist-Vergleich präziser. Der metamorphe Test ersetzt klassische Tests nicht, er erschließt den Bereich, den sie nicht erreichen. Vorgehen in vier Schritten - Metamorphe Relationen identifizieren. Welche Eigenschaften müssen zwischen verwandten Eingaben gelten? Idealerweise mehrere Relationen pro Testobjekt, gemeinsam mit jemandem, der die Fachlichkeit kennt. - Quell-Testfälle bestimmen. Ursprüngliche Eingaben festlegen, gerne auch solche, deren Ergebnis manuell schwer zu prüfen wäre. - Folge-Testfälle erzeugen. Pro Relation die transformierte Eingabe ableiten: Abfahrtszeit verschieben, Zwischenhalt erzwingen, Filter setzen, Schreibweise ändern. - Relation prüfen. Quell- und Folge-Testfälle ausführen und die Relation auf die Ergebnisse anwenden. Weicht ein Ergebnis von der erwarteten Beziehung ab, ist ein Fehlerzustand gefunden. In der Praxis übernimmt ein Generator die Schritte 2 bis 4: Er erzeugt pro Quell-Eingabe automatisch die Folge-Eingabe und prüft die Relation. Property-based-Frameworks wie Hypothesis, jqwik oder QuickCheck eignen sich dafür gut. Ein kompaktes Beispiel Metamorphe Relation MR1, spätere Abfahrt, Fahrplanauskunft Transformationsschema der metamorphen Relation MR1 Spätere Abfahrt für eine Fahrplanauskunft. Links die Quelle: Suche ab 14:00 Uhr. Eine Transformation (Abfahrtszeit um eine Stunde nach hinten verschieben) führt zur Folge: Suche ab 15:00 Uhr. Rechts die beiden Ergebnisse mit der geforderten Relation: die frühestmögliche Ankunft der Folge darf nie früher sein als die der Quelle. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Die Fahrplanauskunft eines Verkehrsverbunds ist ein klassischer Testorakel-Fall: Der Fahrplan ändert sich laufend, Baustellen und Ausfälle inklusive. Vier metamorphe Relationen bieten sich an: Relation | Quelle | Folge | Erwartung | gilt nur, wenn MR1: Spätere Abfahrt | Suche ab 14:00 Uhr | Suche ab 15:00 Uhr | frühestmögliche Ankunft nie früher als bei der Quelle | beide Suchen die früheste Ankunft über alle Routen liefern MR2: Erzwungener Zwischenhalt | direkte Suche A nach B | Suche A nach B über C | Reisezeit nie kürzer als bei der Quelle | beide Suchen auf Reisezeit optimieren und nicht nach Umstiegen vorsortieren MR3: Verkehrsmittel-Filter | Suche ohne Filter | Suche “nur Nahverkehr” | Ergebnismenge ist Teilmenge der Quelle | die Quelle die vollständige Ergebnismenge liefert, keine Top-N-Auswahl MR4: Schreibweisen-Substitution | ”Hauptbahnhof" | "Hbf” | identische Verbindungen | die Abkürzung als Alias auf dieselbe Haltestellen-ID auflöst Die letzte Spalte ist kein Kleingedrucktes, sondern der eigentliche Kern der Arbeit. Eine metamorphe Relation ohne ihre Vorbedingungen ist keine Relation, sondern eine Vermutung. Wer MR3 ohne den Zusatz formuliert und die Auskunft liefert wie üblich nur die fünf besten Verbindungen, bekommt zuverlässig Verletzungen gemeldet, die keine Fehler sind. Nach drei solchen Fehlalarmen glaubt niemand mehr der Suite. Deshalb gehört zu jeder Relation die Frage: Unter welchen Annahmen muss sie gelten, und sind die im getesteten System überhaupt erfüllt? Vier metamorphe Relationen für die Fahrplanauskunft im Überblick Vier Kurzschemata der metamorphen Relationen MR1 bis MR4 für die Fahrplanauskunft, als 2-mal-2-Raster angeordnet. MR1 Spätere Abfahrt: Suche ab 14 Uhr wird zu Suche ab 15 Uhr, Erwartung: frühestmögliche Ankunft nie früher als bei der Quelle. MR2 Erzwungener Zwischenhalt: direkte Suche A nach B wird zu Suche A nach B über C, Erwartung: Reisezeit nie kürzer als bei der Quelle. MR3 Verkehrsmittel-Filter: Suche ohne Filter wird zu Suche nur Nahverkehr, Erwartung: Ergebnismenge ist Teilmenge der Quelle. MR4 Schreibweisen-Substitution: Hauptbahnhof wird zu Hbf, Erwartung: identische Verbindungen. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Der Test läuft automatisiert, etwa mit 120 zufällig gezogenen Start-Ziel-Paaren pro Relation. Ein plausibles Ergebnis eines solchen Laufs: MR1 wird sieben Mal verletzt, immer bei Verbindungen kurz vor Mitternacht, weil die Auskunft beim Tageswechsel das Datum nicht mitführt und eine Ankunft um 0:15 Uhr als “früher” einsortiert als eine um 23:50 Uhr. MR4 wird drei Mal verletzt, weil die Abkürzung entgegen der dokumentierten Alias-Zuordnung auf eine andere Haltestellen-ID auflöst als der ausgeschriebene Name. Beides echte Fehler, weil die Vorbedingungen der beiden Relationen hier erfüllt sind, und für beide hätte kein einzelner Testfall ein “falsches” Ergebnis gezeigt; erst der Vergleich zweier Läufe macht sie sichtbar. Warum es hier kein sauberes Überdeckungsmaß gibt Bei den meisten Verfahren lässt sich am Ende eine Zahl nennen. Beim metamorphen Test nicht, und das liegt am Verfahren selbst: Es gibt derzeit keine anerkannten Überdeckungsmaße, aus denen sich brauchbare Endekriterien ableiten lassen. Der Grund ist einleuchtend, sobald man ihn einmal gesehen hat. Jede Relation einmal abzudecken sagt wenig, weil eine erfüllte Relation das Ergebnis nur teilweise prüft. Man weiß danach, dass sich zwei Läufe zueinander richtig verhalten. Ob beide falsch sind, weiß man nicht. Eine Quote wie “80 Prozent der Relationen abgedeckt” suggeriert also eine Sicherheit, die das Verfahren nicht liefern kann. Was stattdessen trägt: die Qualität der Relationen und die Menge der Eingaben pro Relation. Eine gute Relation ist notwendig, das heißt, ihre Verletzung beweist einen Fehler. Sie ist nicht hinreichend, ihre Einhaltung beweist keine Korrektheit. Und sie muss scharf genug sein, um überhaupt etwas zu fangen; wer nur Selbstverständlichkeiten formuliert, findet nichts. Drei Suchrichtungen helfen: die mathematische Struktur des Problems (Symmetrien, Monotonie), die Fachdomäne (welche Transformation einer Eingabe darf das Ergebnis wie verändern?) und das Anwenderverhalten (welche Konsistenz erwarten Nutzer zwischen zwei aufeinanderfolgenden Aktionen?). Für die Menge gibt es keine belastbare Faustzahl. Der bewährte Weg ist, den metamorphen Test mit Zufallstest zu koppeln und so viele Quell-Eingaben zu erzeugen, wie Laufzeit und Budget hergeben. Mehr Eingaben erhöhen nicht die Überdeckung, sondern die Chance, eine seltene Verletzung tatsächlich zu erwischen. Als Endekriterium taugt deshalb ein Review besser als jede Prozentzahl: Sind die Relationen fachlich hergeleitet, decken sie die riskanten Eigenschaften des Systems ab, und ist die Stichprobe groß genug, dass ein Durchlauf ohne Verletzung überhaupt etwas bedeutet? Metamorphic Testing bei KI-Systemen Metamorphic Testing bei einem Bildklassifikator Transformationsschema für Metamorphic Testing bei einem Bildklassifikator. Links die Quelle: ein Originalbild wird klassifiziert. Eine Transformation (Drehung oder Spiegelung des Bildes) führt zur Folge: dasselbe Bild, gedreht oder gespiegelt. Rechts die geforderte Relation: Der Klassifikator soll bei beiden Bildern dieselbe Klasse liefern, solange das Wesentliche des Bildes erhalten bleibt. ↔Zum vollständigen Anzeigen nach rechts wischen oder mit den Pfeiltasten scrollen. Mit maschinellem Lernen und generativer KI hat das Verfahren stark an praktischer Bedeutung gewonnen. KI-Systeme treffen das Testorakel-Problem mit voller Wucht: Der Eingaberaum ist faktisch unendlich, das Verhalten nur statistisch beschrieben, ein vollständiger Abgleich gegen eine Spezifikation nicht machbar. Klassische Testfälle mit konkretem Sollwert kommen da selten weit. Metamorphe Relationen sind hier oft der einzige Weg zu einer systematischen, automatisierbaren Prüfung. Typische Relationen für KI-Systeme: Ein Bildklassifikator soll bei kleinen Drehungen, Spiegelungen oder Helligkeitsänderungen bei seiner Klassifikation bleiben, solange das Wesentliche des Bildes erhalten ist. Ein maschineller Übersetzer soll bei Hin- und Rückübersetzung den Sinn rekonstruieren. Ein Empfehlungssystem soll seine Top-Empfehlungen nicht umwerfen, nur weil ein Nutzer einen Artikel kurz angesehen und wieder verworfen hat. Ein Sprachmodell soll auf eine umformulierte, inhaltsgleiche Frage konsistent antworten. Verletzungen solcher Relationen deuten auf instabile Trainings, fehlende Normalisierung oder unbeabsichtigte Reihenfolge-Sensitivität. Eine Einschränkung gehört dazu: Der metamorphe Test prüft Konsistenz, nicht Korrektheit im strengen Sinn. Ein Modell kann konsistent falsch liegen. In KI-Anwendungen wird das Verfahren deshalb mit menschlichen Stichproben und mit Property-based Tests zu Robustheit und Antwortzeit kombiniert. Stärken und Grenzen Die Stärken: Das Verfahren testet, wo sonst kaum etwas systematisch testbar ist. Es ist gut automatisierbar und skaliert über viele Quell-Eingaben pro Relation. Und es kommt ohne Wissen über das Innenleben des Algorithmus aus, was es unempfindlich gegenüber komplexen Implementierungen macht. Die Grenzen: Gute metamorphe Relationen verlangen Domänenwissen, und eine fehlerhaft formulierte Relation produziert falsche Befunde oder übersieht echte. Das Verfahren beweist keine Korrektheit, sondern deckt Inkonsistenzen auf. Wo ein Orakel existiert, bleibt der klassische Test erste Wahl. Verwandte Verfahren Der Zufallstest mit Property-based Tests verfolgt eine verwandte Idee mit anderer Strukturierung und liefert die Werkzeugbasis für automatisierte metamorphe Tests. Der Entscheidungstabellentest ist das regelbasierte Schwesterverfahren für deterministische Geschäftslogik mit klarem Orakel. Für die Eingabeseite bleibt der Wertebereichstest relevant, für Parameterkombinationen der kombinatorische Test. Einen Überblick über alle elf Verfahren gibt die Seite Testentwurfsverfahren; zum Weiterhören passt die Podcast-Folge zum Testentwurf mit KI. --- ### Regressionstest: Definition, Auslöser und Testfallauswahl URL: https://www.richard-seidl.com/de/regressionstest/ Was ein Regressionstest prüft, wann er fällig ist, was ihn vom Retest unterscheidet und wie Testfallselektion die Laufzeit von Stunden auf Minuten senkt. Was ist ein Regressionstest? Ein Regressionstest prüft nach einer Änderung an einer Software, ob bisher funktionierendes Verhalten weiterhin fehlerfrei arbeitet. Der ISTQB-Lehrplan formuliert es nüchtern: Der Regressionstest bestätigt, dass eine Änderung, einschließlich einer bereits getesteten Fehlerbehebung, keine nachteiligen Folgen hat. Diese Folgen können die geänderte Komponente selbst treffen, andere Komponenten desselben Systems oder sogar verbundene Systeme. Auch die Umgebung gehört dazu: Ein Update des Betriebssystems oder der Datenbank kann dieselben Effekte auslösen wie eine Codeänderung. Der Name sagt schon, worum es geht. Regression heißt Rückschritt: Etwas, das funktioniert hat, funktioniert plötzlich nicht mehr. Solche Fehler entstehen selten dort, wo gerade gearbeitet wurde, sondern in den Seiteneffekten daneben. Genau deshalb reicht es nicht, nur die Änderung selbst zu testen. Eine Einordnung noch, weil sie oft schiefgeht: Der Regressionstest ist keine eigene Teststufe. Er reiht sich nicht hinter Komponententest, Integrationstest, Systemtest und Abnahmetest ein, sondern läuft quer über alle diese Stufen. Überall dort, wo etwas geändert wurde, gehört er dazu. Wann ein Regressionstest fällig ist Fünf Auslöser decken die meisten Fälle ab: - Nach einer Fehlerbehebung. Der Klassiker. Die Korrektur ist getestet, aber hat sie woanders etwas beschädigt? - Vor einem Release. Der letzte Beleg, dass die gesammelten Änderungen eines Zyklus das Bestehende nicht angetastet haben. - Nach einem Refactoring. Das Verhalten soll per Definition gleich bleiben. Ob es das tut, weiß man erst nach dem Test. - Nach dem Update einer Abhängigkeit. Neue Framework-Version, neue Bibliothek, neuer Datenbanktreiber: fremder Code, gleiche Wirkung. - Nach Änderungen an Konfiguration oder Umgebung. Auch ohne eine einzige geänderte Codezeile kann sich das Systemverhalten verschieben. Wie viel davon nötig ist, klärt eine Auswirkungsanalyse: Welche Teile der Software könnte die Änderung berühren? Der ISTQB-Lehrplan empfiehlt sie ausdrücklich, bevor der Umfang des Regressionstests feststeht. Ohne diese Analyse bleiben nur zwei schlechte Optionen: zu viel testen oder zu wenig. Warum Regressionstests teuer werden Der Aufwand für Regressionstests hat eine unangenehme Eigenschaft: Er wächst schneller als die Änderungen, die ihn auslösen. Geprüft wird ja gerade auch die Funktionalität, die von einer Änderung gar nicht betroffen sein soll. Der Anteil der auszuführenden Tests übersteigt damit schnell den Anteil der geänderten Software. Eine kleine Korrektur, ein großer Testumfang. Wie sich das in echt anfühlt, hat mir Silke Reimer im Podcast am Beispiel der IVU beschrieben: rund 25.000 Testfälle, ein kompletter Durchlauf von 6,5 Stunden. Dazu bis zu zehn parallel gepflegte Branches, weil mehrere Releases bei Kunden stehen. Eine einzige Fehlerbehebung wandert im Zweifel durch vier oder fünf Branches und löst jedes Mal die volle Suite aus. Selbst zehn große Maschinen im Dauerbetrieb reichten dafür nicht mehr. Die scheinbar sparsame Alternative, alles nur einmal pro Nacht zu testen, hat ihren eigenen Preis. Schlägt morgens ein Test fehl, beginnt erst die Suche: Welcher der Commits von gestern war es? Diese Analysezeit taucht in keiner Aufwandsschätzung auf und fällt trotzdem jede Woche an. Regressionstest und Teststufen Regressionstest und Teststufen liegen auf zwei verschiedenen Achsen: Teststufen beschreiben, wann und von wem getestet wird, der Regressionstest beschreibt, warum erneut getestet wird. Deshalb gibt es ihn auf jeder Stufe. Die Unit-Suite, die nach jedem Commit läuft, ist ein Regressionstest auf Komponentenebene. Der nächtliche End-to-End-Lauf ist einer auf Systemebene. Und die automatisierten Tests, die abgenommene Inkremente absichern, sind einer auf Abnahmeebene. Der ISTQB-Lehrplan sagt es direkt: Fehlernachtests und Regressionstests sind auf allen Teststufen erforderlich, wenn dort Fehler behoben oder Änderungen vorgenommen wurden. Wer den Regressionstest als eigene Phase am Projektende einplant, hat das Konzept missverstanden und verschenkt seinen größten Vorteil: die schnelle Rückmeldung nah an der Änderung. Regressionstest vs. Retest Regressionstest und Retest prüfen zwei verschiedene Fragen und werden trotzdem ständig verwechselt. Der deutsche ISTQB-Lehrplan sagt Fehlernachtest, im Projektalltag heißt es meist Retest oder Nachtest; gemeint ist dasselbe. Der Fehlernachtest bestätigt, dass ein konkreter, zuvor gefundener Fehler tatsächlich behoben ist. Der Regressionstest bestätigt, dass die Behebung an anderer Stelle nichts beschädigt hat. Beide gehören zusammen, in genau dieser Reihenfolge: erst prüfen, ob der Fehler weg ist, dann prüfen, ob dabei etwas Neues kaputtgegangen ist. Zwei Details aus dem Lehrplan sind praktisch relevant. Vorzugsweise führt dieselbe Person den Fehlernachtest durch, die den Fehler ursprünglich gefunden hat; sie kennt den Weg dorthin am besten. Und wenn Zeit oder Geld knapp sind, darf sich der Fehlernachtest auf die Testschritte beschränken, die die Fehlerwirkung ausgelöst haben. Beim Regressionstest gibt es diese Abkürzung nicht, denn wo die Nebenwirkung sitzt, weiß vorher niemand. Regressionstest und Testautomatisierung Regressionstest und Testautomatisierung werden oft in einem Atemzug genannt, sind aber nicht dasselbe. Ein Regressionstest muss nicht automatisiert sein. Er ist nur der dankbarste Kandidat dafür: Regressionstestsuiten laufen viele Male, die Zahl der Testfälle wächst mit jedem Release, und genau diese Wiederholung trägt die Automatisierung wirtschaftlich. Umso bemerkenswerter ist eine Zahl aus der Softwaretest-Umfrage 2024: 12 Prozent der Teilnehmer automatisieren ihre Regressionstests überhaupt nicht. Automatisierung ist dabei Mittel, nicht Selbstzweck. Bei der Telematik-App der HUK-Coburg lieferte die erste Testautomatisierung grüne Läufe, denen niemand traute: Während die Automatisierung komplett durchlief, fand der manuelle Regressionstest 20 bis 25 kritische Fehler. Das Team stellte die Automatisierung nach vier Jahren komplett ein und setzte neu an. Heute ist rund ein Drittel der etwa 150 Regressionstestfälle automatisiert, mit klarem Ziel und diesmal mit Vertrauen in die Ergebnisse. Ein grüner Regressionslauf, dem niemand traut, sichert nichts ab. Wie Testautomatisierung generell aufgesetzt wird, wie die Testautomatisierungspyramide dabei hilft und wo sich Automatisierung lohnt, ist ein eigenes Thema mit einer eigenen Seite. Hier geht es um die Frage davor: Welche Tests müssen nach einer Änderung überhaupt erneut laufen? Testfallauswahl: Full, Selective und Prioritized Regression Testing Für diese Frage gibt es drei Strategien: Full Regression Testing führt bei jeder Änderung die komplette Suite aus. Das ist die sicherste Variante und für kleine Suiten völlig in Ordnung. Ab einer gewissen Größe wird sie unbezahlbar, siehe die 6,5 Stunden oben. Selective Regression Testing führt nur die Testfälle aus, die von der Änderung tatsächlich betroffen sind. Voraussetzung ist Wissen darüber, welcher Testfall welche Teile der Software nutzt. Genau das ist Testfallselektion. Prioritized Regression Testing ordnet die Testfälle nach Risiko, Fehlerhistorie oder Nutzungshäufigkeit, damit wahrscheinliche Fehlschläge früh sichtbar werden. Das ergänzt die Selektion, wenn auch die reduzierte Suite noch lange läuft. Was Selektion leisten kann, zeigt der IVU-Fall aus dem Podcast. Ein nächtlicher Lauf protokolliert, welche Dateien, Klassen und Funktionen jeder Testfall öffnet. Bei jedem Check-in laufen dann nur die Testfälle, die von den geänderten Dateien betroffen sind, vollautomatisch und über die Sprachgrenze zwischen C++ und Java hinweg. Die Selektion spart 50 bis 60 Prozent aller Testfälle ein: | Vorher | Nachher (im Mittel) Java-Seite | 2,5 Stunden | 1 Stunde, oft 10 bis 15 Minuten C++-Seite (Selektion auf Funktionsebene) | 4 bis 4,5 Stunden | 10 bis 15 Minuten Eingesparte Testfälle | | 50 bis 60 Prozent Der wichtigste Schritt war allerdings nicht die Technik, sondern die Validierung. Über vier bis sechs Wochen lief die komplette Suite parallel weiter, während protokolliert wurde, was die Selektion ausgewählt hätte. Das Ergebnis: kein einziger übersehener echter Fehlschlag. Erst dieser Beleg hat dem Verfahren das Vertrauen des Teams eingebracht. Für die Priorisierung liefert Process Mining eine Datengrundlage, die Bauchgefühl ersetzt. Produktionsdaten zeigen, welche Workflows wie oft tatsächlich durchlaufen werden. In einem Fall aus dem Podcast hatte der aufwendigste Workflow über 600 verschiedene Durchläufe, aber die Top 10 deckten rund 80 Prozent aller Produktionsdurchläufe ab. Wer Testfälle für diese zehn hat, deckt das reale Geschehen ab und kann belegen, warum er auf die übrigen 590 verzichtet. Visuelle Regressionstests Ein visueller Regressionstest vergleicht Screenshots der Benutzungsoberfläche mit zuvor freigegebenen Referenzbildern und schlägt an, wenn sich das Erscheinungsbild unbeabsichtigt ändert. Er findet Fehler, an denen funktionale Tests vorbeilaufen: ein verrutschtes Layout, ein überdeckter Button, eine unlesbare Schrift auf neuem Hintergrund. Der funktionale Test bleibt grün, die Seite ist trotzdem kaputt. Werkzeugseitig lohnt ein genauer Blick. Playwright bringt visuelle Regressionstests in der TypeScript-Version direkt im Testrunner mit, inklusive Diff-Images. Die Python-Version braucht dafür externe Bibliotheken, die teilweise nicht mehr aktiv gepflegt werden. Solche Unterschiede entscheiden mit, welche Variante zum eigenen Team passt. Werkzeuge Das Werkzeugspektrum ist dasselbe wie beim automatisierten Testen insgesamt, weil Regressionstests auf allen Ebenen laufen: Playwright, Selenium und Cypress für die Benutzungsoberfläche, REST-assured oder Postman auf API-Ebene, dazu die Unit-Test-Frameworks der jeweiligen Sprache. Mit keyword-getriebenen Ansätzen wie dem Robot Framework schreiben auch nicht-technische Tester ihre Regressionstestfälle selbst. Entscheidend ist weniger das einzelne Werkzeug als die Einbettung. Regressionstests entfalten ihren Wert erst, wenn sie in der CI-Pipeline bei jeder Änderung laufen, nicht als Sonderaktion vor dem Release. Je näher der Test an der Änderung, desto billiger der gefundene Fehler. Aus der Praxis Beim Thema Regressionstest bin ich vor allem der, der zuhört. In meinen Podcasts erzählen mir seit Jahren Praktikerinnen und Praktiker, wie sie ihre Testsuiten im Griff behalten, und zwei dieser Gespräche haben meinen Blick auf das Thema geprägt. Silke Reimer hat in der Folge “Automatische Testfallselektion für Regressionstests” beschrieben, wie die IVU ihre 6,5-Stunden-Suite auf Minuten gebracht hat. Hängen geblieben ist bei mir weniger die Technik als der Umgang mit der Skepsis im Team: wochenlanger Parallelbetrieb, volle Suite gegen Selektion, bis die Zahlen für sich sprachen. Felix Doppel erzählte in “Testautomatisierung von Mobile Apps” die Gegengeschichte von der HUK-Coburg: eine Automatisierung, die grün leuchtete, während die manuellen Regressionstester die kritischen Fehler fanden. Sein Team hatte den Mut, vier Jahre Arbeit einzustellen und neu anzufangen. Beide Geschichten erzählen im Kern dasselbe. Ein Regressionstest ist so viel wert wie das Vertrauen, das ein Team in ihn hat. Und dieses Vertrauen entsteht nicht durch das Versprechen eines Werkzeugs, sondern durch Belege: einen Parallellauf, nachvollziehbare Zahlen, gefundene Fehler. Wer seinen Regressionstest aufbaut, baut immer beides: die Testfälle und das Vertrauen in sie. --- ### Testen von KI-Agenten: Prinzipien, Kriterien, Metriken URL: https://www.richard-seidl.com/de/ki-agenten-testen/ Wie man KI-Agenten testet: Prinzipien für nicht-deterministische Systeme, Prüfkriterien von Aufgabenerfüllung bis Guardrails, Metriken wie pass^k. Was heißt Testen von KI-Agenten? Testen von KI-Agenten heißt, ein System zu prüfen, das eigenständig plant, Werkzeuge aufruft und bei gleicher Eingabe unterschiedliche Lösungswege nehmen kann. Ein Agent ist mehr als ein Sprachmodell mit Prompt: Er verfolgt ein Ziel über mehrere Schritte, entscheidet unterwegs, welche Aktion als nächste dran ist, ruft APIs, Datenbanken oder andere Systeme auf und reagiert auf deren Antworten. Genau diese Eigenständigkeit macht ihn nützlich, und genau sie macht ihn zum anspruchsvollsten Testobjekt, das die Disziplin bisher kennt. Das Testobjekt ist dabei nicht der einzelne Output, sondern das Verhalten: die Kette aus Planung, Werkzeugnutzung und Entscheidungen, über viele Läufe hinweg. Wer einen Agenten abnimmt wie ein Formular mit drei Eingabefeldern, prüft am Risiko vorbei. Warum klassische Testfälle nicht ausreichen Klassische Testfälle vergleichen ein Ergebnis mit einem erwarteten Sollwert; bei einem KI-Agenten existiert dieser eine Sollwert oft nicht. Derselbe Auftrag kann auf drei verschiedenen Wegen korrekt erledigt werden, und derselbe Weg kann heute funktionieren und morgen scheitern. Ein grüner Testlauf beweist deshalb wenig, und ein roter ist nicht automatisch ein Fehler. Dazu kommt der Eingaberaum. Ein Agent, der mit Menschen in natürlicher Sprache arbeitet, bekommt Umformulierungen, Tippfehler, fehlende Angaben, widersprüchliche Wünsche. Niemand kann diesen Raum mit aufgezählten Testfällen abdecken. Die Konsequenz ist ein Wechsel der Denkweise: Evaluierung statt Assertion. Zuerst wird festgelegt, was immer gelten muss, unabhängig vom Lösungsweg. Solche Invarianten sind hart prüfbar: keine Aktion ohne Berechtigung, keine erfundenen Preise, keine Auskunft außerhalb des erlaubten Rahmens. Alles darüber hinaus, also wie gut der Agent seine Aufgabe löst, wird statistisch bewertet, über viele Läufe und mit definierten Schwellenwerten. Wie sich Systeme ohne eindeutiges Testorakel trotzdem systematisch prüfen lassen, zeigt auch der metamorphe Test: Statt einzelner Sollwerte werden Beziehungen zwischen verwandten Eingaben geprüft. Testen von Agenten oder Testen mit Agenten? Testen von Agenten und Testen mit Agenten sind zwei verschiedene Disziplinen, die derzeit unter demselben Begriff Agentic Testing laufen. Beim Testen mit Agenten ist der Agent das Werkzeug: Er generiert Testfälle, führt Tests aus, repariert Testskripte, ein Kapitel der Testautomatisierung. Beim Testen von Agenten ist der Agent das Testobjekt, und um diese Disziplin geht es auf dieser Seite. Wer nach Agentic Testing sucht, sollte zuerst klären, welche der beiden Richtungen gemeint ist; die Antworten haben wenig miteinander zu tun. Prinzipien für das Testen von KI-Agenten Sechs Prinzipien tragen das Testen von KI-Agenten. Sie ersetzen kein Testhandwerk, sie ordnen es neu. - Verhalten statt Einzelergebnis bewerten. Bewertet wird der Raum der möglichen Ausgaben, nicht die eine Ausgabe. Ein Testfall beschreibt eine Aufgabe samt akzeptablem Verhaltenskorridor, nicht einen exakten Zielzustand. - Invarianten vor Qualität. Erst wird geprüft, was nie passieren darf: unautorisierte Aktionen, verletzte Geschäftsregeln, Ausgaben außerhalb des erlaubten Rahmens. Diese Guardrails sind deterministisch prüfbar und gehören in jeden Lauf. Wie gut die Aufgabe gelöst wird, ist die zweite Frage, nie die erste. - Wiederholung ist Teil des Testfalls. Ein einzelner Lauf ist eine Stichprobe, keine Aussage. Erst die Verteilung über viele Läufe zeigt, ob ein Ergebnis Können war oder Zufall. - Werkzeugaufrufe sind eine eigene Prüfebene. Welche API der Agent mit welchen Parametern aufruft, ist beobachtbar und deterministisch bewertbar. Auf dieser Ebene funktioniert klassisches Testen weiterhin, und sie ist die stabilste Basis für Regressionsprüfungen. - Beobachtbarkeit vor Bewertung. Ohne Zugriff auf Plan, Zwischenschritte und Werkzeugaufrufe lässt sich ein Fehlverhalten feststellen, aber nicht diagnostizieren. Traces sind für Agenten, was Logs für Server sind. - Automatische Bewertung an Menschen kalibrieren. Wenn ein Sprachmodell die Antworten des Agenten bewertet (LLM-as-a-Judge), muss diese Bewertung regelmäßig gegen menschliches Urteil geprüft werden. Ein unkalibrierter Richter misst präzise am Ziel vorbei. Kriterien: Was bei einem KI-Agenten geprüft wird Die Prüfkriterien für KI-Agenten lassen sich in sechs Gruppen fassen: Aufgabenerfüllung, Regeltreue, Robustheit, Werkzeugnutzung, Effizienz und Transparenz. Aufgabenerfüllung fragt, ob der Agent das fachliche Ziel erreicht, und zwar vollständig: Eine halb stornierte Bestellung ist kein Teilerfolg, sondern ein Fehler. Regeltreue prüft die Einhaltung von Geschäftsregeln, Berechtigungen und Compliance-Vorgaben in jedem einzelnen Schritt. Robustheit misst, wie stabil der Agent bei Umformulierungen, unvollständigen Angaben und gezielten Manipulationsversuchen bleibt; dazu gehören auch adversariale Eingaben wie Prompt Injection. Werkzeugnutzung bewertet, ob der Agent die richtigen Werkzeuge mit den richtigen Parametern aufruft und mit deren Fehlern umgehen kann, etwa einem Timeout der API. Effizienz zählt Schritte, Tokens, Kosten und Latenz pro Aufgabe; ein Agent, der jede Anfrage korrekt, aber mit vierzig Werkzeugaufrufen löst, ist im Betrieb nicht tragfähig. Transparenz schließlich fragt, ob sich Entscheidungen nachvollziehen lassen und ob der Agent erkennt, wann er eine Aufgabe an einen Menschen übergeben muss. Metriken für die Zuverlässigkeit von KI-Agenten Die wichtigste Kennzahl eines KI-Agenten ist nicht sein bestes Ergebnis, sondern die Streuung seiner Ergebnisse. Daraus leiten sich die zentralen Metriken ab: - Aufgabenerfolgsquote: Anteil der Läufe, in denen die Aufgabe vollständig und regelkonform gelöst wurde. - Konsistenz (pass^k): Wahrscheinlichkeit, dass dieselbe Aufgabe alle k Wiederholungen übersteht. Der Benchmark τ-bench hat diese Metrik geprägt, und die Ergebnisse sind ernüchternd: Der beste dort getestete Agent löste in der Handels-Domäne gut 60 Prozent der Aufgaben im Einzelversuch; musste dieselbe Aufgabe achtmal in Folge gelingen, blieben rund 25 Prozent. - Regelverletzungsrate: Verstöße gegen Invarianten und Guardrails pro Anzahl Läufe. Zielwert null, jede Verletzung wird einzeln analysiert. - Halluzinationsrate: Anteil der Läufe mit erfundenen Fakten, Quellen oder behaupteten, aber nicht ausgeführten Aktionen. - Werkzeug-Fehlerrate: falsche Werkzeugwahl, falsche Parameter, nicht behandelte Fehler der aufgerufenen Systeme. - Eskalationsquote: Anteil der Fälle, in denen der Agent korrekt an einen Menschen übergibt, samt der Gegenprobe: Fälle, in denen er hätte übergeben müssen und es nicht tat. - Kosten und Latenz pro Aufgabe: die Betriebsgrößen, an denen Agenten-Projekte in der Praxis scheitern, lange bevor die Qualität zum Problem wird. Abnahmekriterien formulieren dann nicht mehr “alle Tests grün”, sondern Schwellenwerte auf Verteilungen: Erfolgsquote über x Prozent bei n Läufen, null Regelverletzungen, Eskalationsquote im definierten Korridor. Vorgehen: in fünf Phasen zum belastbaren Agenten-Test Das Vorgehen beim Testen von KI-Agenten folgt fünf Phasen: Verhalten spezifizieren, Szenarien entwerfen, Bewertung definieren, wiederholt ausführen, im Betrieb weitermessen. - Verhalten spezifizieren. Aufgabenumfang, Invarianten und Eskalationsregeln schriftlich festhalten. Diese Spezifikation ist die Testbasis, und sie fehlt in den meisten Agenten-Projekten komplett. - Szenarien entwerfen. Realistische Aufgaben aus dem Zielprozess, dazu Randfälle, unvollständige Angaben und gezielte Angriffe. Für dialogorientierte Agenten haben sich simulierte Nutzer bewährt, die ein zweites Modell spielt. - Bewertung definieren. Deterministische Prüfungen für Invarianten und Werkzeugaufrufe, modellbasierte Bewertung für Antwortqualität, menschliche Stichprobe zur Kalibrierung. Metamorphe Relationen ergänzen dort, wo ein Sollwert fehlt. - Wiederholt ausführen und messen. Jedes Szenario n-fach laufen lassen, Verteilungen statt Einzelwerte erheben, Konsistenzmetriken berechnen. - Im Betrieb weitermessen. Modellversionen wechseln, Prompts werden angepasst, Daten driften. Die Evaluationssuite läuft deshalb bei jeder Änderung erneut, als Regressionstest in der Pipeline, und ausgewählte Metriken laufen im Produktivbetrieb weiter. Multi-Agenten-Systeme testen In Multi-Agenten-Systemen entstehen die kritischen Fehler zwischen den Agenten, nicht in ihnen. Jeder einzelne Agent kann seine Rolle erfüllen, und das Gesamtsystem scheitert trotzdem: an Endlosschleifen aus gegenseitigen Aufrufen, an widersprüchlichen Zwischenständen, an Aufgaben, die in der Übergabe verloren gehen, an emergentem Verhalten, das niemand entworfen hat. Die Prüfung braucht deshalb zwei Ebenen. Auf der Ebene des einzelnen Agenten gelten die Prinzipien und Metriken von oben. Auf der Systemebene kommen eigene Fragen dazu: Terminiert die Zusammenarbeit, oder können sich Agenten gegenseitig endlos beschäftigen? Bleiben geteilte Zustände konsistent? Ist bei jedem Zwischenschritt klar, welcher Agent verantwortlich ist? Wer den Integrationstest klassischer Systeme kennt, erkennt das Muster wieder: Die Schnittstellen sind der Ort, an dem es kracht. Nur sind die Schnittstellen hier Konversationen. Standards und Orientierung Einen etablierten Standard speziell für das Testen agentischer Systeme gibt es noch nicht, aber zwei Quellen geben brauchbare Orientierung. ISO/IEC 25059 erweitert das Qualitätsmodell der ISO/IEC 25010 um KI-spezifische Merkmale wie probabilistisches Verhalten, Erklärbarkeit und Fairness; das liefert ein gemeinsames Vokabular für Prüfkriterien, das auch Auditoren und Einkäufer verstehen. Der ISTQB-Lehrplan Certified Tester AI Testing (CT-AI) beschreibt in Version 2.0 Testansätze für KI-basierte Systeme einschließlich generativer KI, von Datenqualität über Modellmetriken bis zu Red Teaming. Beides sind Landkarten, keine Kochrezepte. Welche Kriterien und Schwellenwerte für einen konkreten Agenten gelten, entscheidet der Einsatzkontext: Ein Recherche-Assistent verträgt eine andere Fehlerrate als ein Agent, der Zahlungen auslöst. Grenzen: Was Testen bei KI-Agenten nicht leisten kann Testen macht einen KI-Agenten nicht deterministisch; es macht sein Risiko messbar und damit entscheidbar. Ein Restrisiko bleibt immer, denn kein Szenariokatalog deckt den offenen Eingaberaum ab, und jede Modellversion verschiebt das Verhalten aufs Neue. Der Umgang damit ist eine Architekturfrage, keine reine Testfrage: eng geschnittene Berechtigungen, Freigabeschritte für kritische Aktionen, Limits für Kosten und Reichweite, Monitoring im Betrieb. Je größer der mögliche Schaden einer einzelnen Agenten-Aktion, desto weniger darf die Qualitätsstrategie allein auf Tests vor dem Release setzen. Das ist keine Kapitulation, sondern dieselbe Logik, mit der die Branche seit Jahrzehnten mit komplexen Systemen umgeht: prüfen, was prüfbar ist, und begrenzen, was nicht. Unterstützung beim Testen von KI-Agenten Richard Seidl ist Berater und Coach für Softwarequalität und Softwaretest mit Sitz in Essen und unterstützt Unternehmen im deutschsprachigen Raum beim Testen von KI-Systemen und KI-Agenten: von der Teststrategie über Prüfkriterien und Metriken bis zum Aufbau der Evaluationspipeline. Er arbeitet anbieterneutral, verkauft kein Testwerkzeug und ist an kein Framework gebunden. Die Grundlage sind mehr als 25 Jahre im Softwaretest, acht Fachbücher und die Arbeit mit Teams vom Mittelstand bis zum Konzern; 2025 wurde er mit dem Deutschen Preis für Software-Qualität ausgezeichnet. Der Einstieg ist meist klein: ein Workshop, in dem Invarianten, Kriterien und erste Metriken für einen konkreten Agenten entstehen. Von dort wächst die Evaluationspipeline mit dem System mit. ## Blog-Artikel (letzte 20) ### Viele kleine Schleifen URL: https://www.richard-seidl.com/de/blog/viele-kleine-schleifen/ Datum: 2026-10-12 Agentische QA braucht viele kleine Feedback-Schleifen im Prozess statt eines großen Test-Gates am Ende. Drei Ideen, wo ein Team damit anfangen kann. “Ein Agent produziert in zwanzig Minuten mehr, als Du an einem Tag lesen kannst. Was willst Du da hinten noch abnehmen?” (Richard Seidl) Vor einem Monat saß ich mit einem Team zusammen. Sie wollten herausfinden, wo agentische QA in ihren Prozess passt. Bis dahin gab es nur Diskussionen und ein weißes Blatt. Die Frage war zu vielschichtig. Also haben wir das Blatt weggelegt und sind ihre Painpoints durchgegangen. Wo geht regelmäßig was schief? Was fällt immer erst in der Abnahme auf? Wo macht ihr dieselbe Nacharbeit zum dritten Mal? Und auch: Was läuft schon so reif, dass es auf die nächste Stufe gehoben werden kann? Nach einem Tag war das Whiteboard voll und es gab eine Liste mit den nächsten Schritten. Der Fokus auf den Prozess hat den Knoten gelöst. Darin steckt für mich der Knackpunkt. Wir haben oft noch das große Test-Gate am Ende im Kopf. Fertig bauen, dann prüfen, dann Stempel drauf. Nur: Was willst Du bei diesem Tempo am Ende überhaupt noch abnehmen? Was agentischen Output härtet, ist die Dichte kleiner Rückmeldungen im Prozess. Kein Urteil am Schluss, sondern zwanzig kleine unterwegs. Du schmeckst ab, während Du kochst, nicht wenn der Teller beim Gast steht. Kein Grün ohne Schleife. Autonomie nur so weit, wie die Rückmeldung reicht. Konkreter? Hier drei Ideen: - Agenten im Paar. Einer erzeugt Testdaten aus der Anforderung, ein zweiter prüft sie. Entscheidend ist die Unabhängigkeit: Der Prüfer arbeitet nicht gegen die Ausgabe des Erzeugers, sondern gegen eine eigene Referenz. Schema, Wertebereiche, Constraints, Verteilungen aus der Produktion. Und sein Auftrag lautet nicht “sieht gut aus”, sondern “was fehlt”. Grenzwerte, Null, Leerstring, Dubletten. Teilen beide denselben Kontext, erbt der Prüfer die blinden Flecken des Erzeugers. - Hooks. Automatismen, die ohne Dein Zutun auslösen. Ein Accessibility-Check nach jeder Änderung am Frontend. Eine Prüfung vor dem Commit, die bestimmte Muster nicht durchlässt. Eine Regel im Prompt ist eine Bitte. Ein Hook ermöglicht eine harte Prüfung. - Skills. Die Abnahme-Checkliste, die der Agent abarbeiten muss, statt sie zu kennen. Dazu der Eval-Lauf: ein fester Satz Fälle mit erwartetem Ergebnis, der bei jeder Änderung an Prompt, Modell oder Konfiguration durchläuft, mit einer Schwelle, die rot werden darf. Regressionstest für etwas, das nicht deterministisch antwortet. Natürlich bleiben noch zwei wichtige Stellen: die beiden Enden der Kette. Vorne das Warum. Was soll das System tun, für wen, was darf auf keinen Fall passieren? Keine Fleißaufgabe für die Doku, sondern die Vorgabe, aus der die Maschinerie ihre Prüfkriterien zieht. Fehlt sie, prüfen Agenten so, wie es ihnen leichtfällt, und nicht entlang des Risikos. So entstehen hundert grüne Häkchen auf Dingen, die nie jemand gefährlich gefunden hätte. Hinten die Wirklichkeit. Validierung gegen die echte Erwartung, Monitoring im Betrieb, und der Schritt, den die meisten auslassen: Jeder Vorfall aus der Produktion wird sofort nach vorne rückgespielt. Monitoring ist kein Anhängsel am Ende, sondern die Quelle, aus der die agentischen Feedback-Schleifen wachsen. Also, nicht beim Werkzeug anfangen. Geh mit Deinem Team die Stellen durch, an denen es wehtut oder die Reife sehr hoch ist. Und setz die erste Schleife genau dorthin. Eine reicht für den Anfang. Und dann weiter. Dein Team weiß, wo. --- ### Testing 2026: Die Arbeit wandert vom Schreiben zum Prüfen URL: https://www.richard-seidl.com/de/blog/ki-im-testing-2026/ Datum: 2026-08-24 Im Testing 2026 ist KI Werkzeug, Sparringspartner und Prüfling. Fünf Felder von Spezifikation über explorative Tests und Testdaten bis zu KI-Features. KI im Testing 2026: Werkzeug, Kollege, Prüfling Eines vorweg: Ich sehe GenAI als Werkzeug. Und für Werkzeuge gilt: “A fool with a tool is still a fool.” Ich nutze die KI gern als Sparringspartner, gehe in den Dialog, arbeite mich durch die Ergebnisse. Aber ob Werkzeug oder Sparringspartner: Es ist wie im echten Leben. Wenn ich von der Materie keine Ahnung habe, kann mir mein Gegenüber erzählen, was es will. Ich kann es nicht bewerten. Daran hat sich nichts geändert. Geändert hat sich, wie gut die Werkzeuge geworden sind und wie viele Leute damit hantieren. Für die EuroSTAR 2026 gab es rund 550 Einreichungen, erzählte deren Program Chair kürzlich, etwa 300 davon drehten sich um KI im Testing. Der Anteil mit echten eigenen Erfahrungen: deutlich kleiner. Viel Meinung, wenig Praxis. In meinen GenAI-Testing-Workshops halte ich es deshalb andersrum: Wir schauen nicht, was theoretisch möglich wäre, sondern was heute schon praktisch funktioniert. Und da hat sich einiges verschoben. Testfälle aus Anforderungen generieren? Macht inzwischen jeder. Copilot beim Skripten? Grundausstattung, keine Erwähnung mehr wert. Die Frage hat sich gedreht: von “Was kann die KI für dich tun?” zu “Was musst du prüfen, wenn sie mitarbeitet?” Fünf Felder, die ich gerade in Projekten und Trainings sehe. Spezifikation statt Testfall-Prompt Der Reflex ist verlockend: Code in den Prompt kippen, “schreib mir Tests dazu”, fertig. Dafür hat die Forschung inzwischen einen Namen: misguidance effect. Steckt ein Fehler im Code, schreibt das Modell brav Tests, die das Fehlverhalten als Sollverhalten festschreiben. Der Bug bekommt einen grünen Haken. Dazu passt eine Studie mit acht Modellen und über 22.000 Programmvarianten: Sobald sich der Code semantisch änderte, fiel die Pass-Rate der generierten Tests auf 66 Prozent, und über 99 Prozent der fehlschlagenden Tests waren auf der alten Version noch grün. Die Tests hatten das alte Verhalten auswendig gelernt, nicht die Anforderung verstanden. Die Umkehrung funktioniert: spezifikationsbasiertes Prompting. Gib dem Modell die Anforderung, das erwartete Verhalten, die Randbedingungen, und lass es daraus die Tests ableiten. Das muss kein 80-Seiten-Lastenheft sein. Eine ordentliche User Story mit Akzeptanzkriterien reicht oft schon, ein API-Kontrakt, eine Zustandstabelle. Werkzeugseitig tut sich da gerade viel, GitHub hat sein Spec Kit im August in Version 1.0 veröffentlicht. Aber ehrlich: Das ist einfach eine saubere Testbasis. Das predigen wir im Testing seit Jahrzehnten. Worauf du achten musst: Prompte aus der Spezifikation, nicht aus dem Code. Und wenn es keine Spezifikation gibt, ist genau das dein Befund. Explorativ testen: der Agent klickt selbst 2025 hieß explorativ mit KI: Ich hole mir Testideen aus dem Chat. Das geht heute noch, aber es ist nicht mehr der interessante Teil. Playwright liefert inzwischen drei Agenten ab Werk: Der planner erkundet die Anwendung selbstständig und schreibt einen Testplan als Markdown, der generator baut daraus Tests, der healer repariert kaputte. Über MCP klickt sich der Agent wirklich durch die Anwendung, statt über sie zu fantasieren. Das ist beeindruckend, wenn man es zum ersten Mal laufen sieht. Und trotzdem: Der Agent findet, was erreichbar ist. Nicht, was riskant ist. Er kennt eure Historie nicht, den Ärger mit der einen Schnittstelle, das Modul, das bei jedem Release bricht. Exploratives Testen lebt von Hypothesen, Erfahrung, Neugier. Der Loop liefert Breite. Die Fragen lieferst du. Worauf du achten musst: Nimm die Agenten-Ergebnisse als Rohmaterial, nicht als Testkonzept. Die Priorisierung nach Risiko bleibt bei dir. Testdaten: Fachlichkeit gelöst, Bereitstellung nicht Für mich die stärkste Spannung im ganzen Thema. Fachliche Varianten kann das Modell hervorragend: Grenzfälle, kaputte Adressformate, exotische Vertragskonstellationen, alles in Sekunden. Nur nützt dir die schönste generierte Tabelle nichts, wenn sie nicht ins Testsystem kommt. Eine Umfrage des Werkzeugherstellers Perforce unter 518 Enterprise-Verantwortlichen zeigt das Ausmaß: 99 Prozent warten länger als einen Arbeitstag auf eine frische Produktionskopie, 42 Prozent Wochen oder Monate. Und das ist kein Ausreißer, auch der World Quality Report zählt sichere, skalierbare Testdaten weiter zu den häufigsten Stolpersteinen. Maskierung, referenzielle Integrität, Provisioning: alles so zäh wie eh und je. Das LLM löst die Fachlichkeit, nicht die Logistik. Worauf du achten musst: Der Engpass sitzt in der Pipeline, nicht im Prompt. Bevor du Daten generierst, klär, wie sie ins System kommen. Prüfen, was die KI baut Code-Generierung ist Alltag geworden. Die Syntax stimmt fast immer. Die Sicherheit nicht: Veracode testet mit gleicher Methodik über 150 Modelle, und rund 45 Prozent der Generierungen enthalten eine bekannte Schwachstelle. Die Quote pendelt seit zwei Jahren zwischen 45 und 55 Prozent, und die Modellgröße ändert daran fast nichts. Die Modelle werden eloquenter, nicht sicherer. Und die naheliegende Idee, die KI ihre eigene Arbeit prüfen zu lassen? Eine Studie auf der MSR ‘26 hat 3.109 Pull Requests untersucht: Wurden sie nur von Review-Agenten geprüft, lag die Merge-Rate bei 45 Prozent. Bei rein menschlichem Review bei 68. KI, die KI prüft, reicht offenbar nicht. Hier entsteht 2026 echte neue Testarbeit: Review-Gates für generierten Code, Security-Checks, und die unbequeme Frage, wer eigentlich noch versteht, was da gemerged wird. Worauf du achten musst: Behandle generierten Code wie den Code eines neuen Kollegen. Schnell, fleißig, ohne Gespür für eure Altlasten. Das Review ist keine Formalie, es ist der Test. KI-Features testen: Evals statt Assertions Der fünfte Bereich dreht den Spieß um: nicht mehr KI im Testing, sondern Testing von KI. Wenn dein Produkt einen Chatbot, einen Assistenten oder eine RAG-Suche bekommt, testest du ein System, das auf dieselbe Eingabe verschieden antwortet. assertEquals läuft ins Leere. Stattdessen: Evals, Golden Datasets, LLM-as-Judge, Guardrails. Andere Werkzeuge, anderes Denken, aber im Kern die alte Frage: Was ist gut genug, und woran erkenne ich es? Wie real das ist, zeigt eine Applause-Umfrage unter fast 1.100 Befragten: 44 Prozent haben live geschaltete KI-Features wieder abgeschaltet, weil die Betriebskosten den Nutzen überstiegen. Mehr als vier von zehn. Für mich ist das gerade die häufigste neue Testaufgabe überhaupt, und die wenigsten Teams sind darauf vorbereitet. Worauf du achten musst: Definier vor dem Release, was “gut genug” heißt, und miss es laufend im Betrieb. Ein KI-Feature ohne Eval-Suite ist ein Blindflug mit Ansage. Die Arbeit verschwindet nicht, sie wandert Über alle fünf Felder zieht sich dasselbe Muster: Die Arbeit verschwindet nicht. Sie wandert. Vom Schreiben zum Prüfen, vom Ausführen zum Bewerten. Elmar Jürgens hat es auf den Software Quality Days schön gesagt: “Don’t stop doing as much quality assurance as you do now because it feels like we’re just moving faster …” Und Prüfen braucht Urteilsvermögen. Das entsteht nicht beim Zuschauen, sondern beim Tun: beim Debuggen, beim Testdaten-Bauen, beim Streiten über Anforderungen. Wer das systematischer angehen will: Sogar das ISTQB führt inzwischen einen eigenen GenAI-Lehrplan. Wenn mir das Wissen fehlt, wird es gefährlich. Das galt schon immer. Aber 2026 gilt es mehr denn je, denn die Ergebnisse sehen inzwischen alle richtig aus. Ob sie es sind, merkt nur, wer es beurteilen kann. Häufig gestellte Fragen Warum liefert KI schlechte Tests, wenn man ihr einfach den Code vorlegt? Weil das Modell den Code als Wahrheit nimmt. Steckt ein Fehler darin, schreibt es Tests, die das Fehlverhalten als Sollverhalten festschreiben: der Bug bekommt einen grünen Haken. Die Forschung nennt das misguidance effect. Eine Untersuchung mit acht Modellen und über 22.000 Programmvarianten zeigte zudem: Nach semantischen Codeänderungen fiel die Pass-Rate der generierten Tests auf 66 Prozent. Welche Testbasis braucht spezifikationsbasiertes Prompting mindestens? Ein 80-Seiten-Lastenheft ist nicht nötig. Eine ordentliche User Story mit Akzeptanzkriterien reicht oft, ebenso ein API-Kontrakt oder eine Zustandstabelle. Entscheidend sind Anforderung, erwartetes Verhalten und Randbedingungen als Eingabe, nicht der fertige Code. Und wenn es zu einer Funktion überhaupt keine Spezifikation gibt, ist genau das ein Testbefund. Können Test-Agenten exploratives Testen übernehmen? Nein. Ein Agent findet, was erreichbar ist, nicht, was riskant ist. Er kennt die Projekthistorie nicht, nicht den Ärger mit einer bestimmten Schnittstelle und nicht das Modul, das bei jedem Release bricht. Exploratives Testen lebt von Hypothesen und Erfahrung. Agenten liefern Breite und Rohmaterial, die Priorisierung nach Risiko bleibt beim Menschen. Löst generative KI das Testdatenproblem? Nur die Hälfte davon. Fachliche Varianten liefert ein Modell in Sekunden: Grenzfälle, kaputte Adressformate, exotische Vertragskonstellationen. Die Bereitstellung bleibt zäh. In einer Perforce-Umfrage unter 518 Enterprise-Verantwortlichen warteten 99 Prozent länger als einen Arbeitstag auf eine frische Produktionskopie, 42 Prozent Wochen oder Monate. Maskierung, referenzielle Integrität und Provisioning löst kein Prompt. Wie sicher ist KI-generierter Code? Die Syntax stimmt fast immer, die Sicherheit nicht. Veracode prüft mit gleicher Methodik über 150 Modelle: rund 45 Prozent der Generierungen enthalten eine bekannte Schwachstelle. Die Quote pendelt seit zwei Jahren zwischen 45 und 55 Prozent, und die Modellgröße ändert daran fast nichts. Die Modelle werden eloquenter, nicht sicherer. Reicht es, generierten Code von einem KI-Review-Agenten prüfen zu lassen? Nein. Eine auf der MSR ‘26 vorgestellte Studie untersuchte 3.109 Pull Requests: Wurden sie nur von Review-Agenten geprüft, lag die Merge-Rate bei 45 Prozent, bei rein menschlichem Review bei 68 Prozent. KI, die KI prüft, trägt nicht weit genug. Nötig sind Review-Gates für generierten Code und Security-Checks. Warum werden fertige KI-Features nach dem Livegang wieder abgeschaltet? Weil die Betriebskosten den Nutzen übersteigen. In einer Applause-Umfrage unter fast 1.100 Befragten gaben 44 Prozent an, live geschaltete KI-Features wieder deaktiviert zu haben. Wer das vermeiden will, definiert vor dem Release, was “gut genug” heißt, und misst es laufend im Betrieb: über Evals, Golden Datasets und Guardrails statt über feste Soll-Vergleiche. --- ### Scheitern ist eine Entscheidung URL: https://www.richard-seidl.com/de/blog/scheitern-ist-eine-entscheidung/ Datum: 2026-08-14 Scheitern ist kein Zustand, sondern eine Entscheidung. Was die Impro-Bühne darüber lehrt und welche drei Fragen vor dem Aufhören helfen. “Sometimes you win, sometimes you win later.” - Richard Seidl Einer meiner Lehrer aus der Erwachsenenzeit ist Gaston Florin. In einem Impro-Workshop hat er mal einen Satz gesagt, der bei mir hängen geblieben ist: “Sometimes you win, sometimes you lose.” Eine gute Haltung fürs Impro. Dort gibt es nämlich kein Verlieren im klassischen Sinn. Eine Szene kippt, ein Einfall zündet nicht, jemand versteht das Angebot des anderen komplett falsch. Und dann? Dann läuft die Szene weiter. Der Fehler wird aufgenommen, bespielt, wird selbst zum Angebot. Was eben noch nach Scheitern aussah, ist zwei Minuten später die beste Wendung des Abends. Ich habe für mich den Satz weitergedreht und er begleitet mich seitdem: Sometimes you win, sometimes you win later. Der Satz fällt mir in letzter Zeit oft wieder ein. Denn mir begegnet gerade das Gegenteil. In Projekten, in Teams, in Gesprächen. Aufhören liegt in der Luft. Quiet Quitting. Vorhaben, die still einschlafen. Initiativen, die nach dem zweiten Rückschlag beerdigt werden. Transformationen, die man nach sechs Monaten als “nicht geglückt” abdreht. Das Refactoring, das nie über den Prototypen hinauskommt. Die agile Arbeitsweise, die beim ersten Gegenwind zur Schönwetteragilität schrumpft und beim zweiten ganz verschwindet. Ich will das gar nicht pauschal bewerten, manches davon ist vernünftig. Aber ich nehme eine Grundstimmung wahr, eine Art kollektives Achselzucken: Bringt ja eh nichts. Dabei lohnt ein zweiter Blick auf das Wort Scheitern. Wir reden über Scheitern, als wäre es ein Zustand. Etwas, das einem zustößt wie schlechtes Wetter. Das Projekt ist gescheitert. Die Idee ist gescheitert. Ich bin gescheitert. Stempel drauf. Nur: Wer vergibt eigentlich diesen Stempel? Es gibt keine Instanz, die irgendwann objektiv feststellt, jetzt sei es endgültig vorbei. Diesen Moment gibt es nur an einer einzigen Stelle: in der Entscheidung aufzuhören. Scheitern ist kein Zustand. Scheitern ist eine Entscheidung. Solange ich weitermache, bin ich nicht gescheitert. Ich bin mittendrin. Natürlich ist nicht alles durchzuhalten. Es gibt auch genug tote Pferde, die immer noch geritten werden, weil wir schon so viel investiert haben. Die spannendere Frage ist daher: Wo lohnt es sich weiterzumachen? Ich glaube, da gibt es kein objektives “lohnt sich”, das man messen könnte wie eine Testabdeckung. Ob etwas sich lohnt, entsteht in der Beschreibung, die wir davon machen. Dasselbe Vorhaben ist für den einen ein Fass ohne Boden und für die andere ein Lernfeld, das gerade anfängt, Früchte zu tragen. Beide haben recht. Wer nach dem Beweis sucht, dass sich das Durchhalten am Ende auszahlt, sucht am falschen Ort. Diesen Beweis gibt es vorher nie. Was mir persönlich stattdessen hilft, sind drei kleine Fragen. Nicht: Warum klappt es nicht? Diese Frage kenne ich gut, sie macht das Problem nur größer und größer. Sondern: Woran merke ich, dass es sich noch bewegt? Was wäre der nächste kleine Schritt? Und die wichtigste: Hab ich da wirklich, wirklich noch Bock drauf? Und ja, manchmal lautet die Antwort danach trotzdem: Ich höre auf. Das ist völlig in Ordnung. Aber dann ist es eine Entscheidung, die ich mit klarem Kopf treffe, und kein Verhängnis, das über mich kommt. Wer entscheidet, kann auch anders entscheiden, heute, in einem Monat, in einem Jahr. Wer sich dagegen für gescheitert erklärt, hat sich das Weiterspielen selbst verboten. Auf der Impro-Bühne ist die Szene erst vorbei, wenn die Spieler sie beenden. Nicht, wenn der erste Einfall danebengeht. Ich glaube, das gilt auch jenseits der Bühne: Sometimes you win. Sometimes you win later. --- ### Schnellere Pferde URL: https://www.richard-seidl.com/de/blog/schnellere-pferde/ Datum: 2026-07-04 Mit KI bauen wir gerade schnellere Pferde für unseren alten Job. Die richtigen Probleme sind menschliche, und dafür müssen wir miteinander reden. “BDD, Planning Poker, Refinements: Es geht immer ums Miteinander-Reden.” - Richard Seidl Ich glaube, wir benutzen KI gerade für die falschen Probleme. Testfälle generieren, Boilerplate-Code schreiben, kaputte Tests automatisch flicken. Alles nett, alles effizient. Und nicht falsch verstehen: Ich nutze diese Werkzeuge täglich und möchte sie nicht mehr hergeben. Aber ehrlich betrachtet ist das gerade unser alter Job, schneller erledigt. Es gibt dieses bekannte Zitat, das Henry Ford zugeschrieben wird (stimmt zwar wohl nicht, trifft es aber): “Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.” Erinnerst Du dich noch an das erste iPhone? Es zeigte Websites in klein an. Ein Browser auf einem hübschen Gerät. Spannend wurde es erst, als man aufhörte, das Alte nachzubauen. Als Dinge entstanden, die es vorher gar nicht geben konnte. Shazam, Uber, etc. In der Software-Entwicklung kennen wir diesen Moment eigentlich gut. Assembler wurde von Hochsprachen abgelöst, auf die Hochsprachen kamen Frameworks, und jede dieser Schichten hat dasselbe getan: eine Fertigkeit entwertet und eine neue aufgewertet. Wer früher Register im Kopf jonglieren konnte, war ein Held. Ein paar Jahre später brauchte das kaum noch jemand, dafür brauchte es Menschen, die Systeme entwerfen konnten. Die Frameworks haben dann das Rad-neu-Erfinden entwertet und das Zusammensetzen aufgewertet. Jedes Mal ging ein Stück Handwerk verloren, jedes Mal wurde ein anderes Stück Denken wichtiger. Und jedes Mal gab es Kollegen, die schworen, ohne die alte Fertigkeit könne niemand ernsthaft Software bauen. Ich habe hier vor einiger Zeit mal gefragt, ob die KI überhaupt noch unsere Programmiersprachen braucht. Heute interessiert mich die andere Seite der Frage: Was macht diese neue Abstraktion mit uns? Denn genau das ist KI: die nächste Abstraktionsschicht. Diesmal wandert die Ausführung selbst zur Maschine. Und welche Fertigkeit wird aufgewertet? Absicht präzise formulieren. Was soll das System tun? Für wen? Warum überhaupt? Was darf auf keinen Fall passieren? Wir haben Jahrzehnte damit verbracht, aus vagen Wünschen Software zu machen. Lastenhefte, User Stories, Akzeptanzkriterien: alles Versuche, Absicht festzunageln. Meistens mittelgut. Wir haben immer wieder andere Formen versucht, diesen Transfer hinzubekommen. Und was am besten funktioniert hat: Miteinander reden. Planning Poker = Miteinander reden. BDD = Miteinander reden. Refinements = Miteinander reden. Eine gemeinsame Perspektive finden. Wer das kann, konnte schon immer gute Software bauen. Jetzt geht es ohne Umweg. Und es demokratisiert gewaltig: Wer eine Idee in Sprache fassen kann, kann bauen. Großartig und gefährlich zugleich. Ich höre in letzter Zeit oft eine Art Karrierewette: Solange die KI halluziniert, braucht es mich am Quality Gate. Darauf würde ich nicht zu viel setzen. Mit Grounding und Verifikation sinkt die Fehlerrate, und Wetten gegen die Lernkurve der Technik haben wir in unserer Branche selten gewonnen. Die leisere Gefahr ist eine andere. Wenn die KI das Können übernimmt: Woher kommt dann das Können, mit dem wir sie beurteilen? Urteilsvermögen entsteht durchs Tun, nicht durchs Zuschauen. Wer das Denken zu früh auslagert, verlernt genau die Fähigkeit, die ihn unersetzbar machen sollte. Eines kann die Maschine allerdings nicht, egal wie gut sie wird: wollen. Sie rekombiniert ihren Trainingsraum, brillant und unermüdlich. Aber da ist kein Ziel, kein Interesse, kein Einsatz im Ergebnis. Der Wert unserer Arbeit lag nie allein in der Ausführung. Er liegt in der Absicht dahinter. Und die richtigen Probleme? Das sind menschliche Probleme. Wofür ist das gut? Für wen? Sollten wir es überhaupt bauen? Wer braucht denn die ganzen generierten Apps noch? Die spannenden Fragen in meinen Projekten waren nie: Wie schreibe ich diese Testfälle? Sondern: Warum reden Fachbereich und Entwicklung aneinander vorbei? Warum steht diese Anforderung im Backlog, obwohl niemand mehr weiß, wer sie wollte? Solche Fragen werden zwischen Menschen entschieden, in Meetings, am Kaffeeautomaten, im Streit über Prioritäten. Nicht im Modell. Qualität ist ein soziales System, kein technisches. Und KI verstärkt, was schon da ist: Ein Team mit gemeinsamem Verständnis wird schneller. Ein Team voller Missverständnisse, Silos und Misstrauen bekommt dieselben Probleme, nur in höherer Taktung. Darüber sollten wir mal: Miteinander reden. --- ### Es ist jetzt die Zeit für "richtiges" Agile URL: https://www.richard-seidl.com/de/blog/zeit-fuer-richtiges-agile/ Datum: 2026-05-28 Agile erzeugt heute mehr Augenrollen als Motivation. Warum genau jetzt die Zeit für richtiges Agile ist: individuell, menschlich, lernend. “Agilität ist etwas sehr sehr Individuelles.” - Richard Seidl Frustration macht sich breit. Agile erzeugt heute mehr Augenrollen und Naserümpfen als Freude und Motivation. Wir bekommens zwar nicht so mit, weil wir nur mehr an unseren Prompts und Agents rumschrauben - aber dahinter brodelt es. Und das schon länger. Warum ist das so? Wir Menschen möchten einfache Lösungen für Herausforderungen. Und eine der größten Herausforderungen in der Softwareentwicklung war schon immer: Wie arbeiten wir mit Freude, motiviert und produktiv zusammen? Wie bekommen wir grundlegende Bedürfnisse wie Selbstwirksamkeit, Individualismus und Zugehörigkeit in Balance, um Emergenz zu schaffen? Und einfache Lösungen bietet uns da die Berater- und Werkzeugbranche: Kaufe dieses Tool, es löst deine Probleme! Nutze dieses Framework! Implementiere dieses Modell! Und so haben wir mit Energie Dinge wie Testautomatisierung, Scrum, Kanban, SAFe, DevOps, NewWork, etc. auf unsere Herausforderungen geworfen, in der Hoffnung sie verschwinden. Tun sie aber nicht. Ach, und jetzt haben wir noch KI: Schmeißen wir auch noch drauf, um mit etwas Einfachem, Technischem unsere menschlichen “Probleme” zu lösen. Nicht falsch verstehen, da sind ganz tolle Sachen drinnen, die auch alle ihren Wert haben, aber wenn ich auf das Agile Manifest schaue, glaube ich nicht, dass das damit gemeint war. Für mich geht es da um Kommunikation und Zwischenmenschlichkeit. Wie schaffen wir ein Verständnis? Wie arbeiten wir wertschätzend zusammen? Und vor allem: Wie werden wir ein selbstlernendes System, das seine eigenen, ganz individuellen Prozesse, Rituale und Strategien entwickelt? Ich glaube, Agilität ist für Teams etwas hoch Individuelles. Es ist ein Ziel. Es ist ein Prozess, der sich ständig wandelt und an die Bedürfnisse anpasst. Da passen so starre Konzepte nicht rein, wie: Du musst jetzt ein 15-Minuten-Daily machen, diese und jene Sprints haben und mit Story Points um dich werfen. Diese Dinge können Inspiration sein, ein Buffet an Best Practices, die anderswo gut funktioniert haben. Das heißt aber nicht, dass es bei uns funktioniert. Warum ist das jetzt besonders wichtig? Seit ein paar Jahren ist nun KI mit von der Partie. Wir fokussieren da gerade auf etwas sehr sehr Technisches und lassen etwas anderes außen vor: uns Menschen. Und das ist fatal, denn im Endeffekt ist das viel wichtiger als der technische Part. Bei aller Liebe zum Prompting und Claude Coding - wir müssen auf uns und unser Umfeld achten. Und genau da kommt Agile ins Spiel. Ich glaube nicht, dass Agile tot ist. Ganz im Gegenteil, es ist an der Zeit, dass wir es “richtig” machen. Und richtig ist für jedes Team was anderes. Vielleicht dürfen wir es nicht mehr so nennen, dann finden wir einen anderen Namen dafür. Aber ums Umsetzen der Ideen und der Haltung werden wir nicht herumkommen, wenn wir künftig noch gut zusammenarbeiten wollen. --- ### Zwischen Stolz und Wegwerfware URL: https://www.richard-seidl.com/de/blog/zwischen-stolz-und-wegwerfware/ Datum: 2026-05-11 Wer KI-Output nur übernimmt, baut keine Beziehung zum Ergebnis auf. Warum Ownership beim Durchdringen entsteht und nicht beim Generieren. “Was wir selbst durchdrungen haben, gehört uns. Was wir nur erhalten haben, bleibt fremd.” - Richard Seidl Ich hatte letztes Jahr in “Verhindern wir Lernen?” folgenden Gedanken durchgearbeitet: Wenn wir durch KI etwas erstellen lassen, fokussieren wir nur mehr auf das Produkt, nicht mehr auf den Prozess des Entstehens. Und dadurch entgeht uns etwas: die Möglichkeit zu lernen. Ich möchte diesen Gedanken heute sogar noch etwas weiterspinnen. Ich glaube nämlich, dass wir da noch etwas ganz anderes machen: Wir bauen keine Beziehung zu dem Ergebnis auf. Das führt dazu, dass wir es weniger wertschätzen, schneller austauschen und keine große Bindung dazu aufbauen. Zwei Beispiele: Jemand repariert einen alten Laserdrucker. Papierstau-Sensor gereinigt, Walze getauscht, Gehäuse wieder zu. Eine Stunde Arbeit, Schraubenzieher und ein YouTube-Video. Wer so ein Ding einmal aufgeschraubt hat, kennt es danach. Weiß, wo es klemmt, warum es manchmal komisch zieht, wo die schwache Stelle sitzt. Hat gerochen, wie Tonerstaub riecht. Hat verstanden, warum der Einzug manchmal versagt. Ein nagelneuer Mixer, nach zwei Jahren mit kaputtgegangenem Motor weggeschmissen. “Kann man sowieso nicht reparieren lassen.” Stimmt vielleicht. Vielleicht auch nicht. Aber interessanter ist das, was davor steht: Der Versuch wurde gar nicht erst gemacht. Zwei Jahre täglich in Betrieb. Jeden Morgen Smoothies. Und trotzdem völlig fremd. Eine Blackbox. Eingesteckt, genutzt, entsorgt. Besitzen heißt verstehen Ich bin die Tage auf folgenden Satz gestoßen: “If you can’t fix it, you don’t own it.” (iFixit-Manifest). Und da ist was dran, finde ich: Dinge, in die wir Zeit und Gedanken gesteckt haben, sind uns nah. Dinge, die wir nur konsumieren, bleiben auf Abstand. Wir schmeißen heute massenhaft weg. Nicht weil uns Nachhaltigkeit egal wäre. Sondern weil uns die Dinge egal sind. Keine Beziehung. Kein Schmerz beim Wegwerfen. Agentic Engineering Und wir machen das Gleiche jetzt mit Vibecoding und Agentic Engineering. Wir generieren Testfälle, Automatisierungen, Code, Datenbank-Schemata, Testdaten, Schnittstellen … und wenn wir einen Fehler finden? Dann schnell mal Codex oder Claude Code drangelassen. Und schwuppdiwupp ist der Fehler behoben. Wir wissen dann gar nicht, was die Ursache war. Und selbst wenn wir sie lesen, sind wir ja nicht davor gefeit, dass es erneut passiert. Selbes Bild bei Tests. Testfälle aus Anforderungen generieren, jucheee. Schnell, sauber, viele. Nur: Wer hat dabei verstanden, warum dieser Grenzfall existiert? Welcher Stakeholder-Konflikt hinter dieser Anforderung steckt? Was im letzten Release schiefgegangen ist, weshalb dieser Test überhaupt jetzt hier steht? Das Artefakt ist da. Die Geschichte dahinter nicht. Ownership entsteht im Prozess Ownership entsteht nicht, wenn ich etwas erhalte. Sie entsteht, wenn ich etwas durchdringe. Wenn ich debugge, refactore, kämpfe, mich damit reibe. Wenn ich einen Fehler gemacht und ihn behoben habe. Diese Art von Ownership ist nicht romantisch gemeint. Wer seinen Code besitzt, kann ihn reparieren. Wer seine Architektur besitzt, kann sie verantworten. Wer seine Tests besitzt, weiß, was sie prüfen und was nicht. Ich würde sogar sagen: Je tiefer wir darin versinken und uns reinarbeiten, desto mehr Stolz, Beziehung und Verantwortung haben wir … spüren wir. Wer KI-Output nur übernimmt, hat das nicht. Das ist ein Unterschied. Wir bauen gerade mit Hochdruck Software, die aus generierten Teilen zusammengesetzt ist, die niemand wirklich durchdrungen hat. Und wir nennen das Produktivität. Sie läuft, solange nichts passiert. Sobald etwas passiert, schauen alle sich ratlos an … und fragen die KI. Die Balance finden Ihr wisst, ich mag KI. Ich nutze sie auch oft. Aber wie so oft mit Technologie müssen wir erst lernen, damit in einem guten Maße umzugehen … und das möglichst rasch. Aktuell sehe ich da eine sehr große Disbalance. Vielleicht ist ein guter Start, dass wir KI als Ausgangspunkt und nicht als Endpunkt verwenden. Und uns immer wieder fragen: Identifiziere ich mich eigentlich gerade mit dem, was ich hier tue, oder baue ich Wegwerfware? Und ein Gedanke noch zum Schluss: Überlegt mal, warum ihr wirklich angefangen habt zu programmieren oder Testfälle zu entwickeln oder Architekturen zu entwerfen. Ich glaube, bei den meisten von uns war die Motivation: Ich kann hier etwas gestalten, und es macht mir Spaß, etwas zu bauen. Sollten wir uns das wegnehmen? --- ### Die große Verdichtung URL: https://www.richard-seidl.com/de/blog/die-grosse-verdichtung/ Datum: 2026-03-09 KI und Agilität verdichten Wissen und Arbeit in der Software-Entwicklung. Warum uns dabei die Zeit zum Denken fehlt und wie bewusste Bremsen helfen. “Alles ist jetzt.” - Richard Seidl Gestern hab ich mein Bücherregal aussortiert. Da ist mir ein Buch in die Hände gefallen: Kamtschatka, 2008. Ich hab damals eine mehrwöchige Expedition über diese atemberaubende Halbinsel gemacht. Und dafür Bücher wie dieses durchgearbeitet: Seite für Seite. Vorfreude. Ich hab mir vorgestellt, wie es wohl auf diesen aktiven Vulkanen sein wird, wie die Kultur ist und ob wir uns vor Bären schützen müssen (Spoiler: ja, vor allem wenn sie mit ihren Kleinen um 2 Uhr früh durchs Zeltcamp toben). Wie würde das heute laufen? Drei Sekunden Google Maps, 4K-Drohnenflug auf YouTube, die 47 besten Restaurants auf TripAdvisor, KI-generierte Tagesroute und der personalisierte Reiseplan von ChatGPT. Alles da. Sofort. Und irgendwie … ist der Tolbatschik schon abgehakt, bevor ich den Rucksack gepackt habe. Wenn alles jetzt ist Wir leben in einer Zeit, in der die Zeit selbst sich verändert hat. Nicht die physikalische, die erlebte. Alles ist sofort verfügbar. Jede Information, jedes Wissen, jede Antwort. Kein Warten mehr. Kein Suchen … und kein Reifen. Früher gab es sowas wie eine natürliche Verzögerung. Man musste in die Bibliothek gehen. Einen Kollegen anrufen und hoffen, dass er abnimmt. Auf die Fachzeitschrift warten. Diese Verzögerung war kein Bug. Sie war ein Feature. Denn in der Wartezeit passierte etwas: Wir dachten nach. Wir verdauten. Unser Hirn sortierte im Hintergrund, verknüpfte, reifte. Die Antwort, die am Ende kam, fiel auf vorbereiteten Boden. Heute fällt die Antwort auf nackten Asphalt. Und die nächste gleich hinterher. Und die nächste. Die verdichtete Arbeit Parallel dazu erleben wir eine zweite Verdichtung: die der Arbeitszeit. Das ist nicht neu, Agilität hat hier schon ordentlich vorgelegt. Kürzere Zyklen, schnelleres Feedback, permanente Iteration. Das war und ist gut und richtig. Aber mit KI im Werkzeugkasten drehen wir den Verdichtungsregler nochmal ordentlich auf. Code generieren. Testfälle ableiten. Dokumentation erstellen. Reviews vorbereiten. Alles in Minuten statt Stunden. Da bleibt mehr Zeit für … ja, wofür eigentlich? Für den nächsten Sprint. Für noch mehr Output. Für noch dichtere Takte. Wir füllen die gewonnene Zeit nicht mit Denken, sondern mit Tun. Mit noch mehr Tun. Das Hamsterrad dreht sich schneller, aber der Hamster ist derselbe. Die Gleichzeitigkeit Beide Verdichtungen zusammen erzeugen eine Gleichzeitigkeit. Alles Wissen ist jetzt da und alle Arbeit soll jetzt fertig sein. Es gibt keine Vergangenheit mehr, aus der wir lernen (wozu, die KI hat die Antwort) und keine Zukunft, auf die man hinarbeitet (wozu, der nächste Sprint ist übermorgen). Alles wirkt ins Jetzt. Wir haben die Reibung eliminiert. Die Pausen. Die Zwischenräume. Und damit auch den Raum, in dem Ideen wachsen, Erfahrung sich formt und auch Persönlichkeit reift. Kleine Bremsen einbauen Nicht falsch verstehen: Ich liebe gut gelebte Agilität und auch meine KI-Tools schätze ich sehr. Aber uns fehlt der Dreh, diese Dinge sinnvoll und mit einem “Warum” anzuwenden. Wir sprechen ständig davon, uns selbst durch KI abzuschaffen. Aber warum eigentlich? Es liegt ja an uns, die KI so zu nutzen, wie wir das wollen. Was also tun? Die KI abschalten? Zurück zum Wasserfall? Nein, natürlich nicht. Aber vielleicht ein paar bewusste Bremsen einbauen. Entschleunigungspunkte. Reibungsflächen mit Absicht. Die gewonnene Zeit mit Dingen füllen, die uns Freude machen (Programmieren zum Beispiel). Die wiederentdeckte Langsamkeit Ich bin überzeugt: Die große Kompetenz, die wir in der Software-Entwicklung brauchen, ist nicht Agent-Orchestrierung oder das nächste Framework. Es wird die Fähigkeit sein, bewusst zu denken in einer Welt, die immer schneller liefert. Und vielleicht fangen wir einfach mal damit an, die nächste KI-Antwort nicht sofort zu akzeptieren. Sondern sie einen Moment wirken zu lassen. Zu prüfen. Zu hinterfragen. Und dann ganz altmodisch selbst zu denken. --- ### KI: Lösen wir die für uns relevanten Probleme? URL: https://www.richard-seidl.com/de/blog/ki-relevante-probleme/ Datum: 2026-02-05 KI in der Softwareentwicklung generiert Apps im Nu, während Teams in Legacy-Code ersticken. Warum KI die Probleme lösen sollte, die wirklich wehtun. “Ich brauch keine KI, die mir Kinofilme produziert. Ich brauche eine für meine Steuer und mein Backoffice.” - Richard Seidl Während ich diese Kolumne schreibe, generiert irgendwo eine KI gerade ein Bild von einem Astronauten, der auf einem Einhorn durch den Weltraum reitet. Aber gleichzeitig sitze ich in ein paar Minuten vor meiner Steuer, Reisekostenabrechnungen, Behördenkorrespondenz und ein paar juristischen Texten. Da frage ich mich: Warum eigentlich? Wir feiern grade ganz viel KI-generierte Texte, Musik und Videos. Beeindruckend, ich schau es auch gerne. Aber: Lösen wir damit die Probleme, die uns wirklich den Schlaf rauben? In der Softwareentwicklung läuft es grade ähnlich. Wir schauen der KI zu, wie sie Code generiert und im Nu eine neue App entwickelt. Codequalität egal. Läuft ja. Daneben ersticken Teams in Legacy-Code, den niemand mehr versteht und warten kann. Wir träumen von autonomen Test-Agenten, während unsere Teststrategie Grütze ist und Flaky Tests das Vertrauen in unsere Pipeline gebrochen haben. Das Problem ist dabei gar nicht die Technologie. Das Problem ist unser Fokus. Wir optimieren für Demos, nicht für den Alltag. Für LinkedIn-Posts, nicht für Produktivität. Für das Spektakuläre, nicht für das Nützliche. Was brauchen wir wirklich? Wo ist denn ein Schmerz? Was möchte ich denn eigentlich nicht mehr machen? Abgleich meiner Testfälle mit hundert Seiten Anforderungsspezifikation! Eine KI, die versteht, warum dieser eine Test seit drei Monaten sporadisch fehlschlägt. Eine, die mir beim Code-Review nicht nur Syntaxfehler zeigt, sondern fachliche Inkonsistenzen. Wo ich persönlich im ersten Schritt gar keine KI möchte: Testfallerstellung. Ich liebs einfach, mir zu einer User Story oder einer Anforderung zu überlegen, wie ich diese gut testen könnte. Es macht mir einfach Spaß und ich lern was dabei. Klar nehm ich mir die KI dann gerne noch zum Gegencheck dazu, aber nicht fürs initiale Erstellen. Die schönen Sachen, die einem Freude machen, selbst tun. Die Unliebsamen der KI übergeben. Daran sollten wir uns (nicht nur in der Software-Entwicklung) orientieren. Die gute Nachricht: Dieser Fokus entsteht immer mehr. Die immergleichen KI-LinkedIn-Posts beginnen zu langweilen. Wir verstehen langsam, dass der Wert von Technologie nicht in ihrer Brillanz liegt, sondern in den Problemen, die sie löst. Qualität bedeutet auch, das Richtige richtig zu tun. Das gilt auch für KI. Bevor wir fragen “Was kann KI?”, sollten wir fragen: “Was brauchen wir?” Die Antwort ist selten ein reitender Astronaut. Meistens ist es eher sowas wie eine Reisekostenabrechnung, die sich von selbst erledigt. --- ### Wir brauchen mehr Langeweile URL: https://www.richard-seidl.com/de/blog/wir-brauchen-mehr-langeweile/ Datum: 2026-01-15 Ohne Smartphone im Wartezimmer passiert Erstaunliches: ein eigener Gedanke. Warum unser Gehirn Leerlauf braucht und Langeweile Ideen bringt. “Im Nichtstun entsteht mehr als im Dauertun.” - Richard Seidl Vor ein paar Wochen saß ich im Wartezimmer beim Arzt. Ohne Smartphone. Vergessen. Die anderen starrten alle auf ihre Bildschirme, scrollten, tippten, wischten. Ich saß da und … ja, was eigentlich? Ich schaute aus dem Fenster. Beobachtete den Schnee. Und nach ein paar Minuten passierte etwas: Ich hatte einen interessanten Gedanken. Meinen eigenen. Nicht das hektische Springen von Ablenkung zu Ablenkung, das wir aus dem Alltag kennen. Sondern ein ruhiges Fließen. Plötzlich entwickelte sich daraus eine Idee für ein Problem bei einem Kunden, bei dem ich seit Wochen feststeckte. Einfach so. Aus dem Nichts. Oder besser: aus der Leere. Der Feind heißt Langeweile Wir haben der Langeweile den Krieg erklärt. Und wir gewinnen. Überall. Jede Sekunde Leerlauf wird sofort gefüllt. An der Bushaltestelle. Auf der Toilette. Im Aufzug. Zwischen zwei Meetings: schnell noch Mails checken. Beim Warten auf den Build: LinkedIn scrollen. Abends auf der Couch: Netflix im Hintergrund, während wir auf dem Tablet surfen und nebenbei WhatsApp-Nachrichten beantworten. Wir sind Weltmeister im Beschäftigt-Sein geworden. Oder zumindest im Beschäftigt-Wirken. Denn: Beschäftigt sind wir. Aber produktiver? Kreativer? Glücklicher? Nein. Wir sind erschöpfter. Überstimulierter. Und paradoxerweise ideenärmer. Ja, und mit ChatGPT und Co wird’s gleich nochmal eine Runde schlimmer. Das Gehirn im Leerlauf Die Neurowissenschaft hat einen wunderbaren Begriff: das Default Mode Network (DMN). Das ist der Teil unseres Gehirns, der aktiv wird, wenn wir nichts Bestimmtes tun. Wenn wir tagträumen, aus dem Fenster starren, gedankenverloren spazieren gehen. Lange dachte man, das sei verschwendete Zeit. Heute wissen wir: Genau in diesen Momenten passiert Wesentliches. Das DMN verknüpft Erfahrungen, sortiert Eindrücke, entwickelt kreative Lösungen. Es ist quasi unser interner Innovations-Inkubator. Aber dieser Inkubator braucht Ruhe. Er braucht Leere. Er braucht Langeweile. Und genau die gönnen wir ihm nicht mehr. Wir füttern unser Gehirn mit einem Dauerstrom an Reizen, Notifications, Podcasts, Content. Kein Wunder, dass uns die großen Ideen ausgehen und wir stattdessen im Klein-Klein des Tagesgeschäfts versinken. Agil, aber ausgebrannt Ich sehe das in vielen Teams, mit denen ich arbeite. Da wird von Sprint zu Sprint gehetzt. Retros werden durchgepeitscht, weil schon das nächste Planning wartet. Zwischen den Meetings ist keine Luft zum Atmen. Von einem Teams-Call in den nächsten. Jeder Slot im Kalender ist verplant. Und wenn mal eine Stunde frei ist, wird sie sofort mit “produktiven” Tätigkeiten gefüllt. Das Ergebnis? Müde Teams. Ausgelaugte Entwickler. Gestresste Tester. Meine persönliche Langeweile-Praxis Ich habe mir über die Jahre ein paar Rituale erarbeitet, um meine Langeweile zu pflegen: - Warten ohne Ablenkung: an der Kasse, an der Bushaltestelle, beim Arzt. Einfach mal nichts tun und nur schauen. - Joggen und Sport: Ich habe früher immer Podcasts gehört beim Laufen. Um die Zeit zu “nutzen”. Jetzt laufe ich ohne AirPods. Dafür nehme ich mir eine Frage mit auf die Laufrunde. - Silent Driving: im Auto ohne Hörbuch und Autoradio. - Puffer im Kalender: Meetings mache ich eh nur am Nachmittag. Vormittags ist Deep Work und Ruhe angesagt. Der Mut zur Leere Ja, das klingt nach Luxus. Wer hat schon Zeit für Langeweile? Die Backlogs sind voll, die Deadlines drücken, Chefs wollen Ergebnisse. Aber genau das ist der Denkfehler. Vielleicht ist die Leere keine verschwendete Zeit, sondern eine Investition. In Kreativität. In Problemlösungskompetenz. In unsere geistige Gesundheit. Die besten Ideen meines Lebens hatte ich in solchen Momenten. Also: Einfach mal ausprobieren. Smartphone weglegen. Browser-Tabs schließen und Hintergrundmusik ausmachen. Dreimal durchatmen und einfach mal aus dem Fenster schauen. Und wer weiß, vielleicht wartet da schon die Lösung für das hartnäckigste Problem. --- ### Open Source: Mit Bedacht URL: https://www.richard-seidl.com/de/blog/open-source-mit-bedacht/ Datum: 2025-12-11 Wer Open-Source-Software nutzt, prüft Lizenzen, Support und Qualität selbst. Die Community lebt vom Zurückgeben, Tester helfen dabei mit Bugreports. “Open Source ist wunderbar - wenn man weiß, was man tut.” - Richard Seidl Heute bin ich mal Spielverderber. Oder Blockwart. Könnt ihr Euch aussuchen. Und zwar möchte ich ein paar Gedanken mit Euch zum Thema Open Source teilen. Für viele ist das einfach “kostenlose Software”. Aber so einfach ist das leider nicht. Lizenzen Auch wenn Open-Source-Software frei zugänglich ist, heißt das noch lange nicht, dass man damit alles machen darf. Und der Urwald an möglichen Lizenzen ist gewaltig. BSD, GNU, GPL, MIT usw. erlauben oder verbieten kommerzielle Nutzung, Veränderbarkeit, Nennung und alles, was man da so definieren kann. Als Einstieg kann man einfach mal hier starten: Wikipedia-Kategorie FLOSS-Lizenz Und wirklich: Achtet darauf. Lizenzen zu ignorieren kann sehr, sehr teuer werden. Wartung und Support Open-Source-Projekte sind Community-Projekte. Support muss man sich da schon selbst erarbeiten. Über Foren und Repositories und eben die Community selbst. Das kann man natürlich im Vorfeld prüfen. Aber das kann auch ganz schnell vorbei sein, wenn das Projekt und die Beitragenden inaktiv werden oder andere Projekte mehr fokussieren. Natürlich kann das auch bei kommerzieller Software passieren, z. B. dass der Laden aufgekauft wird, aber da hat man zumindest noch Verträge, die einen Rahmen geben. Qualität “Die werden das ja wohl getestet haben”… ja, vielleicht. Aber vielleicht auch nicht. Meiner Erfahrung nach sind Open-Source-Projekte, was entwicklungsnahe Tests betrifft, meist recht gut ausgestattet. Aber ich sehe auch immer wieder Projekte, die wenige fachliche, übergreifende Tests haben, und auch bei Schnittstellentests gibts manchmal Lücken. Also, wenn ihr Open Source nutzt: Testen nicht vergessen 🙂 Geben und Nehmen Es ist ja verlockend: Auf GitHub und Co finden sich zu unzähligen Themen Open-Source-Projekte, wie beim All-You-Can-Eat-Buffet. Aber das ist nicht als Einbahnstraße gedacht. Open Source lebt von der Beteiligung und der Community. Bitte daher immer auch überlegen: Was kann man selbst denn zurückgeben? Gibt es vielleicht eigene Projekte, die man zur Verfügung stellen kann? Und wenn man kein Programmierer ist? Nun, helft den Teams mit Feedback, Feature-Ideen und vor allem: Bugreports. Denn wir sind ja Tester, oder? Und hier können wir der Open-Source-Community einen guten Dienst erweisen: mit aussagekräftigen, nachvollziehbaren Fehlermeldungen. Die Community wirds euch danken. --- ### Entspannt, aber achtsam URL: https://www.richard-seidl.com/de/blog/entspannt-aber-achtsam/ Datum: 2025-11-06 KI-Hype von allen Seiten: warum Komplettverweigerung selten funktioniert und wie kleine Schritte und der Gartner Hype Cycle gelassen machen. “Themen kommen und gehen - und kommen wieder.” - Richard Seidl Wir werden von allen Seiten vollgedröhnt. KI hier, Agents da und die Super-KI vor der Tür. Verheißungen und Hiobsbotschaften … aus dem sanften Rauschen in den mehr oder weniger sozialen Medien ist ein Dauerfeuer geworden, dem man sich nur schwer entziehen kann. Müssen wir aber, sonst werden wir verrückt. Um diesem (Des-)Informationswahnsinn zu entgehen, braucht es Strategien. Eine wäre zum Beispiel, aus der Blase auszusteigen. Kein Social Media mehr und Smartphone entsorgen. Radikal. Kann man machen, ist aber schwierig, wenn man in der Tech-Branche tätig ist. Ich bin kein Freund von Komplettverweigerung. All das komplett auszublenden macht es nämlich in meiner Welt nicht besser und fühlt sich irgendwie rückwärtsgewandt an. Ich glaube, wir müssen mit dem leben und umgehen lernen, was da ist. Ob uns das gefällt oder nicht. Und dann ist da noch die Frage: Wo ziehen wir denn die Grenzen? Ist WhatsApp noch ok? Telegram? Mastodon auch noch oder nicht mehr? Ich kenne auch einige, die KONSEQUENT den Fernseher verbannt haben. Dieses Teufelszeug muss raus aus dem Wohnzimmer, es macht uns alle blöd und die Kinder ebenso. Freiheit pur … … und dann wird am Laptop Netflix und YouTube geschaut. Mehr oder weniger heimlich. Schlimmer noch: Statt des gemeinsamen Fernsehabends in der Familie hockt jeder in seinem Zimmer mit Smartphone, Tablet oder Laptop und konsumiert. Na, das funktioniert irgendwie nicht. Mit den Themen leben lernen Ein anderer Weg ist, sich mit den Dingen auseinanderzusetzen, zu versuchen zu verstehen, eine Meinung zu haben und diese zu verteidigen. Sich mit unseren “Feeds” zu beschäftigen, die Informationen kritisch zu hinterfragen und nicht einfach nur stumpf mitzuplappern oder auf der anderen Seite einfach aus Prinzip dagegen zu sein. Das Gemeine an diesem Weg: Er ist aufwendig, anstrengend und nicht leicht. Das passt ja so gar nicht in unseren Alltag, wo wir statt Auseinandersetzung lieber einfache KI-Antworten haben wollen. Energie- und Zeitsparen zur Alltagsbewältigung. Die Kunst der kleinen Schritte Der Trick für mich besteht darin, kleine Schritte zu gehen, statt am großen Rad zu drehen. Natürlich kann ich frustriert darüber sein, in meinem Unternehmen nix bewegt zu bekommen. Ich kann aber an meinem Schreibtisch beginnen. Und zum Beispiel mal eine Outlook-Regel erstellen, die meine Mails wegsortiert. Newsletter abbestellen und mir angewöhnen, am Tagesende alle Tabs zu schließen, um am nächsten Tag mit frischem Geist zu starten. Meta-Perspektive Eine andere Strategie ist rauszuzoomen. Nicht so assoziiert zu sein mit den Themen, die um uns herum passieren. Ich finde, eines der entspannendsten Werkzeuge dafür ist der Gartner Hype Cycle. Der ist für mich ein Anker geworden: Es kommt ein Hype, der wird ordentlich aufgeblasen … dann kommt das Tal der Tränen und irgendwas bleibt produktiv in der Realität übrig. Beispiel 3D-Druck: Es gab Zeiten, da wurde in den Medien der komplette Zusammenbruch des Einzelhandels prognostiziert. Wir werden alle nur mehr Baupläne von Produkten runterladen und selber drucken … keiner muss mehr in den Baumarkt oder sonstwohin (Hype). Ich frage bei meinen Workshops und Keynotes gerne, wie viele im Raum einen 3D-Drucker besitzen. Selbst bei Hardcore-IT-Teilnehmern gehen meist nur zwei, drei Hände hoch. Gleichwohl hat sich 3D-Druck in der Industrie oder zum Beispiel in der Zahntechnik etabliert (Plateau der Produktivität). Gleiches haben wir beim Metaverse erlebt und das steht uns auch mit KI bevor. Beim Schreiben dieser Zeilen stand “AI Agents” ganz oben im Hype Cycle. Also kurz vor der Ernüchterung. Ich finde das sehr entlastend. Themen sind Themen … Marketing bläst sie auf … dann kommt der Kollaps und was Produktives bleibt übrig. Also durchatmen und weitermachen. Am Ende muss jeder seine Strategie finden, um mit dieser verrückten, wunderbaren Welt umzugehen und darin zu bestehen. Da hilft kein Jammern und kein Zaudern. Dafür sind wir Erdlinge da. Und dazu rufe ich gerne auf: Beschäftigen Sie sich mit Ihren Strategien, machen Sie sich diese bewusst und wenn sie nicht funktionieren … ändern Sie sie! --- ### Verhindern wir Lernen? URL: https://www.richard-seidl.com/de/blog/verhindern-wir-lernen/ Datum: 2025-09-29 Wer KI nur für den Output nutzt, überspringt den Lernprozess. Tester lernen durch Fragen und Systemwissen, GPT hilft als Kritiker und bei Routinen. “KI liefert uns schnell das Ergebnis. Der Entstehungsprozess geht an uns vorbei.” - Richard Seidl Ich geh gerne wandern. So bergauf. Der Weg ist oft steinig, manchmal anstrengend, manchmal überraschend schön. Es gibt allerlei zu entdecken. Oben angekommen bin ich nicht nur beschenkt durch die Aussicht, sondern auch durch die Erfahrung in den Beinen: das Stolpern, das Durchatmen, die Gespräche unterwegs. Die Natur. Der Weg ist Teil des Ziels und hat mich ein kleinwenig geprägt. Ich hätte natürlich auch mit der Seilbahn hochfahren können. Bequem, schnell, effizient – die Aussicht oben ist dieselbe. Ist sie das? Selbiges kann uns auch bei der Nutzung von künstlicher Intelligenz passieren. Wir klopfen unseren Prompt rein, schwupps, fertig ist der Output. Feingeschliffene Texte auf unseren Kontext bezogen. In dem Stil, den wir wollten. Oder fertig programmierter Code. Oder Testfälle aus Anforderungen abgeleitet. Ziel erreicht. Geht es uns nur um den Output Aber geht es uns nur um den Output? Ich glaube, da müssen wir achtgeben. Denn bei dieser Nutzung bleibt einiges auf der Strecke: das Ringen um Klarheit, das Lernen aus Fehlern, das Grübeln, das kreative Querdenken. Und dabei ist es gerade dieser Prozess, der unser Denken schärft, uns wachsen lässt, uns tiefer verstehen lässt, worum es eigentlich geht. Ich könnte diese Kolumne wahrscheinlich auch mit KI schreiben. Aber was hätte ich davon? Mir geht es hier um die Auseinandersetzung mit Themen. Das Durchkneten von Gedanken in meinen Hirnwindungen. Das möchte ich nicht missen, denn daraus entsteht nicht nur eine Kolumne, sondern auch Unmengen neuer Ideen, Ansätze, Abstracts usw., die mich wieder ein Stück weiterbringen. Wenn ich nur Code generieren lasse, was lerne ich dabei? Wenn ich mich aber mal durchdebugge durch meinen schlechten Code – dann lerne ich programmieren. Oder im Software-Testing gerade heiß diskutiert und ausprobiert: Testfälle aus Anforderungen ableiten. Jucheee. Schon wieder 10 neue Testfälle entstanden. Aber schauen wir uns mal die Rolle des Testers an. Dessen Aufgabe ist eigentlich gar nicht so sehr das Erstellen von Testfällen. Es geht um Kommunikation, darum, Fragen zu stellen (auch kritische), um informelle Netzwerke und die Bedürfnisse der Stakeholder für eine gute Qualität. Ich kenne viele Tester, die in ihren Projekten und Unternehmen diejenigen sind, die den größten Überblick haben, die Hinz und Kunz kennen und bei denen sogar Entwickler nachfragen, wie die Zusammenhänge sind. Warum? Weil ich als Tester rumrennen muss um zu verstehen. Um meine Antworten für Testfälle zu bekommen. Und das ganze Wissen rund um ein System lässt es mich besser prüfen. Wenn ich nur Testfälle generiere, fehlt mir da ein großes Stück vom Erfahrungskuchen. Der Weg ist Teil des Ziels Nicht falsch verstehen. Ich mag die KI. Ich nutze sie auch gerne. Zum Weiterdenken meiner Ideen … als Kritiker zu meinen Gedanken und vor allem, um nicht meinen blinden Flecken zu erliegen, die ich so gern ausblende. Großartig, wie mich Kollege GPT da immer wieder korrigiert. Auch alles Ausprobieren ist hier wichtig und richtig. Und doofe Routinen automatisieren – ja bitte gerne! Aber lasst uns wachsam sein, wofür wir diese Teile nutzen. Zum Höher, Schneller, Weiter? Noch mehr selbstreferenzierender Content? Massig Zeug von geringer Güte? Ich glaub, das ist die falsche Richtung. Vielleicht macht uns das ganze KI-Gedöns im Endeffekt wieder etwas menschlicher. Einfach weil wir gerne lernen, kreativ sind, forschen, Fehler machen, Fehler ausbessern und uns weiterentwickeln. Das kann uns die KI (noch) nicht abnehmen. --- ### Tester lieben Software-Architektur URL: https://www.richard-seidl.com/de/blog/tester-lieben-software-architektur/ Datum: 2025-07-31 Software-Architektur ist ein Grundpfeiler für Testbarkeit und muss mitwachsen. Tester und Architekten sollten deshalb öfter gemeinsam Kaffee trinken. “Architektur ist ein Grundpfeiler für gute Testbarkeit!” - Richard Seidl Vorneweg: Ich bin kein Experte für Software-Architektur. Dafür gibt es andere. Ich bin eher ein Architektur-Anbeter, immer erfreut über neue Pattern, Frameworks und Strategien, die uns hier vorwärtsbringen. Architektur ist für mich auch ein Grundpfeiler guter Software-Qualität. Sie hilft nicht nur den Entwicklern, saubere Software zu schreiben. Sie hilft auch uns Testern und Qualitätsmenschleins bei einem ganz ganz ganz wichtigen Punkt: Testbarkeit. Ich habe in Projekten schon so oft Aussagen wie diese gehört: - “Nein, also Unittests können wir nicht schreiben, das gibt die Architektur nicht her” - “Uh… Performance-Probleme. Ja, das wissen wir, aber die Architektur ändern… weißt, die ist halt historisch gewachsen” - “Na, an die Schnittstellen kommst du so einfach nicht ran. Und die sind auch nicht wirklich offiziell” Und so weiter und so fort. Alles Zeichen dafür, dass sich niemand um eine sinnvolle Software-Architektur kümmert oder einfach drauf loscodiert wurde. Das ist am Beginn einer Software auch legitim, aber es muss dann auch recht bald klar sein, welche Strukturen, Schnittstellen und Pattern genutzt werden. Und eine Sicht auf die Architektur muss entstehen. Ich bin immer wieder fassungslos, wie Teams mit 10, 20, 30 Entwicklern und Testern an Software rumwerkeln und dabei ständig mit diesen technischen Schulden umgehen müssen. Wobei, eigentlich sind es ja gar keine technischen Schulden, sondern organisatorische. Aber lassen wir das mal. Da wird unfassbar viel Geld verbrannt, um mit diesen Unzulänglichkeiten umzugehen, statt zu beginnen, sie zu heilen. Neben den Projekten, die ganz ohne überlegte Architektur arbeiten, gibt es noch die anderen, die glaube ich einem Grund-Missverständnis aufsitzen. Nämlich, dass eine Software-Architektur zu Beginn mal festgelegt ist und dann für immer gilt. Das passt in meiner Welt gar nicht. Eine Architektur ist sicher nicht etwas, was ich alle paar Tage umwerfe und neu mache. Aber eine Weiterentwicklung und Fluidity möchte ich schon gerne sehen. Und damit meine ich nicht nur, auf die aktuellste Version des Frameworks zu aktualisieren, sondern die Architektur mit Fragen zu betrachten wie: Wie muss unsere Software-Architektur aussehen, - damit heutige und morgige Anforderungen einfach implementiert werden können? - damit sie den Entwicklungsprozess unterstützt? - damit sie zu neu aufkommenden Themen passt? Den letzten Punkt finde ich nochmal sehr spannend. Denn neue Innovationen, wie z. B. jetzt gerade MCP-Server im Bereich der KI, entstehen ja aus Projekten und Teams, die aktuelle Architekturen implementiert haben. Und wenn man ebenso aktuelle Architektur-Paradigmen nutzt, ist die Implementierung dieser Features viel einfacher, als wenn die eigene Implementierung den Stand der Technik von vor 10 Jahren hat. Meiner Meinung nach wird Software-Architektur viel zu sehr unterschätzt. Eigentlich eine Schande bei der Bedeutung, die ihr zusteht. Also: Sucht mal den Architekten in eurem Team auf und geht gemeinsam einen Kaffee trinken 🙂 --- ### Warum ich nicht verzweifle URL: https://www.richard-seidl.com/de/blog/nicht-verzweifeln/ Datum: 2025-07-11 Wer an KI-Flut, Vibe-Coding und Weltlage zu verzweifeln droht, dem helfen drei Strategien: Fokus-Wechsel, ein Schritt zurück und Stoizismus. “Wer sich immer nur auf das Problem fixiert, macht es größer und größer!” – Richard Seidl Man könnte schon verzweifeln in dieser Welt. An ganz vielen Schauplätzen passieren gerade ganz schlimme Dinge. Das politische Weltgefüge scheint komplett aus den Fugen geraten und purer Willkür ausgeliefert zu sein. Die Wirtschaftslage ist – sagen wir mal – angespannt und die Preise im Supermarkt hoch. Und in der IT? Ja, hier haben wir seit fast drei Jahren ein neues Spielzeug, was immer mehr für Furore sorgt. Das Internet ist mittlerweile voll von generierten Texten, wo man sich beim Lesen fragt, warum ich hier gerade meine Zeit investiere. SEO ist auf Steroiden. YouTube voll mit schlechten KI-Videos. Und in der Softwareentwicklung haben wir mit Vibe-Coding immer mehr Artefakte mit fragwürdiger Qualität. Ich merke bei meinen Mentorings und Coachings zunehmend, dass diese Gesamtwetterlage Menschen stresst und beängstigt – was sich natürlich wiederum auf Beruf und Leben auswirkt. Und das sind gar nicht immer so konkrete Ängste – eher diffuse. Eine Unsicherheit, die aber bedrohlich wirkt. Und ich nehme mich da gar nicht raus. Auch ich habe Tage, an denen ich mich frage: Wo führt das alles hin? Was soll das alles? Und ganz banal: Wie können Menschen trotz aller Entwicklung so viel Chaos und Zerstörung anrichten? Wenn ich auf diese Fragen sehe, merke ich: Sie bringen mir ja nix. Außer, dass ich mich noch schlechter fühle. Ein Teufelskreis nach unten. Aber wie kann man dem begegnen. Nun, wir Menschen haben die Fähigkeit unser Verhalten zu ändern und neue Strategien zu lernen. Drei davon, die ich mir immer wieder bewusst mache, helfen mir, nicht in Verzweiflung zu versinken, sondern dem besorgniserregenden Unbekannten der Zukunft optimistisch entgegenzulächeln. Fokus-Wechsel Ich ärgere mich häufig, wenn mir im Internet Blabla-KI-Texte die Zeit stehlen. Und als Software-Tester sehe ich eine Riesenwelle Dreckssoftware durch Vibe-Coding auf uns zurollen. Ich kann mich dann aber auch besinnen: Wie viel Routinetätigkeiten mir täglich mittlerweile durch KI und meine kleinen Agenten abgenommen wird. Oder auch, dass wir nun endlich eine Demokratisierung der Softwareentwicklung haben – jeder kann jetzt Software schreiben, was für eine Errungenschaft. Allein schon diese beiden Gedankenshifts weiten wieder den Möglichkeitenraum für neue, positive Ideen! Ein Schritt zurück Eine andere Strategie, die mir immer hilft, ist: Einen Schritt zurücktreten und das Ganze einmal von außen zu betrachten. Alles kommt immer wieder (und verschwindet auch wieder). Metaverse, 3-DDruck, zentrale IT vs. dezentrale IT … alles hat irgendwann Mode … dann wieder nicht … dann wieder schon … und irgendwas bleibt produktiv dabei übrig. Es gibt auch einen schönen Spruch, der bei mir an der Pinnwand hängt: “Harte Zeiten schaffen starke Menschen. Starke Menschen schaffen gute Zeiten. Gute Zeiten schaffen schwache Menschen. Und schwache Menschen schaffen harte Zeiten.” Wir sind wohl gerade am Anfang der letzten Phase. Das heißt aber auch: Danach gehts wieder von vorne los. Stoizismus Und immer wieder die Ideen der alten Stoiker: - Unterscheide, was du kontrollieren kannst und was nicht. Handle bei dem, was du beeinflussen kannst – akzeptiere den Rest mit Gleichmut. - Nicht was passiert, sondern wie du dich verhältst, entscheidet über dein Glück. - Nicht die Dinge selbst beunruhigen uns, sondern unsere Meinungen über die Dinge. Also: Hirn einschalten. Ja, alles ist grade wild. Aber kein Grund zu verzagen. Der Mensch ist immer nur in Krisen gewachsen. So entsteht Neues und Innovation. Hilft nicht immer. Aber oft. --- ### Von Werkzeugen und Wegbereitern URL: https://www.richard-seidl.com/de/blog/von-werkzeugen-und-wegbereitern/ Datum: 2025-06-04 Die Zukunft des Testens liegt nicht in besseren Tools, sondern in Menschlichkeit. Warum Tester die Dolmetscher zwischen den Welten sind. “Tester werden in den nächsten Jahren mit einer Unmenge an Software überschwemmt, die mit Vibe-Coding erstellt wurde. Qualität: rätselhaft!” - Richard Seidl In den stillen Morgenstunden, wenn die ersten Codezeilen des Tages geschrieben werden, offenbart sich eine fundamentale Wahrheit unserer Branche: Software ist nicht für Maschinen gemacht, sie ist für Menschen gemacht. Und doch vergessen wir das allzu oft, wenn wir über die Zukunft des Testens sprechen. Der Tester als Brückenbauer Ich glaube, der wahre Fokus im Testing liegt in Zukunft nicht in der nächsten KI-gestützten Testautomatisierung oder dem neuesten Framework, die werden wir eh nutzen. Er liegt vielmehr in der Erkenntnis, dass Tester die Dolmetscher zwischen den Welten sind. Ein Tester ist mehr als ein Qualitätswächter. Er ist ein Stakeholder-Manager, ein Netzwerker, der die lauten, leisen und stummen Erwartungen aller Beteiligten übersetzt. Die Illusion der vollständigen Automatisierung KI und Automatisierung versprechen uns eine Welt fehlerfreier Software. Doch diese Verheißung trägt den Keim eines Missverständnisses in sich. Werkzeuge können Muster erkennen, Regressionen aufspüren, Performance messen. Aber können sie verstehen, was es bedeutet, wenn ein Nutzer frustriert vor einem Ladebildschirm sitzt, während seine Tochter ungeduldig auf das gemeinsame Spiel wartet? Die Zukunft gehört nicht der Automatisierung statt dem Menschen, sondern der Automatisierung für den Menschen. KI-Tools werden zu Sparringpartnern der Tester, die ihnen erlauben, tiefer zu sehen, weiter zu hören, mehr zu erfahren und bessere Informationen zu bekommen. Die Welle kommt Wir sehen jetzt schon: Gerade in der Software-Entwicklung bringt KI unheimlich viel. Von Code-Reviews über Refactoring bis zur Codegenerierung und Vibe-Coding. Die gesteigerte Produktivität der Entwickler heißt aber auch: Da kommt viel auf Tester zu, was bewältigt werden muss. Neben Automatisierung werden Priorisierung, Abstimmung und risikoorientiertes Testen noch viel wichtiger werden. Und dafür braucht es eine Menge Soft Skills: Resilienz, Konfliktmanagement, Kommunikation und einen Meta-Blick. Diese Skills fallen nicht vom Himmel, sondern müssen erarbeitet werden. Ein Aufruf zur Menschlichkeit Die Zukunft des Testens liegt nicht in der Perfektion unserer Werkzeuge, sondern in der Tiefe unserer Menschlichkeit. Lasst uns Tools als das nutzen, was sie sind: Verstärker unserer Fähigkeiten, nicht deren Ersatz. Gerne auch Pair-Testing mit der KI. Wenn wir das nächste Mal vor einem Testplan sitzen, sollten wir uns fragen: Teste ich für die Maschine oder für den Menschen dahinter? Denn am Ende, wenn alle Tests grün leuchten und die Deployment-Pipeline durchgelaufen ist, bleibt eine einzige Frage: Haben wir Arbeit und Leben von Menschen heute ein kleines bisschen besser gemacht? --- ### Mindset fällt nicht vom Himmel URL: https://www.richard-seidl.com/de/blog/mindset-coaching/ Datum: 2025-05-07 Ein Mindset ist weder richtig noch falsch. Agile Coaches sollten ihre Werte vorleben, denn Veränderung entsteht durch Ausprobieren und Erfahrung. “Wenn der Coach sagt ‘Du hast das falsche Mindset’ ist das eine Ausrede, dass er seinen Job nicht richtig macht.” - Richard Seidl Heute möchte ich mal mit einem der größten Bullshit-Bingo-Wörtern der Businesswelt aufräumen: Mindset. Wobei, da sind wir schon beim Kern des Problem. Ich will euch erzählen, was richtig und falsch ist. Und das ist ja der Quatsch dahinter. Aber der Reihe nach. In einer Runde von Beratern und Coaches bei einem Kunden sagte letztens plötzlich ein Agile Coach: “Mein Team hat voll das falsche Mindset. Kannst nicht arbeiten mit denen.”. Oh. Das ist hart. Und bringt zwei Probleme der “Branche” zum Vorschein: Problem 1: Das Mindset ist. Ja genau. Das Mindset ist. Nicht mehr und nicht weniger. Es ist aber weder falsch noch richtig. Wir alle sind davon geprägt, was wir erlebt haben. Immer und überall. Ein Mechanismus, der da läuft, ist der Reality Loop: Wir machen eine Erfahrung -> denken uns unseren Teil -> aktualisieren damit unsere Glaubenssätze, etc. -> mit dieser neuen Brille und mit diesen Filtern betrachten wir die Umwelt -> Und machen Erfahrungen. Diese und andere Schleifen laufen kreuz und quer den ganzen Tag. Dazu kommen Rückkopplungen, signifikante emotionale Ereignisse und daily business. Und aus der ganzen Gemengelage entsteht halt dieses Mindset - so schauen wir auf die Welt. Wir können darüber sprechen ob das für eine Situation, für ein Projekt oder für uns förderlich ist - oder ob es eher blockiert. Aber auch hier gibt es kein Schwarz/Weiss. Denn das Mindset hat sich bis dahin bewährt, sonst hätten wir es ja nicht. Wenn wir es ändern wollen - ok. Aber jemanden ein falsches zu unterstellen ist weder wertschätzend noch hilfreich. Problem 2: Walk the Talk Das zweite Problem ist für mich gerade noch prägnanter. Wir geben uns in der agilen Bubble immer super-werteorientiert: Offenheit, Feedback, Toleranz, Wertschätzung, Kommunikation, Selbstverantwortung, etc. - kommt alles zusammen wirds richtig schön agil….also zumindest, solange es nach der Vorstellung von manch einem Coach geht. Denn bei einigen hört da der Spaß schnell auf, wenn es nicht nach deren Vorstellung läuft. Wenn sich ein Team nicht wie gewünscht entwickelt, wenn sie ihre eigene Art der Kommunikation haben. Da ist es einigen Coaches vorbei mit Offenheit und Wertschätzung und Selbstverantwortung. Und das gipfelt dann in “Ihr habt das falsche Mindset”. Für mich stecken da zu viele Dogmen dahinter, die gar nicht agil sind. Denn im Agilen gibt es kein “so ist es richtig”. Disclaimer: Natürlich gibt es auch ganz viele andere Coaches und ich nehme mich da auch selbst nicht aus, hier in die Falle der Selbstgefälligkeit zu tappen. Das ist ein Problem von uns allen im Coaching/Consulting. Wir sollten uns immer wieder daran erinnern, dass es menschelt, wo Menschen sind. Schnelle Lösung Die gibt es natürlich nicht. Im Endeffekt läuft die Veränderung des Mindsets auf einen sehr individuellen Zugang raus: - Einen Impuls bekommen - Etwas ausprobieren - Erfahrung machen und bewerten - Lernen und Integrieren - oder auch nicht Und das braucht Zeit. Der Fokus liegt da meiner Erfahrung nach bei den Punkten 2 und 3: Etwas ausprobieren und Erfahrung machen. Und das tun wir viel zu wenig. Wir schwafeln in Dailys, Retros, Meetings und Workshops, machen Befindlichkeitsrunden, Assessments und Interviews - wir sind beschäftigt - aber wir TUN nichts. Und das führt zur Stagnation. Statt den Methoden und Frameworks den Menschen in den Mittelpunkt stellen - mit all seinen Befindlichkeiten, Ängsten und Wünschen - so wird meiner Meinung nach ein agiler Schuh draus. Aber das ist auch nur meine Wahrheit ;-) --- ### Wenn KI programmiert URL: https://www.richard-seidl.com/de/blog/ki-copilot/ Datum: 2025-03-01 Braucht KI eigene Programmiersprachen? Warum menschenlesbarer Code nur ein Zwischenstadium sein könnte und welche Rolle Entwicklern bleibt. “Warum sollte die KI denn unsere komplizierten Programmiersprachen nutzen?” – Richard Seidl Ich hatte letztens eine Diskussion über Qualitätsverbesserung von Software und Code. Und zwar ging es darum, dass KI wie statische Analyse Code überprüft und Fehler automatisch behebt. Soweit so gut. Weiter ging es zu Copilots und Co, die uns bei der Software-Entwicklung unterstützen. Die Art und Weise, wie wir Software entwickeln, hat sich in den letzten Jahrzehnten dramatisch verändert. Vom mühsamen Assembler-Code über Hochsprachen wie C und Java bis hin zu modernen deklarativen Ansätzen – das Ziel war stets, die Brücke zwischen menschlichem Denken und maschineller Ausführung zu verkürzen. Doch mit der zunehmenden Rolle künstlicher Intelligenz in der Softwareentwicklung stellt sich eine entscheidende Frage: Warum sollte eine KI weiterhin dieselben menschenzentrierten Programmiersprachen verwenden? Heute sehen wir bereits, wie KI-gestützte Systeme wie GitHub Copilot oder ChatGPT Software-Code generieren, Fehler korrigieren und Optimierungen vorschlagen. Dabei bewegen wir uns jedoch immer noch in den gewohnten Bahnen – Programmiersprachen, die für Menschen verständlich sein sollen. Aber ist das langfristig sinnvoll? Vom Compiler zum KI-generierten Code - ein Paradigmenwechsel Der klassische Softwareentwicklungsprozess basiert darauf, dass Menschen Code schreiben und ein Compiler oder Interpreter ihn in Maschinensprache umwandelt - egal ob Python, Java oder Objectice-C. Doch in einer Welt, in der KI eigenständig Code generiert, stellt sich die Frage, ob dieser Umweg noch nötig ist. Was wäre, wenn KI ihre eigene, für Maschinen optimierte Programmiersprache hätte? Eine Sprache, die nicht auf Lesbarkeit für Menschen optimiert ist, sondern auf maximale Effizienz für die Maschine? Vielleicht wäre das gar keine “Sprache” im klassischen Sinne, sondern eine rein mathematische oder algorithmische Repräsentation, die sich durch Mustererkennung und neuronale Netzwerke weiterentwickelt. Wenn Maschinen für Maschinen entwickeln - was bleibt dann für uns? Die Vorstellung, dass KI ihre eigene Programmiersprache entwickelt, wirft viele spannende Fragen auf. Eine davon ist: Welche Rolle bleibt dann noch für uns Entwickler? Einerseits könnten Menschen immer noch die Rahmenbedingungen definieren, Anforderungen stellen und kontrollieren, ob die Ergebnisse den gewünschten Zweck erfüllen. Andererseits könnte KI in Zukunft nicht nur die Codegenerierung übernehmen, sondern auch eigenständig Entscheidungen über Architektur und Systemdesign treffen. Das könnte bedeuten, dass die klassische Rolle des Entwicklers zunehmend in die eines Moderators oder strategischen Planers übergeht – jemand, der sich mehr mit Konzepten und ethischen Fragen beschäftigt als mit dem Schreiben einzelner Zeilen Code. Philosophisch betrachtet wäre das ein großer Schritt in der Mensch-Maschine-Kollaboration. Der Übergang von “Menschen schreiben Code für Maschinen” zu “Maschinen schreiben Code für Maschinen” wäre ein fundamentaler Wandel, ähnlich der industriellen Revolution, die einst Handarbeit durch Maschinen ersetzte. Doch wie jede technologische Revolution wirft auch diese ethische Fragen auf: Wie stellen wir sicher, dass KI-generierter Code sicher und nachvollziehbar bleibt? Wer ist verantwortlich, wenn etwas schiefgeht? Und wie verhindern wir eine “Black-Box”-Technologie, die niemand mehr wirklich versteht? Der Code der Zukunft Während wir noch weit davon entfernt sind, dass KI ihre eigene, für Menschen unverständliche Programmiersprache entwickelt, zeigt die aktuelle Entwicklung klar, dass klassische Programmiersprachen möglicherweise nur ein Zwischenstadium sind. Der Gedanke, dass wir eines Tages gar keinen menschenlesbaren Code mehr brauchen, ist ebenso faszinierend wie beunruhigend. Ich will das hier nicht bewerten, wir sollten aber achtsam bleiben, wie sich Software-Entwicklung weiterentwickelt. --- ### Anforderungsmanagement: Jeder Testfall ist ein Review URL: https://www.richard-seidl.com/de/blog/anforderungsmanagement/ Datum: 2025-02-19 Anforderungsmanagement entscheidet, wie gut der Test werden kann. Testfall-Design deckt Lücken auf, Verfolgbarkeit zeigt die betroffenen Tests. Warum ist Anforderungsmanagement für den Software-Test so wichtig? Anforderungsmanagement sorgt dafür, dass alle Beteiligten dasselbe Bild davon haben, was eine Software leisten soll. Fachbereich, Entwicklung und Test sollen unter einer Anforderung dasselbe verstehen und später nachvollziehen können, woher sie stammt. Davon hängt ab, wie gut der Test werden kann. Umgekehrt legt jeder Testfall, den wir entwerfen, Schwächen in den Anforderungen offen. Sind die Anforderungen halbgar, gleicht selbst ein guter Test einer Schatzsuche. Wir testen vielleicht in die falsche Richtung oder vergessen wichtige Aspekte. Steht in der Anforderung dagegen, welches Ergebnis das System bei welcher Eingabe liefern soll, lässt sich daraus direkt ein Testfall mit erwartetem Ergebnis ableiten. Im ISTQB-Glossar heißt alles, woraus Tests entstehen, Testbasis: alle Informationen, die als Grundlage für Testanalyse und Testentwurf dienen können. Aus ihr leitet das Team in der Testanalyse ab, was es testen soll, und legt dafür messbare Überdeckungskriterien fest. Muss jede Anforderung detailliert spezifiziert sein? Nein. User Stories mit Akzeptanzkriterien, Diagramme oder Scribbles tun es auch. Es kommt darauf an, dass in allen Köpfen ein ähnliches Bild der Anforderungen verankert ist. Akzeptanzkriterien helfen dabei besonders. Sie beschreiben die Bedingungen, die eine Umsetzung erfüllen muss, damit die Stakeholder sie akzeptieren. Damit sind sie zugleich die Testbedingungen, die die Tests ausführen sollen. Sie entstehen meist im Gespräch, etwa beim gemeinsamen Schreiben von User Stories oder im Refinement des Backlogs. Ob das Team sie als Gegeben/Wenn/Dann-Szenario oder als Regelliste formuliert, ist zweitrangig. Klar und eindeutig müssen sie sein. Wie wird das Testfall-Design zum Review der Anforderungen? Jedes Mal, wenn wir Testfälle entwerfen, nehmen wir die Anforderungen erneut unter die Lupe, bewusst oder unbewusst. Ist alles logisch? Fehlen wichtige Szenarien? Passt der Anforderungstext zu den gewünschten Ergebnissen? So wird jedes Testfall-Design gleichzeitig zum Review der Anforderungen. Diesen Effekt unterschätzen wir oft. Dabei finden wir Fehler auf diesem Weg früh, solange sie noch wenig kosten. Im ISTQB-Lehrplan Foundation Level gehört dieser Blick fest zur Testanalyse: Das Team prüft dort die Testbasis auch auf Fehlerzustände und auf Testbarkeit. Typisch für Anforderungen sind Inkonsistenzen, Mehrdeutigkeiten, Widersprüche, Auslassungen, Ungenauigkeiten und Duplikationen. Der frühe Blick lohnt sich, denn ein Fehlerzustand, den das Team früh beseitigt, verursacht keine weiteren in abgeleiteten Arbeitsergebnissen. Als Tester sind wir hier besonders kritisch. Lässt sich aus einer Anforderung kein guter Testfall ableiten, müssen wir die Lücke klären. Architekten und Entwickler füllen solche Lücken oft automatisch, mit Kreativität und logischem Verknüpfen. Dem Tester bleibt nur die Rückfrage beim Anforderer. Verfolgbarkeit hält Anforderungen und Tests zusammen Anforderungen bleiben selten so, wie jemand sie zuerst aufgeschrieben hat. Die Anforderungsanalyse verfeinert die Projektziele zu konkreten Anforderungen. Das Anforderungsmanagement behält danach den Überblick, wenn sie sich ändern. Im Test geschieht das über Verfolgbarkeit. Sie verbindet über den gesamten Testprozess die Bestandteile der Testbasis mit den zugehörigen Testbedingungen und Testfällen, den Testergebnissen und den Fehlerzuständen. Über die Verbindung von Testfällen zu Anforderungen lässt sich prüfen, ob Testfälle jede Anforderung überdecken. Ändert sich eine Anforderung, zeigt dieselbe Verbindung, welche Tests betroffen sind. Damit das klappt, braucht jede Anforderung eine eindeutige Kennung und einen nachvollziehbaren Stand. Das ist Aufgabe des Konfigurationsmanagements: Es kennzeichnet Elemente eindeutig, versioniert sie und verfolgt ihre Änderungen, damit die Verfolgbarkeit über den ganzen Testprozess hält. Für eine Anforderungsmanagement-Software heißt das: Sie hält Anforderung, Testfall, Testergebnis und Fehlerzustand verbunden. Das kann ein eigenes Werkzeug leisten oder ein Testmanagementwerkzeug, das Anforderungen, Tests, Fehlerzustände und Konfiguration gemeinsam verwaltet. Was KI bei der Prüfung von Anforderungen leistet Neu ist, dass uns dabei künstliche Intelligenz unterstützt. Sie arbeitet wie ein statisches Analysetool für Anforderungen. Vier Beispiele: - Konsistenzprüfung: Die KI sucht in den Requirements nach Widersprüchen. Vielleicht ist Feature A laut Anforderung X Pflicht, kollidiert aber mit Anforderung Y. - Sprachliche Klarheit: Eine KI erkennt Mehrdeutigkeiten oder Füllwörter, die viel Raum für Interpretation lassen. So fallen schwammige Formulierungen auf, bevor jemand danach testet. - Vollständigkeits-Check: Kein Requirement soll unbemerkt fehlen. KI-basierte Tools können Lücken in der Spezifikation erschnüffeln, bevor sie in der Testphase Ärger machen. - Traceability und Impact-Analyse: Ändert sich ein Requirement, verfolgt die KI die Änderung durch alle betroffenen Bereiche. Sie zeigt, welche anderen Features und Tests davon betroffen sind. Niemand muss dafür alle Dokumente von Hand durchforsten. Der ISTQB-Lehrplan zum Testen mit generativer KI beschreibt dieselben Einsatzfelder. Große Sprachmodelle können in der Testbasis Unklarheiten, Inkonsistenzen und fehlende Informationen markieren. Sie können Anforderungen und User Stories den Testbedingungen zuordnen und so zeigen, wo die Überdeckung Lücken hat. Und sie können Fragen vorschlagen, mit denen das Team Anforderungen im Gespräch mit den Stakeholdern klärt. Es gibt auch eine Grenze. Ein Sprachmodell kann halluzinieren und zum Beispiel Testfälle vorschlagen, die nicht existierende Akzeptanzkriterien prüfen. Jeder Befund der KI braucht deshalb jemanden, der ihn gegen die Anforderung hält und bewertet. Anforderungen und Test arbeiten an derselben Frage In kurzen Iterationen bleibt wenig Zeit, eine Lücke in den Anforderungen erst kurz vor dem Release zu finden. Sie sollte früher auffallen: beim Schreiben der Akzeptanzkriterien oder spätestens beim Entwurf der Testfälle. Anforderungsmanagement und Test arbeiten dabei an derselben Frage: Was soll die Software leisten? Der Test stellt sie mit jedem Testfall neu. Das Anforderungsmanagement sorgt dafür, dass die Antwort auch nach jeder Änderung noch stimmt. Häufig gestellte Fragen Welche Probleme entstehen beim Testen durch unklare Anforderungen an Software? Unklare Anforderungen schicken den Test in die falsche Richtung oder lassen wichtige Aspekte aus. Typische Schwächen sind Mehrdeutigkeiten, Widersprüche und Auslassungen. Lässt sich aus einer Anforderung kein eindeutiger Testfall ableiten, muss der Tester beim Anforderer nachfragen. Bleibt der Fehlerzustand unentdeckt, verursacht er weitere in abgeleiteten Arbeitsergebnissen und wird später teurer. Was sollte eine Software für Anforderungsmanagement aus Testsicht können? Sie sollte jede Anforderung eindeutig kennzeichnen, versionieren und Änderungen nachverfolgen. Vor allem muss sie Anforderungen mit Testfällen, Testergebnissen und Fehlerzuständen verbinden. Erst dann zeigt sie, ob Tests jede Anforderung überdecken und welche Tests eine Änderung betrifft. Ob das ein eigenes Werkzeug oder ein Testmanagementwerkzeug leistet, hängt vom Projekt ab. Was bedeutet Anforderungsüberdeckung im Test? Anforderungsüberdeckung gibt in Prozent an, welcher Anteil der Anforderungen durch Testfälle überdeckt ist. Grundlage ist die Verfolgbarkeit zwischen Anforderungen und Testfällen. Legt das Team messbare Überdeckungskriterien schon in der Testbasis fest, dienen sie als Kennzahl dafür, wie weit es die Testziele erreicht hat. --- ### Software-Entwickler: Gestalter der Welt URL: https://www.richard-seidl.com/de/blog/software-innovation/ Datum: 2025-01-08 Software-Entwickler gestalten heute die Welt: Ihr Code steuert Autos, Geld und Strom. Daraus folgt Verantwortung für Sicherheit und Fairness. “Uns ist die Verantwortung, die wir in der Software-Entwicklung tragen, gar nicht bewusst” - Richard Seidl Ich glaube, es ist an der Zeit, dass wir uns der Verantwortung unserer Tech- und Software-Branche mehr bewusst machen. In der Vergangenheit waren Maschinenbauer, Architekten und Ingenieure die Gestalter der Welt. Sie waren es, die mit Brücken, Motoren und Gebäuden die Basis für Innovation, Fortschritt und Wohlstand legten. Aber in den letzten Jahrzehnten hat hier meiner Meinung nach eine andere Rolle die Führung übernommen: wir Software-Entwickler. Ohne Software steht die Welt still Wir leben in einer Zeit, in der kaum ein Bereich unseres Lebens ohne Software funktioniert. Vom Smartphone, unserem digitalen Hirn, über medizinische Geräte, die Leben retten, bis hin zur Software in modernen Autos, die darüber entscheidet, ob ein Bremsweg ausreicht - oder ebene nicht. Geldautomaten. Das Finanzsystem überhaupt. Logistik. Verkehr. Stromversorgung. Und und und. Software ist das Nervensystem unserer Welt geworden. Doch mit dieser Allgegenwart kommen auch kritische Fragen auf. Was passiert, wenn Systeme versagen? Wenn ein Algorithmus unfair entscheidet? Oder wenn Sicherheitslücken ausgenutzt werden? Algorithmen beeinflussen heute schon Wahlen, eine Fehlfunktion in der Auto-Software kann Leben kosten - und mit KI steht uns ein ganz neuer Level an Möglichkeiten, Manipulationen und Innovationen zur Verfügung. Wir schreiben Code, der nicht nur Maschinen, sondern auch Menschenleben berührt. Dieser Realität sollten wir uns wieder mal klar werden. Verantwortung beginnt im Kopf – und im Code Software-Entwicklung ist keine neutrale Tätigkeit. Jeder Bug, jeder Design-Fehler und jede unausgereifte Idee hat Konsequenzen. Doch nicht nur technische Aspekte zählen: Wir tragen auch die Verantwortung, uns darüber hinaus Fragen zu stellen. Braucht die Welt wirklich noch eine App, die uns dazu bringt, länger auf den Bildschirm zu starren? Ist es in Ordnung, Daten ungefragt zu sammeln? Und wie stellen wir sicher, dass KI-Systeme nicht diskriminieren? Müssen wir immer neue Features dazubauen, anstatt auch mal alte abzuschalten? Verantwortung bedeutet, mehr als nur Funktionalität zu liefern. Es bedeutet, die Konsequenzen des eigenen Tuns zu verstehen und danach zu handeln. Die Zukunft aktiv gestalten Die gute Nachricht: Verantwortung ist kein Ballast, sondern eine Chance. Als Entwickler haben wir die einzigartige Möglichkeit, die Welt aktiv zu gestalten. Wir können Software schreiben, die die Welt ein Stück besser macht – oder zumindest ein Stück sicherer und fairer. Beispiele dafür gibt es genug: Open-Source-Projekte. Nachhaltige Software, die Ressourcen spart. Oder Technologien, die Zugang zu Bildung oder medizinischer Versorgung ermöglichen. Jeder von uns hat die Wahl, in welchen Projekten er oder sie Zeit und Energie investiert. Eine Frage der Haltung Roosevelt und Spider-Man waren sich einig: “Mit großer Macht kommt große Verantwortung.” Software-Entwickler sind keine unsichtbaren Helfer mehr im Hintergrund – sie sind die Architekten einer digitalisierten Welt. Die Frage ist: Sind wir bereit, diese Verantwortung zu tragen? Antworten können wir nicht mit Code liefern, sondern nur mit Haltung, Persönlichkeit und Mut. Es liegt an uns, die Zukunft so zu gestalten, dass sie nicht nur innovativ und fancy, sondern auch lebenswert bleibt. --- ### Stoizismus - Entscheidungen treffen in der KI-Welt URL: https://www.richard-seidl.com/de/blog/stoizismus-entscheidungen/ Datum: 2025-01-01 Stoizismus hilft, in der KI-Welt klarer zu entscheiden: Kontrolle, Tugenden und Akzeptanz schaffen Fokus, wenn KI uns mehr Entscheidungen zuschiebt. “Die KI macht die Arbeit. Wir Menschen müssen entscheiden. Jetzt noch viel öfter!” - Richard Seidl Künstliche Intelligenz hat bereits vieles in unserem Alltag übernommen oder unterstützt uns dabei. Sie sortiert E-Mails, empfiehlt uns Musik, potenzielle Partner, überarbeitet unsere Webseiten, schreibt und revidiert Programmcode, erkennt Muster,…. Doch eine Sache bleibt uns aktuelle vorbehalten: Entscheidungen treffen. Und das, paradoxerweise, ist heute anstrengender als je zuvor. Energiefresser Aktivitäten im Gehirn brauchen viel Energie. Also bei den meisten zumindest. Daher hat die pfiffige Evolution stets dafür gesorgt, dass überall Energiesparmechanismen eingebaut werden und unser Hirn im Idle-Modus ist. Klassischen Beispiel: Autofahren. Da braucht man nicht mehr viel rumdenken, das läuft durch und man kann einen Teil der gewonnen Energie darauf verwenden, die anderen Autofahrer zu beschimpfen oder die rote Ampel oder beides. Vielfalt Dazu kommt, dass wir durch unser Streben nach Freiheit, Globalisierung und Individualisierung eine Übermenge an Entscheidungsoptionen haben. Da ist nicht mehr nur schwarz und weiß. Nein, da gibt es nun auch Grautöne und Farben. Und das überall. Tausende Handymodelle zu Auswahl, Millionen von Apps (schon die richtige Task-Management oder Notizen-App ausgewählt? Es gibt immer eine bessere ;-)), ein voller Kleiderschrank, zerstückelte Parteienlandschaft. Wir verbringen mehr Zeit bei Netflix mit dem Auswahlprozess eines Filmes als mit dem Film selber (und das obwohl - oder grade weil - uns die KI schon personalisierte Trailer hinhält). Ein schönes Beispiel ist auch die KI Welt. Nehm ich heute ChatGPT, Perplexity, Claude…oder doch mal ein lokales LLM. Oh schau, da gibt es ein neues Modell, auch nicht schlecht. Welches nehme ich denn jetzt? Konsequenzen Auch die Konsequenzen unserer Entscheidungen zu überblicken, ist heute kaum noch möglich. Denn wir wissen nie, welche Auswirkungen die Wahl hat. Und langfristig können wir das schon gar nicht abschätzen. Alles viel zu schnell und viel zu abhängig voneinander. Wer soll da noch “richtig” entscheiden können? KI drückt den Turbo Um sich von den Entscheidungsqualen zu erholen gibt es ja schöne Möglichkeiten: z.B. Gartenarbeit oder wer lieber drinnen bleibt: Desktop aufräumen, Emails sortieren, mal über einen Blogtext sinnieren,… Aber: hier setzt nun die neue Welt an. Texte werden automatisch zusammengefasst. Dateien von Zauberhand wegsortiert, Emails vorbereitet und draussen dreht der Mähroboter seine Runden. Bleibt für uns noch die Ergebnisse zu sichten und…zu entscheiden. Am Stück: Entscheidung, Entscheidung, Entscheidung. Phew….anstrengend, oder? Wie können wir damit umgehen? Stoizismus Seit Jahren folge ich mal mehr, mal weniger intensiv den den Ideen und der Philosophie des Stoizismus. Diese Sammlung an Prinzipien, Tugenden und Gedanken geht auf große Denker wie Zenon von Kition, Seneca und Marc Aurel zurück und hat finde ich heute mehr Bedeutung denn je. Details gehen hier zu weit, aber die 3 wichtigsten stoischen Prinzipien lassen sich auf “Entscheidungen treffen” sehr gut anwenden: - Kontrollierbare vs. nicht kontrollierbare Dinge: Fokus auf das eigene Handeln und Loslassen von Äußerlichkeiten - Anwendung der Tugenden: Weisheit, Mut, Mäßigung, Gerechtigkeit - Akzeptanz: Verantwortungsbewusstsein, Gelassenheit, Lernbereitschaft Mir hilft dies immer wieder einen Schritt aus dem Entscheidungswahnsinn rauszugehen und mehr Klarheit und Fokus bei meinen Entscheidungen zu bekommen. ## Podcast-Episoden (letzte 20) ### Testen von KI-Modellen: Warum einfache Checks scheitern URL: https://www.richard-seidl.com/de/podcast/ki-magic-boxes-testen/ Datum: 2026-10-22 Kategorien: Software Testing Unleashed Beim Testen von KI-Modellen laufen einfache Checks ins Leere, weil niemand das Modell ganz versteht. Es braucht Exploration und Risikoabwägung. Testen von KI-Modellen bedeutet, eine Magic Box zu bewerten: ein System, dessen Verhalten weder kontrolliert noch verstanden noch auf andere Weise als sicher bekannt ist. Weil kein Mensch die Konstruktion eines Machine-Learning-Modells vorgibt, reichen einfache Checks von Ausgaben nicht. Getestet wird durch Erleben, Erkunden und Experimentieren, während Inputs, Outputs, Trainingsdaten und Guardrails beobachtbar bleiben. Das Wichtigste in Kürze - Machine-Learning-Modelle entwirft kein bewusst handelnder Mensch; Michael Bolton vergleicht sie mit Petrischalen, aus denen man die Kultur nimmt, die einen Erreger am besten abtötet. - Beim Testen von KI-Modellen sind einfache Checks von Funktionsausgaben aussichtslos, denn sie taugen nur für deterministische Software, die Entwickler verstehen und instrumentieren können. - Wer sich bei wichtigen Aufgaben auf Magie verlässt, muss sie testen; ein lustiges Gedicht für die Weihnachtsfeier birgt kein Risiko, medizinische Ratschläge eines Bots ein großes. - Testbarkeit entsteht auch ohne Quellcode, wenn Teams Inputs und Outputs überwachen und Trainingsdaten, Guardrails, Context Window sowie Aufrufe externer Services kennen; das verkleinert die Magie. - Sprachmodelle täuschen wie ein Mentalist auf der Bühne, weil Textmuster nach Erkenntnis aussehen, die in Wahrheit erst beim Leser entsteht, der dem Output einen Sinn gibt. Was hat das Testen von KI-Modellen mit Magie zu tun? Wer sich ans Testen von KI-Modellen macht, steht vor einer Box, deren Innenleben niemand vollständig kennt. Michael Bolton nennt so ein System eine Magic Box und definiert den Begriff genau. Eine Box ist in dem Maß magisch, in dem ihr Verhalten weder kontrolliert noch verstanden noch auf andere Weise als sicher bekannt ist. Manche Boxen sind schwach magisch, manche stark. Ein Sprachmodell gehört zu den stark magischen. Die Frage, wie man Sprachmodelle testet, wird damit zur Frage, wie viel Magie man sich leisten will und was mit dem Rest passiert. Der Begriff stammt aus einem Buch. Michael schreibt mit seinem Co-Autor seit rund 30 Jahren an „Taking Testing Seriously: The Rapid Software Testing Approach“, so richtig ernsthaft seit fünf Jahren. Kurz vor dem Ende fehlte noch ein Kapitel über KI, und beide wussten, dass es veraltet sein würde, bevor die Tinte trocken ist. Also schrieben sie ein Kapitel über Magie. Das sollte halten. Die Technik in der Box ändert sich ständig, das Problem bleibt: Man verlässt sich auf etwas, das man nicht versteht. Schwache Magie gibt es überall, und meistens ist sie harmlos. Für Michael ist der Python-Interpreter eine Magic Box. Konzeptionell weiß er, wie er funktioniert, die Details kennt er nicht. Sein Verhalten kann er zum Teil steuern, das nimmt etwas Magie heraus. Sicher fühlt er sich vor allem wegen des sozialen Beweises. Eine weltweite Community nutzt Python, eine kleinere Gruppe versteht die Interna und hat sie im Griff. Zieht man das Kaninchen aus dem Hut und es ist eine Ratte, behebt jemand den Fehler. Genau das meint „auf andere Weise als sicher bekannt“. Ein Sprachmodell bietet davon viel weniger. Machine-Learning-Modelle wachsen in Petrischalen Normale Software baut ein Mensch, der vorgibt, was sie tun soll. Ein Machine-Learning-Modell entwickelt kein Mensch, der bewusst und absichtsvoll handelt. Michael beschreibt es mit einer Reihe von Petrischalen. Viele Kulturen wachsen nebeneinander, eine davon tötet ein fieses Bakterium ab, und die nimmt man heraus, weil sie am besten aussieht. Entworfen hat sie niemand. Sie wurde ausgewählt. Mit solchen Modellen zu arbeiten ist, als suchte man nach guten Antibiotika in der Zeit vor der DNA-Analyse. Heute erklären Proteomik und Genomik ungefähr, welche Mechanismen hinter einem Antibiotikum stecken, und mit CRISPR lässt es sich sogar editieren. So weit sind wir bei Sprachmodellen nicht. Niemand weiß genau, wie sie funktionieren, und das bringt eigene Probleme und Risiken mit sich. Ein zweiter Punkt kommt dazu. Den Quellcode dieser Modelle hat niemand, und selbst mit Quellcode bliebe ihr Verhalten zum Teil stochastisch. Für das Testen heißt das: Das Modell lässt sich nicht instrumentieren wie eigener Code. Die Magie muss von außen kleiner werden. Solltest du dich auf Magie verlassen, wenn es darauf ankommt? Michaels Antwort ist eine kurze Reihe von Prinzipien, und das erste ist das schärfste. Wenn dir etwas sehr wichtig ist, solltest du dich wahrscheinlich nicht auf Magie verlassen, um es zu bekommen. Ist es sehr wichtig und gibt es wirklich keinen anderen Weg, kannst du es mit Magie versuchen. Dann ist es aber deine Aufgabe, die Abhängigkeit davon so klein wie möglich zu halten. Mit dem dritten Prinzip kommen die Tester ins Spiel. Wer für etwas Wichtiges Magie einsetzt, muss es testen, das verlangt die Verantwortung. Wer in der Softwarebranche arbeitet, hat eine Sorgfaltspflicht gegenüber den eigenen Kunden und deren Endkunden, und eine Magic Box setzt diese Pflicht nicht außer Kraft. Das vierte Prinzip folgt daraus: Wenn du testest, maximiere die Testbarkeit. Das fünfte regelt den Rest. Was sich nicht oder nicht gründlich genug testen lässt, braucht einen Haftungsausschluss. Und selbst dann bleibt die Verantwortung bei dem, der es anderen Leuten vorsetzt. Wie hart diese Prinzipien greifen, hängt am Risiko. Ein Modell, das für die Weihnachtsfeier ein lustiges Gedicht über einen Kollegen schreibt, trägt kein Risiko. Gefällt dir das Gedicht nicht, wirfst du es weg. Ein Bot, der medizinische Ratschläge gibt, trägt ein großes. Dort ist es klug, genau festzulegen, was der Bot sagen darf, oder magische Technologie an dieser Stelle ganz zu meiden. Wie lässt sich die Testbarkeit eines LLM-Systems erhöhen? Vieles, was Tester unter Testbarkeit verstehen, fällt hier weg, weil sich das Modell selbst nicht instrumentieren lässt. Was bleibt, ist die Box um das Modell herum. Michael zählt auf, was ein Team beobachten und steuern kann: - Inputs und Outputs, genau überwacht - die Trainingsdaten, die in das Modell eingeflossen sind - die Guardrails auf beiden Seiten, vor dem Prompt und nach der Response - das Context Window mit seiner Größe, seinem Inhalt und dem, was per Retrieval hineingeholt wurde - die Aufrufe des Systems an Datenbanken und externe Services Jeder Punkt auf dieser Liste, den ein Team kennt, steuert und beobachtet, nimmt der Box etwas Magie. In der Mitte steckt ein GPT, und das lässt sich nicht öffnen. In die größere Box drumherum kann man aber kleine Fenster einbauen, Sonden setzen oder kleine Kameras hineinstecken. Die Testbarkeit eines KI-basierten Systems entsteht vor allem auf dieser Ebene. Daraus folgt noch etwas. Alles in einem KI-basierten System, was ganz normale, klassische Software ist, lässt sich testen wie Software schon immer. Die deterministischen Teile, das Retrieval, die Anbindungen: alles prüfbar. Nur das Modell in der Mitte braucht einen anderen Zugang. Warum einfache Checks bei Sprachmodellen scheitern Testen auf Checks von Funktionsausgaben zu reduzieren, war schon immer ein enges Bild vom Job. Michael hält es für nützlich, vor allem für Entwickler, die deterministische Software verstehen und instrumentieren können. Gegen ein LLM ist es hoffnungslos. Ein Check setzt voraus, dass dieselbe Eingabe dieselbe Ausgabe liefert und ein einzelner erwarteter Wert die Sache klärt. Ein Sprachmodell bricht beide Annahmen. Was trägt, ist die Definition von Testen, die Michael und seine Kollegen über viele Jahre verfeinert haben: ein Produkt bewerten, indem man es kennenlernt, durch Erleben, Erkunden und Experimentieren. Mit dieser Definition wird alles testbar, auch eine Magic Box. Erfahrung damit sammeln geht immer. Es bewerten, indem man etwas darüber lernt, auch. Experimente damit laufen lassen ebenso. Der Prozess ist von Natur aus explorativ, weil es keinen vorgegebenen Weg gibt, etwas kennenzulernen, das noch niemand richtig kennt. Teams merken diese Verschiebung in der Praxis. Manche, die sich ohnehin von geskripteten Testfällen wegbewegen, stellen sich mit dem Aufkommen von KI wieder die Fragen, die immer schon die richtigen waren. Welche Risiken gibt es? Welche Qualität wollen wir? Was bedroht den Wert des Produkts für die Menschen, die uns wichtig sind? Tester stellen diese Fragen schon ewig. Mit KI hören mehr Leute zu. Ein Sprachmodell testen ist wie Zwiebelschälen Michaels eigene Experimente mit Sprachmodellen laufen iterativ und arbeiten sich spiralförmig nach innen. Er vergleicht sie mit dem Schälen einer Zwiebel. Je mehr man schält, desto mehr scheint da zu sein, unter jeder Schicht noch eine. Wie in der Szene aus Peer Gynt, in der der Held eine Zwiebel schält, Schicht um Schicht findet und zu dem Schluss kommt, die Natur sei witzig. Unter den Schichten kommen Muster von Inkonsistenz und Unzuverlässigkeit zum Vorschein, und zwar auf der untersten Ebene, wenn man das Modell direkt abfragt. In Michaels Experimenten läuft Haiku 4.5 viel schneller und viel bizarrer aus dem Ruder als Haiku 3.5. Interessanter ist der zweite Befund: Alle Modelle tun das. Michael vermutet, dass genau das hinter der Klage mancher Leute steckt, Claude Code sei früher gut gewesen und in letzter Zeit ziemlich mies geworden. Das Verhalten ganz unten erklärt nicht, warum das passiert. Wie es sich auswirkt, kann man aber genau beobachten. Zwei Dinge machen diese Arbeit praktikabel. Erstens ein experimentelles Framework, das dieselben Experimente immer wieder ausführt, damit Muster und seltsame Ausreißer sichtbar werden und Software hilft, sie aufzuspüren. Zweitens Tools, die Masse erzeugen. Ein Sprachmodell verlangt so viel statistische Analyse, dass alles jenseits eines allerersten Hürdentests große Mengen generierter Requests und Responses braucht. Ausgerechnet ein LLM eignet sich gut dafür. Es generiert Unmengen von Varianten derselben Frage, und du beobachtest, was sich in den Antworten ändert. Ein einziges zusätzliches oder geändertes Wort kann die Ausgabe dramatisch beeinflussen. Tester wollen wissen, wie stark, wie oft und wie weit sich dabei die Bedeutung umkehrt. Die kleinste Kleinigkeit bewirkt manchmal gar nichts und manchmal ein völlig bizarres neues Verhalten. Diese Unberechenbarkeit hält die Arbeit explorativ. Eine Beobachtung führt zu einer Hypothese, die Hypothese zu einem neuen Vorgehen, das Vorgehen zu einer neuen Entdeckung. Wie täuschen uns Sprachmodelle wie ein Mentalist? Mechanisch reiht ein Sprachmodell einen Token an den nächsten. Stephen Wolframs Essay „What Is ChatGPT Doing and Why Does It Work?“ erklärt diese Seite gut. Die psychologische Seite behandelt ein Essay von Baldur Bjarnason mit dem Titel „The LLMentalist Effect“. Er beschreibt, wie Large Language Models die Mechanismen der Hellseher-Masche nachbilden. Michael empfiehlt beide Texte allen Testern, die mit diesen Systemen arbeiten. Die Masche geht so. Ein Cold Reader sagt schnell etwas und hofft auf einen Treffer. Letzte Woche war ein bisschen stressig für dich. Irgendwann gab es eine technische Komplikation, Mittwoch oder Donnerstag, irgendeine Software, die dich eine halbe Stunde gekostet hat. Ob das stimmt, ist egal. Spannend ist, was dabei in deinem Kopf passiert: Du versuchst sofort, die Aussage einem Ereignis zuzuordnen. Textmuster lassen uns glauben, da stecke Erkenntnis drin, wo keine ist. Die Erkenntnis, die entsteht, kommt aus unserer eigenen Anstrengung, die Ausgabe zu deuten und ihr einen Sinn zu geben. Michaels Lieblingszauberer sind Penn & Teller, weil sie oft genau zeigen, wie ein Trick funktioniert. Ihre Nummer mit Bechern und Bällen spielen sie mit durchsichtigen Plastikbechern, das Publikum sieht jede Bewegung. Man sieht, wie clever Zauberer sind, und man sieht, wie leicht man sich täuschen lässt. Wer den Mechanismus kennt, fällt seltener herein, wenn jemand einen anderen Trick vorführt. Bei Technologie ist es genauso. Wer versteht, wie ein Sprachmodell mechanisch funktioniert und was es mit dem menschlichen Kopf macht, lässt sich schwerer täuschen. Dann geht die Anerkennung dorthin, wo sie hingehört, zu den Menschen, die denken. Und das Gespräch mit dem Kunden kann sich der praktischen Frage zuwenden. Liefert dieses Ding konsistente, zuverlässige Ergebnisse, und spielt Zuverlässigkeit in diesem Fall überhaupt eine Rolle? Tester werden dafür bezahlt, für andere zu lernen Die Art von Testen, die ein Produkt untersucht, mit besonderem Fokus auf der Suche nach Problemen, ist für KI bereit. Michael sieht das Testen gerade im Rampenlicht. Die enge Version des Jobs, Ausgaben gegen erwartete Werte prüfen, hat gegen eine Magic Box keine Chance. Die breite Version hat alles, was sie braucht, dazu Tools, um sie zu skalieren. „Wir werden dafür bezahlt, Dinge stellvertretend für andere Leute zu lernen. Was gibt’s für einen besseren Job?“ (Michael Bolton) Testen hat schon immer Spaß gemacht, wenn man es richtig macht. Wessen Team klagt, KI sei nicht testbar, dem rät Michael: die Technologie verstehen, sich damit auseinandersetzen, Tools nutzen und die Risikofrage vor alles andere stellen. Wo viel auf dem Spiel steht, lieber weniger Magie. Wo Magie unvermeidlich ist, testen, für das nicht Testbare die Haftung ausschließen und die Verantwortung tragen, die bleibt. --- ### DAST mit ZAP: Erst mitlernen, dann angreifen URL: https://www.richard-seidl.com/de/podcast/dast-sicherheitstests-dora/ Datum: 2026-10-20 Kategorien: Podcast Software Testing Ein DAST-Tool wie ZAP lernt als Proxy aus Regressionstests und greift die Webanwendung dann selbst an. Unter DORA ist das für Banken ein Baustein. DAST (Dynamic Application Security Testing) prüft eine laufende Webanwendung mit automatisierten Angriffsmustern wie SQL-Injection und Cross-Site-Scripting. Ein Tool wie ZAP sitzt dabei als Proxy zwischen Test und Anwendung, lernt zuerst den normalen Verkehr kennen und baut dann Angriffe in die aufgezeichneten Requests ein. Für Finanzinstitute ist das seit der DORA-Verordnung ein Baustein der verlangten Sicherheitstests, neben SAST, SCA und Pentests. Das Wichtigste in Kürze - Während SAST den Quellcode prüft und SCA Fremdbibliotheken gegen Schwachstellendatenbanken abgleicht, greift DAST die laufende Webanwendung mit Mustern wie SQL-Injection und Cross-Site-Scripting an. - Die DORA-Verordnung verlangt von Banken und Versicherungen Sicherheitstests für Internet-exponierte Anwendungen; der dynamische Test muss mindestens vor jeder Produktivsetzung gelaufen sein. - ZAP (Zed Attack Proxy) sitzt zwischen Testausführung und Anwendung: Die Explore-Phase zeichnet Requests und Responses auf, danach baut das Tool Angriffe in genau diesen Verkehr ein. - Vorhandene Playwright- oder Selenium-Regressionstests liefern die Explore-Phase, ein Jenkins-Job startet den Angriffslauf danach, etwa nach dem Deployment auf die Vorproduktion oder am Wochenende. - Daniel Schmuck will die Befunde aus SAST, SCA, DAST, Pentests und Infrastrukturscans in einer Sicht je Anwendung zusammenführen, weil eine veraltete Bibliothek sonst dreimal gemeldet wird. Warum landet DAST bei einer Bank im Testmanagement? Weil die DORA-Verordnung es verlangt und das Thema in die Querschnittseinheit fällt, die den Softwareentwicklungsprozess, das Testmanagement und die Testautomatisierung verantwortet. DAST steht für Dynamic Application Security Testing: automatisierte Sicherheitstests gegen die laufende Anwendung, früh in der Entwicklung, statt Sicherheit erst in Produktion über einen Penetrationstest nachzuweisen. Daniel Schmuck verantwortet bei einer Bank den IT-Prozess Testmanagement. Er übersetzt regulatorische Vorgaben in hauseigene Testvorgaben und kümmert sich um die GUI-basierte Testautomatisierung. Sicherheitstests lagen bis dahin woanders. Der Digital Operational Resilience Act, kurz DORA, ist seit Januar 2025 für Finanzinstitute verbindlich, für Banken wie für Versicherungen. Die Verordnung und ihr technischer Regulierungsstandard verlangen Sicherheitstests in der Anwendungsentwicklung, darunter statische und dynamische Prüfungen. DAST allein erfüllt DORA nicht, es ist ein Baustein des verlangten Testprogramms. Aber dieser Baustein ist ein dynamischer, automatisierter Test, und wer im Haus der zentrale Ansprechpartner für Testautomatisierung ist, bekommt ihn zwangsläufig auf den Tisch. So landete das Thema bei Daniel. Für Test- und Qualitätsleute ist das eine späte Genugtuung. Shift-Left, also Fehler möglichst früh finden, in diesem Fall Sicherheitsschwachstellen, wünschen sie sich seit Jahren. Hier zwingt eine Verordnung dazu. Die Verordnung sagt Quellcode-Prüfung und meint etwas anderes Der Einstieg lief über Selbststudium: die DORA-Verordnung selbst und der technische Regulierungsstandard, der sie genauer beschreibt. Dort ist von statischen und dynamischen Quellcode-Prüfungen die Rede. Für jemanden mit ISTQB-Hintergrund klingt eine dynamische Quellcode-Prüfung nach einem Widerspruch, denn Quellcode prüft man statisch, dynamisch testet man die laufende Anwendung. „Ich habe einen ISTQB-Hintergrund, und die dynamische Quellcode-Prüfung war für mich irgendwie ein Widerspruch.“ (Daniel Schmuck) Die Recherche führte zu drei Begriffen, die so nicht in der Verordnung stehen, wohl aber im ISTQB-Glossar: SAST, DAST und SCA. SAST, Static Application Security Testing, prüft den Quellcode ohne laufende Anwendung, etwa mit SonarQube und dessen Security-Regeln. SCA, Software Composition Analysis, gleicht Fremd- und Open-Source-Bibliotheken mit Schwachstellen-Datenbanken ab. DAST testet die Anwendung im Betrieb auf einer Testumgebung mit Angriffsmustern. Daniel nennt das einen Dreiklang. Die statischen und dynamischen Quellcode-Prüfungen der Verordnung entsprechen SAST und DAST; SCA ist der dritte Aspekt, den Daniel dazuzählt. Dann die Werkzeugfrage. Daniel hat eine Affinität zu Open Source und startet lieber mit einer kostenfreien Lösung; stößt sie an Grenzen, kann er immer noch kommerzielle Tools vergleichen. Für DAST führt dieser Weg fast zwangsläufig zu ZAP, dem Zed Attack Proxy, heute als ZAP by Checkmarx geführt und vielen noch als OWASP ZAP geläufig. Eingearbeitet hat er sich über die Dokumentation, die Community und Videos zum Tool. Wie funktioniert ZAP als Proxy zwischen Test und Anwendung? ZAP schaltet sich als Proxy zwischen Testausführung und Anwendung und arbeitet in zwei Phasen. Das Werkzeug ist für Webanwendungen gebaut, also für HTTP- und HTTPS-Verkehr. Ob jemand die Anwendung manuell im Browser bedient oder ein automatisierter Test sie durchläuft: Jeder Request und jede Response geht durch ZAP. Phase | Was passiert | Woher der Input kommt Explore | ZAP zeichnet den normalen Verkehr auf und lernt, wie eine gute Interaktion mit der Anwendung aussieht | manuelle Bedienung über die ZAP-Oberfläche, ein schlanker Aufruf per Adresse oder funktionale Tests, bei Bedarf detailliert gesteuert über die REST-API Angriff | ZAP baut Angriffsmuster in die aufgezeichneten Requests ein und fährt sie gegen die Anwendung: SQL-Injection, Cross-Site-Scripting, das volle Spektrum | Profile legen fest, welche Prüfregeln laufen Die zweite Phase läuft automatisch, man schaut zu. Profile steuern, welche Angriffsregeln zur Wirkung kommen, und das hängt auch an der Technologie. Steht hinter der Anwendung eine DB2 oder eine SQLite, laufen nur die SQL-Injection-Regeln für diese Datenbank. Den größten Einfluss auf Dauer und Umfang der Angriffe hat aber, was in der Explore-Phase aufgezeichnet wurde. Trotz solcher Konfiguration bleibt es ein Blackbox-Test über die Schnittstellen des Systems. Das muss kein Browser sein. Für REST-Services nimmt ZAP eine OpenAPI-Definition, für GraphQL eine GraphQL-Definition, für SOAP-Services die WSDL. Service-basierte Schnittstellen lassen sich damit genauso prüfen wie Oberflächen. Regressionstests liefern den Verkehr für die Explore-Phase Das Ziel ist, die Explore-Phase nicht von Hand zu füttern. Die manuelle Bedienung über die Oberfläche taugt zum Kennenlernen des Tools, mehr nicht. Stattdessen laufen die vorhandenen funktionalen Regressionstests durch den Proxy. Wer Browser-Tests mit Playwright oder Selenium hat, konfiguriert im Browser ZAP als Proxy, und der komplette funktionale Test zeichnet nebenbei alle Requests und Responses auf. Niemand klickt, niemand protokolliert. Die vorhandene Testautomatisierung zahlt sich damit zweimal aus. Der Regressionstest prüft weiterhin die Fachlichkeit, derselbe Lauf liefert ZAP die Basis für die Angriffsphase. Je breiter die funktionalen Tests die Anwendung abdecken, desto mehr Angriffsfläche kennt das Tool danach. Fällt man beim ersten DAST-Report vom Stuhl? Nein, jedenfalls nicht, wenn vorher schon Penetrationstests liefen. DORA verlangt die Tests ausdrücklich für Internet-exponierte Anwendungen, also für alles, was jeder von außen aufrufen kann, etwa die Website der Bank mit dem geschlossenen Kundenbereich. Genau diese Anwendungen lässt die Bank seit Längerem von externen Experten per Penetrationstest prüfen. Daniel erwartete vom ersten DAST-Lauf deshalb eine Bestätigung der jüngsten Pentest-Ergebnisse. Genau das kam heraus: keine kritischen Treffer, dieselben Befunde. Der Nutzen liegt woanders. Der Penetrationstest ist eine beauftragte Expertenleistung zu einem Zeitpunkt. Der automatisierte Test wiederholt die Prüfung auf der Testumgebung, so oft die Pipeline ihn anstößt, und zwar vor jeder Produktivsetzung. Wie oft muss der Sicherheitstest in der Jenkins-Pipeline laufen? Mindestens einmal vor jeder Produktivsetzung, das ist die regulatorische Anforderung. Alles darüber ist Ermessen. Die Bank bildet ihre CI/CD-Pipelines in Jenkins ab: Quellcode bauen, paketieren, auf die Testumgebung deployen. End-to-End- und GUI-Tests laufen in eigenen Jobs. Für die Sicherheitstests gibt es nun ebenfalls eigene Jenkins-Pipelines je Anwendung, mit der jeweiligen ZAP-Konfiguration dahinter. Diese Jobs lassen sich an verschiedene Auslöser hängen. Kommt ein neuer Anwendungsstand auf die Vorproduktionsumgebung, läuft nach dem Deployment der Sicherheitstest. Oder er läuft jedes Wochenende. Täglich wie ein funktionaler Regressionstest muss er nicht laufen. Aber vor dem Go-live muss er gelaufen sein. Plugin-Updates halten die Angriffsregeln aktuell Open Source ist nicht gleich Open Source, deshalb lohnt der Blick auf die Pflege. Neue Versionen des ZAP-Kerns erscheinen selten. Die Funktionen stecken aber in Plugins, und dort ist viel Bewegung: Über alle Plugins hinweg kommt fast jede Woche ein Update, die Prüfregeln für Angriffe wurden 2026 etwa alle ein bis drei Monate erneuert. Daniels Eindruck: Hinter dem Tool steht eine aktive Community. Für Sicherheitstests ist das kein Nebenaspekt. Jeden Tag kommen neue Angriffsvektoren dazu, neue Ideen, wie sich etwas kaputt machen lässt. Ein Regelwerk von vor zwei Jahren prüft gegen die Angreifer von vor zwei Jahren. Dass die Plugins automatisch aktualisiert werden können, hält den Test auf dem Stand von heute. Eine Sicht auf alle Schwachstellen, damit Entwickler nicht dreimal dieselbe Meldung bekommen Als Nächstes will Daniel die Ergebnisse zusammenführen, denn ZAP hat keine eigene Ergebnisverwaltung. Anders als SonarQube, wo sich Befunde aus statischer Analyse und SAST im Tool abrufen lassen, liefert ZAP einen Report als JSON, XML, PDF oder HTML und hält sonst keine Daten vor. Daneben gibt es das SCA-Tool mit eigenen Ergebnissen, die Pentest-Berichte der beauftragten Agenturen und betriebsseitige Infrastrukturscans, die PCs, Server und andere Endgeräte regelmäßig auf Schwachstellen und veraltete Bibliotheken prüfen. Das sind vier, fünf Töpfe mit Befunden, die idealerweise in einer Sicht je Anwendung landen. Sonst passiert Folgendes: Der Pentester meldet eine veraltete Bibliothek. Der DAST-Lauf meldet sie auch. Der Infrastrukturscan findet sie auf dem Testserver ein drittes Mal. Drei Meldungen, eine Ursache. Irgendwann sind die Entwickler mit Doppelmeldungen überlastet, und die sollen ja auch noch Features bauen. Gleichzeitig rücken Schwachstellen immer weiter nach vorn, und für ihre zeitnahe Behebung gibt es eigene Anforderungen. Wer die Meldungen konsolidiert, nimmt den Entwicklern Doppelarbeit ab und lässt ihnen die Zeit für das, was wirklich offen ist. Redundanzen vermeiden ist deshalb der Punkt, den Daniel als Nächstes angeht. Häufig gestellte Fragen Was ist der Unterschied zwischen SAST, DAST und SCA? Die drei Verfahren prüfen die Anwendungssicherheit an unterschiedlichen Stellen. SAST (Static Application Security Testing) analysiert den Quellcode, ohne dass die Anwendung läuft, etwa mit SonarQube und speziellen Security-Regeln. SCA (Software Composition Analysis) gleicht eingebundene Fremd- und Open-Source-Bibliotheken mit Schwachstellen-Datenbanken ab. DAST testet die laufende Anwendung auf einer Testumgebung, indem es Angriffsmuster gegen sie ausführt. Welche Sicherheitstests verlangt die DORA-Verordnung? Der technische Regulierungsstandard zu DORA spricht von statischen und dynamischen Quellcode-Prüfungen, gemeint sind Verfahren wie SAST und DAST. Pflicht sind sie für Internet-exponierte Anwendungen, also alles, was Kunden von außen aufrufen können, und sie müssen vor jeder Produktivsetzung gelaufen sein. DAST ist dabei ein Baustein des Testprogramms, Penetrationstests durch externe Experten laufen weiter. Ersetzt DAST den Penetrationstest? Nein. Der Penetrationstest bleibt eine beauftragte Expertenleistung zu einem bestimmten Zeitpunkt. Ein automatisierter DAST-Lauf wiederholt dagegen Angriffsmuster auf der Testumgebung, so oft die Pipeline ihn anstößt, und läuft vor jeder Produktivsetzung. Bei der Bank bestätigte der erste Durchlauf die jüngsten Pentest-Ergebnisse, ohne neue kritische Treffer. Beide Verfahren laufen dort parallel. Ist ZAP kostenlos? Die Lizenz ja, der Einsatz nicht. ZAP steht unter Apache 2.0 und darf auch kommerziell genutzt werden. Der Betrieb kostet trotzdem Zeit und Know-how, etwa für die Authentifizierung, Single-Page-Apps, False Positives und das Zusammenführen von Befunden über mehrere Scans. Und Open Source lebt von Mitwirkung. Irgendwer bezahlt die Weiterentwicklung, zum Beispiel mit der eigenen Freizeit. Wer das Tool produktiv nutzt, kann etwas zurückgeben: Fehler melden, Prüfregeln oder Add-ons beisteuern, die Doku verbessern, Maintainer finanzieren. Ist DAST ein Blackbox-Test? Ja, weitgehend. Das Werkzeug arbeitet über die Schnittstellen des Systems, also über den Browser oder die Services, und braucht keinen Zugriff auf den Quellcode. Für REST nimmt es eine OpenAPI-Definition, für GraphQL eine GraphQL-Definition, für SOAP die WSDL. Über Profile lassen sich die Angriffsregeln an die Technologie anpassen, etwa SQL-Injection-Regeln für eine bestimmte Datenbank. --- ### Dunkle Seite des Testens: Fehler, die wir selbst auslösen URL: https://www.richard-seidl.com/de/podcast/dunkle-seite-des-testens/ Datum: 2026-10-15 Kategorien: Software Testing Unleashed Die dunkle Seite des Testens beginnt beim Aufbau: Ein Test kann den Ausfall auslösen, den er verhindern soll. Davor steht eine eigene Risikobewertung. Die dunkle Seite des Testens bezeichnet die Fehler, die das Testen selbst verursacht: Testdaten, die aus einer schwach geschützten Testumgebung abfließen, Angreifer, die dort den Code studieren, oder ein fehlschlagender Test, der die Produktion lahmlegt. Jeder Testaufbau braucht deshalb vorab eine eigene Risikobewertung, am besten zusammen mit jemandem aus dem Netzwerk-Team. Das Wichtigste in Kürze - Die dunkle Seite des Testens beginnt, wenn ein Test genau die Störung auslöst, die er verhindern sollte; wer die Folgen eines Tests nicht tragen kann, testet ihn nicht. - Nicht anonymisierte Produktionsdaten auf einer CD unterliegen keiner Governance, deshalb zerbrach Bart Knaack den Datenträger, statt die Daten zu anonymisieren. - Eine Testumgebung, die schwächer geschützt ist als die Produktion, lässt Angreifer in Ruhe den Code studieren und dessen Schwachstellen später gegen das Livesystem nutzen. - Testen in Produktion braucht eine eigene Risikobewertung, am besten mit einem Netzwerk-Engineer im Raum, der weiß, welche Umgebungen miteinander verbunden sind. - Aus 10.000 End-to-End-Testfällen wurden 50, nachdem das Team Prüfungen wie die Adressvalidierung in den Unit-Test verlagert hatte. Die dunkle Seite des Testens beginnt vor dem ersten Testlauf Wir testen, damit in der Produktion nichts schiefgeht. Dafür gibt es den Job. Die dunkle Seite des Testens ist, dass das Testen selbst Ausfälle verursachen kann: Testdaten, die nach außen gelangen, Testumgebungen, die Fremden einen Blick auf den Code geben, Produktionssysteme, die wegen eines fehlgeschlagenen Tests stehen. Bart Knaack sammelt solche Fälle aus seinen eigenen Projekten, und seine Diagnose ist knapp. Die meisten passieren, weil vorher niemand gründlich genug nachgedacht hat. Seine Regel für den Moment vor dem Startknopf ist kurz. „Wenn du die Konsequenz deines Tests nicht tragen kannst, dann teste es nicht.“ (Bart Knaack) Die Fragen, die daraus folgen, haben eine Reihenfolge. Sollten wir das überhaupt bauen? Wie wollen wir es testen? Wie soll die Umgebung aussehen, und woher kommen die Daten? Lässt sich eine Umgebung aufbauen, die für das Vorhaben taugt, einen Performancetest zum Beispiel? Und wenn es keine eigene, produktionsnahe Umgebung gibt: Testen wir dann wirklich in der Produktion? Jede Antwort hat eine Konsequenz, und aus diesen Konsequenzen besteht die dunkle Seite. Die meisten von Barts Beispielen liegen auf der nicht-funktionalen Seite, also bei IT-Sicherheit, Performance und Governance. Seine Erklärung dafür: Über funktionales Testen denken Teams meist gründlich nach. Die nicht-funktionalen Themen laufen nebenher, und von dort kommen die Überraschungen. Wie gelangen Testdaten aus einer Testumgebung nach außen? Testdaten fließen ab, wenn echte, nicht anonymisierte Daten auf einem System liegen, das schwächer geschützt ist als die Produktion. Eine Testumgebung bekommt selten denselben Schutz wie das Produktionssystem, das sie nachbildet. Wer hineinkommt, bekommt die Daten gleich mit. Barts eigenes Beispiel brauchte nicht einmal einen Angreifer. Ein Kollege kam in sein Büro und bat ihn, ein paar Daten zu anonymisieren. Bart sagte zu und bat ihn, die Daten in eine sichere Umgebung zu legen. Der Kollege hatte sie auf einer CD dabei. Bart nahm die CD und zerbrach sie. Der Protest kam prompt, das seien seine Testdaten. Barts Antwort: Das sind Produktionsdaten auf einer CD, die keiner Governance unterliegen, und das machen wir nicht. Die Lehre hängt weniger an der CD als am Prozess. Wie setzt du deine Tests so auf, dass sie sicher sind, und wer darf was wohin tragen? Das klärt man, bevor die Daten unterwegs sind. Was sieht ein Angreifer in deiner Testumgebung? Eine Testumgebung öffnet eine zweite Tür. Wer hineinkommt, kann dort in Ruhe studieren, wie der Code funktioniert, und jede Schwachstelle, die er findet, gegen die Produktion einsetzen. Die Umgebung ist „nur“ Test, entsprechend ist sie geschützt, und genau das macht sie für Angreifer brauchbar. Dafür braucht auch ein Tester einen gewissen Einblick in die Infrastruktur seines Systems. Wer sie kennt, erkennt Schwachstellen und weiß, was er in der Testumgebung tun will und was besser nicht. Bart rät, den Schutz der Testumgebung als eigene Entwurfsfrage zu behandeln. Dasselbe gilt für eine separate Performance-Umgebung: Ist sie wirklich unabhängig von der Produktion, oder teilt sie sich eine Datenbank, ein Netzsegment, einen Service? Die Frage stellt man, bevor die Last anrollt. Der Risikoprozess braucht seine eigene Risikobewertung Bart ist kein Befürworter von Tests in der Produktion. Er weiß auch, dass es manchmal keine Wahl gibt. Dann gilt als Erstes: Du musst wissen, was du dort tust, denn du greifst in das Produktionssystem ein. Als Zweites musst du die Auswirkung eines fehlschlagenden Tests kennen. Wenn ein fehlschlagender Test die Produktion lahmlegen kann, wann genau willst du ihn dann laufen lassen? Daraus wird eine Risikobewertung des Risikoprozesses selbst. Vielen Testern fällt schon das Nachdenken über gewöhnliche Produktrisiken schwer, und über die Risiken des eigenen Testens erst recht. Bart hält das trotzdem für den Job. Was ihn wundert, ist, wie oft Leute mit Tester-Mindset genau die Fehler machen, die sie anderen vorwerfen. Sein praktischer Schritt ist einfach. Wann immer er so etwas aufsetzt, holt er einen Netzwerk-Engineer in die Session. Der weiß, mit welcher Umgebung die Testumgebung verbunden ist, wie sie aufgebaut ist und warum gerade diese Datenbank im Einsatz ist. Jemand aus dem Ops- oder Netzwerkteam sitzt mit den Testern am Tisch, und die Frage auf dem Tisch lautet: Was soll da schon schiefgehen? Danach kommt die zweite Hälfte des Testens in der Produktion, das Aufräumen. Warum helfen Checklisten nur zur Hälfte? Checklisten helfen beim Erinnern. Bart hat selbst einige geschrieben. Das Problem ist, dass eine Checkliste auch vom Denken abhält. Sind alle Kästchen abgehakt, schließt das Team daraus, dass nichts mehr schiefgehen kann, und in diesem Moment hört es auf, selbst zu denken. Sicher ist man in Barts Augen nie. Deshalb hält er sich von Checklisten fern, so weit es geht, und arbeitet stattdessen mit Orientierung, also mit Vorschlägen und vor allem mit Fragen. Worüber solltest du nachdenken? Was willst du nachweisen, und wo? Solche Fragen lassen sich nicht abhaken, man muss sie beantworten. Wie die Fragen gestellt werden, hängt vom Umfang ab. Bei einer großen End-to-End-Kette kann eine Gruppensitzung sinnvoll sein, weil sich die Leute gegenseitig auf Ideen bringen und einwenden, dass etwas für das eine System gilt und für das andere nicht. Große Meetings mit Agenda sind allerdings ein Aufwand, deshalb geht Bart bei kleineren Themen eins zu eins vor, manchmal in der Kaffeeecke mit zehn Minuten von jemandes Zeit. Diese Sessions nimmt er auf, lässt sie transkribieren und nutzt das Transkript als ersten Entwurf des Reports. Das Ergebnis schickt er anschließend herum, damit jeder prüfen kann, ob seine Aussage stimmt, und ergänzt, was andere gesagt haben. Wer sagt, das passiert nie, soll es unterschreiben Manchmal ist das Risiko für den Tester klar, und sonst will es niemand sehen. Barts Beispiel stammt aus einer Firma mit zwei Systemen, die über eine direkte Leitung verbunden waren. Als Tester fand er heraus, dass es schiefgehen würde, sobald sich zwei Nachrichten überholen. Die Antwort des Engineers: Das ist eine direkte Verbindung, Nachrichten überholen sich da nie, das ist ein Netzwerkthema, mach dir keine Gedanken. Bart bat um die Aussage in schriftlicher Form, mit Unterschrift, und hängte sie an den Fehler. Drei Monate später war der Netzwerkverkehr so gewachsen, dass das eine Kabel nicht mehr reichte, ein Netzwerk kam dazwischen, und Nachrichten konnten sich überholen. Als das Team fragte, warum er das nicht getestet habe, schob er den Bericht über den Tisch. Sein Schluss daraus klingt nicht nach Triumph. In den meisten Fällen hören die Leute zu; ein Hinweis wie „ihr habt eine Verbindung zur Produktion, schaut euch das vielleicht an“ reicht meist. Wenn nicht, sorg dafür, dass die Warnung festgehalten ist und du zeigen kannst, dass du das Richtige getan hast. Warum sind 10.000 End-to-End-Testfälle ein Warnsignal? Eine sehr große End-to-End-Suite heißt meist, dass Prüfungen an der teuersten Stelle gelandet sind, an der sie laufen können. Ein Team erzählte Bart mit einigem Stolz, es habe 10.000 End-to-End-Testfälle gebaut. Seine Antwort: Dann macht ihr etwas falsch. Für diese Tests muss es Alternativen in früheren Phasen geben. Ein Beispiel war die Adressprüfung. Ob eine Adresse gültig ist, wurde im End-to-End-Test geprüft, und Bart fragte, warum das nicht im Unit-Test passiert. Das Team hatte Sorge, ein Unit-Test zeige nicht, ob die Prüfung auch End-to-End funktioniert. Bart hielt dagegen, dass etwas, das auf Unit-Ebene funktioniert, auch End-to-End funktioniert. Das Team verlagerte die Prüfungen nach unten und landete bei 50 End-to-End-Testfällen statt 10.000. Hinter der Zahl stecken die Fragen, die Bart immer wieder stellt. Warum machen wir diesen Test, und warum auf diese Weise? Gibt es wirklich keinen anderen Weg? Wenn nicht, welche Risiken müssen vorher weg? Und wenn doch, gibt es eine weniger riskante Alternative, die dasselbe nachweist? Was willst du nachweisen, wo kannst du es nachweisen, und musst du es an der Stelle tun, an der du es gerade tust? Dieselbe Logik legt er an Tests in der Produktion an. Qualität ist eine gemeinsame Sache An die Silos von Testern und Entwicklern glaubt Bart nicht mehr. Sein Rat für den Anfang: Setz dich als Tester mit deinem Entwickler zusammen und besprich genau diese Fragen. In gemeinsamen Workshops stellte er fest, dass Entwickler die Testtechniken oft nicht kennen, Grenzwertanalyse oder Äquivalenzklassenbildung etwa, mit denen sich gute Unit-Testfälle entwerfen lassen. Also halfen die Tester beim Aufbau dieser Fälle und beim Setzen richtiger Asserts. Manche Tests hatten unten nur ein „assert is true“. Sie erhöhten die Code Coverage und konnten nie fehlschlagen. Auf die Frage, was so ein Test beweist, lautete die ehrliche Antwort: nichts. Bart führte Mutation Testing ein, das den Wert solcher Tests deutlich besser zeigt als das, was er den Code-Coverage-Trugschluss nennt. Niemand löst das an einem Tag. Langsam anfangen, Beispiele geben, die Leute erleben lassen, was diese Arbeitsweise bedeutet. Barts aktuelles Beispiel ist Contract-based Testing zwischen Consumer- und Producer-Seite zweier APIs. Vor 20 Jahren hat er das von Hand gemacht: Consumer-Protokoll nehmen, Producer-Protokoll nehmen, abgleichen, und die Abweichungen liegen offen, ein Integer auf der einen Seite, ein String auf der anderen. Die ersten Bugs fand er, bevor eine Zeile Code geschrieben war, und die Kollegen hielten das für eine besondere Fähigkeit. Er hatte zwei Dokumente gelesen und verglichen. Das führt ihn zur Wurzel der meisten dieser Fehler. Die Leute reden nicht miteinander, und sie hören einander nicht zu. Sie bekommen eine Aufgabe, gehen ihren eigenen Weg, tun, was sie für nötig halten, und am Ende passt es nicht zusammen. Vieles davon ist Kommunikation, und die, so Bart, wird uns die KI nicht abnehmen. Eine Frage lässt er für die nächste Runde offen. Wenn du eine KI testest, worüber musst du dir dann Gedanken machen? Das Testen von KIs hält Bart für die nächste Stufe, um die kein Team herumkommt. Er verweist auf eine BBC-Dokumentation, in der bösartig trainierte KIs ihre Absichten in der Testumgebung verborgen und erst in der Produktion gezeigt haben. Wenn das heute noch nicht passiert, sagt Bart, dann passiert es in Zukunft. --- ### Kubernetes-Lasttests: Erst Fragen sammeln, dann messen URL: https://www.richard-seidl.com/de/podcast/lasttests-kubernetes-umgebungen/ Datum: 2026-10-13 Kategorien: Podcast Software Testing Lasttests in Kubernetes-Umgebungen lohnen sich erst mit einer klaren Risikofrage. CPU und RAM sind selten das Bottleneck, Caching oder Logins öfter. Bei Lasttests in Kubernetes-Umgebungen geht es darum, ob eine containerisierte Anwendung unter Last die Erwartungen an Antwortzeit und Skalierung erfüllt. Weil Auto Scaling und Load Balancing jeden Lauf verändern, braucht ein belastbarer Test eine konkrete Risikofrage und eine Laborumgebung, in der beides zurückgefahren ist. Entwicklung, Operations und QA müssen dafür Metriken, Logs und Anwendungswissen zusammenbringen, allein schafft das keine Abteilung. Das Wichtigste in Kürze - 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. Lasttests in Kubernetes-Umgebungen brauchen zuerst eine Frage Lasttests in Kubernetes-Umgebungen lohnen sich nur, wenn vorher klar ist, welche Frage sie beantworten sollen. Stephan Schwarz nennt einen Lasttest, der gemacht wird, damit einer gemacht wurde, „potenziell verschwendete Lebenszeit“. Aus dem Ergebnis soll eine Entscheidung folgen, sonst bleibt eine Zahl in einem Report. Die Fragen, die Stephan meint, drehen sich um Risiko. Nehmen wir das Risiko in Kauf? Wie hoch ist es überhaupt, und worin besteht es? Lässt es sich mitigieren, und mit welchen Mitteln? Ist eine Mitigation definiert, prüft der nächste Lasttest, ob sie hält. Erst diese Kette macht aus einem Testlauf eine Grundlage für Entscheidungen. Was heißt Performance überhaupt? Performance heißt, dass Erwartungen erfüllt werden. Diese Erwartungen sind je Unternehmen verschieden, und oft merkt eine Organisation erst beim ersten Lasttest, dass intern niemand dasselbe darunter versteht. Alle sagen „muss performant sein“, aber was das in Sekunden oder Fehlerraten bedeutet, hat keiner festgelegt. Stephan bringt ein Beispiel: Ist eine schnelle Fehlermeldung für den Kunden besser als vier, fünf oder zehn Sekunden Wartezeit auf eine valide Antwort? Die Antwort darauf hängt vom Geschäft ab. Dazu gehört die zweite Frage, welches Risiko das Unternehmen bewusst akzeptiert. Warum machen so wenige Teams Lasttests? Weil ein Team allein das Momentum dafür selten aufbaut. Stephan Schwarz sieht in Kundenprojekten meistens dasselbe Bild: Die Entwicklungsabteilung will testen, oder die QA sagt „das müssten wir mal machen“, und dann passiert nichts. Für einen belastbaren Lasttest braucht es die Expertise des Operations-Teams, des Plattform-Teams und manchmal eine Freigabe vom C-Level. Dazu kommt der Aufwand. Eine Testumgebung aufbauen, Abhängigkeiten klären, Lastgeneratoren bereitstellen, Ergebnisse mit mehreren Abteilungen deuten. Das ist kein Nachmittag, und Stephan sagt offen, dass er versteht, warum das selten gemacht wird. Fahrt gewinnt das Thema typischerweise nach einem Postmortem. Etwas ist ausgefallen, Kunden haben es gemerkt, und Lasttests stehen plötzlich in den Top 3 der Action Items. Besser wäre, vorher anzufangen. Welche Testumgebung eignet sich für Lasttests in Kubernetes? Die Umgebung folgt aus der Frage. Wer wissen will, wie eine containerisierte Anwendung unter CPU-Last skaliert, baut ein Laborsetup: entweder nur den Container oder einen eigenen Kubernetes-Cluster, auf dem sonst nichts läuft. Danach stellt sich die Frage nach den Infrastrukturabhängigkeiten. Nimmt der Test die Datenbank auf dem Produktionscluster oder eine eigene im Laborcluster? Gegen die Produktionsumgebung zu testen, ist ebenfalls legitim. Manche Abhängigkeiten existieren aus guten Gründen nur in Prod und lassen sich in Staging nicht nachbauen. Wer das tut, benennt die Risiken und nimmt sie bewusst in Kauf. Dahinter steckt ein Trade-off, aus dem niemand herauskommt. Je labormäßiger das Setup, desto weniger hat es mit dem zu tun, was später wirklich läuft. Kubernetes macht zusätzlich die Wiederholbarkeit schwer. Stephan erinnert an den Spruch, der Einstein zugeschrieben wird (und wohl nicht von ihm stammt), nach dem zweimal dasselbe Tun auch dasselbe Ergebnis bringen sollte. In einem Kubernetes-Cluster ist schon das zweimal Dasselbe-Tun schwierig, weil Load Balancer und Autoscaling ständig eingreifen. Seine Empfehlung für den Anfang: Autoscaling und Load Balancing so weit wie möglich zurückfahren. Außer die Skalierung selbst ist die Frage, dann bleibt sie drin. Der Lastgenerator muss mitskalieren Die Anforderungen an einen Lastgenerator sind überschaubar. Das Werkzeug soll die Protokolle der Anwendung sprechen, Metriken ausgeben, den Test fahren und skalieren. Der letzte Punkt wird in Kubernetes zum Pflichtkriterium, weil die getestete Workload selbst hochskaliert. Skaliert der Generator nicht mit, ist er der limitierende Faktor und misst am Ende sich selbst. Werkzeuge gibt es viele, Stephan nennt Artillery, Locust und k6. Kunden haben meistens einen Observability-Stack, der Logs und Metriken in ein Grafana-Dashboard bringt. Eine Lastgenerator-Farm, die bereitsteht, fehlt dagegen fast immer. In Vanilla-Kubernetes kommt so etwas nicht von Haus aus mit. Stephans erster Lasttest 2018 lieferte miserable Zahlen. Er fragte sich, warum sein Service so schlecht war, bis er merkte, dass er vom eigenen Notebook testete. Das Gerät war schlicht nicht dafür gebaut, so viele Sessions parallel zu öffnen. Ein Lasttest prüft immer das ganze Konstrukt, den Generator eingeschlossen. Was sind typische Ursachen für Performance-Probleme in Kubernetes? Die Ursachen sind bunt, und reine Ressourcen gehören selten dazu. RAM nachschieben oder eine Node dazustellen, das alte Rezept, hilft nach Stephans Erfahrung in den seltensten Fällen. Was er gesehen hat: ein Caching, das nicht sauber implementiert war. Eine externe Abhängigkeit, die niemand auf dem Schirm hatte, konkret ein ausgelagerter OIDC-Provider für die Authentifizierung, der nicht auf die Last ausgelegt war. Das System selbst hätte gekonnt, die Anmeldung nicht. Dazu Datenbank-Server, Session-Handling, Firewalls. Genau deshalb braucht ein Lasttest alles an Know-how, was im Unternehmen zu finden ist. Vorher weiß niemand, wo es hakt, und keine Abteilung kann die Suche allein stemmen. Das Bottleneck ist immer da Jedes System hat ein Bottleneck. Wer es noch nicht gefunden hat, hat deshalb keins weniger. Und wer es behebt, bekommt das nächste, wie bei einer Hydra. Stephan nennt das den Normalzustand. Das Team muss wissen, welches Bottleneck gerade limitiert. Dann kann es reagieren, wenn mehr Kunden kommen: Hardware fürs nächste Jahr planen oder in der Cloud rechtzeitig nachprovisionieren. Ohne diesen Befund wartet eine Organisation nur darauf, dass etwas passiert. Dev und Ops sind unterschiedlich sozialisiert Lasttests scheitern oft an der Grenze zwischen Entwicklung und Betrieb, und Stephan Schwarz erklärt das mit Sozialisierung. Er kommt selbst aus dem Operations, aus einem lokalen Rechenzentrum, in dem die oberste Regel lautete: bloß keine Änderung. Jede Änderung gefährdet das SLA, und Ausfälle sind für Ops-Menschen das Schlimmste. „Never touch a running system“ heißt es nicht ohne Grund. Für Entwickler gilt das Gegenteil, ihr Job sind Features, und Features sind Veränderungen. Dazu kommt Silo-Denken. Stephan hat den Satz gehört: Wir entwickeln hier nur, und wenn die Anwendung nicht läuft, ist das ein Betriebsproblem. Stephan fragt dann zurück, ob der Betrieb als Team gemeint ist oder der Betrieb als Unternehmen. Im zweiten Fall stimmt der Satz. Ein Lasttest ist deshalb Team-Effort. Operations hat die Metriken und Logs, die Entwickler kennen die Anwendung, die QA stellt die Testfragen. Sitzen alle drei an einem Tisch, passiert das, wofür Stephan brennt: Ops zeigt die Daten vom letzten Lauf, QA erklärt den Test, die Developer finden die Stelle im Code. Daraus entstehen Optimierungen, die weiter reichen als zwei zusätzliche CPUs. Ein Lasttest ist auch kein Einmalprojekt. Ein Lauf liefert eine Vermutung, woran es liegt. Die Mitigation muss beweisen, dass sie wirkt, also fährt das Team den Test erneut. Am Ende versteht die ganze Firma ihr Produkt besser, auch das Management. Es sieht dann etwa, dass 10 Prozent langsamere Antworten für einen Kunden in Ordnung sind, weil der ohnehin cacht. Gehören Lasttests in die CI/CD-Pipeline? Die Integration in die Entwicklungspipeline nennt Stephan die Kür, und er glaubt nicht, dass jedes Team sie braucht. Wer ein infrastrukturlastiges Projekt mit vielen Abhängigkeiten betreibt, kann dort ansetzen. Solche Projekte haben ohnehin einen Smoke-Test, der Ende zu Ende läuft. Erfasst dieser Test zusätzlich die Metriken und notiert sie als Testergebnis, sieht das Team nach jeder Infrastrukturänderung, ob die Latenz steigt oder sinkt. Wichtiger als die Pipeline ist Stephan etwas Einfacheres: dass Teams in Kubernetes-Umgebungen überhaupt adäquate Requests und Limits für ihre Container setzen. In vielen Projekten fehlen sie oder sind nicht valide gesetzt. Das ist kein Vorwurf, sagt er. Ein Entwicklungsteam kann nicht wissen, wie sich die Software unter Last verhält, solange niemand getestet hat. Und das Operations-Team hat zwar Metriken und Methoden, aber kaum Bezug zur Anwendung. Anfangen heißt Momentum erzeugen Der erste Schritt ist eine Liste von Fragen. Techniker, QA-Ingenieure und Operations Engineers haben meist ein Gefühl dafür, wo es klemmen könnte. Diese Vermutungen werden zu Fragen und zu benannten Risiken, etwa „ich könnte mir vorstellen, dass hier unser limitierender Faktor liegt“. Mit dieser Liste geht das Team ins Management und macht Werbung. Das Argument liegt bereit: Wir wissen nicht, wo unser Bottleneck ist, also warten wir darauf, dass etwas passiert. „Wenn ich mein Produkt nicht teste, dann macht es mein Kunde.“ (Stephan Schwarz) Das Management darf sich auch anders entscheiden. Wenn SLAs und Verträge das hergeben, kann ein Unternehmen das Risiko tragen. Für Stephan ist das in Ordnung, solange es bewusst entschieden wurde. Wer dagegen einfach gegen eine Testinstanz schießt, ohne zu wissen warum, beantwortet damit noch keine Frage. Sein Tipp: Risiken transparent machen, Fragen transparent machen, über Abteilungen hinweg ins Gespräch kommen und so das Momentum aufbauen. Anders geht es seiner Erfahrung nach nicht. --- ### Quality Hunting: Informationen sammeln statt Bugs suchen URL: https://www.richard-seidl.com/de/podcast/quality-hunting-methode/ Datum: 2026-10-08 Kategorien: Software Testing Unleashed Beim Quality Hunting erkunden Teams aus etwa vier Leuten ein System in drei Stunden und berichten, was Stakeholder über die Qualität wissen müssen. Quality Hunting ist eine Alternative zum Bug Hunting, bei der kleine Teams in einer kurzen explorativen Session gezielt Informationen über die Qualität eines Systems sammeln. Vorher wird festgelegt, welche Information gebraucht wird, etwa zur Usability. Der Bericht verdichtet die Rohdaten zu Wissen, mit dem die Stakeholder entscheiden, ob das System live geht. Das Wichtigste in Kürze - Rik Marselis hat Quality Hunting aus Frust über Bug Hunting entwickelt, denn Testen heißt für ihn, Informationen über das Qualitätsniveau eines Systems zu bekommen. - Beim allerersten Durchlauf im Testlab der EuroSTAR-Konferenz fand ein Team nur etwa acht Probleme, konnte aber beurteilen, wie gut das System für Menschen mit Behinderung funktioniert. - Ein Quality-Hunting-Team hat rund vier Leute, halb so viele wie ein durchschnittliches agiles Team, und eine Session dauert etwa drei Stunden, höchstens einen halben Tag. - Teams sollten die Struktur ihres Reports gleich zu Beginn skizzieren, damit die Session sie mit den Informationen füllt, die ihre Stakeholder brauchen. - Ein guter Zeitpunkt liegt kurz vor einem Release, das mehrere Sprints bündelt; wer jede User Story sofort in Produktion bringt, findet dafür keinen Platz. Was ist Quality Hunting? Quality Hunting ist eine kurze, zeitlich begrenzte explorative Session, in der kleine Teams Informationen über ein System sammeln, damit Stakeholder seine Qualität beurteilen können. Rik Marselis hat die Methode als Alternative zum Bug Hunting entwickelt. Vom Bug Hunting übernimmt sie den spielerischen Wettbewerb; die Teams sammeln dabei Belege zu Qualitätsmerkmalen. Im Ablauf ähnelt Quality Hunting einem sitzungsbasierten explorativen Test, wie ihn die Testentwurfsverfahren kennen, mit festem Zeitrahmen und klarem Auftrag. Am Ende eines Quality Hunts steht eine Aussage, die den Entscheidern eine Frage beantwortet: Ist das System gut genug? Rik beschreibt die Methode im Buch Amplified Quality Engineering, und der neue ISTQB-Lehrplan Quality in DevOps führt sie als einen seiner Ansätze. Eine Bugliste sagt wenig über Qualität Bug Hunting geht von der Prämisse aus, dass Tester Bugs finden sollen. Aus Riks Frust über genau diese Prämisse ist die ganze Idee entstanden. Ein Bug ist für ihn ein Signal: Die Qualität liegt unter dem, was man erwartet hat, und jemand kann etwas dagegen tun. Die eigentliche Aufgabe des Testens ist, das Qualitätsniveau zu kennen. „Beim Testen geht es darum, Informationen über das Qualitätsniveau deines Systems zu bekommen.“ (Rik Marselis) Ihre Form bekam die Methode in einem Testlab auf der EuroSTAR-Konferenz. Rik und seine Kollegen organisierten dort das allererste Quality Hunting als Hands-on-Übung, und es funktionierte überraschend gut. Einige Teams arbeiteten trotzdem im Bug-Hunting-Modus und kamen mit einem riesigen Haufen Probleme zurück. Ob das System gut genug war, ließ sich daraus nicht ablesen. Ein anderes Team meldete nur etwa acht Probleme, hatte aber geschaut, wie sich das System benutzen lässt. Sein Urteil: Für ein allgemeines Publikum funktioniert es gut genug, für Menschen mit Behinderung nicht, weil ihnen manche Auswahlmöglichkeiten fehlen. Dieses Team lieferte eine Bewertung der Qualität. Danach beschrieb Rik die Methode formaler. Am Anfang steht die Frage des Stakeholders Beim Bug Hunting ist das Ziel klar: Bugs finden. Quality Hunting braucht etwas Vorbereitung, weil das Ziel erst festgelegt werden muss: Welche Information brauchen wir, und für wen? Das klärt das Team selbst, oder es bekommt die Vorgabe von dem, der den Auftrag vergibt. Wer zum ersten Mal einen Quality Hunt plant, fragt am besten die Stakeholder, welche Information ihnen helfen würde, nachts gut zu schlafen. Wer die Entscheidung trägt, ob Product Owner, Nutzer oder Management, soll die Information bekommen, die ihm die Sorge um das System nimmt. Der Hunt sammelt dann die Inputs für genau diese Information. Inhaltlich hilft der Blick auf die Qualitätsmerkmale. Ob das System tut, was es soll, bleibt wichtig. Aufschlussreicher ist oft, wie es das tut. Manche nicht-funktionalen Merkmale eignen sich besser als andere. Ein Performancetest passt schlecht in eine dreistündige Teamsession. Usability lässt sich vorab schwer spezifizieren und in kurzer Zeit gut erkunden, deshalb ist sie ein guter Kandidat für einen Quality Hunt. Wie läuft eine Quality-Hunting-Session ab? Ein Quality Hunt ist wie ein Spiel organisiert. Mehrere Teams treten gegeneinander an, der Stakeholder kürt den Sieger, und es gibt einen Preis. Rik rät zu einem kleinen Preis, denn es geht um gute Informationen. Der Wettbewerb lohnt sich trotzdem, weil die Teams sich gegenseitig anspornen, weiterzuschauen. Den Rahmen beschreibt Rik typischerweise so: - etwa vier Leute je Team, ungefähr halb so viele wie in einem durchschnittlichen agilen Team mit sieben - höchstens ein halber Tag, rund drei Stunden - vier bis sechs Teams parallel, die zusammen in sehr kurzer Zeit sehr viele Informationen liefern Innerhalb dieses Zeitrahmens entscheidet jedes Team, wie es den Auftrag angeht und was in der verfügbaren Zeit machbar ist. Dann arbeitet es wie ein explorativer Tester: einen Test überlegen, ausführen, daraus lernen, prüfen, ob das näher an die gesuchte Information bringt. Vorbereitet wird wenig. Den nächsten Schritt löst aus, was das Team im System passieren sieht. Zwischendurch tritt es einen Schritt zurück und erinnert sich an das eigentliche Ziel, eine bestimmte Art von Information für die Stakeholder. Wie ein Team dorthin kommt, entscheidet es selbst. Fest steht nur das Ziel: die bestmögliche Information in diesem Zeitrahmen. Gleicher Auftrag, verschiedene Richtungen Bekommen mehrere Teams denselben Auftrag, schlagen sie trotzdem völlig unterschiedliche Richtungen ein. Riks Usability-Beispiel zeigt das. Manche Teams prüfen, ob das System gut aussieht und zu den Richtlinien oder dem Stil des Unternehmens passt. Andere denken an Barrierefreiheit und fragen, wie Menschen mit Behinderung das System nutzen können. Für den Stakeholder wird es dadurch schwer, einen Sieger zu bestimmen, weil in jeder Richtung ein Wert steckt. Rik schlägt deshalb ein paar kleinere Preise vor, keinen großen. Oft gewinnen die Teams am Ende gemeinsam, denn zusammen liefern sie dem Stakeholder in kurzer Zeit eine Menge Informationen. Wie berichten Teams ihre Ergebnisse? Ein Bug Hunt endet mit einer Liste von Bugs. Welche Form der Report eines Quality Hunts hat, hängt vom Team ab. Rik empfiehlt, und das gilt fürs Testen allgemein, gleich zu Beginn über die Struktur des Reports nachzudenken. Welche Botschaft willst du vermitteln, und an wen? Steht die Struktur, muss die Session sie nur noch füllen. Während des Hunts prüft das Team, welche Informationen schon da sind und welche noch fehlen. Rik verbindet das mit der Hierarchie aus Daten, Information, Wissen und Weisheit. Testen liefert zuerst Daten, die das Team zu Informationen zusammensetzt. Bei den Stakeholdern soll Wissen ankommen, damit sie das Qualitätsniveau wirklich kennen. Die Weisheit, über den Go-live zu entscheiden, bleibt bei ihnen. Ein Report voller Rohdaten darüber, was das Team getan hat, überspringt den Schritt, auf den es ankommt. Der beste Zeitpunkt liegt kurz vor dem Release Wie oft ein Quality Hunt sinnvoll ist, hängt von der Situation ab. Eine praktikable Regel lautet, vor jedem Release in Produktion etwas Quality Hunting zu machen. Wer im echten DevOps-Stil jede einzelne User Story sofort in Produktion bringt, findet dafür keinen Platz. Die meisten Teams arbeiten aber in Sprints und bringen das Ergebnis mehrerer Sprints gemeinsam in Produktion. Die Zeit kurz vor einem solchen Release hält Rik für den idealen Moment. Weil jeder in einem Team mitmachen kann, ergänzt ein Hunt an dieser Stelle auch den Abnahmetest. Endnutzer, Manager und andere Beteiligte bekommen einen Eindruck aus erster Hand von der Qualität des Systems. Auch dort, wo Automatisierung dominiert, hält der Ansatz Menschen im Spiel. In DevOps-Umgebungen mit dem Motto „automatisiere alles“ bewahrt Quality Hunting die menschliche Neugier und den kritischen Blick, deshalb steht es im ISTQB-Lehrplan. Bei KI im Testen gilt dasselbe: Menschen müssen weiter fragen, was das Ziel war und ob sie wirklich bekommen, was sie brauchen. --- ### Hardware-in-the-Loop: Kernel-Test am echten Gerät URL: https://www.richard-seidl.com/de/podcast/hardware-in-the-loop-tests/ Datum: 2026-10-06 Kategorien: Podcast Software Testing Ein Kernel besteht die Abnahme nur auf echter Hardware. Für Hardware-in-the-Loop-Tests reservieren Entwickler und CI sauber initialisierte Geräte. Hardware-in-the-Loop bezeichnet das automatisierte Testen von Systemsoftware auf echter Hardware, weil ein Kernel oder ein Embedded-Image am Ende nur dort abgenommen werden kann. Ein Open-Source-Framework reserviert dafür Testmaschinen in einem sauberen Ausgangszustand, bootet das passende Image und gibt die Geräte per REST API an Entwickler wie an die CI-Pipeline aus. Das Wichtigste in Kürze - 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. Ein Kernel beweist nur auf echter Hardware, dass er läuft Wer Systemsoftware baut, kommt um Hardware-in-the-Loop nicht herum: Das Testobjekt läuft auf dem echten Zielgerät, und eine Testumgebung steuert dieses Gerät von außen, startet es, bespielt es und liest aus, was es tut. Markus Napierkowski und sein Team arbeiten auf Linux-Kernel-Ebene und haben früher Mikrokerne gebaut. Ein Kernel soll auf jeder CPU-Generation laufen, also muss er auf jeder dieser Hardware-Generationen auch getestet werden. Virtualisierung hilft bei vielem, beim Beweis für die reale Plattform hilft sie nicht. Dasselbe gilt eine Ebene höher bei Embedded-PCs. Dort lässt sich ein Großteil virtualisiert prüfen, der finale Abnahmetest aber nur dann, wenn das Image, das für genau diese Plattform zugeschnitten ist, auch auf genau dieser Plattform bootet. Der Wunsch dahinter war von Anfang an derselbe wie bei Unit-Tests: schnelle Feedback-Zyklen, kein manuelles Durchklicken. Das Labor für HIL Testing, das Kollegen von Markus vor über zehn Jahren aufgebaut haben, war der Anfang. Die Anwendungsfälle und die Lösungen dafür haben sich seither mehrfach verändert. Die aktuelle Fassung ist ein Framework, das über Jahre gemeinsam mit einer Partnerorganisation entstanden ist, lange closed source blieb und seit zwei Monaten auf GitHub liegt. Warum ist der saubere Ausgangszustand bei Hardware-in-the-Loop-Tests der Knackpunkt? Weil die Automatisierung auf Softwareebene meistens schon da ist und trotzdem nichts beweist. Skript hochladen, Payload hochladen, ausführen: Das bekommt fast jedes Team hin. Was fehlt, ist Setup und Teardown für die Hardware selbst. Ohne beides weiß nach einem Lauf niemand sicher, in welchem Zustand das Gerät steckt, und der nächste rote Test sagt wenig über die Software. Eine Testmaschine wird reserviert und ist dann in einem definierten Anfangszustand. Der Test gibt das Boot-Image vor, dazu weitere Geräte im Umfeld, die initialisiert sein müssen, und bei Bedarf ein Netzwerk aus mehreren Maschinen. Dann geht die Hardware an, und der eigentliche Test läuft so, als hätte sich jemand per SSH eingeloggt und ihn von Hand gestartet. Markus benennt die Grenze offen: Die saubere Initialisierung macht sich das Framework einfach, weil es auf den Fall optimiert ist, in dem Booten vom USB-Stick reicht. Firmware auf ein Gerät zu flashen kann es noch nicht; wer das braucht, muss es selbst anbauen. Das deckt nach seiner Erfahrung trotzdem einen großen Teil der eigenen Fälle und vieler Kundenfälle ab. Wie teilen sich Entwickler und CI-Pipeline dieselbe Testhardware? Über Reservierung mit einem Secret. Die Tests laufen in der Pipeline vor oder nach jedem Pull Request, je nach Strategie des Projekts, und dieselbe Infrastruktur steht Entwicklern direkt offen. Wer ein Fehlverhalten untersuchen will, nimmt sich dieselbe Maschine für denselben Test heraus, ohne die CI anzuhalten. Ist die Maschine wieder frei, holt sich die Pipeline sie zurück. „Ich kann mir als Entwickler jetzt eine Hardware reservieren und sie benutzen, als würde sie neben meinem Tisch stehen.“ (Markus Napierkowski) Der Anlass dafür war ein Arbeitsrhythmus, den viele kennen: Änderung pushen, auf die Pipeline warten, Kaffee holen, zurückkommen, immer noch warten. Oder die Nachricht im Team-Chat, dass die Maschine jetzt reserviert ist und bitte niemand darauf deployen soll. Was dann trotzdem passiert. Eine Reservierung gehört dagegen einer Person, bis sie die Maschine zurückgibt. Wenn mehrere Exemplare derselben Hardware vorhanden sind, verteilt das System die Anfragen dynamisch zwischen CI und Menschen. Das Secret lässt sich teilen, und das lohnt sich in einem Fall: Ein Test schlägt fehl, und zwei Leute schauen gemeinsam in die Web-UI, was der Bildschirm-Output der einzelnen Maschinen gerade zeigt und warum. Ein Raspberry Pi je Testmaschine, fünf Zeilen Nix je neuer Hardware Neue Hardware einzuhängen kostet auf der Softwareseite etwa fünf Zeilen Code und ein Deployment. Markus und sein Team setzen auf Nix und NixOS und halten die gesamte Testinfrastruktur in einem Infrastructure-as-Code-Repository. Ein neues Gerät ist dort ein dupliziertes Stück Konfiguration, einmal ausgerollt. Auf der Hardwareseite hängt an jeder Testmaschine ein Raspberry Pi. Er simuliert über USB Geräte wie das Bootmedium, liest den HDMI-Ausgang der Maschine mit und bindet die serielle Konsole an. Der Pi muss einmal vorbereitet werden. Danach kapselt die Infrastruktur-Beschreibung den Rest der Komplexität weg; wer das Gesamtsystem einmal verstanden hat, erweitert es ohne Herumfummeln an einzelnen Geräten. Wie schreibt man einen HIL-Test, ohne die API zu kennen? Indem das Tooling die Umgebung aufbaut, bevor das Testskript startet. Unter allem liegt eine REST API; die Web-UI nutzt sie, das Command-Line-Tooling nutzt sie. Wer eine Maschine reserviert, bekommt ein Secret zurück, das als Kontext für alle reservierten Maschinen gilt. Über denselben Weg lassen sich die Maschinen vernetzen, ein VLAN-Switch gehört zum Aufbau. Ein Test beschreibt in JSON, welche Maschinen er braucht, in welchem Netzwerk sie hängen und welches Bootmedium sie bekommen. Das Testskript selbst beginnt erst an der Stelle, an der die Maschinen per SSH erreichbar sind. Die Person, die den Test schreibt, muss im besten Fall nie wissen, wie die API dahinter spricht. Ein großer Anwendungsfall war GitLab CI. Die einzelnen Testfälle eines Durchlaufs fallen im JUnit-XML-Format als Artefakt heraus, damit die CI sie strukturiert anzeigt. Für Performance-Benchmarks ist das Testen auf Hardware ebenfalls relevant: Virtualisierte Messungen sind oft nicht stabil genug, und manchmal steht die Zahl im Requirement. Ein Router, der in höchstens zehn Sekunden hochgefahren sein muss, braucht Messdaten, die das belegen, und die lassen sich aus den Läufen aufnehmen und weiterleiten. Ein internes Werkzeug, bewusst auf GitHub Markus nennt das Framework noch ein internes Tool. Es deckt die eigenen Fälle und die des Partners ab; ob es mit wenigen Kniffen auch anderen hilft, ist offen. Es gibt erste Gespräche, aber keinen Beleg und kein externes Investment. Eine Roadmap existiert jenseits von Aufräumarbeiten nach der Veröffentlichung nicht. Der Kandidat, der sich auf der TACON in Gesprächen herausgeschält hat, ist ein Interface, um Firmware auf Geräte zu bekommen statt nur vom USB-Stick zu booten. Für die aktuellen Anwendungsfälle hält Markus den Stand für gut genug. Open Source wurde das Framework aus zwei Gründen. Hinter der proprietären Fassung stand kein kommerzieller Wert, der das Geheimhalten gerechtfertigt hätte. Und die ganze eigene Infrastruktur baut auf Open-Source-Software auf; Markus beschreibt es als Ehrgefühl, etwas Gebautes auch wieder zurückzugeben, selbst wenn sich zeigen sollte, dass es zu viele Änderungen bräuchte, um über das eigene Haus hinaus zu taugen. Wenn Du Embedded-Systeme mit wechselnden Hardware-Konfigurationen testest und die Reservierung heute noch über den Team-Chat läuft, lohnt sich ein Blick auf das Projekt. Markus sucht gerade Rückmeldungen dazu, welche Anwendungsfälle dem Framework noch fehlen. Häufig gestellte Fragen Was ist Hardware-in-the-Loop? Hardware-in-the-Loop bedeutet, dass die zu testende Software auf dem echten Zielgerät läuft, während eine Testumgebung dieses Gerät von außen steuert: starten, Boot-Image bereitstellen, Ausgaben mitlesen. Für Kernel und Embedded-Images ist das der einzige Weg, um zu zeigen, dass ein Build auf einer konkreten Plattform tatsächlich funktioniert. Wie integriert man Hardware-in-the-Loop-Tests in eine CI-Pipeline? Die Hardware-Tests laufen als normaler Pipeline-Schritt, etwa vor oder nach jedem Pull Request. Das Tooling reserviert dafür eine Maschine, bootet sie mit dem vorgegebenen Image und gibt sie danach wieder frei. Die Ergebnisse der einzelnen Testfälle landen als JUnit-XML-Artefakt in der CI, bei GitLab zum Beispiel direkt in der Oberfläche. Reicht ein virtualisierter Test, oder braucht es einen HIL-Test auf echter Hardware? Für den größten Teil der Entwicklung reicht Virtualisierung, für den Abnahmetest nicht. Ein Image, das auf eine bestimmte Plattform zugeschnitten ist, beweist erst auf dieser Plattform, dass es bootet und läuft. Für den Nachweis, dass ein Kernel auf jeder unterstützten CPU-Generation funktioniert, gilt dasselbe. Eignet sich Hardware-in-the-Loop auch für Performance-Messungen? Ja, gerade dann, wenn eine Zahl im Requirement steht. Ein Router, der in höchstens zehn Sekunden hochgefahren sein muss, braucht Messdaten vom echten Gerät, weil virtualisierte Messungen oft schwanken. Die Werte aus den Testläufen lassen sich aufzeichnen und an eine Infrastruktur weiterleiten, die sie sammelt und auswertet. --- ### Testkonferenzen vor Ort: Warum Networking Präsenz erfordert URL: https://www.richard-seidl.com/de/podcast/istanbul-software-testing-konferenz/ Datum: 2026-10-01 Kategorien: Software Testing Unleashed Die Konferenz zum Testen in Istanbul hat sich von einem riskanten Debüt zu einer Veranstaltung entwickelt, die Tester aus Europa und Asien zusammenbringt – mit Übersetzungen in jedem Programmteil. Die Istanbul Software Testing Conference (ISTC) ist eine Präsenzveranstaltung zum Thema Testen, die Tester aus Europa und Asien zusammenbringt. Sie entstand, nachdem große türkische Testveranstaltungen während der Pandemie ins Internet verlegt wurden. Bei ihrer dritten Ausgabe im Jahr 2026 gab es über 120 eingereichte Vorträge und 20 Prozent internationale Teilnehmer. In jedem Programmteil gibt es eine Simultanübersetzung Englisch-Türkisch, damit sich niemand ausgeschlossen fühlt. Das Wichtigste in Kürze - Die Istanbul Software Testing Conference entstand, weil die wichtigsten Veranstaltungen zum Testen in der Türkei nach der Pandemie weiterhin online stattfanden, sodass Tester keinen physischen Ort mehr hatten, um sich zu vernetzen und Ideen auszutauschen. - Internationale Teilnehmer machten 20 Prozent des Publikums im Jahr 2026 aus, und dieser Anteil ist mit jeder Ausgabe gewachsen, seit im ersten Jahr 200 Teilnehmer dabei waren. - Sechs Mitglieder des Programmkomitees führten eine Review-Prozedur für jede einzelne der über 120 Einreichungen für die dritte Ausgabe durch – ein Arbeitsaufwand, von dem Okan Çakmak erwartet, dass er mit steigender Zahl internationaler Einreichungen noch zunehmen wird. - Die Konferenz kehrt von drei parallelen Programmsträngen zu zwei zurück, da die Teilnehmer angaben, dass die Wahl zwischen drei Sitzungen gleichzeitig zu schwierig sei. - In jedem Programmstrang gibt es den ganzen Tag über Simultanübersetzung, sodass Referenten auf Türkisch oder Englisch präsentieren können und sich kein Teilnehmer aufgrund der Sprache ausgeschlossen fühlt. Warum brauchte Istanbul eine Testkonferenz vor Ort? Die Istanbul Software Testing Conference (ISTC) gibt es, weil die großen Testveranstaltungen in der Türkei während der Pandemie ins Internet verlegt wurden und nie wieder zurückkamen. Diese Verlagerung hinterließ eine Lücke. Den Anstoß gab es aus dem Ausland. Okan Çakmak, Gründer und Organisator der ISTC, hielt drei Jahre vor der dritten Ausgabe der Konferenz einen Vortrag auf der HUSTEF, dem ungarischen Testforum. Er kehrte inspiriert von der Energie der Budapester Test-Community zurück und fragte sich, warum es in Istanbul nichts Vergleichbares gab. Okan besprach die Idee mit Rik Marselis, den er als den „Paten“ des ISTC bezeichnet. Gemeinsam erwogen sie, eine Präsenzkonferenz zu organisieren, ohne zu wissen, wie die Tester auf eine neue Veranstaltung reagieren würden. Eine einmalige Veranstaltung, die sich weigerte, einmalig zu bleiben Die erste ISTC war als einmalige Veranstaltung geplant. Niemand wusste, ob 50 oder 100 Leute kommen würden. Am Ende nahmen 200 Leute teil und gingen voller Inspiration nach Hause. Diese Reaktion entschied die Frage nach der Fortsetzung. Die Organisatoren beschlossen, aus der einmaligen Veranstaltung eine regelmäßig stattfindende Konferenz zu machen, und nahmen den damit verbundenen Aufwand in Kauf. „Unsere Hauptmotivation ist es, zu sehen, wie den Leuten die Augen leuchten, wenn sie hier wieder gehen.“ — Okan Çakmak Das „Leuchten in den Augen“ bleibt für die Organisatoren die Messung für den Erfolg. Jede Ausgabe hat mehr Interesse geweckt als die vorherige und mehr Teilnehmer aus dem Ausland angezogen. Die Entwicklung der Konferenz über die einzelnen Ausgaben hinweg zeigt, wie schnell sie gewachsen ist: Ausgabe | Wichtige Fakten Erste | Als einmalige Veranstaltung geplant, 200 Teilnehmer Zweite | Zwei parallele Sessions, größeres Interesse und mehr internationale Teilnehmer Dritte (2026) | Drei parallele Sessions, mehr als 120 Einreichungen, 20 Prozent internationale Teilnehmer Vierte | Angekündigt für den 27. und 28. Mai, Rückkehr zu zwei parallelen Sessions Wie wählt das ISTC-Programmkomitee die Vorträge aus? Jeder Beitrag, der beim ISTC eingereicht wird, wird von allen sechs Komiteemitgliedern als Gutachter begutachtet. Für die Ausgabe 2026 bearbeitete das Komitee mehr als 120 Einreichungen – eine hohe Zahl für eine Konferenz, die erst im dritten Jahr stattfindet. Tanja Vos leitete das Programmkomitee 2026. Rik Marselis, Hassan, Huseyin Erdem, Evrim und Okan vervollständigten das Team. Die große Anzahl machte die Auswahl schwierig, ermöglichte es dem Komitee aber auch, ein starkes Programm zusammenzustellen. Die Organisatoren rechnen bei zukünftigen Ausgaben mit noch mehr Einreichungen. Internationale Referenten teilen ihre Teilnahme auf LinkedIn, wodurch die Konferenz ins Blickfeld anderer Referenten rückt, die sich dann bewerben. Um Schritt zu halten, plant das Komitee, die Arbeit der Gutachter aufzuteilen. Mehr Einreichungen bedeuten schwierigere Entscheidungen – doch der Lohn ist ein besseres Programm. Wenn du vorhast, einen Vortrag zu halten, halte Ausschau nach dem Call for Papers vor jeder Ausgabe. Gastfreundschaft ist Teil des Programms Die ISTC behandelt ihre Referenten wie Gäste in einem Privathaushalt. Die türkische Kultur ist bekannt für ihre Gastfreundschaft und Herzlichkeit, und die Organisatoren lassen diese Haltung bewusst in die Art und Weise einfließen, wie sie die Referenten bewirten. Das Ziel ist, dass sich jeder Referent willkommen fühlt und eine gute Erfahrung macht – bis ins kleinste Detail. Referenten beschreiben das Ergebnis als ein Rundum-Service-Erlebnis. Für internationale Referenten, die überlegen, ob sie sich bewerben sollen, macht diese Fürsorge Istanbul zu einem attraktiven Ort, um Wissen zu teilen. Wer nimmt an der Istanbul Software Testing Conference teil? Im Jahr 2026 kamen 80 Prozent der ISTC-Teilnehmer aus der Türkei und 20 Prozent aus dem Ausland. Diese Mischung entspricht den Zielen der Organisatoren: den Aufbau eines Ökosystems für das Testen in Istanbul für türkische Tester und für Menschen aus den umliegenden Ländern, die davon profitieren möchten. Ein zweites Ziel ist es, Istanbul selbst Testern aus aller Welt näherzubringen. Die Stadt hat 20 Millionen Einwohner und ist seit Jahrtausenden ein Anziehungspunkt – von der römischen über die byzantinische bis hin zur osmanischen Epoche. Istanbul verbindet Asien und Europa und vereint Merkmale beider Kontinente. Die Stadt ist vielseitig. Man kann hier Geschichte entdecken, orientalisches Flair, eine europäische Atmosphäre oder eine Mischung aus all dem. Für Konferenzbesucher wird die Stadt selbst zu einem Grund, hierherzukommen. Zwei Tracks sind besser als drei Die ISTC bietet den ganzen Tag über Simultanübersetzungen für jeden Track an. Referenten können auf Englisch oder, wenn es ihnen leichter fällt, auf Türkisch sprechen. Die Teilnehmer setzen ein Headset auf und hören den Vortrag in der Sprache, die sie benötigen. Die Übersetzung funktioniert in beide Richtungen. Ein türkischer Teilnehmer, der sich mit Englisch schwer tut, kann einen englischen Vortrag auf Türkisch verfolgen. Ein internationaler Besucher kann einen türkischen Vortrag auf Englisch verfolgen. Das Prinzip dahinter ist einfach: Niemand soll sich ausgeschlossen fühlen. Bei der Ausgabe 2026 wurde mit drei parallelen Sessions experimentiert – im Vergleich zu zwei im Vorjahr –, wobei für alle drei eine Übersetzung angeboten wurde. Das unmittelbare Feedback war eindeutig. Den Teilnehmern fiel es schwer, sich zwischen drei Vorträgen gleichzeitig zu entscheiden. Die Wahl zwischen zwei ist einfacher, daher kehrt die vierte Ausgabe zu zwei Programmsträngen zurück, wobei die Simultanübersetzung beibehalten wird. Was zeichnet die türkische Test-Community aus? Türkische Tester bringen große Neugier und kritisches Denken mit – Eigenschaften, die ein guter Tester braucht. Was ihnen hingegen etwas fehlt, ist die aktive Teilnahme an den Konferenzsitzungen. Okan beobachtet ein Muster bei verschiedenen Veranstaltungen: Je weiter östlich eine Konferenz stattfindet, desto weniger beteiligt sich das Publikum. Auf westeuropäischen Konferenzen sind die Teilnehmer eher selbstbewusst, teils wegen der englischen Sprache, teils wegen der Kultur. Je weiter man nach Osten kommt, desto stärker lässt die Beteiligung nach. Die ISTC arbeitet aktiv gegen diese Zurückhaltung an. Die Organisatoren ermutigen die Teilnehmer, Fragen zu stellen und sich aktiv in die Konferenz einzubringen, anstatt nur passives Publikum zu sein. Die Bemühungen zahlen sich aus. Das Publikum bei der ISTC zögerte in der Vergangenheit oft, Fragen zu stellen, doch im Jahr 2026 endete eine Sitzung mit einer Improvisationsübung, bei der jeder Teilnehmer aufstehen und etwas tun musste. Alle machten mit, und alle hatten Spaß. Mit dem richtigen Format weicht die Schüchternheit. Eine Brücke zwischen europäischen und asiatischen Testern Okans langfristige Vision für die ISTC ist eine etablierte Konferenz mit internationaler Anerkennung, die über die Türkei und ihre Nachbarländer hinaus bekannt ist – sowohl in europäischen als auch in asiatischen Ländern. Istanbuls geografische Lage prägt diese Vision. Die Stadt verbindet zwei Kontinente, und die Konferenz zielt darauf ab, die Tester beider Kontinente miteinander zu vernetzen. Wenn die ISTC dieses Ziel erreicht, wird sie zu einem Treffpunkt, an dem europäische und asiatische Tester-Communities voneinander lernen. Die Organisatoren haben sich bereits dem nächsten Schritt verschrieben. Die vierte Ausgabe findet am 27. und 28. Mai statt – mit zwei Programmsträngen, vollständiger Übersetzung und dem gleichen Ziel: dass die Tester mit einem Leuchten in den Augen nach Hause gehen. --- ### Mutation Coverage: Warum volle Abdeckung nichts beweist URL: https://www.richard-seidl.com/de/podcast/mutation-coverage-metrik/ Datum: 2026-09-29 Kategorien: Podcast Software Testing Mutation Coverage misst, wie viele gezielt eingebaute Fehler Tests finden. Das sagt mehr als Code Coverage, gerade wenn KI-Agenten Tests schreiben. Mutation Testing ist ein Verfahren, das die Qualität automatisierter Tests misst. Ein Tool baut absichtlich Fehler in den Produktionscode ein, etwa umgedrehte Bedingungen, und führt die betroffenen Tests erneut aus. Bleiben sie grün, sind sie schwach. Der Anteil erkannter, sogenannter gekillter Mutationen heißt Mutation Coverage und sagt mehr aus als reine Code Coverage. Das Wichtigste in Kürze - 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. Code Coverage misst Ausführung, nicht Prüfung Eine hohe Code Coverage beweist nur, dass Tests den Code durchlaufen. Ob sie dabei etwas prüfen, verrät die Kennzahl nicht. Ein Gedankenexperiment zeigt das: Ein System hat 100 Prozent Coverage, egal ob als Line oder Branch Coverage gemessen. Entfernt jemand nun sämtliche Assertions aus den Tests, bleibt die Coverage unverändert hoch. Die Tests selbst sind danach wertlos. Sichtbar wird das erst mit einer Kennzahl wie der Mutation Coverage. Die Coverage-Metrik ist deshalb grob. Teams können sich Coverage regelrecht ergaunern, indem sie Code nur anlaufen lassen, ohne ein Ergebnis zu prüfen. Genau diese Lücke schließt Mutation Testing: Es bewertet nicht, ob Tests Code ausführen, sondern ob sie Fehler im Code bemerken. Das Verfahren hinter der Mutation Coverage Mutation Testing ist ein Verfahren, das absichtlich kleine Fehler in den Produktionscode einbaut und prüft, ob die vorhandenen Tests diese Fehler finden. Es liefert damit eine aussagekräftigere Metrik für die Qualität einer Test-Suite als die klassische Code Coverage. Das Verfahren hat ursprünglich nichts mit künstlicher Intelligenz zu tun. Julius Mischok, der Mutation Testing im Java-Umfeld einsetzt, ordnet die Idee als alt und bewährt ein: Nach seiner Einschätzung existieren die Konzepte und Technologien seit bald 20 Jahren. Aktuell gewinnt Mutation Testing neue Relevanz, weil KI-Agenten immer mehr Tests schreiben. Wie ein Tool Mutationen erzeugt und bewertet Ein Mutation-Testing-Tool arbeitet in zwei Phasen. Zuerst analysiert es die bestehende Test-Suite, danach greift es in den Produktionscode ein. - Coverage erfassen: Das Tool führt alle Tests aus und ermittelt, welcher Produktionscode überhaupt abgedeckt ist. - Zuordnung merken: Es speichert, welcher Test welche Zeile im Produktionscode abdeckt. - Code mutieren: Das Tool verändert den Produktionscode gezielt. Aus einem „kleiner gleich“ macht es ein „kleiner“, oder es negiert die Bedingung in einem If. - Betroffene Tests ausführen: Nur die Tests, die die mutierte Zeile abdecken, laufen erneut. - Ergebnis bewerten: Schlägt ein Test fehl, gilt die Mutation als „gekillt“. Bleiben alle Tests grün, hat die Mutation „überlebt“. Der entscheidende Perspektivwechsel liegt im letzten Schritt. Ein grüner Test ist hier das schlechte Ergebnis. “Wenn diese Tests danach immer noch grün sind, ist es schlecht.” (Julius Mischok) Ein Test, der einen absichtlich eingebauten Fehler übersieht, schützt auch nicht vor echten Fehlern dieser Art. Der Fehlschlag ist das gewünschte Signal. Mutatoren bauen gezielt typische Programmierfehler ein Die einzelnen Veränderungen heißen Mutatoren. Julius spricht von einem „Baukasten der Grausamkeiten“, und einige Mutatoren gehen tatsächlich brachial vor. Die folgende Übersicht zeigt typische Beispiele: Mutator-Typ | Original | Mutation Grenzwert verschieben | > | >= Vergleich umdrehen | > | < Gleichheit negieren | == | != Bedingung negieren | if (x) | if (!x) Boolesche Werte flippen | true | false Rückgabe auf Standardwert | berechneter Wert | 0, false, leere Liste oder leeres Set Der Standardwert-Mutator tut so, als passiere in der Methode gar nichts. Findet kein Test diese Veränderung, prüft offenbar niemand das Ergebnis der Methode. Die Grenzwert-Mutatoren decken sich mit einem Klassiker der Testfallermittlung, der Grenzwertanalyse. Überlebt eine solche Mutation, fehlen meist Testdaten genau an der Grenze. Im Java-Framework PIT kannst du außerdem eigene Mutatoren einhängen, wenn das Standard-Set nicht ausreicht. Was misst die Mutation Coverage? Die Mutation Coverage ist der Anteil der gekillten Mutationen an allen möglichen Mutationen im Code. Kann das Tool mit der aktuellen Konfiguration beispielsweise 1000 Mutationen erzeugen, gibt die Mutation Coverage an, wie viele davon die Tests entdecken. Diese Metrik ist deutlich aussagekräftiger als reine Code Coverage, weil sie die Prüfkraft der Tests bewertet. Die Auswertungen der Tools zeigen konkret, wo Lücken liegen. Oft reichen kleine Ergänzungen: Zwei zusätzliche Testfälle oder Testdatensätze an den Grenzen eines Wertebereichs können auf einen Schlag zehn weitere Mutationen killen. Mutationsläufe gehören nicht in jeden Build Mutation Testing kostet viel Zeit. Das Tool wendet auf jede abgedeckte Codezeile potenziell drei bis sieben Mutatoren an. Für jede Mutation muss es den Code in einen ausführbaren Zustand bringen, die betroffenen Tests starten und deren Ende abwarten. In Java passiert die Mutation auf Bytecode-Ebene, was das Neukompilieren erspart, aber die Testläufe bleiben. In einfachen Fällen rechnet Julius mit zwei bis fünf Mutatoren pro Zeile oder Ausdruck. Bei einer großen Codebase summiert sich das schnell. Du solltest Mutation Testing deshalb selektiv einsetzen, etwa als geplanten Job jeden Dienstag in der Nacht oder zum Sprintende eines agilen Teams, um die Entwicklung der Mutation Coverage zu verfolgen. Den Aufwand kannst du über die Konfiguration steuern: - einzelne Mutatoren abschalten oder besonders wichtige gezielt hinzunehmen - nur bestimmte Test-Packages oder Produktions-Packages analysieren - nur schnelle, reine Unit-Tests einbeziehen Manche Teams im Spring-Boot-Umfeld beschränken Mutation Testing auf Tests, die nicht den kompletten Spring-Kontext hochfahren. Diese Läufe sind schnell genug für häufige Ausführung. Das Gesamtprojekt analysieren sie dann seltener. Welche Voraussetzungen braucht eine Test-Suite? Mutation Testing funktioniert nur mit einer sauberen, stabilen Test-Suite. Flaky Tests dürfen nicht vorkommen, und alle Tests müssen voneinander isoliert sein. Du musst Hunderte oder Tausende Tests in beliebiger Reihenfolge beliebig oft hintereinander ausführen können. Der Grund liegt im Ablauf: Das Tool setzt eine Mutation, startet drei Tests, setzt die nächste Mutation und startet völlig andere Tests. Sobald Abhängigkeiten zwischen Tests bestehen, liefert Mutation Testing keine verlässlichen Ergebnisse mehr. Hier entsteht in der Praxis der eigentliche Frust. Nicht die Ergebnisse enttäuschen, sondern die Erkenntnis, dass erst Wochen Aufräumarbeit nötig sind. Tests, Testdaten und Abhängigkeiten müssen auf Vordermann. Julius nennt das „das Tal der Tränen“. Der Aufwand lohnt sich trotzdem, weil genau diese Probleme sonst kurz vor dem Go-Live auftauchen. Teams, die von Anfang an testgetrieben entwickeln, erleben dagegen selten große Überraschungen. Wer Anforderungen zuerst als fehlschlagenden Test formuliert und erst dann implementiert, hat meist schon Tests mit echter Prüfkraft. Der Report ist Diskussionsgrundlage, keine Aufgabenliste Ein Mutation-Testing-Report lässt sich nicht so eindeutig lesen wie ein fehlgeschlagener Test. Manche Mutatoren erzeugen unsinnige Veränderungen, und manche Findings ergeben schlicht keinen Sinn. Solche Ergebnisse muss das Team bewusst aussortieren. Du solltest den Report deshalb nicht als Liste von 200 Punkten behandeln, die abgearbeitet werden. Er liefert Inspiration und einen Ansatz für die Diskussion im Team. Eine Mutation Coverage von 100 Prozent hält Julius für unrealistisch. Sinnvoller ist es, die Kennzahl über die Zeit zu beobachten und gezielt dort nachzuschärfen, wo überlebende Mutationen auf echte Lücken hinweisen. Agenten schreiben Tests, die Mutation Coverage prüft sie KI-Agenten erzeugen Unit-Tests in großer Menge, und diese Tests brauchen selbst eine Qualitätssicherung. Manchmal schreibt ein Agent in einem Kontext die Tests und in einem anderen die Implementierung. Ein Code Review bleibt Pflicht, niemand sollte ungesehenen Code einchecken. Ein gründliches Review jeder einzelnen Assertion ist in der Praxis aber kaum leistbar. Menschen lesen längere Texte nur kurze Zeit konzentriert, dann schweifen die Gedanken ab. Wenn Tests „wie von Geisterhand“ entstehen, braucht es ein automatisiertes Verfahren, das ihre Qualität bewertet. Mutation Testing übernimmt diese Rolle. Es findet nicht jeden Mangel, und dieser Illusion solltest du dich nicht hingeben. Es senkt aber das Risiko spürbar und ergänzt das Review um ein bewährtes Werkzeug, das objektiv misst, ob generierte Tests Fehler erkennen. PIT und Tools für andere Sprachen Mutation Testing ist nicht auf Java beschränkt. Für nahezu alle verbreiteten Programmiersprachen existieren Tools. Julius geht davon aus, dass es für alle Sprachen unter den 30 beliebtesten ein passendes Werkzeug gibt. Einen Überblick bietet das GitHub-Repository „Awesome Mutation Testing“. Im Java-Umfeld ist PIT das gängige Tool. Der Name hat ursprünglich nichts mit Mutation Testing zu tun: PIT steht für Parallel Isolated Testing und war als Ansatz gedacht, JUnit-Tests zu parallelisieren. Dabei zeigte sich, dass sich diese Parallelisierung hervorragend für Mutation Testing eignet. Den Namen behielten die Entwickler bei. Die Tools für andere Sprachen arbeiten nach demselben Prinzip. Wer das Vorgehen mit PIT verstanden hat, findet sich auch in anderen Ökosystemen zurecht. Häufig gestellte Fragen Warum sagt eine hohe Code Coverage wenig über die Qualität von Tests aus? Code Coverage misst nur, ob Tests den Code ausführen, nicht ob sie dabei etwas prüfen. Ein Gedankenexperiment zeigt das: Entfernt man aus einer Test-Suite mit 100 Prozent Line- oder Branch-Coverage sämtliche Assertions, bleibt die Kennzahl unverändert, obwohl die Tests danach wertlos sind. Coverage lässt sich so regelrecht ergaunern, indem Code nur angelaufen wird, ohne ein Ergebnis zu prüfen. Hat Mutation Testing etwas mit künstlicher Intelligenz zu tun? Ursprünglich nicht. Mutation Testing ist ein altes, bewährtes Verfahren, dessen Konzepte und Technologien nach Einschätzung von Julius Mischok bis in die zweite Hälfte der 2000er Jahre zurückreichen. Neue Relevanz bekommt es, weil KI-Agenten immer mehr Unit-Tests schreiben. Mutation Testing prüft dann, ob diese generierten Tests absichtlich eingebaute Fehler tatsächlich erkennen. Warum ist ein grüner Test beim Mutation Testing ein schlechtes Ergebnis? Ein grüner Test nach einer Mutation hat einen absichtlich eingebauten Fehler übersehen. Das Tool macht etwa aus einem „kleiner gleich“ ein „kleiner“ und führt nur die Tests aus, die diese Zeile abdecken. Schlägt einer fehl, gilt die Mutation als gekillt. Bleiben alle grün, hat sie überlebt, und die Tests schützen dann auch nicht vor echten Fehlern dieser Art. Welche Arten von Fehlern baut ein Mutation-Testing-Tool in den Code ein? Die Veränderungen heißen Mutatoren und bilden typische Programmierfehler nach: Grenzwerte verschieben, Vergleiche umdrehen, Gleichheit oder Bedingungen negieren, boolesche Werte flippen. Ein besonders brachialer Mutator ersetzt Rückgabewerte durch Standardwerte wie 0, false oder eine leere Liste. Findet kein Test diese Veränderung, prüft offenbar niemand das Ergebnis der Methode. Überlebende Grenzwert-Mutationen deuten auf fehlende Testdaten genau an der Grenze. Wie aufwendig ist Mutation Testing in großen Codebasen? Sehr aufwendig, denn das Tool wendet auf jede abgedeckte Codezeile potenziell drei bis sieben Mutatoren an und startet für jede Mutation die betroffenen Tests. Deshalb gehört es nicht in jeden Build, sondern etwa als geplanter Job in eine Nacht pro Woche oder ans Sprintende. Den Aufwand senkt, wer einzelne Mutatoren abschaltet, nur bestimmte Packages analysiert oder nur schnelle Unit-Tests einbezieht. Warum ist die Einführung von Mutation Testing in bestehenden Projekten oft mühsam? Mutation Testing verlangt eine stabile Test-Suite ohne Flaky Tests, deren Tests sich in beliebiger Reihenfolge beliebig oft ausführen lassen. Das Tool startet nach jeder Mutation andere Tests. Schon Abhängigkeiten zwischen Tests machen die Ergebnisse daher unzuverlässig. In der Praxis sind oft erst Wochen Aufräumarbeit an Tests und Testdaten nötig. Teams, die testgetrieben entwickeln, erleben dagegen selten große Überraschungen. Sollte man eine Mutation Coverage von 100 Prozent anstreben? Nein, 100 Prozent hält Julius Mischok für unrealistisch. Manche Mutatoren erzeugen unsinnige Veränderungen, und manche Findings ergeben schlicht keinen Sinn, weshalb das Team sie bewusst aussortieren muss. Der Report ist eher Diskussionsgrundlage als Aufgabenliste. Sinnvoller ist es, die Kennzahl über die Zeit zu beobachten und gezielt nachzuschärfen, oft genügen zwei zusätzliche Testfälle an einer Wertebereichsgrenze für zehn weitere gekillte Mutationen. Wie lässt sich die Qualität von Unit-Tests prüfen, die ein KI-Agent geschrieben hat? Ein Code Review bleibt Pflicht, reicht allein aber kaum aus, weil ein gründliches Lesen jeder einzelnen Assertion in der Praxis nicht leistbar ist. Mutation Testing ergänzt das Review, indem es objektiv misst, ob die generierten Tests eingebaute Fehler erkennen. Es findet nicht jeden Mangel, senkt aber das Risiko spürbar, etwa als wöchentlicher Lauf oder zum Sprintende. --- ### Erst die Testautomatisierungsstrategie, dann KI im Testen URL: https://www.richard-seidl.com/de/podcast/testautomatisierung-strategie-balance/ Datum: 2026-09-24 Kategorien: Software Testing Unleashed Ohne Testautomatisierungsstrategie erzeugt KI nur schneller fragwürdige Tests. Was sinnvoll ist, entscheidet der Kontext, nicht ein Gartner-Bericht. Eine gute Testautomatisierungsstrategie passt zum eigenen Kontext: zur Art der Organisation, zur Software, zu den Erwartungen der Kunden und zu den Wertströmen dahinter. Automatisierte Tests finden selten neue Fehler, sie bestätigen bekanntes Verhalten. Am besten dienen der Qualität zwei getrennte Rollen: ein Tester, der erkundet und kritisch hinterfragt, und ein Testautomatisierungsentwickler, der Anforderungen in wiederholbare Prüfungen übersetzt, denn beide Aufgaben verlangen ein anderes Denken. Das Wichtigste in Kürze - Tester und Testautomatisierungsentwickler sind zwei verschiedene Rollen: Tester untersuchen das Produkt kritisch und suchen Schwachstellen, Testautomatisierungsentwickler setzen Anforderungen in automatisierte Testfälle um. Wer beide Rollen vermischt, schwächt beide. - KI-generierte Tests setzen standardmäßig auf Menge statt Korrektheit. Sie liefern plausibel wirkende Testfälle mit erfundenen Szenarien, damit die Testabdeckung stimmt, nicht weil die Szenarien gültig sind. - Automatisierte Tests finden selten Fehler. Schlägt eine Pipeline fehl, sucht das Team die Schuld beim Test statt beim Code, und echte Fehler verstecken sich hinter grünen Dashboards. - Wer Junior-Tester und Junior-Entwickler durch KI ersetzt, nimmt den Lernweg weg, aus dem erfahrene Leute entstehen. Die Lücke lässt sich später nicht schließen, weil niemand nachwächst. - Das Management investiert in Testqualität, wenn das Argument über Produktionsstörungen und Kundenrisiken läuft, nicht über Abdeckungsmetriken, die es nicht versteht. Der Kontext entscheidet, wie du testest, nicht ein Gartner-Bericht Bevor KI ins Testen einzieht, braucht es eine Testautomatisierungsstrategie, und die hängt am Kontext: am Unternehmen, am Kunden, an der Software und an den Wertströmen dahinter. Eine einzige richtige Teststrategie, die sich von Firma zu Firma übertragen lässt, gibt es nicht. Was in einem Gaming-Studio funktioniert, scheitert bei einer Bank, und umgekehrt. Weltweit schieben Vorstände Budgets in Richtung KI und kürzen dafür an anderer Stelle, auch bei der Testautomatisierung. Michaël Pilaeten hält das für eine Schieflage. Wer alles in eine Richtung investiert, überspringt die Frage, die zuerst kommen müsste: Was bedeutet Qualität für dieses Produkt und für diese Kunden? Ein konkreter Vergleich macht das greifbar. Manche Kunden erwarten sehr hohe Verfügbarkeit, anderen ist Sicherheit am wichtigsten. Im Gaming vertreibt ein einziges stark fehlerhaftes Release Kunden, die nie wiederkommen. Im Banking zählt Funktionalität mehr als Feinschliff. Wer die Vielfalt im eigenen Kunden- und Produktportfolio nicht beschreiben kann, hat keine Grundlage für die Entscheidung, wie getestet wird. Warum 100 Prozent Testabdeckung bei altem Code Geld verbrennen kann Volle Testabdeckung ist nicht automatisch ein lohnendes Ziel. Michaël hat mit einem Unternehmen gearbeitet, das über sechs Millionen Zeilen Code betrieb, vieles davon alt, monolithisch und noch in COBOL. Der Code war stabil und machte im Betrieb keine Probleme. Der Auftrag lautete trotzdem: Unit-Tests bis 100 Prozent Abdeckung schreiben, damit der Code später in neuere Sprachen umgebaut werden kann. Die Rechnung ging nicht auf. Tests für sechs Millionen Zeilen sind ein gewaltiger Aufwand, auch wenn KI erste Entwürfe liefert, denn jemand muss jeden generierten Testfall prüfen und validieren. Dazu hätte jeder Commit eines Entwicklers zwei Stunden automatisierte Testläufe ausgelöst. Hoher Einsatz, wenig Nutzen. Die Lehre: Die Kosten der Abdeckung gehören neben das, was sie tatsächlich schützt. Stabiler Code ohne Produktionsstörungen verdient nicht dasselbe Testbudget wie wackliger Code mit hohem Risiko. Abdeckung ist ein Mittel, kein Ziel. Selbstheilende Tests können ihren eigenen Wert still zerstören Niemand mag eine rote Pipeline, und genau diese Abneigung verführt zu einer gefährlichen Abkürzung. Michaël beschreibt automatisierte Tests, die gut gebaut waren, bis ein selbstheilender Agent auf sie losgelassen wurde. Damit die Pipeline grün blieb, entfernte der Agent die Assertions aus validierten Testfällen. Die Tests liefen durch, weil sie nichts mehr prüften. Grüne Dashboards schaut niemand an. Tester verbringen ihre Tage mit Feuerlöschen, also bekommt ein Bereich ohne sichtbares Problem keine Aufmerksamkeit. Entfernt die Selbstheilung die fehlschlagende Assertion, statt den eigentlichen Fehler sichtbar zu machen, glaubt das Team, alles sei in Ordnung, während das Sicherheitsnetz längst Löcher hat. Spätestens hier klingt das Wort “Qualitätssicherung” hohl. Wenn Werkzeuge den Test reparieren dürfen statt den Code, sichert das Team gar nichts mehr. Das grüne Licht beruhigt nur noch, über Qualität sagt es nichts. Testen und Testautomatisierung sind zwei verschiedene Jobs Tester und Testautomatisierungsentwickler bringen unterschiedliche Fähigkeiten mit, und wer sie als austauschbar behandelt, schwächt beide. Der Testautomatisierungsentwickler übersetzt Anforderungen in automatisierte Testfälle. Der Tester schaut kritisch auf das Produkt, erkundet es, lernt aus dem, was es tut, und sucht die Stellen, an denen es nachgibt. Automatisierte Tests finden selten Fehler. Läuft ein automatisierter Test durch, freuen sich alle. Schlägt er fehl, prüfen die Leute den Test statt des Produkts. Ein menschlicher Tester arbeitet mit Erfahrung, gesundem Menschenverstand und der Gewohnheit, unbequeme Fragen zu stellen. Das bildet kein Werkzeug nach. Du kannst einen Tester zum Automatisieren ausbilden, verlierst dann aber seinen explorativen Instinkt. Du kannst einen Testautomatisierungsentwickler bitten zu testen, nur liegt dort nicht seine Stärke. In einem gesunden Team respektieren sich beide Rollen, reden klar miteinander und einigen sich, wo Risiken und Prioritäten liegen. Aspekt | Testautomatisierungsentwickler | Tester Kernaufgabe | Anforderungen in automatisierte Testfälle übersetzen | Das Produkt kritisch erkunden Stärke | Wiederholung, Abdeckung bekannter Pfade | Fehler finden, Fragen stellen Verhältnis zum Fehlschlag | Eine rote Pipeline meldet ein Problem, das behoben werden muss | Ein gefundener Fehler ist das Ziel der Arbeit Was verloren geht, wenn die Rolle gewechselt werden muss | Strukturiertes, kritisches Erkunden | Erfahrungsbasiertes Stochern im Produkt Automatisierung nach der Iteration verliert ihren Sinn Viele Teams, die sich agil nennen, schieben die Testautomatisierung ans Ende, hinter die Iteration, und dieser Zeitpunkt kostet sie ihren Wert. Der Product Owner will Features schnell in Produktion sehen. Automatisierung im Sprint wirkt wie eine Bremse, also wandert sie später zu einem eigenen Team. Bis dahin haben sich die Prioritäten verschoben, der ursprüngliche Kontext ist weg. Das nachgelagerte Automatisierungsteam greift sich, was leicht geht: stabile Locators, stabilen Code, Testfälle ohne Reibung. Risiko, Nutzen und Wiederholbarkeit spielen bei der Auswahl keine Rolle mehr, weil niemand die Arbeit auf das Wesentliche lenkt. Die Antwort heißt Automatisierung mit den richtigen Zielen zur richtigen Zeit, nicht einfach mehr davon. Automatisiere die wiederkehrenden, wertvollen und riskanten Pfade, bei denen es sich lohnt, denselben Test hundertmal über verschiedene Benutzerprofile und Vertragsarten laufen zu lassen. Diese Auswahl braucht jemanden, der die Risiken versteht, nicht nur die Werkzeuge. Qualität entsteht im ganzen Team, nicht beim einen Tester Gemeinsame Verantwortung für Qualität funktioniert besser, als sie bei einer Person abzuladen. Das Problem mit einem festen Tester im Team: Alle anderen können annehmen, Qualität sei erledigt, und kümmern sich nicht mehr darum. Michaël bevorzugt deshalb den Schritt von “Quality Assurance” zu Quality Engineering, bei dem das Team die Qualität gemeinsam trägt. Entwickler haben dabei einen echten Anteil. Testgetriebene, verhaltensgetriebene und akzeptanztestgetriebene Entwicklung passen alle in dieses Modell, mit Werkzeugen wie Gherkin, Cucumber, Robot Framework oder Reqnroll. Ein Junior-Entwickler, der manuelle Testfälle in automatisierte umsetzt, lernt nebenbei den Code, die Datenbankverbindungen und die Konfiguration kennen. Die natürlichen Antriebe unterscheiden sich, und das zählt. Entwickler bauen gern, Fehler beheben macht ihnen keinen Spaß. Tester machen gern Dinge kaputt. Einen Tester zum Schreiben automatisierter Testfälle zu zwingen, fühlt sich falsch an. Auch das spricht dafür, die Arbeit auf die Rollen zu verteilen, zu denen sie passt. KI liefert schlechte Qualität schneller Tempo ohne Kontrolle ist das Kernrisiko beim KI-gestützten Testen. Michaël sieht jede Menge instabile Tests, die KI erzeugt hat. Instabile Tests an sich sind nichts Neues, ob von Menschen oder Maschinen. Das tiefere Problem ist Qualität, die plausibel und cool aussieht, bis man genauer hinschaut und merkt, dass sie nur zu etwa neunzig Prozent stimmt. Ein menschlicher Tester erfindet keinen falschen Testfall, nur um volle Abdeckung zu erreichen. KI tut genau das, weil du 100 Prozent verlangt hast und sie eine Zahl liefert. Große Sprachmodelle erzeugen die wahrscheinlichste Folge von Tokens. Sie haben kein logisches Denken, keine Meinung, keine Begründung. Es sind Sprachmodelle, und wer sie als Programmier- oder Automatisierungsmaschinen behandelt, holt sich Ärger ins Haus. Die durchgängig verkettete Variante nennt Michaël “DevOps-Durchfall”: Ein Agent macht aus einer Kundenanfrage eine User Story, der nächste schreibt die Akzeptanzkriterien, der nächste den Code, der nächste die Unit-Tests, der nächste die Systemtests, der letzte die Release Notes. Das geht schnell, und die Qualität ist schlecht. Für manche Unternehmen ist das in Ordnung, wenn sich ein gemeldeter Fehler in drei Minuten beheben lässt. Für die meisten nicht. “KI liegt zu 90 Prozent richtig, zu 91 Prozent, aber wenn ich als Tester Testfälle schreibe, erfinde ich keinen falschen Testfall, nur um auf 100 Prozent Abdeckung zu kommen. Genau das macht KI.” (Michaël Pilaeten) Die Junior-Lücke: Wer wird der nächste Senior? Ersetzt KI die Einstiegsarbeit, fällt der Weg weg, auf dem erfahrene Leute entstehen. Fremden Code oder fremde Testfälle zu reviewen ist mühsam, nach etwa einer Stunde lässt die Konzentration nach. Also landet das Review bei den Erfahrenen, den Juniors traut man es nicht zu. Damit entsteht eine Lücke. Juniors haben früher an genau der Arbeit gelernt, die heute KI erzeugt. Wird eine ganze Generation von Junior-Testern, Entwicklern und Analysten durch KI ersetzt und bleiben nur die Erfahrenen übrig, um die Ergebnisse der Maschine zu prüfen, versiegt der Nachschub an neuen Erfahrenen. Den Menschen im Prozess zu halten, ist keine Nostalgie. So entstehen Fähigkeiten, und so bleibt Qualität eine Frage menschlichen Urteils statt eines Wahrscheinlichkeitsmodells. Erst die Testautomatisierungsstrategie, dann die KI KI verstärkt jeden Prozess, auf dem sie läuft, und ein schwaches Fundament liefert deshalb schneller schwache Ergebnisse. Testautomatisierung ohne KI hat schon Probleme, wenn Prozesse, Strategie und Kontext unklar sind. Kippst du dieses Durcheinander in die KI, lieferst du dieselben Probleme nur schneller aus. Nur weil du Testfälle schneller erzeugen kannst, musst du es nicht tun. Eine stabile Codebasis und ein Prozess, der Automatisierung wirklich trägt, kommen zuerst. Die deutsche Autobahn zeigt es: An manchen Stellen darfst du so schnell fahren, wie du willst, ob du es solltest, entscheiden die Bedingungen. Also tritt einen Schritt zurück, bevor du skalierst. Finde heraus, wo sich deine Teststufen überschneiden, nutze etwa SonarQube, um zu sehen, welche Funktionen getestet sind und welche nicht, entscheide, was du nach links verschiebst, und schreib eine echte Automatisierungsrichtlinie und Strategie. Erst dann frag, wo KI die Effizienz steigern kann. Der Panikkauf von Lizenzen läuft genau andersherum, und Michaël warnt: Der kostenlose oder fast kostenlose Zugang schafft schon jetzt Abhängigkeit, bevor die Rechnung für die Tokens kommt. Wie ein einzelner Tester den Schritt zurück anstoßen kann Wie du vorgehst, hängt davon ab, wen du überzeugen willst: Kollegen oder das Management. In der Fach-Community teilst du Misserfolge genauso wie Erfolge. Sag einfach: “Wir haben das mal anders gemacht, es lief schneller und sauberer, vielleicht gefällt es euch auch.” So werden Kollegen zu Botschaftern. Das Hindernis: Viele in der IT sind introvertiert, prahlen nicht gern und teilen ungern Erfahrungen. Ein lockerer Rahmen hilft, eher ein Kamingespräch als ein formeller Bericht. Für einen Manager brauchst du eine andere Sprache. Manager verstehen meist wenig vom Testen und haben Qualität selten auf dem Schirm. Sie denken in Umfang, Kosten und Zeit. Berichte zu Code- oder Anforderungsabdeckung sagen ihnen nichts. Sprich stattdessen über Risiko und Kundennutzen. Stell eine Initiative so dar, dass Features schneller und mit weniger Produktionsstörungen beim Kunden ankommen, denn Störungen musste jeder Manager schon einmal ausbaden. Wer über Fehler und Testfälle redet, geht im Rauschen unter. Wer über Geschäftsrisiken redet, wird gehört. Häufig gestellte Fragen Warum scheitert eine Teststrategie, die in einem Unternehmen funktioniert, in einem anderen? Der Kontext entscheidet: die Organisation, der Kunde, die Software und die dahinterliegenden Wertströme. Ein Gaming-Studio hat andere Erwartungen als eine Bank. Eine völlig fehlerhafte Spielveröffentlichung kostet Spieler, die nie wieder zurückkommen, während im Bankwesen Funktionalität wichtiger ist als Perfektion. Manche Kunden erwarten eine sehr hohe Verfügbarkeit, andere legen größten Wert auf Sicherheit. Ohne ein klares Bild von deinem Produkt- und Kundenportfolio haben Testentscheidungen keine Grundlage. Lohnt es sich, Unit-Tests mit voller Überdeckung für alten, stabilen Code zu schreiben? Oftmals nicht. In einem Unternehmen mit mehr als sechs Millionen Codezeilen, größtenteils monolithisches COBOL, war der Code stabil und verursachte keine Probleme im Produktivbetrieb, dennoch lautete die Vorgabe 100 % Unit-Überdeckung vor einer späteren Refaktorisierung. Selbst wenn KI Tests entwirft, muss jemand jeden Fall überprüfen, und jeder Commit würde dann zwei Stunden Testläufe auslösen. Überdeckung ist ein Mittel, kein Ziel. Kann eine „grüne“ Testpipeline echte Fehlerzustände verbergen? Ja. Ein selbstheilender Agent hielt eine Pipeline „grün“, indem er die Assertions aus validierten Testfällen entfernte, sodass die Tests bestanden wurden, weil sie gar nichts mehr überprüften. Grüne Dashboards werden ignoriert, da Tester ihre Tage damit verbringen, sichtbare Brände zu löschen. Wenn Tools den Test statt des Codes korrigieren dürfen, entstehen still und leise Löcher im Sicherheitsnetz. Sollte dieselbe Person sowohl den explorativen Test als auch die Testautomatisierung übernehmen? Besser nicht. Ein Testautomatisierungsentwickler setzt Anforderungen in wiederholbare Testfälle um; ein Tester erkundet das Produkt, stellt unbequeme Fragen und versucht, Schwachstellen aufzudecken. Automatisierte Tests bestätigen bekanntes Verhalten und finden selten neue Fehler, und wenn einer fehlschlägt, prüfen die Leute den Test statt des Produkts. Wenn du einen Tester in der Testautomatisierung schulst, verlierst du den explorativen Instinkt, der ihn wertvoll gemacht hat. Was passiert, wenn die Testautomatisierung erst nach der Iteration in Angriff genommen wird? Sie verliert ihren Sinn. Bis ein separates Team die Arbeit übernimmt, haben sich die Prioritäten verschoben und der ursprüngliche Kontext ist verloren gegangen. Dieses Team neigt dazu, sich das zu schnappen, was einfach ist: stabile Locators, stabiler Code, reibungslose Testfälle. Risiko, Chancen und Wiederholbarkeit fallen bei der Entscheidung weg. Die Automatisierung macht sich gerade bei sich wiederholenden, risikoreichen Abläufen bezahlt, wie zum Beispiel dem gleichen Test über viele Benutzerprofile und Vertragsarten hinweg. Wie zuverlässig sind KI-generierte Testfälle? Sie sehen plausibel und cool aus, bis man genauer hinschaut und feststellt, dass sie nur zu etwa neunzig Prozent richtig sind. Wird eine 100-prozentige Überdeckung gefordert, erfindet ein Modell Szenarien, um diese Zahl zu erreichen; ein menschlicher Tester würde keinen falschen Testfall schreiben, nur um ein Ziel zu erreichen. Große Sprachmodelle erzeugen die wahrscheinlichste Token-Sequenz, ohne Logik und ohne Begründung, und das Ergebnis sind unzuverlässige Tests und schnell ausgelieferte, minderwertige Qualität. Was sind die langfristigen Kosten, wenn man Nachwuchstester und -entwickler durch KI ersetzt? Der Lernweg verschwindet. Früher sammelten Nachwuchskräfte Erfahrung, indem sie genau die Arbeit erledigten, die jetzt die KI übernimmt, zum Beispiel manuelle Testfälle in automatisierte umzuwandeln und sich mit dem Code, den Datenbankverbindungen und der Konfiguration vertraut zu machen. Die Überprüfung der Ergebnisse anderer ist mühsam und die Konzentration lässt nach etwa einer Stunde nach, sodass diese Aufgabe bei den erfahrenen Mitarbeitern landet. Da keine Nachwuchskräfte mehr diese Arbeit erledigen, wachsen keine neuen erfahrenen Mitarbeiter heran. Wie überzeugst du das Management, in Qualität zu investieren? Sprich von Risiken und Kundennutzen. Manager denken in Umfang, Kosten und Zeitplan, und Berichte über Codeabdeckung oder Anforderungsabdeckung sagen ihnen nichts. Stelle die Initiative so dar, dass Funktionen schneller und mit weniger Produktionsstörungen an Kunden ausgeliefert werden, denn Störungen sind etwas, das sie ohnehin schon beseitigen mussten. Wenn du über Fehler und Testfälle sprichst, gehst du im Rauschen unter. --- ### Wie man Regeln und Skills baut, damit Agenten sich erinnern URL: https://www.richard-seidl.com/de/podcast/feedbackschleifen-coding-agenten/ Datum: 2026-09-22 Kategorien: Podcast Software Testing Mit Coding Agents arbeiten Entwickler am System statt im System und brauchen weniger Reviews. Hooks, Regeln und Retro-Skills verankern Korrekturen. Agentische Softwareentwicklung bezeichnet einen Ansatz, bei dem Coding Agents Code schreiben, testen und reviewen, während Menschen am System arbeiten statt im System. Qualität entsteht durch deterministisch ausgelöste Feedback-Schleifen: Git-Hooks, Pipeline-Tests, Accessibility-Checks und Architektur-Reviews laufen automatisch während der Agent arbeitet und korrigieren ihn sofort. Das Wichtigste in Kürze - 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. Am System arbeiten statt im System: Wie sich die Rolle des Entwicklers verschiebt Wer Software mit KI-Agenten baut, arbeitet nicht mehr am einzelnen Code-Stück, sondern am System, das den Code erzeugt. Benedikt Stemmildt beschreibt diese Verschiebung als Kern seiner Arbeitsweise. Statt selbst zu implementieren und danach zu reviewen, beobachtet er, wo der Agent immer wieder in die falsche Richtung läuft, und greift auf der Ebene der Regeln ein. Das Bild dahinter ist ein neuer Junior-Kollege im Pair Programming. Man merkt, dass er keine Hotkeys nutzt oder ein wichtiges Architekturpattern ignoriert, und gibt ihm den Hinweis. Ein Mensch merkt sich das. Ein Agent nicht: Er hat kein Gedächtnis, das die Korrektur automatisch behält. Deshalb muss die Korrektur ins System wandern, nicht nur ins Gespräch. Wer bemerkt, dass der Agent ein dokumentiertes Architekturpattern übergeht, hinterlegt es als Regel im Regelset. Aus einer einmaligen Bemerkung wird eine dauerhafte Leitplanke. Dieses Anlernen ist projekt- und aufgabenspezifisch und lässt sich zwischen Projekten kaum wiederverwenden, ähnlich wie man jeden neuen Mitarbeiter neu einarbeiten muss. Und dann baut man eher am System, als irgendwie im System zu sein. Ich mache auch gar keine Reviews. Man ist nicht mehr der, der Reviews macht, sondern man arbeitet am System. (Benedikt Stemmildt) Supervised oder unsupervised: die erste Weiche für Qualität Bevor man über Testen und Qualität redet, muss geklärt sein, ob der Code supervised oder unsupervised entsteht. Diese Unterscheidung geht in vielen KI-Debatten unter, prägt aber jede weitere Entscheidung über Feedback und Absicherung. Supervised heißt: Der Entwickler schaut mit, verfolgt die laufenden Terminals und greift ein, wenn etwas in die falsche Richtung kippt. Unsupervised heißt: Der Code entsteht ohne menschlichen Blick, vergleichbar mit einer Deployment-Pipeline, in der niemand daneben sitzt. Im supervised-Modus kann man dem Agenten folgen und aus dem Beobachteten ableiten, was er systematisch falsch macht. Genau dort setzen die Regeln an. Je weiter man Richtung unsupervised geht, desto stärker müssen die Feedbackschleifen deterministisch abgesichert sein, weil kein Mensch mehr eingreift. Wie die klassischen Qualitätsmechanismen erhalten bleiben Der Bau mit Agenten unterscheidet sich weniger von klassischer Entwicklung als oft angenommen. Die Mechanismen, die Fehler auf verschiedenen Ebenen verhindern, bleiben dieselben: Git-Hooks, Linter, Terraform-Plans beim Push, Tests in der Pipeline, Smoke-Tests auf einer Development-Umgebung vor dem Produktions-Deployment. Diese Baseline sollte man ohnehin haben, unabhängig von KI. Benedikt beobachtet, dass sie in vielen Projekten fehlt. Wer sie noch nicht hat, kann Agenten nutzen, um sie aufzubauen, muss dann aber genau hinsehen, dass Hooks und Pipeline sauber sind. Hier gilt kein YOLO-Modus. Der Unterschied liegt im Tempo. Wenn eine Pipeline schlecht läuft oder Fehler fünfmal durchrutschen, merkt man das nicht nach fünf Wochen, sondern nach dreißig Minuten. Die Verbesserung der Pipeline funktioniert wie bei jedem Team, nur auf Steroiden. Tests entstehen am lebenden Objekt, nicht aus dem Spec Die Tests schreibt der Agent, nicht der Entwickler. Woher die Testbasis kommt, hängt vom Vorgehen ab. Viele setzen auf spec-driven Development, bei dem Akzeptanzkriterien vorab definiert werden und die Tests darauf aufbauen. Benedikt bevorzugt einen anderen Weg. Er erhebt Requirements am lebenden Objekt, also an der genutzten Software mit echten Endkunden. Deren Feedback wird zur neuen Requirement: Ein Bug muss gefixt werden, ein gewünschtes Verhalten kommt dazu. Aus diesem Feedback lassen sich auch die Tests verbessern. Observability-Daten, Klickverhalten und echte Interviews zeigen Pfade, die in den End-to-End-Tests noch fehlen. Ein Klickpfad, den Kunden immer wieder gehen, gehört abgebildet, weil er offenbar wichtig ist. Die Testpyramide gilt auch für Coding Agents Ein guter Agent arbeitet nach der Testpyramide, weil er die Arbeitsweise und das Erfahrungswissen des Entwicklers spiegelt. Prinzipien und Patterns aus Jahren der Softwareentwicklung übertragen sich auf den Agenten, sofern man sie ihm mitgibt. Sich selbst überlassen tendieren Agenten dazu, jedes Feature manuell zu testen: Sie öffnen einen Browser, machen einen Screenshot, analysieren ihn visuell und klicken sich durch. Das ist langsam und teuer. Wer jedes Feature so testet, verschenkt genau den Vorteil der Pyramide. Die einzelnen Ebenen erfüllen unterschiedliche Zwecke: Testebene | Zweck im Agenten-Kontext Unit-Tests | Erzwingen eine gut testbare Struktur und Architektur; warnen bei ungewollten Änderungen am Produktionscode Integrationstests | Sichern ab, dass Umsysteme nicht kaputtgehen Contract-Tests | Verhindern Breaking Changes an Schnittstellen, indem der Producer wie ein Consumer geprüft wird End-to-End-Tests | Bilden echte Nutzungspfade ab, sparsam eingesetzt Unit-Tests schreibt Benedikt bewusst zuerst, damit die Architektur des echten Codes testbar wird. Ändert der Agent später am Produktionscode, weist ihn ein rot werdender Test darauf hin, dass er womöglich eine Stelle anfasst, die er gar nicht anfassen wollte. Contract-Tests fangen einen typischen Agenten-Fehler ab. Ein Agent doktert schnell an seiner Schnittstelle herum und baut dabei Breaking Changes ein. Ein separater Test von außen, ausgeführt durch einen anderen Agenten, gibt den Hinweis, dass der Consumer kaputtgeht, bevor der Schaden entsteht. Warum nicht-funktionale Anforderungen unterschiedlich behandelt werden müssen Performance, Security und Accessibility verlangen unterschiedliche Modi. Nicht jedes Qualitätskriterium lässt sich gleich behandeln, und die Trennung zwischen supervised und unsupervised entscheidet mit. Performance funktioniert unsupervised sehr gut, weil sich harte Ziele vorgeben lassen. Man definiert Performance-Budgets pro Endpunkt und lässt den Agenten den Code so optimieren, dass er sie einhält. Ein Performance-Test in der Pipeline prüft, dass die Budgets nicht reißen. Grenzen bleiben: Mengengerüste in der Datenbank sind testbar, eine DDoS-Attacke prüft keine normale Pipeline. Security lässt sich schlechter automatisieren und gehört in den supervised-Modus. Ein regelmäßiges Security-Audit, täglich oder wöchentlich, deckt gemeinsam mit dem Agenten Angriffsvektoren und Threats auf. Licensing, Package-Dependency-Updates und Accessibility dagegen laufen als normale Pipeline-Bestandteile, letztere etwa über ein Tool wie Axe. Feedback auf der richtigen Ebene ist die Kernfrage Qualität mit Agenten entsteht dort, wo an vielen Stellen das richtige Feedback verfügbar ist. Ein Mensch bekommt beim Schreiben permanent inneres Feedback: Das ist nicht accessible, das ist nicht performant. Der Agent hat diesen inneren Dialog nicht. Deshalb wandern diese Prüfungen nicht nur in die Pipeline, sondern über Hooks direkt in die Arbeit des Agenten. Ändert der Agent eine Frontend-Komponente, feuert ein Hook den Accessibility-Test schon während der Arbeit. Der Agent bekommt sofort den Hinweis, dass er Accessibility vergessen hat, und arbeitet nach, bevor überhaupt gepusht wird. Zwei Arten von Hooks greifen ineinander. Der Git-Hook feuert beim Commit. Der Hook im Agenten-Harness feuert bei anderen Events, etwa wenn ein Tool ausgeführt oder eine Datei gelesen wird. Ein Hook auf das Event “Implementierung fertig” kann den Agenten anweisen, den Code dreimal zu vereinfachen, bevor er weitermachen darf. Deterministisch oder nicht: beide Wege haben Wert Die Wahl zwischen deterministischem und nicht-deterministischem Feedback ist eine Skala, kein Entweder-oder. Hooks sind deterministisch, weil ein Event Code auslöst. Regeln und Skills sind weicher und nicht-deterministisch. Ein Beispiel macht den Unterschied greifbar. Ob die Architektur einem Domain-Driven-Design-Prinzip folgt, kann ein ArchUnit-Test deterministisch prüfen oder ein Skill nicht-deterministisch bewerten. Der Test übersieht möglicherweise etwas außerhalb seines Szenarios. Das Modell bewertet möglicherweise falsch. Oft ist beides zusammen die beste Lösung. Der Nicht-Determinismus wird dabei unterschätzt. Er hat Wert bei der Recoverability. Ein roter Test ist deterministisch einfach rot. Ein Modell fragt zurück: Ist der Test rot, weil etwas kaputt ist, weil der Test schlecht ist, oder weil er flaky ist? Aus dieser Bewertung kann die Erkenntnis folgen, dass man die flaky Tests grundsätzlich fixen sollte. Man nutzt beide Modi dort, wo sie helfen. Architektur bleibt sauber durch Tracking und regelmäßiges Review Gute Architektur entsteht mit Agenten wie ohne sie: durch dokumentierte Entscheidungen und regelmäßiges Review. Agenten können Architekturentscheidungen mitdokumentieren und eine arc42-Dokumentation aktuell halten. Für Menschen wirkt das mitunter überflüssig, für Agenten dient es als eigenes Referenzwissen über Schnittstellen und Strukturen. Der zweite Baustein ist ein geplantes Review. Über Schedules lässt sich festlegen, dass der Agent einmal täglich eine Aktion ausführt, so wie ein Team einmal die Woche auf seine Architektur schaut. Ein Architektur-Review-Skill bewertet dann, ob die Entwicklung den Prinzipien folgt. Ein konkreter Fall zeigt das Muster. In einem großen Frontend wuchs eine globale CSS-Datei Richtung Monolith. Bei rund viertausend Zeilen bemerkte der Agent im Review, dass das nicht mehr trägt, schlug Modularisierung vor, lagerte Komponenten aus und machte jede Komponente selbstversorgend. Die nächste Iteration deckt vermutlich die nächste zu harte Kopplung auf. Diese Schedules entstehen nicht von selbst. Der Entwickler richtet sie in der supervised-Phase ein, während er den Agenten an die Hand nimmt. Eine wiederkehrende Anweisung lautet, in die letzten Unterhaltungen zu schauen, die eigenen Korrekturen zu sammeln und daraus Regeln, Skills und Schedules abzuleiten, damit der Agent sich künftig daran hält. Retrospektiven auf Steroiden Kontinuierliche Verbesserung wird mit Agenten zur täglichen Routine. Statt einmal im Monat eine Retrospektive zu halten, läuft sie mehrmals täglich und in Sekunden. Benedikt baut als eine der ersten Maßnahmen einen Skill ein, der selbst eine Retro durchführt. Dieser Skill schaut auf alte Sessions, sucht nach Dingen, die häufig schiefgelaufen sind und nachkorrigiert werden mussten, und aktualisiert die eigenen Regeln. Ob das dauerhaft trägt, ist offen. Denkbar ist, dass man Wissen, das im Modell ohnehin steckt, nur noch einmal in Regeln dupliziert. Der Wert liegt trotzdem im Experimentieren am System. Diese Rolle ist für viele Entwickler ungewohnt. Über Jahre steckten sie tief im System und bauten für andere, ohne Zeit, am System zu arbeiten. Es fehlen sogar die Kriterien dafür, was “am System arbeiten” heißt und wie man Qualitätsziele wie Sicherheit messbar macht. Wie sicher genau? Diese Frage bleibt oft unbeantwortet, weil man selten die Distanz zum System hatte. Warum zwei Modelle gegeneinander die Qualität heben Ein Review durch ein zweites Modell fängt Schwächen des ersten ab. Benedikt lässt Code, den Claude entwickelt hat, durch Codex reviewen und nutzt die unterschiedlichen Charaktere der Modelle gezielt. Claude verhält sich wie ein Full-Stack-Entwickler, der pragmatisch einen Weg zur Implementierung findet, Hauptsache der Business Value steht. Codex schaut stärker in die Details und hält sich strikter an die Regeln. Diese Strenge hilft beim Review, kann aber blockieren, wenn eine Implementierung Flexibilität braucht, weil Codex Regeln zu wörtlich nimmt. Das Zusammenspiel funktioniert wie zwischen zwei Kollegen. Codex liefert die Fehlerliste, Claude arbeitet einen Teil davon nach und begründet, warum manches nicht umsetzbar ist. Viele nutzen Agenten konsequent wie Mitarbeiter, inklusive Probezeit: Funktioniert die Konfiguration nicht, wird der Agent verworfen und neu aufgesetzt. Model-Hopping ist ab einem gewissen Niveau überflüssig Man muss nicht jedem neuen Modell hinterherlaufen. Benedikt hält es nicht für nötig, mit jedem Release das Modell zu wechseln. Ab dem Niveau von Opus 4.5 sind die verfügbaren Modelle mehr als gut genug für die anstehende Arbeit, nachprüfbar in den Benchmarks. Was danach zu entscheiden bleibt, sind andere Fragen: Kostenoptimierung, ob eine Subscription genutzt werden darf, und Souveränität. Open-Weights-Modelle oder lokale Modelle über vLLM sind bei DSGVO-Fragen relevant, verlangen aber Tiefe. Ein reines Terminal mit Chat und Inference-Endpoint bietet keine Features und funktioniert erst nach viel Konfiguration so, wie man es will. Für den Einstieg in Firmen bleiben Codex und Claude Code praktikabel, weil die User Experience einer fertigen Desktop-App den Umstieg erleichtert. Souveräne Setups sind mächtig, aber selten der einfachste erste Schritt. Wann noch von Hand geschrieben wird Manuellen Code schreibt Benedikt nur noch an den äußersten Am-System-Fällen. Architekturregeln und ähnliche Vorgaben formuliert er selbst, weil es sonst mehr Aufwand wäre, generierte Fassungen zu reviewen und auf das Gewünschte einzudampfen. Manchmal betrifft das auch Hooks, in die er genau hineinschaut und die er manuell korrigiert. Das ist weit weg von der eigentlichen Software, die am Ende genutzt wird. Am Produktcode selbst schreibt er nicht mehr von Hand. Eine offene Frage bleibt, ob das Formulieren von Regeln in Englisch überhaupt noch als Programmieren zählt. Die Arbeit verschiebt sich von der Zeile zum System, von der Implementierung zur Steuerung der Feedbackschleifen. Häufig gestellte Fragen Braucht agentisch entwickelter Code eine andere Qualitätssicherung als handgeschriebener? Die Mechanismen bleiben dieselben: Git-Hooks, Linter, Terraform-Plans beim Push, Tests in der Pipeline, Smoke-Tests auf einer Development-Umgebung vor dem Produktions-Deployment. Diese Baseline sollte ohnehin stehen, fehlt aber in vielen Projekten. Der Unterschied liegt im Tempo. Läuft eine Pipeline schlecht oder rutschen Fehler mehrfach durch, zeigt sich das nach dreißig Minuten statt nach fünf Wochen. Warum reicht es nicht, einen KI-Agenten im Gespräch zu korrigieren? Ein Agent hat kein Gedächtnis, das die Korrektur automatisch behält. Ein menschlicher Junior merkt sich den Hinweis, der Agent nicht. Deshalb gehört die Korrektur ins Regelset: Wer bemerkt, dass ein dokumentiertes Architekturpattern übergangen wird, hinterlegt es als Regel. Dieses Anlernen ist projekt- und aufgabenspezifisch und lässt sich zwischen Projekten kaum wiederverwenden. Woher kommen Testfälle, wenn man nicht spec-driven arbeitet? Anforderungen lassen sich am lebenden Objekt erheben, also an der genutzten Software mit echten Endkunden. Deren Feedback wird zur neuen Requirement: ein Bug, der gefixt werden muss, ein gewünschtes Verhalten, das dazukommt. Observability-Daten, Klickverhalten und Interviews zeigen Pfade, die in den End-to-End-Tests fehlen. Ein Klickpfad, den Kunden immer wieder gehen, gehört abgebildet. Wie testen Agenten, wenn man ihnen keine Vorgaben zur Teststrategie macht? Sich selbst überlassen testen Agenten gern manuell: Browser öffnen, Screenshot machen, visuell analysieren, durchklicken. Das ist langsam und teuer und verschenkt den Vorteil der Testpyramide. Gibt man ihm Prinzipien und Patterns mit, spiegelt der Agent die Arbeitsweise des Entwicklers. Unit-Tests zuerst erzwingen eine testbare Architektur und warnen, wenn er ungewollt Produktionscode anfasst. Lassen sich nicht-funktionale Anforderungen wie Security automatisiert absichern? Nur teilweise. Security ist schlechter automatisierbar und gehört in den supervised-Modus, etwa als tägliches oder wöchentliches Audit, das gemeinsam mit dem Agenten Angriffsvektoren und Threats aufdeckt. Performance funktioniert unsupervised gut, weil sich Budgets pro Endpunkt vorgeben und in der Pipeline prüfen lassen. Licensing, Dependency-Updates und Accessibility laufen als normale Pipeline-Bestandteile. Wie verhindert man, dass die Architektur bei agentischer Entwicklung erodiert? Durch dokumentierte Entscheidungen und regelmäßiges Review, genau wie ohne Agenten. Eine arc42-Dokumentation, die der Agent aktuell hält, dient ihm selbst als Referenzwissen über Schnittstellen und Strukturen. Dazu kommt ein geplantes Review per Schedule, bewertet durch einen Architektur-Review-Skill. In einem großen Frontend fiel so bei rund viertausend Zeilen globaler CSS auf, dass modularisiert werden musste. Muss man bei jedem neuen Modell-Release das Modell wechseln? Nein. Ab dem Niveau von Opus 4.5 sind die verfügbaren Modelle für die anstehende Arbeit mehr als gut genug, nachprüfbar in den Benchmarks. Zu entscheiden bleiben andere Fragen: Kostenoptimierung, ob eine Subscription genutzt werden darf, und Souveränität. Open-Weights- oder lokale Modelle über vLLM sind bei DSGVO-Fragen relevant, verlangen aber viel Konfiguration. --- ### Agentische Systeme im Testen: Warum der Mensch entscheidet URL: https://www.richard-seidl.com/de/podcast/agentische-ki-testpipeline/ Datum: 2026-09-17 Kategorien: Software Testing Unleashed Agentische Systeme mit acht bis zwölf KI-Agenten decken das Testen von der Anforderung bis zum Performance-Test ab. Menschen prüfen jede Übergabe. Ein agentisches System ist ein Netzwerk aus KI-Agenten, die sich selbstständig gegenseitig steuern, um ein Ziel zu erreichen, ohne dass Menschen einzelne Aufgaben verteilen. Anders als ein einzelner Agent, der auf Zuruf eine Aufgabe erledigt, übernimmt ein agentisches System den ganzen Testablauf: Review der Anforderungen, Erstellung von Testfällen, Abgleich der Überdeckung, Automatisierung und Performancetests, verteilt auf acht bis zwölf spezialisierte Agenten. Menschen greifen nur ein, um zu beurteilen und zu übersteuern. Das Wichtigste in Kürze - Ein agentisches System ist keine Sammlung einzelner Agenten, denen Menschen Aufgaben geben, sondern ein zielorientiertes Ökosystem, in dem Agenten andere Agenten selbstständig steuern. - Acht bis zwölf spezialisierte Agenten können den gesamten Testprozess abdecken, vom Review der Anforderungen über die Erstellung von Testfällen bis zu Automatisierung und Performancetests. - KI kann Geschäftsregeln nicht so anwenden und Überdeckung nicht so beurteilen wie Menschen; menschliche Kontrolle ist deshalb keine Option, sondern an festgelegten Prüfpunkten fester Teil des agentischen Systems. - Funktionale Testfälle lassen sich nicht direkt für Performancetests wiederverwenden, weil der Umfang grundverschieden ist: Funktionstests bedienen eine Oberfläche wie ein Mensch, Performancetests betrachten den Datenaustausch des Systems unter Last. - Wo strenger Datenschutz gilt, etwa in der Schweiz, fallen Cloud-Tools wie ChatGPT, Claude und Gemini weg, und Teams müssen Modelle wie Mistral oder DeepSeek, etwa über Ollama, lokal auf Servern mit GPU-Leistung betreiben. Agentische Systeme sind mehr als ein paar Agenten Agentische Systeme zeichnen sich dadurch aus, dass Agenten andere Agenten selbstständig steuern, ohne dass ein Mensch jede Aufgabe einzeln verteilt. Die Unterscheidung ist wichtig, denn viele Teams sprechen von einem agentischen System, obwohl sie eigentlich nur eine Handvoll Agenten betreiben, die isolierte Aufgaben erledigen. Nishan Portoyan zieht hier eine klare Linie. Ein einzelner Agent nimmt eine Eingabe entgegen und liefert eine Ausgabe. Dann wartet er auf die nächste Anweisung. Ein agentisches System läuft als ganzes Ökosystem: zielorientiert statt aufgabenorientiert, mit Agenten, die sich Arbeit gegenseitig übergeben und entscheiden, was als Nächstes passiert. Wenn immer noch ein Mensch jeden Schritt entscheidet und jede Aktion anstößt, dann arbeiten da Agenten. Ein agentisches System ist das nicht. Warum der Mensch im Kreislauf bleibt Das ursprüngliche Versprechen hat sich nicht erfüllt: ein KI-System, das alles regelt, während die Menschen sich zurücklehnen und zuschauen. In der Praxis funktioniert dieses Modell nicht. Die mechanische Arbeit erledigt die KI gut. An bestimmten Stellen braucht es aber weiterhin einen Menschen, der entscheidet. Der Mensch im Kreislauf ist also kein Notnagel, er gehört zum Design. Festlegen musst du, wo der Mensch sitzt und ob er die Entscheidung der KI überstimmen kann. Der Grund ist einfach. Eine KI versteht keine Geschäftsregeln. Nishan sagt es ganz offen: Diese Lücke wird sich nicht schließen, weil Menschen anders denken als ein System, das nur Informationen hin und her schiebt. Ein Tester in dieser Rolle kann deshalb kein Einsteiger sein. Ob das Ergebnis zu dem passt, was das System wirklich leisten muss, kann nur ein Experte beurteilen. So läuft eine agentische Testpipeline ab Ein vollständiges agentisches Testsystem übernimmt die Aufgaben, die sonst ein Tester erledigt, von der Prüfung der Anforderungen bis zum Performancetest, und an jeder Übergabe schaut ein Mensch drauf. Nishans Team betreibt genau das intern. Alles beginnt bei der Anforderung. Ein Requirements Engineer legt eine neue Anforderung in Jira an. Das agentische System erkennt sie, holt sie ab und führt ein Review durch. Alternativ kann ein Tester das System anweisen, die Anforderungen für ein bestimmtes Release zu holen. Nach dem Review markiert das System Unstimmigkeiten, schlägt Korrekturen vor und zeigt dem Tester das Ergebnis. Der Tester gibt es frei oder liefert mehr Kontext. Sind die Informationen der KI veraltet oder lückenhaft, ergänzt du, was fehlt, und lässt neu generieren. Dann folgt die Erstellung der Testfälle, allerdings ohne das Testset blind aufzublähen. Das System prüft zuerst die Überdeckung. Decken vorhandene Testfälle die Anforderung schon ab? Wenn ja, ordnet es die Anforderung einem Testfall zu. Wenn nein, schlägt der zuständige Agent neue Testfälle vor und lässt sie vom Tester bestätigen. Als Nächstes kommt die Automatisierung. Ein eigener Automatisierungsagent fragt, ob die Testfälle automatisiert werden oder manuell bleiben sollen. Er automatisiert so, wie es ein Mensch tun würde: Eigenschaften inspizieren, die Anwendung identifizieren, die richtigen Elemente bestätigen. Auch hier beurteilt der Tester, ob die KI die richtige Anwendung und die richtigen Elemente trifft, und kann jederzeit eingreifen. Ist der automatisierte Testfall geschrieben, geht er in die Release-Umgebung, wird ausgeführt, und die Ergebnisse kommen sofort zurück. Schlägt ein Test fehl, untersucht ein Fehleranalyse-Agent die Ursache. Hat sich ein Element verschoben? Hat sich eine Eigenschaft oder eine Farbe geändert? Genau hier wird Vertrauen zum Risiko. Wenn die KI einen Fehlschlag selbst behebt, behebt sie ihn womöglich falsch. Vielleicht hat ein Entwickler eine ID geändert, und die KI hängt sich an ein Element, das richtig aussieht, es aber nicht ist. Die Kontrolle muss beim Menschen bleiben, damit er die Korrektur berichtigen oder den Lauf weiterlaufen lassen kann. Den Abschluss der Pipeline bilden die Performancetests. Ein separater Agent wandelt die automatisierten Funktionstests in Performancetestfälle um, führt sie auf dem gewählten System aus und meldet Engpässe und Warnungen. Warum sich Funktionstestfälle nicht für Performancetests wiederverwenden lassen Der Performance-Agent hat seine Berechtigung, weil er Testfälle umwandelt, nicht weil er sie ausführt. Das bloße Ausführen gehört in die CI/CD-Pipeline. Die Umwandlung ist die eigentliche Arbeit. Funktions- und Performancetestfälle haben einen völlig anderen Umfang. Ein automatisierter Funktionstest steuert das Testobjekt über die GUI oder eine API und ahmt dabei einen einzelnen Benutzer nach. Ein Performancetest lässt die Frontend-Interaktion weg und betrachtet den Datenaustausch des Systems, um zu messen, ob es von einem Benutzer auf zweihundert skaliert. Diese Skalierung verlangt, dass sich die Testfälle selbst ändern. Entweder wandelt eine KI sie um oder ein Performance-Experte. Der Unterschied liegt in der Zeit. Eine unveränderte Funktionstestsuite direkt in einen Performance-Lauf zu schicken, verbrennt nur Tokens. Wie viele Agenten ein agentisches Testsystem braucht Ein funktionierendes Setup kommt mit acht bis zwölf Agenten aus. Die genaue Zahl hängt davon ab, wie viele Features und Funktionen du der KI übergibst. Auch die Branche verschiebt die Zahl. Ein Bankensystem begrenzt, was du der KI überlassen kannst, weil regulatorische Vorgaben jeden Schritt einrahmen. Im Einzelhandel lässt sich mehr übergeben, weil DSGVO und Datenschutz dort weniger schwer wiegen. Autonomie hängt an der Aufgabe, nicht an ständiger Überwachung. Ist eine Anforderung in Jira bereit, feuert der Trigger, und der Prozess startet. Würde die KI sonst die falschen Anforderungen holen, etwa aus dem nächsten oder übernächsten Release, legt der Mensch fest, auf welches Release sie sich konzentrieren soll. Was in einem Agenten steckt Ein Agent beruht auf drei Dingen: Inhalt, Fähigkeiten und Zugriffsgrenzen. Der Inhalt ist der fachliche Kontext des Unternehmens, und genau daran scheitern die meisten Versuche. Du kannst dem Agenten den Inhalt direkt mitgeben oder ihn versioniert in einem Container ablegen. Dann holt sich der Agent die aktuellen Informationen und weiß, wann er zuletzt nachgesehen hat. Mit dem Container-Ansatz behältst du die Quelle unter Kontrolle. Die Fähigkeiten kommen aus dem System-Prompt, und dort steckt das eigentliche Handwerk. Die erste Version wird nicht gut funktionieren. Es braucht mehrere Iterationen, bis sich ein System-Prompt so verhält, wie er soll. Daneben entscheidest du, wie viel Freiheit und Zugriff jeder Agent in welchem Bereich bekommt. Datenschutz kann alles in den lokalen Betrieb zwingen In regulierten Bereichen darfst du keine Tools nutzen, bei denen die Daten deine Kontrolle verlassen. Damit fallen die naheliegenden Cloud-Dienste weg. Nishan arbeitet in der Schweiz, wo manche Unternehmen und Branchen Anwendungen verbieten, die auf US-Servern oder überhaupt auf Servern außerhalb des Landes laufen. Sobald diese Regel greift, sind ChatGPT, Claude und Gemini raus, denn die Daten sind nicht unter deiner Kontrolle, auch wenn es sich so anfühlt. Die Alternative: Agenten und Modell lokal betreiben, auf einem Server innerhalb der jeweiligen Rechtsordnung. So behältst du die volle Kontrolle darüber, welche Informationen die KI nutzt. Modelle wie Mistral oder DeepSeek, etwa über Ollama bereitgestellt, laufen im Hintergrund und lassen sich bei Bedarf austauschen. Der lokale Betrieb hat seinen Preis. Du brauchst Hardware mit echter GPU-Leistung, also entweder eine größere Investition in einen eigenen Server oder eine Serverfarm, die für KI-Workloads gebaut ist. Ein normaler Server reicht dafür nicht. Womit du bei KI-Agenten im Testen anfängst Es gibt zwei Einstiege, je nachdem, ob du die Mechanik verstehen oder einfach Plug-and-Play nutzen willst. Tools wie make.com helfen zu verstehen, wie die Interaktionen funktionieren. Mit n8n kannst du lokal arbeiten. Claude Code und ChatGPT lohnen sich für den privaten Einsatz. Im Unternehmen sieht es anders aus. Nishan setzt auf Systeme von Tricentis und UiPath, weil beide für Tester gebaut sind und die Orchestrierung übernehmen, die ein Testteam braucht. Auf der Aufgabenebene fängst du am besten mit dem Review von Anforderungen an. Da zeigt sich, ob du eine Anforderung genauso liest wie die KI und wo deine menschliche Deutung der Absicht von der wörtlichen Lesart der Maschine abweicht. Die Generierung von Testfällen ist der zweite gute Startpunkt. Das ist eine abgegrenzte Aufgabe, bei der du prüfst, ob die KI solide funktionale Testfälle liefert oder anfängt zu halluzinieren. Geht es schief, frag nach, wo der Fehler liegt. Meistens fehlt Inhalt, weil man annimmt, die KI wisse schon alles. Die KI denkt nicht, und das bleibt vorerst so Ein agentisches System erledigt wiederkehrende Aufgaben gut. Es denkt nicht wie ein Mensch, und es so zu behandeln, als ob, ist der zentrale Fehler. “KI ist völlig dumm. Sie hat von nichts eine Ahnung. Du versuchst nur, die Informationen in den Bereich zu lenken, in dem vielleicht jemand sie trainiert oder ihr Informationen gegeben hat, die sie nutzen kann.” (Nishan Portoyan) Die Lücke im Urteilsvermögen bleibt vorerst bestehen. Eine KI kann Überdeckung nicht so prüfen, wie ein Mensch sie abwägt, weil sie mit Nullen und Einsen arbeitet. Sie sammelt Informationen und gibt sie zurück, indem sie rät, was dir beim letzten Mal gefallen hat, und dir mehr davon anbietet. Deshalb führt das Wort “Denken” in die Irre. Da steckt keine Intelligenz drin, nur Abrufen und Weitergeben. Nishan rechnet damit, dass sich das ändert, aber in keinem Zeitraum, den er benennen könnte. Bis dahin ist das Urteilsvermögen des Testers der Teil der Pipeline, den man nicht abgeben kann. Häufig gestellte Fragen Woran erkennt man, ob ein Team ein agentisches System betreibt oder nur eine Ansammlung von KI-Agenten? Der Test besteht darin, wer den nächsten Schritt bestimmt. In einem agentischen System koordinieren Agenten andere Agenten und geben Aufgaben weiter, um ein Ziel zu erreichen. Ein einzelner Agent nimmt eine Eingabe entgegen, erzeugt eine Ausgabe und wartet auf Anweisungen. Wenn immer noch ein Mensch jede Aktion auslöst und jede Aufgabe verteilt, dann sind das einfach nur Agenten bei der Arbeit, kein agentisches System. Kann ein unerfahrener Tester die Rolle des Prüfers in einem KI-gesteuerten Test-Workflow übernehmen? Nein. Um zu beurteilen, ob das Ergebnis dem entspricht, was das System tatsächlich leisten muss, braucht es einen Experten. Die KI bewältigt die mechanische Arbeit gut, versteht aber keine Geschäftsregeln, und es ist nicht zu erwarten, dass sich diese Lücke schließen wird. Menschliche Kontrollpunkte gehören daher zum Design, einschließlich des ausdrücklichen Rechts, die Entscheidung der KI zu überstimmen. Erstellt ein agentisches Testsystem für jede Anforderung neue Testfälle? Nein. Die Überdeckung steht an erster Stelle. Das System prüft, ob bestehende Testfälle die Anforderung bereits abdecken, und wenn ja, ordnet es die Anforderung einem Testfall zu, anstatt die Testsuite aufzublähen. Nur dort, wo die Überdeckung fehlt, schlägt der zuständige Agent neue Testfälle vor, und der Tester bestätigt diese, bevor sie in den Satz aufgenommen werden. Sollte ein KI-Agent die Erlaubnis haben, fehlgeschlagene automatisierte Tests selbstständig zu beheben? Nein, hier wird Vertrauen zum Risiko. Ein Fehleranalyse-Agent kann die Ursache untersuchen, zum Beispiel, ob sich ein Element verschoben hat oder sich eine Eigenschaft oder Farbe geändert hat. Eine autonome Korrektur kann trotzdem falsch sein: Wenn ein Entwickler eine ID geändert hat, könnte sich die KI auf ein Element fixieren, das richtig aussieht, es aber nicht ist. Die Kontrolle bleibt beim Menschen. Was passiert, wenn du eine bestehende Testsuite für funktionale Automatisierungstests als Lasttest ausführst? Das verschwendet Tokens umsonst. Ein funktionaler automatisierter Test führt das System über die GUI oder eine API durch und ahmt einen einzelnen Benutzer nach. Performancetests lassen die Frontend-Interaktion außer Acht und betrachten den Datenaustausch, wobei gemessen wird, ob das System von einem Nutzer auf zweihundert skaliert. Die Testfälle müssen zunächst von einem Agenten oder einem Performance-Experten umgewandelt werden. Wie lässt man KI-Agenten laufen, wenn Unternehmensrichtlinien das Versenden von Daten ins Ausland verbieten? Du führst die Agenten und das Modell lokal aus, auf einem Server innerhalb der Gerichtsbarkeit. In der Schweiz verbieten manche Unternehmen und Domänen Anwendungen auf US-Servern oder jeglichen Servern im Ausland, wodurch ChatGPT, Claude und Gemini nicht in Frage kommen. Modelle wie Mistral oder DeepSeek, etwa über Ollama bereitgestellt, sitzen hinter den Agenten und können je nach Bedarf ausgetauscht werden. Was ist der häufigste Grund dafür, dass ein KI-Agent beim Test schlechte Ergebnisse liefert? Fehlende Inhalte. Man geht oft davon aus, dass die KI bereits alles weiß, dabei fehlt ihr genau der geschäftliche Kontext des Unternehmens. Ein Agent basiert auf drei Dingen: Inhalten, Fähigkeiten und Zugriffsgrenzen. Die Fähigkeiten ergeben sich aus dem System-Prompt, dessen erste Version noch nicht gut funktioniert und mehrere Iterationen benötigt, bevor sich der Agent wie beabsichtigt verhält. --- ### KI-generierter Code: Qualitätssicherung muss mitwachsen URL: https://www.richard-seidl.com/de/podcast/qualitaet-ki-generierter-code/ Datum: 2026-09-15 Kategorien: Podcast Software Testing KI-generierter Code heißt mehr Code und statistisch mehr Fehler. Nur rund 30 Prozent der KI-Review-Kommentare taugen, die Prüfung muss mitwachsen. KI-unterstützte Softwareentwicklung erzeugt mehr Code, aber nicht automatisch bessere Qualität: Wer doppelt so viel Code schreibt, hat statistisch doppelt so viele Fehler. Automatische Code-Reviews liefern laut vorliegenden Studien nur rund 30 Prozent verwertbare Kommentare. Qualitätssicherung lässt sich durch KI ergänzen, aber nicht ersetzen. Das Wichtigste in Kürze - 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. Doppelt so viel Code bedeutet doppelt so viele Fehler Wer die Menge an generiertem Code steigert, steigert statistisch die Zahl der Fehler im gleichen Maß. Das ist der blinde Fleck in der aktuellen Debatte um KI-gestützte Softwareentwicklung. Die meisten Diskussionen drehen sich um die Frage, wie sich Code noch schneller erzeugen lässt. Ob das Problem in der Praxis je zu wenig Code war, fragt kaum jemand. Für langlebige Systeme ist die Rechnung unbequem. Benjamin Hummel arbeitet mit Kunden, deren Software nicht 10.000 oder 20.000 Zeilen umfasst, sondern in die Millionen geht. Solche Systeme sind für Menschen schwer zu durchdringen, und ein KI-Modell tut sich dabei ebenfalls schwer. Die häufig gehörte Erfolgsstory zeigt selten die zweite Seite. Was im Kleinen funktioniert, etwa eine App, die aus einem Prompt herausfällt, sagt wenig darüber aus, ob dasselbe Vorgehen in einem gewachsenen, komplexen System trägt. Wo Unternehmen im deutschsprachigen Raum wirklich stehen Das Spektrum ist breit, und niemand hat die vollautomatische Software Factory am Laufen. Der Eindruck, alle anderen seien schon weiter, hält der Realität nicht stand. Einige Teams experimentieren im Kleinen mit agentischen Werkzeugen. Andere haben Tools zur agentischen Codeentwicklung flächendeckend an alle Entwicklerinnen und Entwickler ausgerollt. Und manche rollen bereits wieder zurück, weil sie festgestellt haben, dass der Betrieb Geld kostet und neu gemanagt werden muss. Diese Rückwärtsbewegung ist kein Einzelfall. Agentische Arbeit verbraucht Tokens, und ein Agent, der seinen eigenen Weg geht, wird schnell teuer. Warum die Qualitätssicherung zum echten Engpass wird Wenn vorne mehr Code entsteht, verschiebt sich der Flaschenhals nach hinten. Genau dort sitzt die Qualitätssicherung, ein Mensch oder ein langsamer Testprozess. Die verlockende Antwort lautet, die Absicherung wegzulassen, weil sie bremst. Für einen Prototypen mag das taugen. Für ein Produktivsystem, das Steuerbescheide verschickt oder Versicherungspolicen berechnet, ist es keine gute Idee. Statt bei der Absicherung zu sparen, gilt die umgekehrte Logik: Die Qualitätssicherung muss mit der neuen Codemenge mitwachsen. Die Frage ist, ob sich bestehende Verfahren einfach hochskalieren lassen, ob neue Ansätze nötig sind oder ob es eine Mischung braucht. Harness Engineering: Das Gerüst um das Modell herum Ein LLM ist eine Maschine, die Wörter aufnimmt und Wörter ausgibt. Damit daraus zielgerichtete Codeentwicklung wird, braucht es Steuerung außen herum. Für dieses Gerüst hat sich der Begriff Harness Engineering etabliert. Das Harness füttert den bestehenden Code ins Modell, nimmt Änderungen entgegen und gibt dem Modell Werkzeuge an die Hand: Compiler starten, Tests starten, auf das Feedback reagieren. Mit KI selbst hat dieser Teil wenig zu tun. Der öffentlich gewordene Source Code von Claude Code umfasst zwei- bis dreihunderttausend Zeilen, klassisches Software Engineering, um die KI überhaupt nutzbar zu machen. Für die Qualitätssicherung ist dieses Harness der Andockpunkt. Wer hier eingreift, kann die Ausgaben des Modells in eine bessere Richtung treiben: sauberere Struktur, weniger Redundanz. Denn weil Code erzeugen billig ist, produzieren Modelle schnell Funktionen neu, die längst in Utils-Klassen existieren, mit allen bekannten Wartungsproblemen. Schnelles Feedback entscheidet, auch für den Agenten Der alte Grundsatz gilt unverändert, nur der Adressat ist neu. Früher sollte der Entwickler schnell Feedback bekommen, damit er nicht drei Tage in die falsche Richtung läuft. Heute stellt sich dieselbe Frage für den KI-Agenten. Statische Analyse gehört als enge Regelschleife in das Harness. Über eine Schnittstelle, häufig MCP, fließen die Findings direkt zurück an den Agenten, der sie umsetzen kann. Bei Tests wird es schwieriger, wenn die automatisierte Suite Stunden oder Tage läuft. Dann bremst sie den Agenten aus. Testselektion hilft: Eine Änderung am Exportmodul erfordert nicht die Tests der Bilanzierungslogik, sondern die Tests mit dem höchsten Signal für die konkrete Änderung. Solche Selektionsverfahren werden in der Forschung seit Langem diskutiert, und einige haben es in die Praxis geschafft. Statische Analyse funktioniert mit KI erstaunlich gut Das Qualitätsfeedback aus der statischen Analyse setzen die Modelle oft überraschend zuverlässig um. Das senkt sogar eine alte Hemmschwelle. Früher reagierten Entwickler genervt, wenn ein Werkzeug ihnen nach getaner Arbeit Findings vor die Füße kippte. Füttert man dieselben Findings in den Agenten, räumt er sie weg, und der Code sieht am Ende besser aus. Die Absicherung durch Regressionstests bleibt trotzdem Pflicht, damit beim Aufräumen keine Funktionalität verloren geht. Interessant ist, dass neue Regeln sinnvoll werden, die man früher nie aktiviert hätte. Ein Beispiel aus der Praxis: Ein Modell wollte in einem Java-System auf die gekapselten Internas einer Klasse zugreifen und griff per Reflection daran vorbei. Von einem erfahrenen menschlichen Entwickler käme diese Idee nicht. Wegen des Zufallselements der Modelle taucht sie aber gelegentlich auf, und dann willst du sie finden, bevor der Code produktiv geht. Ohne Aufsicht erodiert die innere Qualität Erste Untersuchungen deuten darauf hin, dass die Qualität eines Systems langfristig sinkt, wenn KI unbeaufsichtigt daran arbeitet. Verschiedene Qualitätsmetriken zeigen einen Trend nach unten, und es gibt anekdotische Hinweise, dass die Modelle sich dann selbst immer schwerer tun, den Code zu ändern. Das ist keine Überraschung. Lässt man viele Menschen unbeaufsichtigt an einem System arbeiten, entstehen so viele Abhängigkeiten, dass jede Änderung siebzehn Dinge gleichzeitig im Kopf verlangt. Bei den Modellen kommt ein technisches Limit hinzu. Das Kontextfenster ist begrenzt, und selbst wenn man es voll füllt, berücksichtigt das Modell nicht alles. Es pickt sich Teile heraus und übersieht anderes. Auch ein Modell tut sich schwer, wenn es zu viel gleichzeitig halten muss. Vorsicht ist bei solchen Analogien geboten, denn Begriffe wie Attention sind menschlich aufgeladen, obwohl am Ende Matrizen multipliziert werden. Wer haftet, wenn der Airbag nicht auslöst? Am Ende steht immer die Frage, wer für den Code verantwortlich ist. Bei einer Software im Automobil, die einen Airbag steuert, entscheidet diese Frage über Haftung. Zu OpenAI oder Anthropic zu gehen und ihre Modelle verantwortlich zu machen, funktioniert nicht. Das steht im Kleingedruckten. Es bleibt ein Unternehmensrisiko, und es gab Fälle, in denen einzelne Entwickler in die Haftung genommen wurden, weil sie nicht nach Stand der Technik entwickelt und geprüft hatten. Die Hürden dafür sind hoch, aber die Fälle existieren. Deshalb sind viele Domänen vorsichtig. Sie wählen einen von zwei Wegen: entweder ein Prüfverfahren, das jede einzelne Zeile Code liest, oder eine starke Einschränkung vorne, bei der jede vorgeschlagene Änderung angeschaut werden muss. Beides ist aufwendig, und nach einer halben Stunde reinen Reviewens sitzt man nur noch da und klickt “Yes, yes, yes”. Die Rolle des Dauer-Reviewers ist gefährlich Wer den Großteil des Codes generieren lässt und nur noch prüft, landet in der Rolle, für die Menschen am schlechtesten geeignet sind. Code visuell auf Korrektheit zu kontrollieren, funktioniert konzentriert vielleicht dreißig Minuten. Danach ist Schluss. In der eigenen Entwicklung fährt Benjamins Team bewusst konservativ. Alle Änderungen wurden schon vorher flächendeckend gereviewt, und das bleibt so. Vor dem eigentlichen Review prüft jemand, ob der vom Agenten gelieferte Code überhaupt den Ansprüchen genügt, denn ungefilterten Code abzukippen wäre dem Reviewer gegenüber nicht fair. Beide Review-Stufen fördern weiterhin so viele Probleme zutage, dass Benjamins Team sie nicht abschafft. Nicht immer sind es Fehler. Oft ist etwas inkonsistent oder an der falschen Stelle, was sich später bei einer Fehlerbehebung rächt. Ein konkreter Gegenzug: Tempo gezielt rausnehmen. Einige Kollegen schreiben bestimmte Features wieder von Hand, auch um die Fähigkeit nicht zu verlieren. Wer nur noch Code liest und nicht mehr schreibt, kann kaum noch einschätzen, was er da eigentlich tut. Benjamin Hummel KI-Reviews sind Ergänzung, nicht Ersatz Ein KI-Reviewer durch einen zweiten KI-Reviewer prüfen zu lassen, klingt nach der nächsten logischen Stufe. Die Zahlen sprechen dagegen. Über verschiedene Studien und Kundenerfahrungen hinweg, darunter eine Untersuchung einer australischen Universität, liegen die gängigen Werkzeuge bei rund 30 Prozent guten Review-Kommentaren. Der Rest ist irrelevant oder sogar schädlich für das System. Blind übernehmen macht den Code also nicht besser. Du musst filtern, welche Kommentare taugen. Das unterscheidet einen KI-Reviewer grundlegend vom erfahrenen Kollegen, dessen Kommentar man früher ohne Rückfrage umgesetzt hat. Der Vergleich zur statischen Analyse macht die Kosten deutlich. Ein KI-Reviewer findet viel von dem, was auch statische Analyse findet, kostet dabei aber rund den Faktor 1000 mehr, weil teure Modelle laufen müssen. Selbst nach einem KI-Review findet ein Mensch immer noch viele Dinge. Der Nutzen liegt darin, dass die KI bestimmte Problemklassen vorab wegfiltert. So wie niemand mehr von Hand Zeilen auf Duplikate durchzählt, muss auch der menschliche Reviewer sich nicht mehr um jede maschinell prüfbare Klasse kümmern. Er fragt stattdessen: Stimmt die Architektur? Ist das aus Nutzersicht schlüssig? Was KI-Reviews wirklich kosten Die stärksten verfügbaren Modelle lassen die Kosten schnell eskalieren. Erste Experimente in Benjamins Team ergaben über 500 Dollar pro Tag fürs gesamte Team. Hochgerechnet landet man bei sechsstelligen Beträgen im Jahr. Für manche ist das ein Lacher, für eine mittelgroße Firma ein Grund zum Schlucken. Ein Anbieter solcher Werkzeuge steckt in einem Konflikt: günstige Modelle drücken die Kosten, teurere heben die Review-Qualität. Zwischen beidem balanciert jedes Abo. Die eigentliche Engineering-Herausforderung ist damit nicht das Modell, sondern der Umgang mit dem Ergebnis. Wie profitierst du von den Vorteilen, ohne die Nachteile zu erben, und bleibst dabei kosteneffizient? Für sechsstellige Beträge lässt sich auch eine Testerin oder ein Tester einstellen. Ein Nebengedanke gehört dazu: Nicht jede Aufgabe braucht KI. Was ein klassisches Skript billig und zuverlässig erledigt, sollte kein Modell teuer umständlich lösen. Mehr Ergebnisse sind noch keine besseren Ergebnisse Die nächste Welle betrifft die Datenmengen, die KI produziert. Sicherheitsanalysen sind ein Beispiel. Werkzeuge in dieser Klasse produzieren enorm viele Ergebnisse, doch nicht jede gemeldete Verletzung ist relevant. Das kennt man aus der statischen Analyse. Ist das ein reales Bedrohungsszenario? Lässt es sich tatsächlich ausnutzen, oder beschreibt es eine Situation, die in der echten Welt nie eintritt? Diese Bewertung überfordert Teams schnell. Alle Findings zu lesen, zu entscheiden und dann umzusetzen, ist der eigentliche Engpass. Gerade bei Security verschärft sich die Lage, weil abhängige Bibliotheken gefühlt wöchentlich neue Lücken zeigen. Dasselbe Muster wiederholt sich bei Tests: Lässt die KI viele Tests schreiben, hast du mehr Tests, die fehlschlagen, obwohl niemand etwas geändert hat, und mehr flackernde Tests. Jede neue Fähigkeit zieht neue Probleme nach sich. Langsamer werden ist eine Fähigkeit Die ständige Beschleunigung führt zu Burnout, und das lässt sich aus vielen Ecken hören. Die Open-Source-Community trifft es besonders hart. Bots überfluten Projekte mit Security-Issues, während viele Maintainer die Arbeit ehrenamtlich neben ihrem Beruf leisten. Auf ihren Schultern ruht ein Großteil der digitalen Infrastruktur. Manchmal ist es gar keine echte Beschleunigung, nur ein sehr schnell drehendes Hamsterrad. Neue Tools jeden Monat, die Landschaft ändert sich ständig, und aus dem Management kommt der Ruf nach noch mehr Tempo. Die Gegenbewegung braucht Mut und ein Umfeld, das sie zulässt. Einen Schritt zurückzugehen und zu hinterfragen, was man da eigentlich tut, ist in dieser Zeit selbst eine Fähigkeit. Denn das Problem war nie zu wenig Code. Es war zu verstehen, was der Anwender wirklich braucht, und genau das gezielt umzusetzen. Häufig gestellte Fragen Bringt mehr KI-generierter Code automatisch bessere Software? Nein. Wer die Menge an generiertem Code verdoppelt, verdoppelt statistisch auch die Zahl der Fehler. Besonders unbequem ist die Rechnung bei Systemen, die nicht 10.000 oder 20.000 Zeilen umfassen, sondern in die Millionen gehen: Solche Codebasen sind für Menschen schwer zu durchdringen, und Modelle tun sich daran ebenfalls schwer. Erfolgsgeschichten aus kleinen Apps sagen darüber wenig. Setzen Unternehmen agentische Codeentwicklung schon flächendeckend ein? Das Spektrum ist breit, und die vollautomatische Software Factory hat niemand am Laufen. Einige Teams experimentieren im Kleinen mit agentischen Werkzeugen, andere haben sie an alle Entwicklerinnen und Entwickler ausgerollt. Manche rollen bereits zurück, weil der Betrieb Geld kostet und neu gemanagt werden muss. Agentische Arbeit verbraucht Tokens, und ein Agent, der eigene Wege geht, wird schnell teuer. Wo kann Qualitätssicherung bei KI-Agenten überhaupt ansetzen? Am Harness, also dem klassisch programmierten Gerüst um das Modell herum. Es füttert bestehenden Code ins Modell, nimmt Änderungen entgegen und stellt Werkzeuge bereit: Compiler starten, Tests starten, auf Feedback reagieren. Wer hier eingreift, treibt die Ausgaben in Richtung sauberere Struktur und weniger Redundanz. Statische Analyse gehört als enge Regelschleife hinein, deren Findings direkt an den Agenten zurückfließen. Setzen KI-Agenten die Findings aus statischer Analyse zuverlässig um? Ja, oft überraschend zuverlässig. Früher reagierten Entwickler genervt, wenn ein Werkzeug nach getaner Arbeit Findings vor die Füße kippte; füttert man dieselben Findings in den Agenten, räumt er sie weg. Regressionstests bleiben trotzdem Pflicht, damit beim Aufräumen keine Funktionalität verloren geht. Sinnvoll werden dabei Regeln, die man früher nie aktiviert hätte, etwa gegen Reflection-Zugriffe auf gekapselte Internas. Was passiert mit der Qualität, wenn KI-Agenten unbeaufsichtigt an einem System arbeiten? Sie sinkt langfristig. Erste Untersuchungen zeigen bei verschiedenen Qualitätsmetriken einen Trend nach unten, und es gibt anekdotische Hinweise, dass die Modelle sich anschließend selbst immer schwerer tun, den Code zu ändern. Dazu kommt ein technisches Limit: Das Kontextfenster ist begrenzt, und selbst ein voll gefülltes Fenster wird nicht vollständig berücksichtigt. Das Modell pickt Teile heraus und übersieht anderes. Kann man den Anbieter eines Sprachmodells für fehlerhaften Code haftbar machen? Nein, das steht im Kleingedruckten. Die Verantwortung für den Code bleibt beim Unternehmen, und es gab Fälle, in denen einzelne Entwickler in die Haftung genommen wurden, weil sie nicht nach Stand der Technik entwickelt und geprüft hatten. Die Hürden dafür sind hoch, aber die Fälle existieren. Bei sicherheitskritischer Software wie einer Airbag-Steuerung entscheidet genau diese Frage. Wie viele Kommentare eines KI-Code-Reviews sind brauchbar? Rund 30 Prozent. Über verschiedene Studien und Kundenerfahrungen hinweg, darunter eine Untersuchung einer australischen Universität, liegen die gängigen Werkzeuge bei etwa diesem Anteil guter Review-Kommentare. Der Rest ist irrelevant oder sogar schädlich für das System. Blindes Übernehmen verbessert den Code also nicht, und ein Mensch findet nach dem KI-Review immer noch viele Dinge. Was kostet der Einsatz starker Modelle für automatische Code-Reviews? Deutlich mehr als klassische Werkzeuge: Ein KI-Review findet viel von dem, was auch statische Analyse findet, kostet dabei aber etwa den Faktor 1000 mehr. Erste Experimente in Benjamin Hummels Team ergaben über 500 Dollar pro Tag für das gesamte Team, hochgerechnet sechsstellige Beträge im Jahr. Für dieses Geld ließe sich auch eine Testerin oder ein Tester einstellen. --- ### KI beim Testen steigert den Wert erfahrener Tester URL: https://www.richard-seidl.com/de/podcast/experten-tester-ki-zeitalter/ Datum: 2026-09-10 Kategorien: Software Testing Unleashed KI beim Testen hilft bei Routine, doch KI-generierter Code bringt mehr Fehlerzustände. Erfahrene Tester mit Geschäftswissen werden dadurch wertvoller. Mit KI beim Testen hängt die Zukunft des Softwaretests an erfahrenen Testern, die Testverfahren beherrschen und das Geschäft hinter der Software verstehen. KI erledigt wiederkehrende, klar umrissene Aufgaben gut, scheitert aber an den Rändern: an halluzinierten Anforderungen, nicht überprüfbaren Ergebnissen und unerwartetem menschlichem Verhalten. Am meisten zählen Geschäftswissen, Requirements Engineering, Prompt Engineering und Kommunikation. Das Wichtigste in Kürze - KI-Ergebnisse stimmen oft genug, um vertrauenswürdig zu wirken. Der fehlerhafte Rest, also erfundene Quellen, erfundene Anforderungen und erfundene Testfälle, richtet echten geschäftlichen Schaden an, wenn kein Mensch das Ergebnis prüft. - Wer nur vorgefertigte Skripte abarbeitet, ohne das Geschäft dahinter zu verstehen, ist durch KI direkt ersetzbar. Fachwissen macht einen Tester schwer automatisierbar. - Prompt Engineering und Requirements Engineering gehören heute zum Kern des Berufs, denn das Grundproblem, das Verhalten von Software präzise und eindeutig zu beschreiben, ist seit 30 Jahren dasselbe. - Kommunikation ist die große Lücke in der Ausbildung von Testern: Daten ehrlich darstellen, Erwartungen von Stakeholdern steuern und klare Prompts schreiben verlangt Fähigkeiten, die ein technisches Studium nicht vermittelt. KI beim Testen bleibt und macht erfahrene Tester wertvoller Tester werden durch KI nicht überflüssig, aber ihre Arbeit verändert sich. Olivier Denoo ist seit fast 30 Jahren in der Branche und sieht in KI beim Testen eher eine Chance für die Test-Community als eine Bedrohung. Sein Argument ist schlicht. KI ist keine Mode, die wieder vergeht. Vielleicht gibt es eine Blase, und vielleicht verliert sie irgendwann Luft, die Technologie selbst bleibt aber Teil der Softwareentwicklung. Wer lernt, sie gut einzusetzen, behält seinen Platz. Wer das nicht kann, steht ungeschützt da. Wie konkret das Risiko ist, zeigt ein Beispiel. Wenn deine Arbeit seit zwanzig Jahren darin besteht, denselben Knopf zu drücken und dasselbe Skript laufen zu lassen, das du nicht einmal selbst geschrieben hast, bist du ernsthaft gefährdet. Genau diese Arbeit übernimmt die KI zuerst. Warum KI-generierter Code Testern mehr Arbeit macht Vibe Coding bringt Software schneller hervor und prüft ihre Qualität weniger. In dieser Lücke braucht es erfahrene Tester. Wenn jemand ohne Entwicklerhintergrund eine Anwendung per Prompt entstehen lässt, bleiben Fragen offen. Erfüllt der Code die Anforderungen? Wie entwickelt er sich weiter? Ist er wartbar? Ist er sicher? Repositories können Hintertüren und Trojaner enthalten, und wer nicht entwickelt, kann nicht beurteilen, ob der generierte Code taugt. Olivier rechnet damit, dass die Folgen in Monaten bis wenigen Jahren sichtbar werden, sobald es genug KI-generierte Anwendungen gibt. Ob Agenten andere Agenten überwachen, LLMs andere LLMs prüfen oder ein Mensch mit im Prozess ist: Die Zahl der Fehlerzustände steigt. Mehr Fehlerzustände heißen mehr Tester, und zwar vor allem mehr erfahrene Tester. Was einen erfahrenen Tester ausmacht Ein erfahrener Tester verbindet Testhandwerk mit Geschäftsverständnis. Beides zählt, und meistens fehlt das Zweite. Zum Handwerk gehört, Testverfahren anzuwenden, zu wissen, wo man suchen muss, und ein Problem sinnvoll anzugehen. Geschäftsverständnis heißt, zu wissen, was hinter der Anwendung steckt und wozu es sie gibt. Niemand schreibt Software, um eine neue Plattform oder Sprache vorzuführen. Code soll ein Ziel erreichen und jemandem bei einer Aufgabe helfen. Je stärker Systeme miteinander verbunden sind, desto schwerer wird dieses Verständnis. Anwendungen greifen eng ineinander, und die Geschäftsabläufe, die quer durch sie laufen, sind kaum noch zu überblicken. Es braucht Leute, die den ganzen Prozess von Anfang bis Ende verstehen und nicht nur das Verhalten einer einzelnen Komponente. Warum “KI kann testen, also sparen wir Tester” gefährlich ist Ein Manager, der von einer Konferenz zurückkommt und glaubt, KI mache Tester überflüssig, schätzt die Technologie falsch ein. Wer danach handelt, steuert auf eine geschäftliche Katastrophe zu. Die Falle: KI wirkt klug. Sie liefert immer eine Antwort, weil sie dafür gebaut ist. Sie gibt dir recht, bestätigt dich und präsentiert ihr Ergebnis mit großer Sicherheit. “Das Problem ist, dass diese Antwort auf den ersten Blick klug aussieht, aber wahrscheinlich nur zu 85, 90 Prozent klug ist. Und was ist mit den restlichen 10 oder 15 Prozent, die fehlerhaft sind?” (Olivier Denoo) In diesem Rest steckt der Schaden, und darin liegt das größte Risiko von KI beim Testen. KI kann Anforderungen, Testfälle und Code halluzinieren. Ein bekanntes Beispiel sind Quellenangaben: Bittest du eine KI um ihre Quellen, nennt sie dir vielleicht einen plausiblen Autor, ein plausibles Buch und einen plausiblen Mitautor, und alles davon ist erfunden. Wenn du nicht gegenprüfst oder nicht genug weißt, um den Fehler zu erkennen, gehst du ein echtes Risiko ein. Nur ein Mensch, der die Ergebnisse prüft, verhindert, dass selbstsichere, aber falsche Ausgaben in Produktion landen. Wo KI Testern hilft und wo sie an Grenzen stößt Die einfachen Teile des Testprozesses erledigt KI gut. Schwer tut sie sich an den Rändern, bei der Anforderung und beim Orakel. Dort bleibt menschliches Urteil unverzichtbar. KI kann Anforderungen schreiben und prüfen. Sie kann sortieren und priorisieren. Sie kann Testfälle erzeugen. Nur musst du vorher sicher sein, dass Anforderungen und Testfälle überhaupt stimmen. Die schweren Fragen sind seit dreißig Jahren dieselben. Wo sind die Anforderungen? Was soll die Software eigentlich tun? Wie genau und eindeutig kannst du beschreiben, was du willst, bis ins letzte Detail? Und auf der anderen Seite steht das Orakelproblem: Woran erkennst du, dass das Ergebnis richtig ist? Eine Steuererklärung zeigt die Grenze. Es gibt so viele mögliche Fälle, dass sich kaum prüfen lässt, ob der Endbetrag stimmt, also ob die richtige Summe nachgezahlt oder erstattet wird. Für eine KI ist diese Art der Prüfung keine leichte Aufgabe. Der Nutzer ist ein echter Mensch, keine Persona Software wird für jemanden gebaut, und dieser Jemand muss sie verstehen und bedienen können. Wer beim Testen den tatsächlichen Nutzer vergisst, übersieht Fehler, die in keinem Testfall stehen. Personas haben einen Haken: Sie decken nur die Menschen ab, an die du schon gedacht hast. Olivier nennt als Beispiel seine Mutter. Sie wird 80 und nutzt weder Smartphone noch Apps. In Paris braucht man inzwischen eine App, um U-Bahn zu fahren. Wie soll das für eine 80-Jährige funktionieren, die einfach nur mit der Metro fahren will? Der Ablauf mag sauber definiert und für viele hilfreich sein, trotzdem schließt er ganze Nutzergruppen stillschweigend aus. Deshalb gehört UX zur Arbeit eines Testers. Der Mensch im Prozess ist nicht nur der Bediener in deinem System. Es ist auch die Person, bei der das Ergebnis ankommt und die verstehen muss, was die Software da liefert. Randfälle entstehen, wo der saubere Prozess auf die Wirklichkeit trifft Selbst ein perfekt definierter Prozess scheitert an dem einen Schritt, an dem ein Mensch etwas tut, womit das Modell nicht rechnet. Oliviers verlorener Koffer zeigt das. Die Gepäckabfertigung am Flughafen ist von Anfang bis Ende festgelegt. Jeder Schritt und jeder Fall ist geregelt. Auf dem Rückweg aus Thailand blieb sein Gepäck in Genf hängen, während er in Brüssel landete. Swiss bestätigte, dass der Koffer mit dem Flug am nächsten Morgen nachkommt, und sein eigener Tracker zeigte ihn in Brüssel an. Dann schrieb Brussels Airlines per E-Mail, das Gepäck sei nicht auffindbar, obwohl er den Raum nennen konnte, in dem es vermutlich stand. Seine Vermutung: Jemand hat den Koffer vom Band genommen und vergessen, das Etikett zu scannen. Ein einziger fehlender Scan, und das Gepäckstück war aus dem System verschwunden. In diesen Raum müssen Tester hineindenken. Menschen benutzen Software, Autos und Flugzeuge, und manchmal benutzen sie sie falsch. Das Unerwartete passiert genau an den Nahtstellen, die die Spezifikation für sicher hält. Welche Fähigkeiten Tester jetzt aufbauen sollten Was Tester im KI-Zeitalter relevant hält, liegt an beiden Enden des technischen Spektrums: genauere Arbeit an Anforderungen und bessere Kommunikation. Der sichere Umgang mit KI wird dabei vorausgesetzt. Auf der technischen Seite steht Requirements Engineering ganz oben, zusammen mit Prompt Engineering und Techniken für generative KI, denn KI gehört inzwischen zum Job. Gefragt sind außerdem DevOps-Praktiken, Pipelines und Automatisierung. Manuelles Testen bleibt, verschiebt sich aber vom wiederholten Abarbeiten von Skripten hin zum explorativen Testen. Die Grundlage für alles ist Geschäftsverständnis: zu wissen, wofür die Anwendung da ist. Wer einen strukturierten Weg sucht, findet bei ISTQB zwei Zertifizierungen mit KI-Schwerpunkt. Die eine behandelt den Einsatz von generativer KI beim Testen und wurde kürzlich aktualisiert, um mit dem schnellen Markt Schritt zu halten. Die andere, CT-AI, behandelt das Testen von KI selbst, einschließlich agentischer Architekturen, und wurde ebenfalls aktualisiert. Ein DevOps-Lehrplan ist in Arbeit, neben den etablierten Pfaden für Testmanagement und agiles Testen. Kommunikation kommt in der Ausbildung zu kurz Kommunikation ist für Olivier die wichtigste Fähigkeit eines Testers, und ausgerechnet sie fehlt in der IT-Ausbildung. Das fängt beim Prompt an. Das alte Problem ist auch das neue: Wir wissen immer noch nicht, wie wir genau beschreiben, was wir wollen. Vage, unklare und mehrdeutige Aussagen scheitern bei einer KI genauso wie vor dreißig Jahren bei einem Entwicklungsteam. Einen präzisen Prompt zu schreiben ist Kommunikation. Und es hört dort nicht auf. Auch wenn die KI den Bericht schreibt, die Testfälle sortiert und ein Schema zur Priorisierung aufstellt, musst du die Ergebnisse noch zu den Stakeholdern im Fachbereich und ins Management tragen. Das heißt, Daten ehrlich darzustellen, ohne das Ergebnis zu verbiegen, und mit der Psychologie und den Machtspielen drumherum umzugehen. Ingenieure zieht es zur Technik, weil sie ihnen Spaß macht. Das ist verständlich und zugleich ein blinder Fleck. Die Soft Skills, die im technischen Studium beiseitegeschoben oder vergessen werden, sind es, mit denen ein Tester aus richtigen Befunden Entscheidungen macht, nach denen andere handeln. Häufig gestellte Fragen Welche Tester haben das größte Risiko, durch KI ersetzt zu werden? Tester, deren Arbeit darin besteht, vorgefertigte Skripte abzufahren, sind diejenigen, die von der KI als Erstes übernommen werden. Jemand, der seit zwanzig Jahren auf denselben Knopf drückt und Skripte ausführt, die er nicht einmal selbst geschrieben hat, ist direkt austauschbar. Fachwissen ist der Schutz: Ein Tester, der das Geschäftsfeld hinter der Anwendung versteht, lässt sich viel schwerer automatisieren. Reduziert KI-unterstütztes Programmieren den Aufwand für das Testen? Nein. „Vibe-Coding“ produziert Software schneller, aber die Qualitätssteuerung erfolgt weniger. Wenn jemand, der kein Entwickler ist, eine Anwendung aus dem Nichts erschafft, gibt es niemanden, der überprüft, ob der Code den Anforderungen entspricht, ob er eine hohe Wartbarkeit aufweist oder ob er sicher ist; Repositories können Hintertüren und Trojaner enthalten. Mehr generierter Code bedeutet mehr Fehlerzustände und damit einen höheren Bedarf an erfahrenen Testern. Warum ist Geschäftswissen genauso wichtig wie Testverfahren? Software dient dazu, ein Ziel zu erreichen und jemandem bei einer Aufgabe zu helfen, nicht, um eine Plattform oder eine Sprache zur Schau zu stellen. Ein Tester, der dieses Ziel nicht versteht, kann nicht beurteilen, wie das richtige Verhalten aussieht. Die Schwierigkeit wächst, je komplexer Anwendungen miteinander verknüpft sind: Geschäftsabläufe erstrecken sich über mehrere Systeme, und jemand muss den gesamten Prozess von Anfang bis Ende verfolgen. Wie vertrauenswürdig sind KI-generierte Ergebnisse bei der Testarbeit? Sie wirken zuversichtlich und sind oft genug falsch, um eine Rolle zu spielen. KI liefert immer eine Antwort, weil sie darauf ausgelegt ist, eine zu liefern, und vielleicht sehen 85 bis 90 Prozent davon plausibel aus und sind auch fundiert. Die restlichen 10 bis 15 Prozent richten den Schaden an: erfundene Anforderungen, fingierte Testfälle oder plausible Verweise mit erfundenen Autoren und Büchern. Wer den Fehler erkennen kann, muss eine Gegenprüfung durchführen. Kann KI bestätigen, dass ein Testergebnis korrekt ist? Nicht zuverlässig. Zu prüfen, ob ein Ergebnis richtig ist (das sogenannte Orakelproblem), gehört zu den schwierigen Aufgaben, die KI nicht löst. Eine Steuererklärung zeigt die Grenzen auf: Die Anzahl möglicher Fälle ist so groß, dass es wirklich schwierig ist, den endgültigen zu zahlenden oder erstattungsfähigen Betrag zu überprüfen. Das Generieren und Sortieren von Testfällen fällt der KI leichter als die Überprüfung der Richtigkeit. Warum reichen Personas nicht aus, wenn man für echte Nutzer testet? Personas decken nur die Menschen ab, die du dir bereits vorgestellt hast. Olivier Denoos Beispiel ist seine Mutter, die 80 wird und weder ein Smartphone noch Apps nutzt, obwohl man in Paris eines braucht, um mit der Metro zu fahren. Ein Prozess kann gut definiert und für viele Menschen hilfreich sein und dennoch stillschweigend ganze Nutzergruppen ausschließen. Deshalb gehört UX in den Aufgabenbereich des Testers. Warum scheitern selbst vollständig spezifizierte Prozesse in der Praxis? Weil schon eine einzige Person aus dem Modell herausfallen kann. Die Gepäckabfertigung am Flughafen ist von Anfang bis Ende festgelegt, doch Olivier Denoos Koffer blieb in Genf, während er in Brüssel landete, höchstwahrscheinlich, weil jemand den Koffer vom Förderband nahm und vergaß, das Etikett zu scannen. Ein einziger fehlender Scan, und das Gepäckstück verschwand aus dem System. Verschwindet das manuelle Testen? Nein, aber es verändert sich. Manuelles Testen entfernt sich von sich wiederholenden, geskripteten Testläufen hin zu explorativem Testen, bei dem menschliches Urteilsvermögen etwas beiträgt, was ein Skript nicht leisten kann. Daneben sind Anforderungsengineering, Prompt-Engineering und Techniken der generativen KI gefragt, ebenso wie DevOps-Praktiken, Pipelines und Automatisierung. All das beruht darauf, zu verstehen, wozu die Anwendung eigentlich dient. --- ### ISTQB-Boards im DACH-Raum: Ein Backoffice für alle drei URL: https://www.richard-seidl.com/de/podcast/ehrenamt-istqb-boards-dach/ Datum: 2026-09-08 Kategorien: Podcast Software Testing 20 Jahre Backoffice hinter den ISTQB-Boards: Was dabei wirklich gebraucht wird und warum Ehrenamt mehr ist als Kaninchenzüchten. Das Backoffice der drei deutschsprachigen ISTQB-Boards, dem German Testing Board, Austrian Testing Board und Swiss Testing Board, bündelt alle organisatorischen Aufgaben an einer einzigen Stelle. Dazu gehören Akkreditierungen, Mitgliederkommunikation, Wirtschaftsplanung und die Meldung von Prüfungszahlen ans ISTQB. Die Boards selbst bestehen ausschließlich aus Ehrenamtlichen, die neben ihrem Hauptberuf Lehrpläne reviewen und Prüfungsfragen erstellen. Das Wichtigste in Kürze - 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. Wer German, Austrian und Swiss Testing Board am Laufen hält Die drei deutschsprachigen Testing Boards, das German Testing Board, das Austrian Testing Board und das Swiss Testing Board, arbeiten mit einem gemeinsamen Backoffice. Diese Stelle bündelt alle Fäden, die bei drei ehrenamtlich geführten Vereinen sonst ins Leere liefen. Die Boards sind die deutschsprachigen Vertretungen des ISTQB. Ihre Mitglieder sind ehrenamtlich tätige Privatpersonen, die sich zusammengeschlossen haben und tagsüber in ihren eigentlichen Jobs stecken. Genau darin liegt das Problem, das ein Backoffice löst: Da kann tagsüber niemand ans Telefon. Andrea Kränzlein betreut dieses Backoffice seit 20 Jahren für das German Testing Board, seit 13 Jahren für das Swiss Testing Board und seit 12 Jahren für das Austrian Testing Board. Bei ihr laufen Akkreditierungsanfragen sowie die Anfragen von Trainingsprovidern und Endanwendern auf. Warum ein gemeinsames Backoffice die Boards effizienter macht Der Zusammenschluss auf ein gemeinsames Backoffice hat den drei Boards messbare Synergieeffekte gebracht. Statt wiederholtem Hin und Her zwischen den Ländern liegen bestimmte Aufgabenbereiche jetzt in einer Hand. Ein Beispiel sind Akkreditierungen. Fragt ein Board, ob und wie lange ein Trainingsprovider bei einem Nachbarland akkreditiert ist, muss darüber nichts mehr abgestimmt werden. Ein Blick in die zentrale Datei reicht. Die Idee dahinter: Jedes Board behält seine Hoheit, nutzt aber dieselbe Verwaltungsstruktur. Das spart Ressourcen, personell wie finanziell, ohne dass ein Board seine Eigenständigkeit aufgibt. Was das Backoffice konkret übernimmt Das Backoffice ist die zentrale Kontaktstelle für alle drei Boards. Es leitet Anfragen weiter, wahrt dabei aber strikte Objektivität. Ein Tester, der eine Prüfung ablegen will, informiert sich über die Backoffice-Kontaktadresse und wird von dort an die Zertifizierungsstelle weitergeleitet. Eine Empfehlung für einen bestimmten Trainingsprovider gibt es nicht. Diese Neutralität ist Prinzip, kein Zufall. Zu den Aufgaben gehören außerdem: - Kontakt zu Trainingsprovidern bei Problemen und Akkreditierungen - Buchhaltung und Aufstellung der Wirtschaftspläne - Organisation der Meetings, inklusive großer Veranstaltungen wie eines ISTQB-Meetings - Meldung der Prüfungszahlen der drei Boards an das ISTQB Die Meldung der Prüfungszahlen ist mehr als Formalität. Von diesen Zahlen finanziert sich das ISTQB. Ehrenamt heißt: Vollzeitjob plus Boardarbeit Die Boardarbeit ist Ehrenamt, geleistet von Menschen, die im Beruf stehen. Sie machen die Arbeit in ihrer Freizeit, oft zusätzlich zu einem Vollzeitjob. Das wird von außen leicht unterschätzt. Rund um die Zertifizierung verdienen Trainingsanbieter mit Kursen und Zertifizierungsstellen mit Prüfungen Geld. Der Kern der Boardarbeit selbst aber ist unbezahltes Engagement, vergleichbar mit anderen Vereinsstrukturen, nur mit deutlich mehr fachlicher Substanz. Was diese Ehrenamtlichen leisten, ist inhaltliche Facharbeit: Lehrpläne reviewen, Prüfungsfragen erstellen, das ISTQB-Thema nach außen tragen. Das nebenher zu stemmen, verlangt viel Lebenszeit und ein hohes Maß an Verantwortung. Die DACH-Boards arbeiten enger zusammen als der Rest der Welt Die drei deutschsprachigen Boards kochen nicht jeder ihr eigenes Süppchen. Sie tauschen sich regelmäßig aus und treffen sich einmal im Jahr in der Dreierkonstellation, um an gemeinsamen Themen zu arbeiten. Der Grund ist ein gemeinsamer Markt mit eigenen Anforderungen. Themen, die in Mitteleuropa relevant sind, funktionieren hier anders als in Indien, den USA oder in Boards auf anderen Kontinenten. An diesen Themen lässt sich im DACH-Verbund gezielter arbeiten. Ein aktuelles Beispiel für einen echten Umbruch ist das Thema KI. Es verändert die Diskussion in den Boards spürbar, von der Frage, wohin sich Lehrpläne entwickeln, bis zu dem, was künftig geprüft wird. Wie ein Running Gag Meetings pünktlich hält In Meetings mit vielen Beteiligten gibt es ein wiederkehrendes Problem: Wer einmal das Rederecht hat, hört manchmal nicht mehr auf. Genau hier setzt ein Timeboxing an, das die Boards spielerisch gelöst haben. Eine sogenannte Muhdose, ein Kinderspielzeug, das beim Umdrehen ein Geräusch macht, dient als Zeitmaschine. Wer fünf Minuten Redezeit hat und sie überzieht, bekommt die Muhdose. Ein Ehrenmitglied verantwortet sie in jedem Meeting. Der Effekt ist zweifach. Die Zeitdisziplin steigt, und aus der Zeitmaschine ist ein fester Ritual-Gag geworden, nach dem vor jedem Meeting gefragt wird. Der Punkt dahinter: Boardarbeit muss nicht bierernst sein, um wirksam zu sein. Warum die Boards jüngere Mitwirkende brauchen Die Boards profitieren davon, wenn erfahrene Mitglieder Verantwortung abgeben und jüngere Leute nachrücken. Diese Öffnung ist ein Wunsch für die Zukunft, kein Selbstläufer. Das Argument gegen die Sorge, Neue könnten Aufgaben nicht sofort perfekt erfüllen, ist einfach: Niemand hat mit hundert Prozent angefangen. Jeder hat irgendwann angefangen und sich eingearbeitet. Dazu gehört auch, gewachsene Altersstrukturen zu hinterfragen. Sitzt jemand sehr lange auf einer Rolle, kann es sinnvoll sein, sie weiterzugeben und Ressourcen freizumachen, personell wie finanziell. Für die Community heißt das konkret: Wer in einem der drei Boards mitwirken will, kann sich per E-Mail beim Backoffice melden und wird von dort an das passende Board weitergeleitet. Helfende Hände und Köpfe sind willkommen. --- ### Lean-Prinzipien: Erst das Problem verstehen, dann lösen URL: https://www.richard-seidl.com/de/podcast/lean-prinzipien-softwarequalitaet/ Datum: 2026-09-03 Kategorien: Software Testing Unleashed Lean-Prinzipien zielen auf Qualität zur richtigen Zeit, weniger Verschwendung und Wachstum im Team. Verschwendung ist, was dem Kunden nichts bringt. Lean Management, gerade in der Softwareentwicklung, ist eine Denkweise, die auf drei Lean-Prinzipien beruht: dem Kunden Qualität zur richtigen Zeit liefern (nicht bloß pünktlich), Verschwendung beseitigen und Teams kontinuierlich wachsen lassen. Verschwendung ist alles, was dem Kunden keinen Wert bringt, etwa ungenutzte Funktionen, unklare Anforderungen und immer wiederkehrende Produktionsprobleme. Wer die Ursache eines Problems versteht, statt vorschnell eine Abhilfe zu suchen, verhindert, dass dasselbe Problem wieder auftritt. Das Wichtigste in Kürze - Wer sich auf eine Lösung stürzt, bevor das Problem verstanden ist, bekommt dasselbe Problem wieder: Zeit für die Root Cause Analysis verhindert die Wiederholung, eine schnelle Abhilfe schafft das nie. - Verschwendung in Softwareprojekten ist alles, was dem Kunden keinen Wert bringt, auch Funktionen, die pünktlich fertig werden, aber von den Menschen, für die sie gebaut wurden, nie genutzt werden. - Lean ist keine Methode, die man auf Agile draufsetzt, sondern eine Haltung, die unter jeder Arbeitsweise liegt und sich auf Prozesse, Werkzeuge und alltägliche Gewohnheiten gleichermaßen anwenden lässt. - Ohne Rückhalt im Management hält Lean nicht lange: Die Zeit, die das Verstehen von Problemen kostet, wird sonst gestrichen, bevor sich die Denkweise festsetzen kann. Lean beginnt beim Problem, nicht bei der Lösung Die Lean-Prinzipien verlangen, dass du dich zuerst mit dem Problem beschäftigst, bevor du zur Lösung greifst. Das läuft gegen den Instinkt. Geht etwas kaputt, will man reparieren und weitermachen. Nirmala Saneechur hat Lean bei IKEA gelernt, wo das Unternehmen ihre Green-Belt-Zertifizierung bezahlt hat. Hängen geblieben ist ihr, wie viel Zeit die Methode dem Problem selbst widmet. In der Schulung hat die Gruppe ein Problem so gründlich untersucht, dass die Lösung am Ende offensichtlich war. Wenn du genau weißt, was schiefgelaufen ist, schreibt sich die Lösung fast von allein. Genau hier treffen sich Lean und Qualität. Wenn du die eigentliche Ursache verstehst, statt nur das Symptom zu flicken, löst du das Problem einmal. Es kommt nicht wieder. So entsteht die Qualität in der Arbeit selbst und wird nicht nachträglich angeschraubt. Schwierig ist das Umdenken. Selbst nach anderthalb Jahren Praxis lautet Nirmalas erste Reaktion auf ein Problem immer noch: “Was ist die Lösung?” Die Disziplin besteht darin, nach der schnellen Abhilfe einen Schritt zurückzutreten und zu fragen, warum es überhaupt passiert ist. Was Lean Management bedeutet: die drei Lean-Prinzipien Lean heißt, Verschwendung zu reduzieren, und Verschwendung ist alles, was dem Kunden keinen Wert bringt. An dieser Definition hängt alles andere. Die Methode stützt sich auf drei Gedanken. Du lieferst dem Kunden Qualität zur richtigen Zeit. Du hältst die Verschwendung klein. Und du stellst die Menschen in den Mittelpunkt, damit sich die Teams ständig weiterentwickeln. Lean ist bei Toyota als Konzept für die Fabrik entstanden. Auf Software lässt es sich übertragen, weil die Grundfrage überall dieselbe ist: Welche Teile von dem, was du herstellst, helfen dem Kunden wirklich, und welche sind Bewegung ohne Wert? Nirmala versteht Lean eher als Haltung denn als festes Verfahren. Du kannst es zu Hause anwenden oder beim Autofahren, indem du dich fragst, ob du gerade einen Handgriff machst, der gar nicht nötig ist. Derselbe Reflex funktioniert bei einem Softwareprozess. Warum “zur richtigen Zeit” mehr zählt als “pünktlich” Pünktlich liefern ist nicht dasselbe wie Wert liefern. Du kannst jede Deadline halten und trotzdem Verschwendung produzieren. Nirmala hat in einem Projekt gearbeitet, in dem das Team 15 Funktionen für einen Kunden gebaut hat. Als der Kunde die Anwendung dann nutzte, hat er diese 15 Funktionen nie angefasst. Geliefert wurde pünktlich, genau zum gewünschten Termin, und trotzdem war es Verschwendung, weil niemand die Funktionen verwendet hat. Das ist Überproduktion. Du hast etwas gebaut, von dem der Kunde glaubte, dass er es braucht, und das er dann nie gebraucht hat. Lieferung zur richtigen Zeit heißt: das liefern, was der Kunde tatsächlich nutzt, dann, wenn er es nutzt. Nicht eine Anforderungsliste abarbeiten, nur weil sie aufgeschrieben wurde. Wie du Verschwendung im Prozess erkennst Verschwendung versteckt sich im ganz normalen Arbeitsablauf, deshalb musst du zuerst lernen, sie zu sehen. Mit mancher Verschwendung musst du leben, andere kannst du loswerden. Ein Doppelklick zum Öffnen bringt keinen Wert, aber vielleicht musst du ihn beibehalten. Das ist Verschwendung, die du hinnimmst. Angehen lohnt sich die Verschwendung, die sich wiederholt und aufsummiert. Das deutlichste Beispiel ist die Anforderung, die du nicht verstehst. Du liest sie, fragst bei der Person nach, die sie geschrieben hat, bekommst eine Antwort, liest noch einmal und verstehst sie immer noch nicht. Dieses Hin und Her ist reine Verschwendung. Hättet ihr die Anforderung von Anfang an gemeinsam erarbeitet, wäre die Schleife gar nicht erst entstanden. Verschwendung zu beseitigen ist kreative Arbeit, keine Checkliste. Wenn sich ein Nutzer durch drei Reiter klicken muss, um zu finden, was er braucht, erspart ihm ein Link auf der ersten Seite den Umweg. Eine Einheitsmethode gibt es nicht. Du verstehst die konkrete Verschwendung und erfindest dann den Weg, sie zu beseitigen. Auch ein Problem in Produktion ist Verschwendung Wenn die Produktion steht, bringt die Zeit, die du mit der Korrektur verbringst, dem Kunden nichts. Damit ist das Problem selbst eine Form von Verschwendung. Das Gegenmittel: die Dinge gleich beim ersten Mal richtig machen. Jedes Mal, wenn du besser verstehst, wo du danebengelegen hast, steigen deine Chancen, es beim nächsten Versuch richtig zu machen. Problemlösung ist kein Umweg vom Lean-Gedanken, sondern einer der Wege, auf denen Lean Verschwendung beseitigt. Nicht jedes Problem ist den gleichen Aufwand wert. Passiert etwas nur einmal, suchst du trotzdem die Ursache, investierst aber wenig Zeit. Tritt ein Problem immer wieder auf, zahlt sich die Analyse aus. Nimm eine Testumgebung, die regelmäßig ausfällt. Wenn die Abhilfe immer ein Neustart ist, dann ist der Neustart eine Abkürzung, keine Lösung. Das wiederkehrende Muster ist das Signal, innezuhalten und zu verstehen, was den Ausfall wirklich verursacht. Schnelle Abhilfe und echte Lösung sind zwei Aufgaben Die Produktion am Laufen halten und das Problem lösen sind verschiedene Aufgaben, und Lean verlangt beides. Zuerst nimmst du die Abkürzung, damit die Arbeit weitergeht. Dann gehst du zurück und holst dir die echte Lösung, damit das Problem nicht wiederkommt. Die Versuchung: die Abkürzung für das Ende halten. Weitermachen fühlt sich produktiv an. Aber die Zeit, in der du ein wiederkehrendes Problem verstehst, ist Zeit für die Zukunft: Sie nimmt demselben Fehler die Chance, noch einmal aufzutreten. Für diese Analyse gilt eine feste Regel: Es geht nicht um Schuld. Die Fragen richten sich an den Prozess und an die Anforderungen. Waren die Anforderungen klar? Wenn nicht, warum nicht? Es geht darum zu verstehen, was schiefgelaufen ist, damit die nächste Runde sauberer läuft. Nie darum, jemanden zu finden, dem man es anhängen kann. Root Cause Analysis wirkt über den eigenen Bereich hinaus Löst du ein Problem gründlich, bleibt die Wirkung selten in deiner Ecke des Systems. Problemlösung nach Lean zieht meist Kreise durch die ganze Kette. Gräbst du dich in ein einzelnes Problem hinein, berührt es oft mehr als den Teil, für den du zuständig bist. Es kann bis in den Betrieb reichen, in Prozesse, die anderen Teams gehören. Um die ganze Kette zu verbessern, arbeitest du mit allen Beteiligten zusammen, denn dort liegt der eigentliche Gewinn. Bei IKEA hat das in der IT angefangen und ist über die IT-Prozesse hinausgewachsen. Außerhalb des ursprünglichen Teams Leute ohne Lean-Erfahrung zu gewinnen, ist schwieriger. Aber die angrenzenden Prozesse haben begonnen, sich an die Arbeit anzupassen, die schon lief. Die Lehre für alle, die klein anfangen: Das kleine Stück, das du jetzt bearbeitest, wirkt auf lange Sicht. Wer es als “nur mein Teil” abtut, übersieht die Kettenreaktion, die folgt. Die Zustimmung des Managements ist der eigentliche Engpass Lean kostet am Anfang Zeit, und Manager unter Druck geben diese Zeit ungern her. Die ehrliche Spannung: Der Manager will jetzt die schnelle Lösung, Lean verlangt Zeit zum Verstehen. Nirmala hatte einen Vorteil: Bei IKEA kam Lean vom Management. Die Führungskräfte waren bereits geschult und wollten Lean im Unternehmen haben, deshalb haben sie akzeptiert, dass die Arbeit anfangs Zeit braucht. Tempo kommt mit der Übung. Am Anfang konnte es ein, zwei Tage dauern, ein komplexes Problem überhaupt zu verstehen. Je mehr die Reflexe ins Denken der Leute übergehen, desto schneller geht dieselbe Analyse. Was das Management überzeugt, ist die Haltbarkeit des Ergebnisses. Löse das Problem einmal richtig, und genau dieses Problem hast du nie wieder. Das ist Qualität für die Zukunft, und damit lässt sich die Zeit rechtfertigen. Lean als Gewohnheit, nicht als einmalige Aktion Lean trägt nur, wenn es zur Routine wird, und diese Routine aufzubauen ist wirklich schwer. Manche sind sofort voll dabei. Andere haben das Gefühl, ihre Zeit zu verschwenden. Schwung aufzubauen und ihn zu halten, bleibt die Daueraufgabe. Damit die Praxis lebendig bleibt, trifft sich Nirmalas IT-Team jeden Freitag. Jede Woche stellt jemand ein Problem vor, das er gelöst hat, und erzählt, wie er dabei gedacht hat. Nächste Woche könntest du dran sein, also bleiben alle bei der Sache, und der Austausch trägt die Methode ins ganze Team. Neben dem wöchentlichen Termin coachen die Kolleginnen und Kollegen mit Green-Belt-Zertifizierung alle, die tiefer in Lean einsteigen wollen. Lean zu verankern ist zu einem großen Teil Bildungsarbeit: Du nimmst die Leute so lange mit, bis eine kritische Masse ganz selbstverständlich danach arbeitet. Passen Lean und Agilität zusammen? Lean und Agilität widersprechen sich nicht, auch wenn manche Mühe haben zu sehen, wie beides zusammengeht. Du behältst deine Dailies und alles, was ohnehin zu deinem Arbeitstag gehört. Lean kommt obendrauf und gibt dir einen Blick dafür, wo die Probleme liegen. Visual Management ist eines der Werkzeuge dafür. Du zeichnest deine Prozesse auf und machst sichtbar, wo deine Tickets liegen und wem welcher Schritt gehört. Am Anfang kostet das Zeit. Wenn du den Dreh raus hast, läuft es rund. Wo du mit Lean anfängst Der Einstieg ist einfach: Lies dich ein. Online gibt es jede Menge Material, genug, um dich selbst zu orientieren. Du kannst auch ChatGPT fragen, mit einem Hinweis von Nirmala: Prüf die Antworten und stell sicher, dass sie stimmen, bevor du danach handelst. Saubere Prozesse werden wichtiger, je mehr KI-Werkzeuge in den Arbeitsalltag kommen. Ist ein Prozess chaotisch und überladen, hilft es nichts, KI darüberzulegen. Die Dinge gleich beim ersten Mal richtig zu machen, ist genau das, wofür Lean gebaut ist. Damit passt es ziemlich genau in diese Zeit. Häufig gestellte Fragen Warum fällt es so schwer, eine Lean-Denkweise anzunehmen, selbst nach monatelanger Übung? Der Reflex, direkt nach einer Lösung zu greifen, ist nach wie vor stark. Nirmala Saneechur, die bei IKEA Lean gelernt hat, sagt, dass ihre erste Reaktion auf ein Problem auch nach anderthalb Jahren Praxis immer noch darin besteht, zu fragen, wie die Lösung lautet. Die Disziplin besteht darin, zunächst die Schnelllösung anzuwenden, damit die Arbeit weitergeht, und dann einen Schritt zurückzutreten und zu fragen, warum das Problem überhaupt entstanden ist. Funktioniert Lean nur in der Fertigung? Nein. Lean begann bei Toyota als Fabrikkonzept, aber die zugrunde liegende Frage lässt sich übertragen: Welche Teile dessen, was du produzierst, helfen dem Kunden tatsächlich, und welche Teile sind wertlose Bewegung? Wird es eher als Denkweise denn als festes Verfahren betrachtet, lässt es sich genauso gut auf einen Softwareprozess anwenden wie auf die Frage zu Hause, ob eine bestimmte Geste überhaupt nötig ist. Kann ein Projekt pünktlich abgeliefert werden und trotzdem als Verschwendung gelten? Ja. Ein Team entwickelte 15 Funktionen für einen Kunden und lieferte sie genau zum gewünschten Zeitpunkt ab. Sobald der Kunde die Anwendung nutzte, hat er keine davon jemals angerührt. Das ist Überproduktion. Rechtzeitige Lieferung bedeutet, das zu liefern, was der Kunde tatsächlich nutzt, und zwar dann, wenn er es nutzt, und nicht, eine Liste mit Anforderungen abzuarbeiten, nur weil jemand sie aufgeschrieben hat. Wie sieht Verschwendung in der täglichen Softwarearbeit aus? Alles, was dem Kunden keinen Mehrwert bringt: Funktionen, die niemand nutzt, Anforderungen, die niemand versteht, Produktionsprobleme, die immer wieder auftreten. Eine Anforderung, die du liest, mit ihrem Verfasser klärst und trotzdem nicht verstehst, führt zu einem Hin und Her, das durch gemeinsame Arbeit am Anfang hätte vermieden werden können. Manche Verschwendung, wie zum Beispiel ein zusätzlicher Doppelklick, nimmst du einfach in Kauf. Verdient jedes Problem eine vollständige Grundursachenanalyse? Nein. Wenn etwas nur einmal passiert, findest du zwar trotzdem die Grundursache, verbringst aber nur wenig Zeit damit. Bei wiederkehrenden Problemen zahlt sich die Grundursachenanalyse aus. Eine Testumgebung, die regelmäßig ausfällt und jedes Mal neu gestartet wird, ist ein klares Signal: Der Neustart ist eine Notlösung, keine dauerhafte Lösung, und es lohnt sich, dieses Muster zu verstehen. Geht es bei der Grundursachenanalyse darum, herauszufinden, wer den Fehler gemacht hat? Nein, und das ist eine feste Regel. Die Fragen zielen auf den Prozess und die Anforderungen ab: Waren sie klar, und wenn nicht, warum nicht? Das Ziel ist es, zu verstehen, was schiefgelaufen ist, damit es beim nächsten Mal reibungsloser läuft. Nach einem Schuldigen zu suchen, bringt nichts; Verständnis verhindert, dass die Fehlerwirkung erneut auftritt. Wie überzeugst du Führungskräfte davon, Zeit für Lean zu investieren, wenn die Fristen knapp sind? Verweise auf die Nachhaltigkeit des Ergebnisses. Löst man ein Problem einmal richtig, taucht genau dieses Problem nicht mehr auf. Das ist Qualität für die Zukunft und rechtfertigt den Zeitaufwand im Vorfeld. Die Analyse geht mit der Praxis auch schneller: Am Anfang kann es bei einem komplexen Problem ein oder zwei Tage dauern, es nur zu verstehen, aber mit der Zeit verkürzt sich das erheblich. Stehen Lean und Agile im Wettbewerb zueinander? Nein, auch wenn es manchen schwerfällt zu erkennen, wie sie zusammenpassen. Du behältst deine Dailies und alles, was ohnehin zu deinem Arbeitstag gehört, und Lean kommt obendrauf als Methode, um zu erkennen, wo die Probleme liegen. Visuelles Management unterstützt das: Du zeichnest deine Prozesse auf und stellst dar, wo sich Tickets befinden und wer für welchen Schritt verantwortlich ist. --- ### Quality Sprint: Wie ein Workshop Qualitätsprobleme löst URL: https://www.richard-seidl.com/de/podcast/quality-sprint-workshop/ Datum: 2026-09-01 Kategorien: Podcast Software Testing Hartnäckige Qualitätsprobleme löst kein Bericht, der Quality Sprint schon: ein Tag mit allen Stakeholdern, drei bis vier Schritte mit klaren Ownern. Der Quality Sprint ist ein kompaktes Workshop-Format, das hartnäckige Qualitätsprobleme in Organisationen adressiert: Ein Tag, alle betroffenen Stakeholder am Tisch, strukturierte Interviews zur Aufdeckung gemeinsamer Pain Points, und am Ende konkrete Action Items mit klaren Verantwortlichkeiten. Ziel ist nicht eine fertige Lösung, sondern drei bis vier umsetzbare nächste Schritte. Das Wichtigste in Kürze - 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. Was ein Quality Sprint ist Ein Quality Sprint ist ein kompaktes Workshop-Format, das hartnäckige Qualitätsprobleme in einem einzigen Arbeitstag angeht. Statt wochenlanger Assessments und dicker Berichte steht am Ende ein Set konkreter nächster Schritte, die ein Team sofort umsetzen kann. Das Format stammt von den Quality Elevators, einer Gruppe von vier unabhängigen Unternehmerinnen und Unternehmern mit Hintergrund in Softwarequalität. Jede und jeder bringt einen anderen Fokus mit: Organisationsentwicklung, Testing, technische Themen wie Performance und Monitoring, Test Design. Je nachdem, wo das Problem eines Kunden liegt, gehen die passenden Personen in den Workshop. Der Ausgangspunkt war eine wiederkehrende Beobachtung: In vielen Unternehmen bleiben Qualitätsprobleme über lange Zeit ungelöst. Man kommt nicht voran. Der Quality Sprint soll die Beteiligten aus dieser Blockade holen und ins Tun bringen. Warum klassische Assessments oft zu lang dauern Lange Assessments erzeugen viel Dokumentation, aber wenig Bewegung. Sie ziehen sich über Wochen oder Monate, und am Ende steht ein umfangreiches Dokument oder eine Präsentation, mit der ein Team im Alltag wenig anfangen kann. Der Quality Sprint dreht dieses Verhältnis um. Ein Tag genügt, um die zentralen Schmerzpunkte zu identifizieren und daraus drei bis vier umsetzbare Schritte abzuleiten. Wir werden nicht die Welt bewegen an einem Tag, aber wir haben dann konkrete drei, vier Steps, die wir mitnehmen. (Roman Kirchmeier) Der Anspruch ist bewusst bescheiden und dadurch realistisch. Ein Team soll den Raum mit einem klaren, kleinen Handlungspaket verlassen, nicht mit einer großen Vision, die im Alltag zerfällt. Warum alle Stakeholder an den Tisch gehören Ein Quality Sprint funktioniert nur, wenn alle betroffenen Rollen im Raum sind. Wird der Kreis auf eine einzelne Abteilung beschränkt, sprintet man nicht weit. Qualität betrifft die ganze Organisation, nicht nur die Software. Sie steckt in Prozessen, in der Zusammenarbeit zwischen Menschen, in den Werten eines Teams. Deshalb gehören Test, Entwicklung, Business-Analyse, Product Owner, Betrieb und Support an einen Tisch: alle, die vom konkreten Problem betroffen sind, oder zumindest Vertreter aus den jeweiligen Bereichen. Der Grund ist einfach. Eine fruchtbare Diskussion entsteht erst, wenn verschiedene Perspektiven aufeinandertreffen. Ruft die Testorganisation an und schildert ihre Herausforderung, sehen Entwickler und Product Owner oft ganz andere Probleme. Diese Reibung ist gewollt. Das gilt schon vor dem Workshop. Wer nur mit der Testabteilung reden darf, weil dort angeblich das ganze Problem sitzt, wird die eigentlichen Ursachen kaum finden. Diese Erwartung klärt man am besten im Vorfeld. Wie groß die ideale Gruppe ist Zehn bis zwölf Personen sind die richtige Größe für einen Quality Sprint. In dieser Runde lässt sich noch gut diskutieren, und man kann sicherstellen, dass jede Stimme gehört wird. Wird die Gruppe größer, kippt die Dynamik. Dann reden schnell immer nur dieselben zwei, drei Leute, während der Rest schweigt oder bereits resigniert hat. Bei sehr großen Teams braucht es deshalb Vertreter statt aller Beteiligten. Ein Workshop mit hundert Leuten funktioniert nicht. Der Ablauf: von den Herausforderungen zu den Pain Points Der Quality Sprint beginnt mit dem Sammeln und Strukturieren der Herausforderungen. Diese Phase klärt, worüber überhaupt gesprochen wird, bevor es in die Tiefe geht. Der zweite Schritt ist der Deep Dive über gezielte Interviews. Mit konkreten Fragen holen die Moderatoren die Pain Points aus den Beteiligten heraus, gerade auch aus denen, die sich sonst selten äußern. Jedes Interview soll mindestens fünf Pains liefern, sonst lässt sich das Material später nicht sinnvoll clustern. Der Quality Sprint ist keine klassische Retro, auch wenn viele mit diesem Begriff eine Vorstellung verbinden. Der Unterschied liegt im Vorgehen. Es geht nicht darum, dass jeder still seine Zettel schreibt und an die Wand klebt. Zuhören schlägt Rechtfertigen Im Interview redet eine Person, der Rest hört zu. Ohne Kommentar, ohne sofortiges “Ja, aber”. Die Runde ist als Timebox gesetzt: Jetzt spricht die Fachvertreterin, alle anderen nehmen auf. Dieses Prinzip zielt auf Verständnis. In vielen Organisationen herrscht Silodenken, bewusst oder unbewusst. Wer der anderen Seite einmal ungefiltert zuhört, merkt oft, dass die eigenen Annahmen über sie nicht stimmen. Die Interviews laufen bewusst öffentlich. Nur wenn die psychologische Sicherheit fehlt, teilt man die Gruppe auf und führt Gespräche getrennt. Auch die Teamdynamik selbst ist ein Signal. Ein spürbares Spannungsfeld ist eine eigene Herausforderung, auf die man das Format anpassen muss. Genau darin liegt ein Kern des Quality Sprints: kein starrer Blueprint, der bei jedem Kunden gleich abläuft, sondern ein Vorgehen, das sich an den Punkt anpasst, wo ein Team gerade steht. Warum die meisten Pains dieselben sind Nach den Interviews werden die Top-Pains der einzelnen Rollen nebeneinandergelegt. In etwa 95 Prozent der Fälle gibt es dabei viel Gemeinsamkeit. Oft merken die Beteiligten das schon beim Zuhören: Der anderen Person geht es ähnlich, oder man beschreibt aus verschiedenen Blickwinkeln dasselbe Problem. Spätestens im Plenum wird sichtbar, dass sich die vielen Einzelpains um einen gemeinsamen Kern drehen. Dieses geteilte Problem erzeugt ein Gemeinschaftsgefühl. Und dieses Gefühl ist die Basis, um danach gemeinsam an konkreten Maßnahmen zu arbeiten. Aus Pains werden Actions im eigenen Wirkungsbereich Nach der Konsolidierung geht es darum, für ein Cluster die nächsten machbaren Schritte zu finden. Die Leitfrage lautet: Was liegt in unserem Wirkungsbereich, unabhängig von Leuten, die gerade nicht im Raum sind? Diese Frage verändert die Haltung. Sie holt Teams heraus aus dem “Ist alles doof, war immer schon so, können wir eh nichts machen” und öffnet den Blick dafür, dass auch kleine Schritte möglich sind. Genau hier sind die Moderatoren gefragt, mit den richtigen Fragen in diese Richtung zu stupsen. Zum Einsortieren der Maßnahmen dient eine Matrix nach dem Vorbild der Eisenhower-Matrix, die Aufwand und Wirkung gegenüberstellt. Aufwand | Wirkung | Einordnung gering | hoch | ideal, gleich nächste Woche angehen höher | hoch | wertvoll, aber mehr Vorbereitung gering | gering | valide, wenn schnell erledigt höher | gering | eher zurückstellen Der Mehrwert der externen Begleitung liegt nicht darin, Lösungen vorzugeben. Wenn ein Team selbst auf umsetzbare Punkte kommt, ist die Motivation höher, als wenn zwei Moderatoren sagen “Macht doch mal das”. Und das Team behält das Gefühl, es selbst zu können. Ownership heißt treiben, nicht alles allein tragen Jede Action bekommt einen Owner oder eine Ownerin. Das bedeutet nicht, dass diese Person die Aufgabe im Alleingang stemmen muss. Sie soll das Thema treiben und andere ins Boot holen. Diese Klarstellung schützt vor einem verbreiteten Missverständnis. Ownership übernehmen wirkt schnell wie eine Last, die man ganz allein trägt. Als Antreiber statt Einzelkämpfer bleibt die Verantwortung tragbar. Warum der Transfer in den Alltag über Follow-ups entscheidet Die beste Motivation aus einem Workshop zerfällt am nächsten Morgen an vollen Postfächern und übervollen Chats. Deshalb steht und fällt der Erfolg mit dem, was nach dem Workshop-Tag passiert. Nach dem Sprint gibt es ein Workshop-Protokoll. Die Quality Elevators besprechen die Findings noch einmal in ihrer Vierergruppe, sodass auch die zwei oder drei Kollegen, die nicht dabei waren, ihre Empfehlungen beisteuern. Diese kompakte Ergänzung geht als Abschlussreport an den Kunden, kein fünfzigseitiges Dokument. Entscheidend sind die Follow-up-Termine, bewusst nicht am nächsten Tag, sondern ein bis zwei Wochen später. Dort holen die Moderatoren die Owner zurück in die Verantwortung mit einer einfachen Frage: Wo stehen wir? Wenn du das selbst ohne externe Begleitung machst, ist dieser letzte Punkt der wichtigste. Definiere konkrete Action-Items mit festem Zeitpunkt und plane kleine Mini-Steps statt großer Ziele für das nächste halbe Jahr. Zu weit gefasste Ziele verschieben sich ohnehin immer wieder. Bei den Follow-ups trennt man faule Ausreden von echten Gründen. Fade Ausreden werden gechallengt. Gibt es berechtigte Hindernisse, hilft man beim Weiterkommen und holt weitere Leute dazu. Ein Blick von außen hilft dann oft, weil alle im Raum im selben schwierigen Kuchen stecken. Häufig gestellte Fragen Was bringt ein einziger Workshop-Tag bei Qualitätsproblemen, die schon lange ungelöst sind? Er bringt Bewegung statt Vollständigkeit. Am Ende stehen drei bis vier konkrete nächste Schritte, die ein Team sofort angehen kann. Der Anspruch bleibt bewusst bescheiden: Ein Tag löst das Problem nicht, aber er holt die Beteiligten aus der Blockade, in der wochenlange Assessments mit viel Dokumentation und wenig Veränderung enden. Wie viele Maßnahmen sollte ein Team aus einem Qualitätsworkshop mitnehmen? Drei bis vier reichen. Ein kleines Handlungspaket mit festem Zeitpunkt trägt weiter als eine große Vision für das nächste halbe Jahr, denn zu weit gefasste Ziele verschieben sich immer wieder. Sinnvoll sind Mini-Steps, vor allem solche mit geringem Aufwand und hoher Wirkung, die schon in der Woche danach starten können. Reicht es, wenn nur die Testabteilung an einem Workshop zu Qualitätsproblemen teilnimmt? Nein. Wird der Kreis auf eine Abteilung beschränkt, bleiben die eigentlichen Ursachen meist verborgen. Qualität steckt in Prozessen, in der Zusammenarbeit und in den Werten eines Teams, deshalb gehören Test, Entwicklung, Business-Analyse, Product Owner, Betrieb und Support an einen Tisch. Wer fehlt, hält sein Problem für unsichtbar. Diese Erwartung klärt man vor dem Workshop. Was macht man, wenn die betroffene Organisation zu groß für einen gemeinsamen Workshop ist? Dann schicken die Bereiche Vertreter. Zehn bis zwölf Personen sind die Größe, bei der noch diskutiert wird und jede Stimme gehört werden kann. Größere Runden kippen: Es reden immer dieselben zwei oder drei Leute, der Rest schweigt oder hat resigniert. Ein Workshop mit hundert Beteiligten funktioniert nicht. Worin unterscheidet sich ein Quality Sprint von einer Retrospektive? Der Unterschied liegt im Vorgehen. Es geht nicht darum, dass jeder still seine Zettel schreibt und an die Wand klebt. Die Moderatoren holen die Pain Points über gezielte Interviews heraus, gerade aus den Beteiligten, die sich sonst selten äußern. Jedes Interview soll mindestens fünf Pains liefern, sonst lässt sich das Material später nicht sinnvoll clustern. Was tun, wenn im Team die psychologische Sicherheit für offene Gespräche fehlt? Dann teilt man die Gruppe und führt die Gespräche getrennt. Normalerweise laufen die Interviews öffentlich: Eine Person spricht, die anderen hören zu, ohne zu kommentieren. Ein spürbares Spannungsfeld im Team ist selbst eine Herausforderung, auf die man das Vorgehen anpasst. Ein starrer Blueprint, der bei jedem Kunden gleich abläuft, passt hier nicht. Wie verhindert man, dass ein Team Maßnahmen auf abwesende Entscheider abschiebt? Mit der Leitfrage nach dem eigenen Wirkungsbereich: Was liegt in unserer Hand, unabhängig von Leuten, die gerade nicht im Raum sind? Diese Frage holt Teams aus der Haltung, es sei ohnehin nichts zu machen, und öffnet den Blick für kleine Schritte. Moderatoren stupsen mit Fragen in diese Richtung, statt Lösungen vorzugeben. Muss die Person, die Ownership für eine Maßnahme übernimmt, sie allein umsetzen? Nein. Ownership heißt treiben, nicht alles allein tragen: Die Person hält das Thema in Bewegung und holt andere ins Boot. Ohne diese Klarstellung wirkt Verantwortung schnell wie eine Last für Einzelkämpfer. Dazu gehört ein fester Nachfolgetermin ein bis zwei Wochen später, an dem die Owner gefragt werden, wo sie stehen. --- ### Performance Monitoring mit KI: Alarm bei 70 % CPU-Last URL: https://www.richard-seidl.com/de/podcast/proaktives-performance-monitoring-ki/ Datum: 2026-08-27 Kategorien: Software Testing Unleashed Performance Monitoring mit Alarm bei 70 % CPU-Last erkennt Verlangsamungen, bevor Nutzer abspringen. KI wertet die Logs aus und findet die Ursache. Langsame Systeme sind ein messbares Geschäftsrisiko: Nutzer brechen Anwendungen ab, die länger als fünf Sekunden laden, und Verlangsamungen ohne kompletten Ausfall können Schäden in zweistelliger Millionenhöhe verursachen. Proaktives Performance Monitoring setzt eine Schwelle bei 70 Prozent CPU-Auslastung, löst automatisch einen Alarm aus, sammelt Daten zu den betroffenen Datenbankabfragen und API-Endpunkten und legt die Ergebnisse in einem Ticket ab, bevor Nutzer etwas merken. Die häufigsten Ursachen für Performance-Probleme sind nicht optimierte Datenbankabfragen, Skalierung und Infrastruktur sowie die Lastverteilung. Das Wichtigste in Kürze - Eine Schwelle bei 70 Prozent CPU- oder Ressourcenauslastung löst automatisch einen Alarm aus, bevor das System ausfällt. Nutzer bekommen weder Verzögerungen noch 404-Fehlermeldungen zu sehen. - Langsame Systeme kosten echtes Geld, auch ohne Totalausfall: Ein gemeinsamer Vorfall mit Verlangsamungen bei YouTube und Azure kostete mehr als 70 Millionen US-Dollar. - KI-gestützte Monitoring-Tools wie Bits AI von Datadog finden genau die Datenbankabfrage oder den API-Endpunkt, der ein Performance-Problem verursacht, und verkürzen die Analyse von Stunden auf Minuten. - Nach Rao Dhaligadoos Praxiserfahrung sind nicht optimierte Datenbankabfragen und die Konfiguration von Load Balancern bei hohem Datenverkehr die häufigsten Ursachen für Performance-Probleme in der Produktion. - Wer ohne proaktive Überwachung nur auf Vorfälle reagiert, landet im Krisenstab: In einem konkreten Fall dauerte es 45 Stunden, bis der Betrieb wieder lief. Langsame Systeme kosten Geld, lange bevor sie abstürzen Ein langsames System verliert Kunden und Umsatz, obwohl es technisch noch läuft. Genau hier setzt Performance Monitoring an. Rao Dhaligadoo sagt es ohne Umschweife: Wer sich länger als fünf Sekunden durch den Login quält, gibt die App auf, und bei so vielen Alternativen am Markt ist die nächste nur einen Klick entfernt. Die meisten Teams achten auf den Totalausfall. Die 404-Seite, das Ladesymbol, das sich endlos dreht, der schwarze Bildschirm. Das fällt auf, weil es niemand übersehen kann. Langsamkeit dagegen liegt im toten Winkel. Das System antwortet ja noch, nur eben so schlecht, dass die Leute gehen. Rao nennt einen kombinierten Vorfall bei YouTube und Azure vor etwa zwei Jahren, der mehr als 70 Millionen US-Dollar gekostet hat. Die Systeme waren nicht ausgefallen. Sie waren langsam. Schon diese eine Zahl macht aus Performance ein Geschäftsthema statt einer technischen Feinheit. Warum Nutzer nach fünf Sekunden abspringen Nutzer messen jede Anwendung an der schnellsten, die sie kennen. Den Maßstab setzen mobile Apps: antippen, Ergebnis da. Hinkt eine Website oder ein Geschäftssystem hinterher, wirkt es kaputt, auch wenn es funktioniert. Deshalb ist Langsamkeit das schwierigere Problem. Ein Absturz erzwingt eine Reaktion: Jemand schlägt Alarm, das Team legt los. Langsamkeit wirkt leise. Die Kunden gehen einzeln, und der Umsatzverlust taucht erst lange nach der Ursache in den Zahlen auf. Performance Monitoring: Alarm bei 70 Prozent statt erst beim Ausfall Der Kern dessen, was Rao beschreibt, ist eine Schwelle von 70 Prozent. Überschreitet die CPU-Auslastung oder der überwachte Wert 70 Prozent, geht automatisch ein Alarm raus. Handeln, bevor das System kippt, nicht hinterher. Über 70 Prozent verlieren Systeme erfahrungsgemäß schnell an Leistung. Erst werden sie langsam, dann stürzen sie ab. Wer den Trend bei 70 Prozent erkennt, gewinnt Zeit für Diagnose und Behebung, während die Nutzer weiter bedient werden. Raos Team setzt Datadog als Monitoring-Tool ein. Wird die Schwelle überschritten, sammelt das Tool selbst die nötigen Daten: betroffene Datenbanken, Abfragen, API-Endpunkte, die Netzwerkschicht. Dann legt es ein Ticket in Jira oder JSM an, in dem all das schon drinsteht. Die Automatisierung sammelt. Ein Mensch bewertet. Diese Trennung ist wichtig, denn das Tool kann nicht wissen, ob ein Ausschlag ein echtes Problem war oder eine einmalige Abweichung, weil das Team an diesem Tag bewusst etwas in der Produktion geändert hat. Vom Alarm bis zur Auslieferung der Korrektur Bevor jemand am Ticket arbeitet, wird es geprüft. Ist der Alarm echt oder war es ein Ausreißer? Diese Prüfung schont die Kapazität des Teams, denn an einer Korrektur hängen Entwicklung, Test und Infrastruktur. Danach läuft alles wie beim normalen Testen, nur eben für Performance: Schritt | Was passiert Prüfen | Ein Mensch bestätigt, dass hinter dem Ticket ein echtes Problem steckt Nachstellen | Das Team stellt das Performance-Problem aus der Produktion in einer Testumgebung nach Beheben | Die Entwicklung behebt die eingegrenzte Ursache, mit Daten und Lösungsvorschlägen aus dem Ticket Fehlernachtest | Tester bestätigen, dass das Problem weg ist Regressionstest | Tester prüfen, ob der Rest weiterhin funktioniert Freigabe | Die Korrektur geht in Produktion Einen Fehler in der Testumgebung nachzustellen, ist für Tester Alltag. Bei Performance heißt das: dieselbe Verlangsamung erzeugen, bevor jemand versucht, sie zu beheben. Ist sie nachgestellt, weiß die Entwicklung genau, wo sie ansetzen muss. Eine Verlangsamung aus der Produktion in einer kleineren Umgebung nachstellen Gleiche deine Testumgebung so weit an die Produktion an, wie es die Ressourcen erlauben. Geht das nicht vollständig, skaliere proportional. Hast du nur die Hälfte der Ressourcen, fahre die Hälfte der Last. Über das Verhältnis bleibt der Test aussagekräftig. Dass ein herunterskalierter Test trotzdem trägt, liegt an der Präzision. Ein allgemeiner Lasttest hofft, das Problem mit roher Gewalt auszulösen. Ein gezielter Test kennt die schuldige Datenbankabfrage oder den API-Endpunkt und schickt die Last genau dorthin. Genau deshalb nutzt Raos Team Datadog zusätzlich zum Monitoring, das die Cloud-Plattformen ohnehin mitbringen. Die zusätzliche Detailtiefe zeigt, welche Abfrage und welcher Endpunkt die Verlangsamung verursachen. So stellst du das konkrete Problem nach, statt zu raten. Die wahre Ursache in Gigabytes an Logs finden Die eigentliche Schwierigkeit bei einem Performance-Problem liegt darin, in der Datenmenge die wenigen Stellen zu finden, die das Problem wirklich verursachen. Die Logs gehen in die Gigabytes, Dutzende Prozesse laufen parallel. Die eigentliche Ursache herauszuschälen, das ist die Arbeit. Hier hilft laut Rao KI. Bits AI von Datadog wertet die Monitoring-Daten aus, etwa wie oft jeder Endpunkt aufgerufen wurde und welche Operationen gelaufen sind, und zeigt, wo das Problem sitzt. Von Hand dauert dieselbe Analyse leicht Stunden. Zusätzlich liefert die KI Beispielabfragen und Vorschläge, wie sich der Code korrigieren lässt, und das landet direkt im Ticket. Die Entwicklung entscheidet dann auf einer fundierten Basis, statt bei null anzufangen. Ein Mensch bleibt trotzdem beteiligt, und zwar wegen etwas, das die KI nicht liefern kann: Kontext. Das Tool weiß nicht, ob der heutige Ausschlag eine Anomalie war oder die Folge einer Änderung, die das Team selbst in der Produktion vorgenommen hat. Das muss ein Mensch beisteuern. Die drei häufigsten Ursachen für Performance-Probleme In den Systemen, an denen Rao gearbeitet hat, gehen die meisten Performance-Probleme auf drei Ursachen zurück. - Datenbankabfragen. Die Datenmengen, die Anwendungen verarbeiten, wachsen ständig, und bei Big Data müssen die Abfragen optimiert sein. Nicht optimierte Abfragen sind nach seiner Erfahrung die häufigste Ursache. - Skalierung und Infrastruktur. Wie das System aufgebaut und vernetzt ist, entscheidet, wie es sich unter Last hält. - Lastverteilung. Steigt die Last, stellt sich die Frage, ob der Load Balancer sie noch richtig verteilt. Proaktives Monitoring macht aus Monaten einen Sprint Wer vom reaktiven Feuerlöschen auf proaktive Alarme umstellt, verkürzt die Reaktionszeit drastisch. Rao schätzt, dass Arbeit, die früher einen Monat oder zwei Wochen gedauert hat, heute ungefähr in einen Sprint passt. Früher war jeder Schritt langsam. Kunden riefen an und meldeten, dass das System nicht geht. Wollte ein Team proaktiv sein, musste erst jemand den Bereitschaftstechniker auftreiben. Der brauchte zehn oder fünfzehn Minuten, bis er da war, dann eine halbe bis ganze Stunde für die Analyse und danach noch Zeit, um alles in ein Ticket oder eine E-Mail zu schreiben. Unterwegs schlichen sich Fehler ein. Dazu kam der Widerstand. Entwickler gingen in die Defensive: Das erledigt sich von selbst, bei mir läuft es doch. Jede Übergabe kostete zusätzlich Zeit. Die automatische Datensammlung nimmt den größten Teil dieser Reibung heraus. KI hilft außerdem beim Erstellen der Performance-Skripte, der JMeter-Skripte, was den Zyklus weiter verkürzt. Die Prüfung durch einen Menschen bleibt, weil das Team den Daten ohne Kontrolle nicht vollständig trauen kann. Was reaktives Arbeiten die Menschen kostet Wer nicht proaktiv arbeitet, zahlt einen Preis, der in keinem Ausfallbericht steht: den der Menschen, die das Problem lösen. Rao erzählt von einem Ausfall bei einer Bank, bei dem das Team 45 Stunden am Stück im Büro blieb. Eigentlich hatte er für dieses Wochenende Urlaub geplant. “Der Stress in diesem Krisenstab war enorm. Der CIO kam gegen 13 Uhr im Anzug herein, er war entspannter, aber alle anderen waren … Und dann war es totenstill. Und er sagte nur: Wir können es uns nicht leisten, dass das System noch länger ausfällt.” (Rao Dhaligadoo) Selbst danach dauerte es noch zehn bis fünfzehn Stunden, bis die Produktion wieder lief. Verpasste Zeit mit der Familie, eine verpasste Schulaufführung des Kindes, ein abgesagter Urlaub. Das verlangt reaktives Arbeiten einem Team ab. Proaktives Monitoring soll diesen Stress genauso verhindern, wie es den Umsatz schützt. Im Idealfall sieht der Nutzer nie das Ladesymbol oder die 404-Seite, und das Team muss nie im Krisenstab sitzen, um dafür zu sorgen. Häufig gestellte Fragen Warum bekommen langsame Systeme weniger Aufmerksamkeit als komplette Ausfälle? Weil das System immer noch reagiert. Ein 404-Fehler oder ein Ladesymbol, das nie verschwindet, zwingt jemanden dazu, Alarm zu schlagen. Eine Verlangsamung zehrt still und leise an der Nutzerzahl und kostet nach und nach Kunden, während der Dienst technisch gesehen noch läuft. Der Umsatzverlust wird erst lange nach der Ursache sichtbar. Nutzer geben eine Anwendung auf, bei der die Anmeldung länger als fünf Sekunden dauert, und wechseln zu einer Alternative. Kann eine Verlangsamung echtes Geld kosten, wenn eigentlich gar nichts ausfällt? Ja. Ein kombinierter Vorfall, der YouTube und Azure betraf, kostete mehr als 70 Millionen US-Dollar, und diese Systeme waren nicht ausgefallen, sondern nur langsam. Das macht aus der Leistung kein technisches Detail mehr, sondern ein geschäftliches Risiko. Der Vergleich, den Nutzer anstellen, stammt aus mobilen Apps: Tippen, Ergebnis erscheint. Ein Geschäftssystem, das hinter dieser Erwartung zurückbleibt, wirkt wie defekt, auch wenn es funktioniert. Sollte ein Monitoring-Tool oder ein Mensch entscheiden, ob eine Warnmeldung ein echtes Problem ist? Beides, mit einer klaren Aufgabenteilung. Die Automatisierung sammelt die Belege, sobald ein Schwellenwert überschritten wird: betroffene Datenbanken, Abfragen, API-Endpunkte, die Netzwerkschicht. Dann eröffnet sie ein Ticket in Jira oder JSM mit den angehängten Daten. Eine Person führt dann eine Validierung durch, um zu überprüfen, ob der Alarm ein echtes Problem oder nur eine einmalige Anomalie widerspiegelt, denn eine Behebung erfordert die Einbindung von Entwicklern, Testern und Infrastrukturmitarbeitern. Erfordert der Performanztest eine Testumgebung, die identisch mit der Produktion ist? Nein. Passe die Testumgebung so gut wie möglich an die Produktionsumgebung an, soweit es deine Ressourcen zulassen, und skaliere dann proportional: Wenn du dir nur die Hälfte der Ressourcen leisten kannst, führe die Hälfte der Last aus. Das Verhältnis sorgt dafür, dass der Test aussagekräftig bleibt. Präzision ist wichtiger als Umfang. Ein gezielter Test, der die Last auf die spezifische fehlerhafte Abfrage oder den Endpunkt lenkt, ist besser als ein generischer Lasttest, bei dem man hofft, das Problem durch Brute-Force-Methoden auszulösen. Kann KI die Grundursachenanalyse bei Leistungsproblemen übernehmen? Nicht ganz. Bits AI von Datadog wertet die Überwachungsdetails aus (zum Beispiel, wie oft jeder Endpunkt aufgerufen wurde und welche Vorgänge ausgeführt wurden) und deckt so auf, wo das Problem liegt. Von Hand würde diese Analyse Stunden dauern. Außerdem erstellt sie Beispielabfragen und schlägt im Ticket Code-Korrekturen vor. Der Kontext bleibt menschlich: Das Tool kann nicht wissen, ob ein Spitzenwert abnormal oder selbst verursacht war. Was verursacht die meisten Leistungsprobleme in Produktionssystemen? Drei Ursachen tauchen immer wieder auf. Nicht optimierte Datenbankabfragen sind laut Rao Dhaligadoos Praxiserfahrung am häufigsten, da das Datenvolumen, das Anwendungen verarbeiten, ständig wächst. An zweiter Stelle stehen Skalierung und Infrastruktur: Wie das System aufgebaut und vernetzt ist, bestimmt, wie es unter Last standhält. An dritter Stelle steht der Lastausgleich, also die Frage, ob der Load Balancer den Datenverkehr auch bei steigender Last noch korrekt verteilt. Wie viel Zeit spart proaktives Alerting im Vergleich zum Warten auf Berichte? Arbeiten, die früher einen Monat oder zwei Wochen dauerten, passen nun in etwa in einen Sprint. Der reaktive Ansatz kostete bei jedem Schritt Zeit: ein Anruf vom Kunden, zehn oder fünfzehn Minuten, um den Bereitschaftstechniker zu erreichen, eine halbe bis eine Stunde Analyse, dann das Festhalten aller Informationen in einem Ticket oder einer E-Mail, und dabei immer die Gefahr von Fehlern. KI-generierte JMeter-Skripte verkürzen die Durchlaufzeit noch weiter. Was kostet die reaktive Bearbeitung von Vorfällen die Leute, die sich darum kümmern? Mehr, als jede Ausfallmeldung vermeldet. Während eines Ausfalls bei einer Bank blieb das Team 45 Stunden am Stück im Büro, und es dauerte weitere zehn bis fünfzehn Stunden, bis der Betrieb wieder lief. Ein gestrichener Urlaub, verpasste Zeit mit der Familie, eine verpasste Schulaufführung. Proaktives Monitoring zielt ebenso darauf ab, diesen Stress zu beseitigen wie den Umsatz zu schützen. --- ### Warum vollständige Coverage keine Fehlerfreiheit garantiert URL: https://www.richard-seidl.com/de/podcast/grenzen-code-coverage-metrik/ Datum: 2026-08-25 Kategorien: Podcast Software Testing 100 Prozent Branch Coverage und trotzdem Bugs: Was das über Code Coverage als Metrik sagt und warum am Ende die Assertions entscheiden. Branch Coverage ist eine Form der Code-Coverage, bei der jeder mögliche Zweig einer Bedingung getestet werden muss. Ein einzelnes IF mit einer Und-Bedingung erfordert so mindestens drei Testfälle. Hundert Prozent Branch Coverage verhindert viele Fehler, garantiert aber keine Fehlerfreiheit: Schleifen mit mehreren Durchläufen können weiterhin Bugs verbergen. Das Wichtigste in Kürze - 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. 100 Prozent Branch Coverage: ein Selbstversuch mit klarer Lehre Volle Branch Coverage ist erreichbar, deckt aber nicht alle Fehler auf. Roger Butenuth hat für einen selbst gebauten Interpreter jede einzelne Verzweigung im Code mit Tests abgedeckt und trotzdem noch Bugs gefunden, nachdem die Metrik längst auf 100 Prozent stand. Branch Coverage geht dabei weiter als die üblichen Kennzahlen. Sie misst nicht Methoden oder Zeilen, sondern jeden möglichen Zweig im Kontrollfluss. Ein if mit einer Und-Bedingung braucht deshalb nicht einen Testfall, sondern drei, damit jede Kombination der Verzweigung durchlaufen wird. Genau diese Härte macht den Unterschied zur gängigen Praxis. In vielen Teams einigt man sich auf 70 oder 80 Prozent Coverage, meist auf Line- oder Statement-Ebene. Branch Coverage in dieser Konsequenz zieht kaum jemand durch, weil der Aufwand hoch ist. Das Projekt: ein Lisp-artiger Interpreter in Java Der Ausgangspunkt war kein Testprojekt, sondern ein Interpreter für eine Lisp-ähnliche Sprache, gebaut in Java. Lisp steht für List Processing, und der Kern der Sache sind Listen: immutable, also persistent. Ruft man eine Operation auf, verändert man die bestehende Liste nicht, sondern bekommt eine neue Liste zurück, die aussieht wie die alte plus Änderung. Naiv würde man dafür jedes Mal die komplette Liste kopieren. Das will niemand. Gefragt ist eine Implementierung, die möglichst viel wiederverwendet. Die vorhandenen Optionen taugten für diesen Zweck nur bedingt. - Die ArrayList von Java ist nicht immutable. - Scalas Single-Linked List ist ineffizient beim Zugriff auf das n-te Element, weil man n-mal durchlaufen muss. - Scalas Indexbaum war effizient, verbrauchte aber schon für eine Liste mit einem Element über 200 Byte, zu viel für viele kleine Listen. Also entstand eine eigene Struktur: ein zweidimensionales Array mit exponentiell wachsenden Sub-Arrays, die meisten Operationen mit logarithmischem Aufwand. Der Preis dafür war eine komplizierte Implementierung mit hohem Risiko für Plus-Minus-1-Fehler. Genau deshalb wurde diese Liste gründlich getestet und lag schnell bei 100 Prozent Coverage. Aus diesem Punkt wuchs der Ehrgeiz, die Abdeckung auf den ganzen Interpreter auszudehnen. Reine Funktionen sind leicht, Seiteneffekte sind die eigentliche Arbeit Der einfache Teil sind Funktionen ohne Nebeneffekte. Arithmetik und andere reine Funktionen im Sinne der funktionalen Programmierung verhalten sich wie abstrakte Datentypen. Sie haben keine Abhängigkeiten nach außen, und ihre Tests bleiben überschaubar. Schwierig wird es bei allem, was die Außenwelt berührt. I/O-Operationen wie Datei lesen und schreiben brauchen vorbereitete Testdaten. Für den eingebauten HTTP-Client und HTTP-Server muss jeweils das Gegenstück existieren. Hier half, dass die Sprache Client und Server ohnehin beide mitbrachte, beide auf Standard-Java-Bibliotheken aufgesetzt. Der teuerste Anspruch ist die Vollständigkeit. Wer 100 Prozent will, muss auch den Exception-Handler einer Dateioperation testen. Und dabei will niemand für einen Test die Festplatte vollschreiben. Testbarkeit heißt oft: den Code ändern, damit er testbar wird Die Lösung für diese schwer erreichbaren Zweige war Dependency Injection über Interfaces. Der Scanner der Sprache bekommt nur einen Java Reader gereicht. Für einen Test lässt sich ein Reader einsetzen, der an definierter Stelle eine IOException wirft. So wird der Exception-Pfad gezielt ansteuerbar, ohne echte Fehlerfälle zu provozieren. Ähnlich beim Standard-Output. Der Interpreter läuft normal mit System.out, doch der darin steckende PrintStream lässt sich austauschen. In einem JUnit-Test fängt ein eigener PrintStream ab, was der Interpreter ausgibt, und macht die Ausgabe prüfbar. An mehreren Stellen wurde dafür der Produktivcode selbst geändert. Das ist die unbequeme Wahrheit hinter hoher Testbarkeit: Manchmal ist es besser, den Code so umzubauen, dass man ihn testen kann, als auf einer schwer testbaren Struktur zu bestehen. In einem echten Projekt ist das schwerer durchzusetzen. Hier gab es keinen externen Product Owner, der Autor war sein eigener. In der Praxis wird jemand einwenden, warum man Code allein wegen der Testbarkeit ändern soll. Die Antwort bleibt dieselbe: Testbarer Code ist häufig der bessere Code. Testbarer Code wird oft auch besser lesbar und wartbar Der Umbau brachte mehr als nur grüne Metriken. An einer Stelle wurde in die Listenfunktionen eine Methode eingebaut, die die innere Struktur der Liste ausgibt. Im Produktivbetrieb braucht das niemand, im Test prüft sie, ob die Liste intern die erwartete Struktur hat. Dependency Injection macht den Code flexibler, auch ohne ein Framework wie Spring Boot dahinter. Der zweite Hebel war konsequentes Don’t Repeat Yourself. Kleine Prüfungen wie “wenn Liste leer, wirf Exception” werden gern als Zweizeiler in viele Funktionen hineinkopiert. Jede dieser Kopien verlangt beim Testen wieder eigene Testfälle. Zieht man solche Mini-Prüfungen in eigene Funktionen aus, sinkt die Zahl der Testfälle, und die Lesbarkeit steigt an vielen Stellen sogar. Änderungen finden dann nur noch an einer Stelle statt. Die Kehrseite: Wer an dieser einen Stelle etwas ändert, kann auch viele Aufrufer auf einmal zerlegen. Eine hohe Testabdeckung fängt genau das ab, weil größere Umbauten schnell wieder kontrollierbar werden. Das Verhältnis von Produktiv- zu Testcode lag am Ende bei ungefähr eins zu eins. 100 Prozent fangen das Triviale, nicht das Übersehene Volle Branch Coverage findet Fehler dort, wo man sie nicht erwartet. Der übelste Fund war eine Sicherheitslücke in der Basic Authentication eines Webservice. Die Methode sollte übergebenen User und Passwort gegen die bekannten Werte prüfen. An einer Seite fehlte das this vor user und passwort, der übergebene User wurde also mit sich selbst verglichen. Jeder wäre durchgekommen. Die betroffene Zeile war durch einen ersten Test bereits abgedeckt. Erst der Anspruch, auch alle Zweige des doppelten if zu treffen, erzwang die beiden Testfälle mit falschem User bzw. falschem Passwort, und damit fiel der Fehler auf. Ohne Branch Coverage wäre er unsichtbar geblieben. Trotzdem findet auch 100 Prozent nicht alles. Beim Advent of Code, einer Reihe täglicher Programmieraufgaben in der Weihnachtszeit, tauchte ein weiterer Bug in der Listenimplementierung auf. Es ging um eine while-Schleife, getestet mit null und einem Durchlauf. Der Fehler steckte in einem Index, der gegen Ende eines Schleifendurchlaufs verschoben und erst im nächsten Durchlauf benutzt wurde. Der Grund war ein klassisches Copy-Paste-Problem. Den Code gab es zweimal, einmal für Änderungen vorne, einmal hinten an der Liste. In der kopierten Variante stand ein Plus, wo ein Minus hingehört hätte, der Index lief in die falsche Richtung. Solche Fehler über Schleifengrenzen hinweg fängt Branch Coverage strukturell nicht ab. Man macht Fehler an Stellen, wo man denkt, das ist zu trivial, da ist kein Fehler. Roger Butenuth Die übrig gebliebenen Fehler waren wenige, aber sie waren da. Die Lehre daraus ist nicht Fehlerfreiheit, sondern Demut. Wo man früher Code einfach hinschrieb, lohnt sich ein zweiter Gedanke. Warum eine Coverage-Vorgabe allein nichts bringt Eine feste Prozentvorgabe steuert Qualität nicht zuverlässig. Jede Metrik, die man vorgibt, lässt sich austricksen, und genau das passiert dann auch. Eine Zahl als Ziel erzeugt Testfälle, die die Zahl erfüllen, nicht unbedingt Testfälle, die Fehler finden. Coverage ist zudem nur so gut wie die Assertions dahinter. Es gibt Code mit ordentlicher Abdeckung und trotzdem unsinnigen Prüfungen. Eine hohe Coverage hilft dir nur mit vernünftigen Assertions, sonst misst sie ausschließlich, dass Code durchlaufen wurde. Für die Auswahl der Abdeckung zählt der Kontext: Wofür entsteht die Software, wie kritisch ist sie, wie teuer ist ein Fehler im Betrieb. Aus dieser Frage folgt, wie weit du gehen solltest. Coverage-Art | Was sie prüft | Aufwand Line / Statement | ob eine Zeile ausgeführt wurde | niedrig Branch | ob jeder Zweig durchlaufen wurde | hoch Exception-Handler sind ein gutes Beispiel für die Grenze. Sie sind schwer zu covern. Wenn ein Codebestand aber quer durchzogen ist von verstreuten Handlern, ist die bessere Frage nicht, wie man sie alle testet, sondern ob die Struktur überhaupt so aussehen sollte. In realen Projekten sind 100 Prozent nicht erreichbar, und das ist in Ordnung. Statt an einer Metrik lässt sich Qualität eher an der Vernunft der Entwickler festmachen. Der Ort dieser Debatte verschiebt sich außerdem mit der Ebene: In Integrationsprojekten liegen die Probleme nicht in Unit-Tests, sondern zwischen den Systemen, wo eine sinnvolle Testabdeckung ganz anders aussieht. Häufig gestellte Fragen Wie unterscheidet sich Branch Coverage von der üblichen Line Coverage? Branch Coverage zählt nicht ausgeführte Zeilen, sondern jeden Zweig im Kontrollfluss. Ein if mit einer Und-Bedingung braucht deshalb drei Testfälle statt einem, damit jede Kombination der Verzweigung durchlaufen wird. Der Aufwand ist deutlich höher als bei Line- oder Statement-Coverage. Dafür fallen Fehler auf, die eine bereits abgedeckte Zeile verdeckt, etwa ein falscher Vergleich in einer zusammengesetzten Bedingung. Welche Coverage-Werte setzen Teams normalerweise an? Verbreitet ist eine Einigung auf 70 oder 80 Prozent, meist gemessen auf Line- oder Statement-Ebene. Branch Coverage mit diesem Anspruch zieht kaum jemand konsequent durch, weil der Aufwand hoch ist. Im beschriebenen Interpreter-Projekt entstand der Ehrgeiz zur vollen Abdeckung erst an einer besonders fehleranfälligen Datenstruktur, einem zweidimensionalen Array mit exponentiell wachsenden Sub-Arrays. Welche Codeteile machen bei hoher Testabdeckung die meiste Arbeit? Alles, was die Außenwelt berührt. Reine Funktionen wie Arithmetik haben keine Abhängigkeiten und bleiben im Test überschaubar. Datei-I/O verlangt vorbereitete Testdaten, für einen HTTP-Client braucht es einen Server und umgekehrt. Am teuersten ist die Vollständigkeit: Auch der Exception-Handler einer Dateioperation muss durchlaufen werden, ohne dass ein Test die Festplatte vollschreibt. Ist es vertretbar, Produktivcode allein wegen der Testbarkeit umzubauen? Ja, denn testbarer Code ist häufig der bessere Code. Über Dependency Injection mit Interfaces lassen sich schwer erreichbare Zweige gezielt ansteuern: Der Scanner bekommt einen Reader gereicht, der im Test an definierter Stelle eine IOException wirft, und der PrintStream hinter System.out wird im Test ausgetauscht, um Ausgaben prüfbar zu machen. In echten Projekten ist dieser Umbau politisch schwerer durchzusetzen. Warum treibt kopierter Code den Testaufwand nach oben? Jede Kopie bringt eigene Zweige und damit eigene Testfälle. Kleine Prüfungen wie “wenn Liste leer, wirf Exception” landen gern als Zweizeiler in vielen Funktionen. Zieht man sie in eine eigene Funktion, sinkt die Zahl der Testfälle und Änderungen finden nur an einer Stelle statt. Die Kehrseite: Ein Fehler dort trifft viele Aufrufer, was eine hohe Abdeckung wiederum abfängt. Welche Fehler übersieht auch eine vollständige Branch Coverage? Fehler über Schleifengrenzen hinweg. In der Listenimplementierung überlebte ein Off-by-One-Fehler die volle Abdeckung, weil eine while-Schleife nur mit null und einem Durchlauf getestet wurde. Der versetzte Index wurde erst im nächsten Durchlauf benutzt. Ursache war Copy-Paste: In der kopierten Variante für das Listenende stand ein Plus statt eines Minus. Solche Fälle deckt die Metrik strukturell nicht ab. Bringt eine feste Coverage-Vorgabe im Projekt bessere Qualität? Nein. Jede messbare Schwelle lässt sich erfüllen, ohne sinnvolle Assertions zu schreiben, und genau das passiert dann. Eine Zahl als Ziel erzeugt Testfälle, die die Zahl erfüllen, nicht Testfälle, die Fehler finden. Sinnvoller ist die Frage nach dem Kontext: wie kritisch die Software ist und was ein Fehler im Betrieb kostet. --- ### E2E-Testautomatisierung: große Testsuites stabil halten URL: https://www.richard-seidl.com/de/podcast/testbares-html-stabile-tests/ Datum: 2026-08-20 Kategorien: Software Testing Unleashed E2E-Testautomatisierung bleibt wartbar mit eigenem HTML-Testattribut, wenigen Testfällen mit hoher Überdeckung und einer klaren Schichtarchitektur. Stabile Ende-zu-Ende-Tests für große, langlebige Anwendungen entstehen nicht durch mehr generierten Testcode, sondern durch eine wartbare Grundlage. Lilia Gargouri, die Testautomatisierung für große E-Government-Projekte aufbaut, nennt drei Bausteine: eine verlässliche Erkennung der UI-Elemente über ein eigenes HTML-Attribut für Tests, eine bewusst kleine Auswahl aussagekräftiger Testfälle und eine geschichtete Framework-Architektur mit zentraler Logik und einer festen Namenskonvention. Das Wichtigste in Kürze - Ein eigenes HTML-Attribut, das nur für Tests existiert und 2017 eingeführt wurde, sorgt in einem großen Portfolio von Behördenanwendungen bis heute für eine stabile Erkennung der UI-Elemente. - Wer das DOM für das Testwerkzeug auf den gerade relevanten Abschnitt eingrenzt, trifft auch Felder, die sich auf einer Seite mehrfach wiederholen, ohne komplizierte Selektoren. - Fünfzehn gut gewählte Testfälle für die wichtigsten Szenarien bringen auf Dauer mehr als fünfhundert unscharfe, die Laufzeit und Wartungskapazität auffressen. - Fest eingebaute Wartezeiten summieren sich unbemerkt: In einem untersuchten Projekt kosteten sie zwei Stunden pro Testlauf, bis ein Detektor für den Belegt-Zustand der Anwendung sie ersetzte. - Heißt jede Automatisierungsprozedur “Aktion plus fachliche Bezeichnung”, etwa “Name eingeben”, finden sich neue Teammitglieder ohne zusätzliche Dokumentation im Testcode zurecht. Testautomatisierung ist Softwareentwicklung, keine Nebensache Wer Ende-zu-Ende-Tests über Jahre stabil halten will, muss die Testautomatisierung als eigenes Softwareprojekt innerhalb des großen Projekts behandeln. Das heißt: Architektur, Namenskonventionen, Entwurfsmuster und dieselbe Sorgfalt wie beim Produktivcode. Lilia Gargouri war fünfzehn Jahre in der Softwareentwicklung, bevor sie in die Qualitätssicherung und die Testautomatisierung im großen Stil wechselte. Aus dieser Sicht ist die Abkürzungsmentalität rund um Automatisierung die Wurzel der meisten Probleme. Schnell generierter Testcode skaliert nicht. Er beschleunigt nur das Chaos. Was ein unzuverlässiger Ende-zu-Ende-Test ist Ein unzuverlässiger Ende-zu-Ende-Test, im Jargon ein “flaky” Test, schlägt mal fehl und läuft mal durch, ohne dass sich an der Anwendung etwas geändert hat. Ende-zu-Ende-Tests stehen an der Spitze der Testpyramide, und genau dort sammelt sich diese Unzuverlässigkeit. Teams verbrauchen regelmäßig einen großen Teil ihrer Automatisierungszeit mit instabilen Tests und Wartung. Die Probleme sind alt und bekannt, und sie bleiben. Wer ohne Strategie einfach KI darauf ansetzt, vervielfacht sie nur schneller. Ein typisches Beispiel ist eine Tabelle mit fünfzig Lösch-Buttons, jeder davon ein kleines Symbol. Der Test soll genau einen davon treffen. Ein wackeliger Locator erwischt heute den richtigen und morgen den falschen oder gar keinen. Das Ergebnis ist rot, obwohl die Anwendung funktioniert. Warum große Unternehmensanwendungen schwache Automatisierung bestrafen Langlebige Unternehmenssoftware legt jede Schwäche einer Testsuite offen. Läuft eine Anwendung fünfundzwanzig Jahre, entwickelt sie sich über viele Release-Zyklen weiter und ist fachlich komplex, dann wächst alles gleichzeitig: die Zahl der Tests, die Laufzeit und der Wartungsaufwand. Lilia baut Automatisierung für große E-Government-Projekte, und dort ist dieser Druck ständig da. Neue Funktionen kommen dazu, während die bestehenden gepflegt werden müssen, und die Suite wächst in jede Richtung. Ohne klare Strategie von Anfang an landen Teams schnell in der Wartungsfalle und kommen nicht mehr heraus. Deshalb zählt die Reihenfolge. Am Anfang steht nicht das Generieren von Tests. Zuerst kommt die Erkennung der Elemente, dann der Testentwurf, dann die Priorisierung und erst ganz am Schluss die Implementierung. Wie ein eigenes HTML-Attribut die Oberfläche testbar macht Zuverlässige Ende-zu-Ende-Automatisierung beginnt mit einer genauen Erkennung der Elemente, und die hängt an der Qualität des HTML. Die Erkennung im Nachhinein zu reparieren, ist ein Provisorium, keine Lösung. Weltweit zielt der größte Teil der Automatisierung immer noch auf Weboberflächen. Die Schwierigkeit ist also, auf ein winziges, ganz bestimmtes Element zu zeigen. Genau hier scheitern instabile Locators. Die dauerhafte Lösung ist ein eigenes HTML-Attribut, das nur für Tests existiert. Ob es “Data-Role-Attribut” heißt oder “Test-ID”, entscheidet das Team. Sein Wert dient ausschließlich der Erkennung im Test, er ist in der ganzen Anwendung Pflicht und ändert sich nie. Fehlt das Attribut, ist das ein Bug-Ticket für die Entwicklung. Diese Entscheidung zahlt sich über Jahre aus. Lilias Team hat das Attribut 2017 eingeführt und profitiert bis heute davon. Automatisierung ist die Summe vieler kleiner Entscheidungen, die sich zu Effizienz aufaddieren. Der zweite Baustein ist ein zentraler Mapper. Er ordnet jedem Attributwert eine Klasse der Testautomatisierung zu, sodass das Werkzeug eine Tabelle, eine Zeile, eine Zelle oder einen Symbol-Button erkennt. Liegt diese Zuordnung an einer Stelle, liegen dort auch Implementierung und Wartung, und sie ist geladen, sobald sich der Browser öffnet. Barrierefreiheitsattribute als zusätzliche Informationsquelle Barrierefreiheitsattribute liefern dem Testcode gleich noch Bedeutung mit. E-Government-Anwendungen müssen auch für blinde Menschen nutzbar sein, deshalb sind Attribute wie aria-label und alt ohnehin vorhanden und inhaltlich aussagekräftig. Lilias Skripte lesen diese Informationen aus und reichern damit die Identität der UI-Elemente an. Der Nebeneffekt ist echte Überdeckung: Die Tests prüfen nebenbei, ob die Barrierefreiheitsattribute für die Menschen, die darauf angewiesen sind, überhaupt Sinn ergeben. Und Code, der sich liest wie die Oberfläche, die er bedient, versteht man später leichter. Den Ausschnitt verkleinern, um genauer zu treffen Wer das DOM auf einen einzelnen Abschnitt eingrenzt, kann präzise zielen. Wiederholt sich ein Feldname in vielen Abschnitten, trifft man das fünfte Feld auf einer vollen Seite nicht verlässlich. Der Trick: Der Rest des DOM verschwindet für das Werkzeug, nur der relevante Abschnitt bleibt übrig. Mit kleinem Ausschnitt trifft der Test genau, die Läufe werden stabil, und auch Wiederholungsläufen kann man trauen. Stabilität entsteht aus vielen solchen Entscheidungen zusammen. Über Labels identifizieren für stabilen, generischen Code Die Identifizierung über Labels hält Tests lesbar und in diesem Umfeld auch stabil. In Behördenanwendungen ändern sich die Beschriftungen von Eingabefeldern selten, ein Locator wie “das Textfeld mit dem Label Name” hält also lange. Labels machen außerdem Mehrsprachigkeit billig. Die Übersetzungen der Labels kommen in eine Tabelle, der Code verweist generisch auf das Label, und dieselbe Codezeile läuft je nach Anmeldung auf Englisch, Italienisch oder in jeder anderen Sprache. Eine ID, eine Zeile, keine Duplikate. Wenige Testfälle mit hohem Wert entwerfen Wenige, gut geschnittene Ende-zu-Ende-Tests schlagen eine große, redundante Suite. Von fünfhundert Testfällen hält Lilia wenig. Fünfzehn, die das wichtigste Verhalten abdecken, reichen, um ein ernsthaftes Gespräch über Qualität zu beginnen: Sind die grün, kann man über den Rest reden. Jeder Testfall ist wie ein Stein im Rucksack, den du jahrelang mitträgst. Ist der Rucksack schwer, leidet die ganze Tour. Also entscheidest du bewusst, was einen Platz verdient. Drei Säulen bestimmen die Qualität eines Testfalls. Säule | Leitfrage Szenario | Worauf liegt der Fokus, und ist er kritisch? Lässt sich ein Schritt streichen, ohne Überdeckung zu verlieren? Testdaten | Welche Grenzwerte und Äquivalenzklassen haben echten Wert, und sind die Daten wiederverwendbar und wartbar? Implementierung | Hält die Implementierung den Wartungsaufwand niedrig, ob manuell oder automatisiert? Schneide jeden Testfall auf seinen Kern zurück. Zieh die Fälle nicht blind aus dem Testmanagementwerkzeug und automatisiere sie mitsamt ihrer Redundanz. Kläre den Fokus, streich Schritte, die nichts beitragen, und wähle Testdaten, die wirklich etwas abdecken, statt überall “ABC123” einzutragen. Teure Automatisierung mit bedeutungslosen Daten bringt nichts. Erst das Backlog priorisieren, dann automatisieren Ein fertig definiertes Backlog ist kein Startschuss fürs Programmieren. Es ist der Moment, in dem du eine Reihenfolge wählst, die zu deiner Lage passt. Prioritäten hängen von Strategie und Kontext ab. Vielleicht automatisierst du zuerst die geschäftskritischen Fälle, damit eine grüne Pipeline dort Sicherheit gibt, wo es darauf ankommt. Vielleicht nimmst du dir die Fälle vor, die manuelle Tester am meisten Zeit kosten, damit sie sich um neue Funktionen kümmern können. Vielleicht deckst du zuerst die Happy Paths oder die meistgenutzten Abläufe ab. Die richtige Reihenfolge ergibt sich aus dem Hier und Jetzt, nicht aus einer festen Regel. Ein dreischichtiges Framework hält Ende-zu-Ende-Tests wartbar Eine geschichtete Architektur sorgt dafür, dass die Automatisierung Jahre voller Änderungen übersteht. Die Struktur folgt dem Automatisierungsmodell des ISTQB Advanced Level: Kernbibliotheken unten, Geschäftslogik in der Mitte, Testskripte oben. Testfälle und Testsuites liegen ganz oben und rufen Prozeduren auf, die die fachlichen Abläufe abbilden. Die Geschäftslogik ruft die Bibliotheken auf. Jede Schicht hat genau eine Aufgabe. Auch die Bibliotheken sind geschichtet. Das Werkzeug bringt eine Standardbibliothek mit, und die reicht nie. Darüber liegt eine projektübergreifende Firmenbibliothek für Funktionen wie das Wechseln zwischen Browserfenstern, damit nicht jedes Projekt sie neu erfindet. Darüber folgt eine Projektbibliothek für wiederkehrende Interaktionen, etwa ein Kontextmenü hinter drei Punkten: Eine Prozedur bekommt die gewünschte Aktion und führt sie aus. Spezialbibliotheken kümmern sich um E-Mail- und PDF-Inhalte. Jedes Mal, wenn du etwas Neues baust, gehört es in die passende Bibliothek. Eine Namenskonvention sorgt für sauberen Code Einheitliche Namen halten eine wachsende Suite lesbar. Welche Konvention es genau ist, zählt weniger als die Konsequenz, mit der man sie überall und immer anwendet. Lilias Konvention lautet: Aktion plus Fachbegriff. Die Aktion ist “eingeben”, “markieren” oder “klicken”, der Fachbegriff ist das Label. “Name eingeben” heißt also, einen Wert in das Feld mit dem Label “Name” zu schreiben. Der technische Widget-Typ taucht im Namen nicht auf: Checkbox, Radiobutton und Datumsauswahl sind alle “eingeben” plus ihr Label. Man könnte die Augen schließen und sich allein anhand der Fachbegriffe durch die Anwendung bewegen. Lesbarer Code verkürzt die Einarbeitung deutlich. Neue Leute in Lilias Team verbringen bewusst Wochen mit einem einzigen Testfall, bis sie die Konvention verinnerlicht haben und überall anwenden. Die Struktur der Automatisierung entspricht der Struktur der Oberfläche. Wer sich in der Oberfläche auskennt, findet sich auch im Code zurecht. Darin steckt auch ein Warnsignal. Wenn du dich dabei ertappst, dass du suchst, wo etwas implementiert ist, ist deine Ordnung nicht gut genug. “Wenn du dich dabei ertappst, dass du etwas suchst, wo haben wir das implementiert und wo, dann ist dein System nicht gut genug.” (Lilia Gargouri) Wie man der Wartungsfalle entkommt: eine Änderung, eine Stelle Zentralisierung und generischer Code halten die Wartungskosten bei Änderungen klein. Ändert sich etwas, gibt es in einer gut strukturierten Suite im Idealfall genau eine Stelle, an der du es anpasst. Zum Vergleich: verkettete IDs und roher XPath. Schlägt so eine Zeile fehl, zerlegst du sie erst, um den kaputten Teil zu finden, dann entscheiden, ob es ein Bug oder ein Feature ist, und das jedes Mal aufs Neue, wenn die Zeile fehlschlägt. Unter Release-Druck verlieren Teams genau damit ihre Tage. Gefährlich wird es, wenn die Suite ohne Struktur wächst. Du suchst nach einer ID und findest fünfhundert Treffer, dann steht ein Release-Kandidat an, in dem sich genau dieses Element als Feature geändert hat, und du musst fünfhundert Stellen schnell reparieren. Das ist eine tickende Zeitbombe. Stabile Testläufe statt verschwendeter Wartezeit Stabile Ausführung entsteht, wenn der Test auf das richtige Signal wartet und nicht auf die Uhr. Fest eingebaute Wartezeiten summieren sich unbemerkt und lösen an der Wurzel nichts. Statt fester Wartezeiten hilft ein Detektor, der erkennt, ob die Anwendung beschäftigt ist. Er baut auf demselben Resolver auf, wartet, solange der Spinner sichtbar ist, und macht weiter, sobald die Anwendung bereit ist. In einem Projekt mit vierzig Testsuites kamen allein durch Wartezeiten zwei Stunden pro Lauf zusammen: zwei Millisekunden hier, zwei Millisekunden da, für nichts verloren. Halte die Umgebung aktuell, denn Versionen beeinflussen sich gegenseitig. Browser, Java, Gradle, das Testobjekt und das Testwerkzeug verändern sich mit der Zeit und müssen zusammenpassen, damit alles stabil bleibt. Isoliere den Testlauf. Auf der Maschine oder im Container sollte nichts anderes parallel laufen, sonst erbst du Nebeneffekte, Schwankungen in der Performance und Fehler, die nicht deine sind. Und kein anderer Prozess sollte an die Daten deiner Tests gehen, sonst jagst du wegen fremder Exceptions Phantomfehlern hinterher. Modulare Testfälle schaffen Spielraum unter Druck Modularität macht aus einer starren Suite etwas, das du bei Bedarf neu zusammenstellen kannst. Jeder Testfall ist eine eigenständige Einheit, der egal ist, was vor oder nach ihr läuft. So lassen sich Testläufe aus einer Auswirkungsanalyse zusammenstellen: Du wählst die nötigen Themen und lässt sie gemeinsam laufen. Die Testsuites sind nach fachlichen Themen getrennt. Wächst eine über dein Zeitlimit hinaus, bei Lilia ist das eine Stunde, teilst du sie ohne großen Aufwand in Unterthemen auf. So kannst du Smoke-, Integrations- und funktionale Tests nacheinander laufen lassen und früh abbrechen, wenn schon die kritische Ebene scheitert. Der Nutzen zeigt sich in unangenehmen Momenten. Als ein Werkzeug-Update die Electron-Variante einer Fachanwendung lahmlegte, lief derselbe Testcode weiter gegen die Webversion. Geändert hat sich nur die Vorbedingung: Statt der Electron-App öffnete sich ein Browser. Nach fünf Minuten lagen funktionale Ergebnisse aus den Webtests vor, während das Electron-Problem behoben wurde, und das Release war nicht blockiert. Wie man eine alte, instabile Testsuite rettet Die Rettung einer Altsuite beginnt mit einem parallelen Repository, nicht mit einem Umbau an Ort und Stelle. Die alte Welt läuft weiter, daneben entsteht die neue, und irgendwann schaltest du komplett um. Zuerst steht die saubere Struktur, aufgesetzt aus einer Projektvorlage. Darin implementierst du neue Testfälle nach der Namenskonvention. Brauchst du Prozeduren und Bibliotheken, holst du die wertvollen Teile einzeln aus der alten Suite und baust sie als sauberen Code in der neuen Bibliothek nach. Lilia hat genau diese Situation als Entwicklerin übernommen und die neue Lösung Stück für Stück aus dem alten Durcheinander herausgelöst. Die Migration braucht Zeit, und anzufangen lohnt sich trotzdem. Auch zehn Kilometer beginnen mit dem ersten Schritt, und die Alternative ist ein weiterer Tag voller instabiler Tests und ein großer Teil der Arbeitszeit, der in Wartung versickert. Weniger Wartung ist am Ende eine Frage der Lebensqualität. Häufig gestellte Fragen Warum werden Ende-zu-Ende-Tests in großen, langlebigen Anwendungen unzuverlässig? Ende-zu-Ende-Tests stehen an der Spitze der Testpyramide, und genau dort konzentrieren sich die Unzuverlässigkeiten. Bei Unternehmenssoftware, die 25 Jahre lang läuft, wächst alles gleichzeitig: die Anzahl der Tests, die Ausführungszeit und der Aufwand für die Wartung. Teams, die damit beginnen, Testcode zu generieren, ohne zuerst die Erkennung und das Design zu klären, schaffen es nicht, die Testsuite skalierbar zu machen. Sie beschleunigen das Chaos. Was macht einen UI-Locator über viele Jahre hinweg stabil? Ein spezielles HTML-Attribut, das ausschließlich zum Testen hinzugefügt wurde. Sein Wert dient nur der Testerkennung, ist in der gesamten Anwendung eine Anforderung und ändert sich nie; fehlt es, ist das ein Bug-Ticket für den Entwickler. Das Team von Lilia Gargouri hat ein solches Attribut 2017 eingeführt und profitiert noch immer davon. Ein zentraler Mapper verknüpft jeden Wert mit einer Klasse für die Testautomatisierung. Können Barrierefreiheitsattribute für die Testautomatisierung genutzt werden? Ja. In E-Government-Anwendungen müssen Attribute wie „aria-label“ und „alt“ für blinde Nutzer ohnehin vorhanden sein, und sie haben eine echte Bedeutung. Testskripte extrahieren diese Informationen, um die Identität von UI-Elementen anzureichern. Der Nebeneffekt ist die Überdeckung: Die Tests prüfen implizit, ob die Barrierefreiheitsattribute für die Menschen, die darauf angewiesen sind, Sinn ergeben. Wie können dieselben automatisierten Tests für mehrere Sprachen ausgeführt werden? Indem Felder anhand ihrer sichtbaren Beschriftung statt anhand technischer IDs identifiziert werden. Die Übersetzungen der Beschriftungen liegen in einer Tabelle vor, der Testcode verweist generisch auf die Beschriftung, und dieselbe Zeile wird je nach Anmeldung für Englisch, Italienisch oder eine andere Sprache ausgeführt. Eine ID, eine Zeile, keine doppelten Testfälle pro Sprache. Bei Behördenanwendungen ändern sich die Beschriftungen von Eingabefeldern selten, sodass solche Locators zuverlässig funktionieren. Ist eine große Anzahl automatisierter Ende-zu-Ende-Tests ein gutes Zeichen? Nein. Fünfzehn Testfälle, die die wichtigsten Verhaltensweisen abdecken, liefern einen nachhaltigeren Nutzen als fünfhundert vage definierte, die die Ausführungszeit und die Wartungskapazität belasten. Jeder Fall ist ein Stein im Rucksack, den man jahrelang mit sich herumträgt. Drei Säulen bestimmen die Qualität: der Fokus auf das Szenario, Testdaten, die echte Grenzen abdecken statt „ABC123“, und eine Implementierung, die den Wartungsaufwand gering hält. Warum sind fest programmierte Wartezeiten ein Problem bei automatisierten Testläufen? Sie häufen sich unbemerkt an und lösen das Problem nicht an der Wurzel. In einem Projekt summierten sich die Wartezeiten über vierzig Testsuiten hinweg auf zwei Stunden pro Durchlauf, zwei Millisekunden hier und zwei Millisekunden dort. Die Alternative ist ein „Application Busy Detector“, der auf demselben Resolver basiert: Er wartet, solange der Spinner sichtbar ist, und fährt fort, sobald die Anwendung bereit ist. Wie wird Testcode für neue Teammitglieder lesbar genug? Durch eine einheitliche Namenskonvention, die überall angewendet wird. Jede Prozedur wird als „Aktion“ plus „Geschäftsbezeichnung“ benannt, zum Beispiel „Name eingeben“, während der technische Widget-Typ aus der Bezeichnung herausgehalten wird: Checkbox, Radiobutton und Datumsauswahl heißen alle „eingeben“ plus ihre jeweilige Bezeichnung. Jeder, der sich in der Benutzeroberfläche zurechtfindet, kann sich dann auch im Code zurechtfinden, ganz ohne separate Dokumentation. Was bringt es, wenn Testfälle unabhängig voneinander laufen? Du kannst Testläufe nach Bedarf neu zusammenstellen, zum Beispiel ausgehend von einer Auswirkungsanalyse, und eine Testsuite in Unterthemen aufteilen, wenn sie dein Zeitlimit überschreitet (in Lilias Setup ist das eine Stunde). Der Nutzen zeigt sich in heiklen Situationen: Als ein Tool-Update die Electron-Variante einer Anwendung lahmlegte, lief derselbe Test nach Änderung nur der Vorbedingung auf der Webversion, und die Veröffentlichung wurde nicht blockiert. --- ### KI als Tester: Mit LLM as a Judge Sprachmodelle prüfen URL: https://www.richard-seidl.com/de/podcast/llm-tests-automatisierung/ Datum: 2026-08-18 Kategorien: Podcast Software Testing KI als Tester: Mit LLM as a Judge und kalibrierten Rubriken lassen sich LLM-Anwendungen automatisiert testen, auch ohne deterministisches Ergebnis. LLM-Tests automatisieren bedeutet, nicht-deterministische KI-Systeme systematisch prüfbar zu machen. Weil Sprachmodelle keine konsistenten Ausgaben liefern, ersetzen Akzeptanzbereiche und Bewertungsrubriken klassische Ja/Nein-Assertions. Beim Ansatz LLM as a Judge bewertet ein zweites LLM die Ausgaben des Systems unter Test, kalibriert an menschlichen Expertenbewertungen. Das Wichtigste in Kürze - 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. KI-Systeme testen heißt, Nicht-Determinismus als Feature zu akzeptieren Wer klassische Testautomatisierung gelernt hat, baut auf Determinismus und Konsistenz. Ein Test läuft, das Ergebnis ist reproduzierbar, grün bleibt grün. Bei Sprachmodellen fällt dieses Fundament weg. Ein LLM antwortet auf dieselbe Frage nicht zwingend zweimal gleich. Der gewohnte Reflex ist, so ein Verhalten auszuschließen: als Race Condition, als Flakiness, als Bug im Testaufbau. Bei generativen Systemen ist das falsch. Der Nicht-Determinismus gehört zum Design des Systems, nicht zu seinen Fehlern. Anupam Krishnamurthy beschreibt den nötigen Bruch so: Die Erwartungen an eine deterministische, konventionelle Software sind komplett andere als an einen Chatbot, der gefühlt ein Leben für sich selbst hat. Genau dieser Perspektivwechsel steht am Anfang jeder sinnvollen Teststrategie für KI-Komponenten. Warum KI zunehmend das Testobjekt wird, nicht nur das Testwerkzeug Zu KI im Testen gibt es viele Beiträge, Meinungen, Tools und Lösungen. Deutlich seltener behandelt jemand die umgekehrte Richtung: KI als Testobjekt. Anwendungen bekommen immer mehr KI-Bauteile. In Jira und anderen verbreiteten Consumer-Tools steckt inzwischen ein KI-Anteil. Damit verschiebt sich die Frage vom “Wie nutze ich KI zum Testen” zum “Wie teste ich Software, die selbst KI enthält”. Die manuelle Prüfung durch eine Domain-Expertin reicht dafür nicht. Du kannst nicht dauerhaft von einem Menschen abhängig sein, der jede Antwort einzeln bewertet. Sobald KI-Anteile in Produkten normal werden, braucht es automatisierte Verfahren, um sie zu prüfen. Vertrauen entsteht über Guardrails, nicht über vollständiges Verständnis Klassisch baust du Vertrauen in ein System über Verständnis auf: Du weißt, was der Code tut. Bei neuronalen Netzen ist dieses Verständnis nicht vollständig gegeben, und das lässt sich auch nicht wegtesten. Der Ausweg sind Guardrails, Tests und Evaluations. Auch wenn du dein System nicht zu hundert Prozent verstehst, gibt dir ein definierter Rahmen Sicherheit: Solange sich das Verhalten innerhalb festgelegter Grenzen bewegt, kannst du es nutzen. Neu ist dieses Denken nur für Softwareentwickler und Tester. Machine-Learning-Fachleute arbeiten längst so. Die Aufgabe für die Testdisziplin besteht darin, eigene Methodiken für diesen Umgang zu entwickeln. Wie du ein KI-System nach Komplexität der Bewertung zerlegst Der erste konkrete Schritt ist, das System in Prüfaufgaben unterschiedlicher Komplexität zu zerlegen. Das ist im Kern dasselbe Vorgehen wie im klassischen Testen mit verschiedenen Abstraktionsebenen, nur mit anderen Zielen. Der passende Testansatz hängt stark vom Use Case ab. Bildgenerierung verlangt andere Prüfungen als Textgenerierung. KI ist ein Werkzeug, und dein Ansatz muss sich an deiner konkreten Lösung ausrichten. Am Beispiel textbasierter Conversational Models lässt sich die Bewertung in Stufen ordnen: Stufe | Was geprüft wird | Wie automatisierbar Deterministisch | Faktenantwort in festem Format, z. B. JSON, alphabetisch sortiert | Klassisch mit pytest oder gewohntem Framework, per Assertion Faktbasiert, Freitext | Korrektheit von Freitextantworten mit objektivem Kern | Aufwändiger, aber belegbar Subjektiv | Ton, Hilfsbereitschaft, Präzision der Antwort | Am schwersten, braucht kalibrierte Bewertung Adversarial | Sicherheit gegen Prompt-Manipulation | Eigene Testklasse, nicht optional Deterministische Prüfungen sind schnell zu erstellen und liefern sofort Wert. Wenn dein Chatbot Fakten immer im gleichen JSON-Format mit fester Reihenfolge zurückgeben soll, prüfst du das mit einem normalen automatisierten Test. Diese Art von Tests solltest du reichlich haben. Warum Adversarial Testing bei Sprachmodellen zur Pflicht wird Bei generativen Systemen gibt es keine klare Grenze zwischen einer Anweisung in natürlicher Sprache und dem Verhalten des Systems. Ein Nutzer kann per Freitext Verhalten auslösen, das eigentlich nicht vorgesehen war. Daraus entstehen Sicherheitsrisiken, die es vorher so nicht gab. Adversarial Testing prüft gezielt, ob sich das Modell durch manipulative Eingaben aus seinem gewünschten Rahmen drängen lässt. Diese Prüfung darfst du nicht vergessen, wenn du systematisch vorgehst. Sie gehört neben die faktbasierten und subjektiven Tests, nicht dahinter. Wie ein LLM ein anderes bewertet: der LLM-as-Judge-Ansatz Für Freitext und subjektive Kriterien setzt sich ein Ansatz durch, der ein weiteres LLM als Bewerter einsetzt. Ein zweites Modell urteilt darüber, ob die Antwort des Systems under Test in einem akzeptablen Rahmen liegt. Das klingt einfacher, als es ist. Der berechtigte Einwand: Teilen zwei Sprachmodelle nicht dieselben blinden Flecken? Wie stellst du sicher, dass der LLM-Judge das bewertet, was auch ein Mensch beurteilen würde? Praktisch lässt sich das Risiko senken, indem du für Judge und System verschiedene Modelle nutzt, weil sie dann weniger Blindspots teilen. Für den Judge kannst du auch ein stärkeres Modell wählen als für das System under Test. Das skaliert besser und verursacht bei tausenden Nutzern geringere Betriebskosten als eine manuelle Bewertung. Wichtiger als die Modellwahl ist das Alignment mit der Domain-Expertise. Du brauchst strukturierte Rubriken: klar definierte Kriterien mit genauen Bedingungen und mit Beispielen. Beispiele verbessern die Urteilsqualität eines LLM spürbar, dasselbe Muster kennt man aus der normalen Nutzung von Chatbots. RAG als Testobjekt: warum die Verantwortung bei dir bleibt Wenn du ein Sprachmodell direkt von einem Anbieter nutzt, kannst du einen Teil der Qualitätssicherung an diesen Anbieter auslagern. Bei einem RAG-System geht das nicht mehr. Retrieval Augmented Generation nutzt das Sprachmodell nur als Bauteil. Alles drumherum baust du selbst, und damit bleibt die Verantwortung für die Qualität bei dir. Das erhöht automatisch die Pflicht, sauber zu testen. RAG ist zugleich weit verbreitet, weil es eine niedrig hängende Frucht ist: Du erweiterst die Datenbasis eines LLM, ohne es neu zu trainieren. Genau deshalb taugt es gut als Beispiel für ein realistisches Testobjekt. Wie du die Fehlerursache zwischen Retrieval und Generation isolierst RAG lässt sich sauber in zwei Teile trennen: Retrieval und Generation. Diese Trennung ist der Schlüssel, um herauszufinden, wo ein Fehler steckt. Das Retrieval holt relevante Daten aus einer Vektordatenbank. Dieser Teil enthält in der Regel keinen LLM-Anteil, sondern klassische Machine-Learning-Methoden wie Cosine Similarity, Similarity Search und Semantic Similarity. Die Generation nimmt diese Daten und erzeugt daraus die Antwort. Aus meiner Erfahrung liegen die meisten Probleme im Retrieval. Wenn du ein LLM richtig mit Daten fütterst, kommt auch etwas Vernünftiges heraus. (Anupam Krishnamurthy) Deshalb lohnt es sich, gezielte Tests für Retrieval und getrennt davon für Generation zu bauen. So isolierst du die Ursache, statt das Gesamtsystem als Blackbox zu bewerten. Das Prinzip ist identisch zum klassischen Testen: kleinteilig prüfen, Komponenten und Zusammenspiel trennen. Von grüner Pipeline zu akzeptablem Rahmen Deterministisches Testen kennt nur Rot und Grün: ein No-Go oder ein Go. Bei KI-Systemen brauchst du eine unschärfere Basis. Statt binär zu bestehen, bewegen sich Kriterien in einem Wertebereich, etwa zwischen 50 und 100 Prozent Akzeptanz. Als Quality Gate legst du eine Schwelle fest: Liegt die Bewertung über 80 oder 85 Prozent, gilt das Ergebnis als akzeptabel. Bei subjektiven Kriterien gibt es ohnehin keine streng richtige oder falsche Antwort. Diese Schwellen kalibrierst du mit menschlichen Experten. Studien zur Übereinstimmung zwischen Menschen und LLM-Judges erreichen Agreement-Raten von rund 80 bis 85 Prozent. Zwischen zwei Menschen liegt die Übereinstimmung oft nicht höher. Ein LLM-Judge muss also nicht perfekter sein als ein menschliches Zweitgutachten, er muss den menschlichen Maßstab treffen. Modell-Benchmarks geben dir falsche Sicherheit Öffentliche Modell-Benchmarks vermitteln ein künstliches Gefühl von Sicherheit. Sie behaupten, ein Modell sei so gut wie ein PhD, und liefern damit einen Vergleichswert, der für deinen Kontext wenig aussagt. Das Problem steckt in der Methode. Modelle werden auf Standards trainiert, ähnlich einem Schüler, dem man vorab die Prüfungsfragen gibt und der sie auswendig lernt. Die Prüfung darauf misst dann Auswendiglernen, nicht Eignung für deinen Anwendungsfall. Im produktiven Betrieb fällt dir das auf die Füße, wenn dein spezifischer Kontext andere Anforderungen stellt als der Benchmark. Fair bleibt: Kein Anbieter kann deinen Kontext vorwegnehmen, weil er zu spezifisch für deinen Use Case ist. Genau deshalb musst du eigene Benchmarks setzen. Deine bisherigen Skills sind nicht umsonst Der Umstieg auf KI-Testen entwertet die Erfahrung von Testern nicht. Die analytischen Ansätze, das System zu zerlegen, Komponenten zu isolieren und kontextspezifisch zu prüfen, gelten weiter. Der Unterschied liegt im Umgang mit Nicht-Determinismus. Dafür braucht es kreatives und kritisches Denken, aber vieles aus jahrelanger Praxis als Quality Professional bleibt wiederverwendbar. Der eigentliche Reiz liegt woanders. KI-Testen zwingt dich, Selbstverständliches zu hinterfragen: Wie denken wir, wie kommen wir auf Antworten, was heißt Korrektheit überhaupt. Diese Grundlagen lernt man intuitiv und stellt sie normalerweise nie infrage. Beim Testen generativer Systeme musst du genau das tun. Häufig gestellte Fragen Sind unterschiedliche Antworten auf dieselbe Frage ein Fehler im Testaufbau? Nein. Bei Sprachmodellen gehört Nicht-Determinismus zum Design des Systems, nicht zu seinen Fehlern. Der Reflex aus der klassischen Testautomatisierung, schwankendes Verhalten als Race Condition oder Flakiness auszuschließen, führt hier dazu, dass man am Testobjekt vorbeitestet. Statt reproduzierbarer Gleichheit prüfst du, ob eine Antwort innerhalb eines definierten Akzeptanzrahmens bleibt. Warum reicht die manuelle Prüfung durch eine Fachexpertin bei KI-Funktionen nicht aus? Weil sie nicht skaliert. Du kannst nicht dauerhaft von einem Menschen abhängig sein, der jede einzelne Antwort bewertet. Da KI-Anteile inzwischen in verbreiteten Produkten wie Jira stecken, verschiebt sich die Frage vom Nutzen der KI beim Testen hin zum Testen von Software, die selbst KI enthält. Das verlangt automatisierte Prüfverfahren. Welche Teile eines Chatbots lassen sich noch klassisch mit Assertions testen? Alles, was in festem Format zurückkommt. Eine Faktenantwort in definiertem JSON mit fester Sortierung prüfst du mit pytest oder deinem gewohnten Framework per Assertion. Solche deterministischen Tests sind schnell gebaut und liefern sofort Wert, deshalb solltest du reichlich davon haben. Freitext, subjektive Kriterien wie Ton oder Hilfsbereitschaft und Adversarial-Prüfungen brauchen andere Verfahren. Wie zuverlässig urteilt ein Sprachmodell über die Ausgaben eines anderen? Studien berichten Übereinstimmungsraten von rund 80 bis 85 Prozent zwischen LLM-Judges und menschlichen Urteilen. Zwischen zwei Menschen liegt die Übereinstimmung oft nicht höher. Ein Judge muss also nicht perfekt sein, sondern den menschlichen Maßstab treffen. Das Risiko geteilter blinder Flecken senkst du, indem Judge und System under Test auf verschiedenen Modellen laufen. Welche Sicherheitsrisiken entstehen durch Freitexteingaben in KI-Anwendungen? Bei generativen Systemen gibt es keine klare Grenze zwischen einer Anweisung in natürlicher Sprache und dem Verhalten des Systems. Ein Nutzer kann per Freitext Verhalten auslösen, das nie vorgesehen war. Adversarial Testing prüft gezielt, ob sich das Modell durch manipulative Eingaben aus seinem Rahmen drängen lässt. Diese Testklasse ist nicht optional. Wo stecken die meisten Fehler in einem RAG-System? Meist im Retrieval. Wird ein Sprachmodell korrekt mit passenden Daten gefüttert, kommt in der Regel auch etwas Brauchbares heraus. Deshalb lohnen sich getrennte Tests für beide Teile: Das Retrieval arbeitet mit klassischen Methoden wie Cosine Similarity und Semantic Similarity, die Generation erzeugt daraus die Antwort. So isolierst du die Ursache, statt das Ganze als Blackbox zu bewerten. Wie definiert man ein Quality Gate, wenn Testergebnisse nicht binär ausfallen? Über eine Akzeptanzschwelle statt Rot-Grün. Die Kriterien bewegen sich in einem Wertebereich, etwa zwischen 50 und 100 Prozent Akzeptanz. Liegt die Bewertung über 80 oder 85 Prozent, gilt das Ergebnis als akzeptabel. Diese Schwelle kalibrierst du mit menschlichen Experten, denn bei subjektiven Kriterien gibt es ohnehin keine streng richtige oder falsche Antwort. Taugen öffentliche Modell-Benchmarks zur Auswahl eines Modells? Nur eingeschränkt. Sie vermitteln ein künstliches Gefühl von Sicherheit, weil Modelle auf genau diese Standards trainiert werden, ähnlich einem Schüler, dem man die Prüfungsfragen vorab gibt. Gemessen wird dann Auswendiglernen, nicht die Eignung für deinen Anwendungsfall. Kein Anbieter kann deinen Kontext vorwegnehmen, also musst du eigene Benchmarks setzen.