Software Quality Days 2026: 
Wenn KI testet, muss der Mensch entscheiden

Die Diskussion entstand als Kooperation von German Testing Board, Austrian Testing Board und Swiss Testing Board im Rahmen der jährlichen „Quality Talk“ Reihe. Ich hatte die Ehre, zu moderieren. Auf der Bühne saßen drei Persönlichkeiten mit sehr unterschiedlichen Zugängen zum Thema:

Dr. Elmar Jürgens, Gründer von CQSE und führender Forscher im Bereich Softwarequalitätsanalyse – mit dem seltenen Vorteil, Erkenntnisse aus der Forschung täglich gegen die Realität von Unternehmen zu spiegeln, die seine Produkte einsetzen.

Mateusz Gren, Head of Software Development bei Atos Austria, der KI-gestützte Entwicklung nicht als Konzept kennt, sondern täglich in Projekten mit hunderttausenden Zeilen Code damit arbeitet.

Lucy Dinu, Gründerin und CEO von KHAIO, mit strategischem Hintergrund aus NATO, Daimler und weiteren Stationen – und einer Perspektive auf KI, die nicht bei der Technologie beginnt, sondern bei der Frage, was Organisationen damit eigentlich erreichen wollen.

Die direkte Antwort von Lucy Dinu: Ja. Menschliches Urteilsvermögen und kritisches Denken lassen sich nicht automatisieren. Mateusz Gren stimmte zu: Die führende Rolle bleibt beim Menschen, aber die Art, wie Software entwickelt wird, verändert sich grundlegend.

Die differenzierteste Antwort kam von Elmar Jürgens:

„I think in a testing conference it’s very tempting to now say that we as testers will always be needed. And I think that’s simply not true, at least for a certain definition of tester.“

Sein Argument: Der Begriff „Computer“ bezeichnete über dreihundert Jahre lang einen Menschen, der mathematische Berechnungen durchführte. Wer heute „Tester“ sagt, meint etwas anderes als noch vor zwanzig Jahren – und in zwanzig Jahren wird das erneut so sein. Wer Scripts manuell durchklickte, ist in vielen Bereichen längst ersetzt. Was bleibt, ist das, was ein LLM nicht autovervollständigen kann: kritisches Denken, Kontextverstehen, das Stellen unbequemer Fragen.

Diese Differenzierung ist wichtiger als die beruhigende Pauschalantwort. Die Rolle verändert sich – das ist keine Bedrohung, sondern eine Gestaltungsaufgabe. Aber nur, wenn man sie aktiv annimmt.

Als diesjähriger Program Chair der EuroSTAR hat Elmar Jürgens alle Einreichungen für das Konferenzprogramm gesichtet: Von 550 Submissions drehten sich rund 300 um KI im Testing. Der Anteil derer, die wirklich eigene Erfahrungen einbrachten – konkrete Ergebnisse statt Versprechen – war deutlich kleiner. Sein Grundsatz: Er glaubt nur, was jemand selbst erlebt oder erfahren hat.

Mateusz Gren brachte Zahlen aus der Praxis: Atos hat die Produktivitätswirkung von KI 2025 auf fünf Rollen gemessen – Projektmanager, Tester, Softwareentwickler, Requirements Engineers und Architekten. Das Ergebnis war stark kontextabhängig. Manchmal ist man ohne KI-Unterstützung schlicht schneller. Und das Messen selbst stieß schnell an Grenzen: Ähnlich wie bei der Einführung von MS Office lässt sich der Beitrag von KI nicht sauber isolieren – er wird Teil der Art, wie Arbeit funktioniert.

Eine Metapher, die ich am Morgen der Diskussion noch gelesen hatte, bringt das Problem auf den Punkt: Man stelle sich eine Autobahn voller Autos im Stau vor. Jetzt ersetze man alle Autos durch Ferraris. Der Stau bleibt. Die Engpässe liegen nicht im Fahrzeug – sie liegen in Architektur, Anforderungen, Koordination, Qualitätssicherung. Mehr Code schneller zu erzeugen, löst das nicht. Es erzeugt mehr, was verstanden, getestet und gewartet werden muss.

Genau hier greift das Paper von Margaret-Anne Storey („From Technical Debt to Cognitive and Intent Debt“), in dem sie ein Triple Debt Model vorschlägt. Neben der bekannten Technical Debt – Schulden im Code selbst – benennt sie zwei neuartige Schuldenformen, die durch KI-gestützte Entwicklung entstehen. Cognitive Debt beschreibt den Verlust des gemeinsamen Systemverständnisses im Team, wenn Code schneller erzeugt wird als Menschen ihn verstehen können. Intent Debt beschreibt den Verlust des explizit festgehaltenen Rationales – das Wissen darüber, warum eine Entscheidung so und nicht anders getroffen wurde, fehlt sowohl Menschen als auch KI-Agenten, die später damit arbeiten müssen.

Das Modell erklärt, warum Produktivitätsversprechen und Praxiserfahrungen so weit auseinanderliegen: Die Gewinne auf der Oberfläche sind real. Die Schulden, die dabei entstehen, sind schwerer sichtbar – und werden später bezahlt.

Lucy Dinu beschreibt in ihrer Beratungspraxis einen Ansatz, der nicht bei der Technologie beginnt, sondern bei der Strategie:

„If the strategy is just ‚give me AI so I can increase my ROI‘, that’s not really a strategy.“

Ihr Beispiel ist konkret: Wenn eine Mitarbeiterin im Marketing durch KI fünf Stunden pro Woche einspart – was passiert mit diesen fünf Stunden? Wenn die Antwort nicht strategisch verankert ist, verpufft der Gewinn. Und die mutigste Frage, die man stellen kann, ist manchmal: Brauchen wir hier überhaupt KI?

Elmar Jürgens differenzierte nach Fehlerkonsequenzen: Der Hype konzentriert sich auf Bereiche, wo Bugs keine gravierenden Folgen haben – Startups mit begrenztem Runway, interne Tools, Wegwerfprototypen. In hochregulierten Bereichen wie Automotive oder Finanzinfrastruktur ist die Zurückhaltung deutlich größer. Und das aus gutem Grund.

Die eigene Beobachtung in seinem Unternehmen: Seit Januar arbeitet das Team intensiv mit Claude Code. In nicht-kritischen internen Systemen ist deutlich mehr Code entstanden. Im Kernprodukt? Keine messbare Veränderung im Code-Volumen – aber qualitativ das Gefühl, schneller zu sein. Das ist keine Datenlage, die 10x-Versprechen rechtfertigt.

Wenn KI den Code schreibt, KI die Tests generiert, alle Tests grün sind – und dann gibt es einen gravierenden Defekt in Produktion: Wer ist verantwortlich?

Lucy Dinu verwendete die Metapher des Michelin-Restaurants: Der Küchenchef verantwortet alles, was das Haus verlässt – unabhängig davon, wer den Teller angerichtet hat. Mit dem EU AI Act rückt Software zunehmend in die Produkthaftung. KI-Tools sind Werkzeuge; Werkzeuge tragen keine Verantwortung.

Mateusz Gren konkretisierte auf Prozessebene:

„If you do automated code reviews, it’s the architect who put that into place – he’s responsible. If it is a developer using Claude for writing his unit tests, and they are nonsense, it’s the developer who committed this unit test.“

Elmar Jürgens ergänzte aus Ingenieursperspektive: Die Frage „Wer ist schuld?“ incentiviert in der Regel falsches Verhalten: Entwickler übernehmen nur noch triviale Aufgaben, um Fehler zu vermeiden. Besser: Verantwortung auf Prozessebene verankern. Bei CQSE gibt es vollständige Code Peer Reviews – nicht als Kontrolle, sondern weil damit immer mindestens zwei Menschen für jede Zeile verantwortlich sind. Das schafft Qualität ohne Schuldzuweisung. Wer KI-Tools einsetzt, übernimmt die Verantwortung für deren Output. In einer regulierten Welt ist das die einzige rechtlich und ethisch haltbare Position.

Die Logik vieler Unternehmen lautet gerade: Wir brauchen weniger Leute, wir brauchen nur noch Seniors, die KI orchestrieren. Juniors, die langsam lernen und viel Betreuung brauchen, rentieren sich nicht mehr.

Ich habe in die Diskussion diese These eingebracht: „The new entry level is a senior.“ Die Idee: Durch KI können Berufseinsteiger von Anfang an auf einem höheren Niveau arbeiten, weil Grundlagenarbeit automatisiert ist.

Elmar Jürgens hielt mit einem einfachen Argument dagegen: CQSE hat in 17 Jahren Unternehmensgeschichte fast ausschließlich Juniors eingestellt – und sieht keinen Grund zur Änderung. Die Fähigkeit zu lernen, die Neugier, die Bereitschaft zur Anstrengung – das sind die Qualitäten, die langfristig zählen. Ob jemand Requirements Engineering beherrscht, ist lernbar. Ob jemand lernen will, nicht.
Lucy Dinu ergänzte: Die Generation, die mit KI-Tools aufgewachsen ist, sieht Dinge anders – und diese andere Perspektive ist wertvoll. Nicht trotz der Unerfahrenheit, manchmal genau deswegen.

Mateusz Gren benannte die Herausforderung aus Unternehmenssicht direkt: Es fehlt an klaren Entwicklungspfaden für Juniors. Die Rolle verändert sich so schnell, dass Unternehmen selbst noch keine Antwort haben, wie Karrierewege in zehn Jahren aussehen sollen. Das ist keine Ausrede – es ist eine kollektive Aufgabe für die gesamte Branche.

Wenn wir jetzt aufhören, in Juniors zu investieren, sägen wir an dem Ast, auf dem wir sitzen. KI generiert heute Code. Aber wer in zehn Jahren entscheidet, ob dieser Code gut ist, muss das irgendwann gelernt haben – durch echte Erfahrung, nicht durch Prompts.

Lucy Dinu: Neugierig bleiben, KI aktiv hinterfragen, nicht blind vertrauen. Und den menschlichen Teil nicht vergessen. Die Fähigkeit zum eigenständigen Denken atrophiert, wenn man sie nicht trainiert.

Mateusz Gren: Wer nicht täglich mindestens dreißig Minuten mit KI-Tools experimentiert, fällt zurück. Die Rolle verändert sich – wer diese Veränderung nicht mitgestaltet, wird von ihr gestaltet.

Elmar Jürgens formulierte das für mich Wesentlichste des ganzen Panels:

„Don’t stop doing as much quality assurance as you do now because it feels like we’re just moving faster – so more things will go wrong, so we can’t do less of the things we used to do to keep things from going wrong.“

Mehr Geschwindigkeit bedeutet nicht weniger Qualitätsbedarf. Es bedeutet das Gegenteil.

Das Panel begann mit der Frage, ob wir noch menschliche Tester brauchen. Die ehrlichere Frage lautet:  Wie stellen wir sicher, dass menschliche Urteile gefällt und getragen werden, in einer Welt in der es immer einfacher scheint, auf diese zu verzichten?

KI kann Code schreiben, Testfälle generieren, Anomalien erkennen. Sie kann nicht entscheiden, was eine Software dürfen soll. Sie kann nicht die ethische Verantwortung tragen, wenn ein Algorithmus Menschen benachteiligt. Sie kann nicht beurteilen, ob ein System wirklich dem dient, wofür es gebaut wurde.

Das ist unsere Aufgabe – der Testing-Community, der Quality Engineers, aller Menschen, die verstehen, was gute Software bedeutet. Nicht nur, was funktionierender Code bedeutet.

Für die drei DACH-Boards ATB, GTB und STB ist das keine abstrakte Debatte. Es ist die Frage, welche Kompetenzen wir in Zertifizierungen verankern, welche Themen wir in Lehrplänen priorisieren und welche Diskussionen wir – gemeinsam mit unseren Partnerboards in Österreich und der Schweiz – auf Konferenzen wie den SWQD weiterführen. Die Diskussion in Wien war ein guter Anfang. Die Arbeit daran hat gerade erst begonnen.