Trends im Software-Testing entwickeln sich gerade entlang zwei paralleler Felder: KI als Werkzeug für Tester und das Testen von KI-basierten Systemen. Umfragedaten zeigen, dass KI-Unterstützung im Testen bereits Platz zwei nach der Programmierung belegt. Agile Vorgehensmodelle, vor allem Scrum, dominieren inzwischen branchenübergreifend, auch in sicherheitskritischen Bereichen wie Luftfahrt und Medizintechnik.
Das Wichtigste in Kürze
- KI-gestützte Testgenerierung funktioniert heute ausschließlich als Assistenz: Die Ausgaben müssen von Fachleuten geprüft und überarbeitet werden, ein blindes Vertrauen auf generierte Tests ist nicht vertretbar.
- Unter den befragten Testing-Praktikern nutzen Programmierung und Test KI bereits am stärksten, während Requirements Engineering trotz naheliegender Anwendungsfälle wie Dublettenerkennung deutlich weniger KI-Unterstützung erhält.
- Scrum dominiert laut Umfragedaten klar als Vorgehensmodell, und selbst sicherheitskritische Branchen wie Luftfahrt und Medizintechnik haben agiles Vorgehen inzwischen regulatorisch zugelassen.
- Szenariobasiertes Testen für autonome Systeme scheitert in der Praxis weniger an der Grundidee als an zwei konkreten Hürden: der Auswahl repräsentativer Szenarien und dem Modellierungsaufwand für jeden einzelnen Testfall.
KI im Software-Test hat zwei Seiten, die man auseinanderhalten muss
Beim Thema KI im Testen geht es um zwei verschiedene Aufgaben, die sich parallel und mit unterschiedlichem Tempo entwickeln. Auf der einen Seite steht das Testen von KI-basierten Systemen. Auf der anderen Seite das Testen mit KI, also KI als Werkzeug der testenden Person.
Wer beides in einen Topf wirft, verwechselt Reifegrade. Das eine Feld ist noch in der Vorbereitung, das andere bereits in der Praxis angekommen.
Tilo Linz ordnet den Stand der beiden Felder aus der Sicht ein, die er bei Kunden, auf Konferenzen und über die Veranstaltungsreihe Trends in Testing gewinnt, die imbus seit über zehn Jahren durchführt.
Wo steht das Testen von KI-basierten Systemen?
Fast jedes ernsthaft softwareentwickelnde Unternehmen prüft derzeit, welche Funktionen im eigenen Produkt durch KI verbessert oder angereichert werden können. Das trifft nicht nur reine Softwareprodukte, sondern auch hardwarebasierte Systeme, in denen Software steckt: Maschinen, die durch KI intelligenter werden sollen.
In diesen Unternehmen entstehen aktuell Prototypen und Experimente, um auszuloten, wo KI die eigenen Produkte tatsächlich besser macht.
Für den Software-Test heißt das: Die Aufgabe, solche Systeme zu testen, wird gerade vorbereitet, aber noch nicht im Ernstfall ausgeführt. Die Leute machen sich schlau, besuchen Konferenzen, lesen sich ein. Die Systeme sind aber noch nicht so weit, dass sie in Produktion gehen und der Test scharf gestellt wird.
Tilo Linz erwartet, dass dieser Moment in den nächsten Jahren schnell und mit Wucht kommt. Dann steht die testende Person vor der Frage, ob sie wirklich alles gefunden hat, was das System leisten soll, und alle Fehler, die darin stecken. Seine Einschätzung dazu ist eindeutig: In solchen Systemen werden mehr Bugs stecken als in dem, was Tester heute auf den Tisch bekommen.
Beim Testen mit KI führt die Programmierung, der Test folgt dicht dahinter
Eine Umfrage von Trends in Testing zeigt eine klare Reihenfolge, wo KI-Werkzeuge in der Softwareentwicklung schon genutzt werden. Programmierung liegt vorn, Test folgt auf Platz zwei, Requirements Engineering auf Platz drei. Das Projektmanagement ist weit abgeschlagen.
Dass die Programmierung führt, war zu erwarten. Die gängigen IDEs haben heute KI-Assistenten eingebaut, mit denen sich Code direkt anpassen oder hinterfragen lässt.
Überraschend ist der dritte Platz für das Requirements Engineering. Requirements sind sprachliche Dokumente mit sprachlichem Inhalt, also naheliegendes Material für eine Analyse durch Sprachmodelle. Eine Erklärung: Die Befragten kommen aus dem Software-Test und haben womöglich weniger Einblick, was die Kollegen im Requirements Engineering tatsächlich tun.
Auch der niedrige Wert beim Projektmanagement irritiert. Gerade dort, ob agil oder hybrid, liegt eine häufige Quelle von Problemen, wenn die Steuerung nicht sauber läuft. Hier sieht Tilo Linz noch ungenutztes Potenzial.
KI im Test heißt heute Assistenz, nicht Autopilot
Im Testbereich wird KI für die Generierung von Testdaten und von Testfällen eingesetzt. Ein Testfall ist dabei mehr als ein Datensatz: Er umfasst auch die Prozedur, wie der Test eingegeben wird, und das erwartete Ergebnis. Beides wird mit unterschiedlichem Reifegrad je nach Unternehmen ausprobiert.
Ein konkretes Beispiel ist die KI-basierte Generierung von Security-Tests, die auf dem OWASP-Kriterienkatalog aufsetzt. Man beschreibt, was die Anwendung tut, übergibt den aktuellen Kriterienkatalog und lässt sich Testprozeduren zu einem bestimmten Kriterium erzeugen.
Das Ergebnis ist kein fertiger Test. Es muss vom verantwortlichen Security-Test-Spezialisten überarbeitet werden, bevor es wirklich läuft.
Genau das ist der entscheidende Punkt: Diese Systeme arbeiten als Assistenten. Du darfst dich nicht auf die KI verlassen nach dem Muster “wenn es grün ist, ist der Test gelaufen”. Die KI ist eine Hilfe, um schneller zu einer Grundlage zu kommen.
Da entspinnt sich ein interessanter Dialog, und da muss man das herausgreifen, was einem hilft, und das wegwerfen, wo man sagt, das ist jetzt merkwürdig. Tilo Linz
Wohin entwickelt sich die Testautomatisierung mit KI?
Der nächste logische Schritt verbindet die KI-gestützte Generierung von Testabläufen mit keyword-basiertem Testen. Wer bereits eine Bausteinbibliothek hat, in der einzelne Keywords zuverlässig automatisiert sind, kann diese Bausteine durch ein KI-Werkzeug immer wieder neu zu Prozeduren arrangieren lassen.
Kombiniert man dieses Arrangement mit den generierten Testdaten, rückt eine vollautomatische Erzeugung von Testabläufen in Reichweite. Das ist die naheliegende Fortsetzung der heutigen Bausteine, nicht ihre Ablösung.
Agilität ist nicht tot, sondern in der Routine angekommen
Die Behauptung, Agilität sei tot, lässt sich aus der Praxis nicht bestätigen. Umfragen von Trends in Testing aus 2023 und 2024 zeigen das Gegenteil: Agile Vorgehensweisen dominieren, und Scrum führt klar. Dieselbe Tendenz liefert die Umfrage des German Testing Board.
Hinter Scrum folgt Kanban. V-Modell-Projekte gibt es weiterhin, dabei handelt es sich aber meist um Altprojekte, deren Umstellung sich nicht mehr lohnt. Wird heute etwas Neues gestartet, geschieht das in aller Regel agil.
Auch in kritischen Branchen ist das angekommen. In Luftfahrt und Medizintechnik erlauben die zuständigen Behörden inzwischen offiziell ein agiles Vorgehen, sofern die nötigen Sicherheitsnetze eingezogen werden. Auf das V-Modell wird nicht mehr bestanden, wie es früher der Fall war.
Wer von gescheiterten agilen Projekten auf das Ende der Agilität schließt, übersieht zwei Dinge. Erstens muss man fair fragen, ob mehr Projekte scheitern als früher nach Wasserfall oder signifikant weniger. Sind es weniger, spricht das für den agilen Ansatz. Zweitens scheitern Projekte oft, weil Agilität nur oberflächlich eingeführt wird.
Wer Scrum oberflächlich macht und die nötigen Techniken und Praktiken nicht wirklich einsetzt, wurstelt sich genauso durch wie früher im phasenorientierten Vorgehen. Scheitert das Projekt dann, liegt es nicht am Modell. Es dem Phasenmodell oder dem Agilen in die Schuhe zu schieben, führt nicht weiter.
Testen in agilen Projekten braucht die alten Teststufen weiterhin
Die aus dem V-Modell bekannten Teststufen bleiben auch im agilen Arbeiten relevant. Unittest, Integrationstest und Systemtest sind als Abstraktionsebenen weiterhin nötig, nur in einem anderen Kontext und mit anderer Gewichtung.
Diese Perspektive verfolgt Tilo Linz in seinem Buch “Testen in agilen Projekten”. Es betrachtet Agilität primär aus der Sicht der testenden Person, gegliedert nach diesen Teststufen, und erklärt die jeweils zugehörigen Techniken auf jeder Ebene.
Die erste Auflage erschien vor rund zehn Jahren. Die aktuelle Auflage musste einiges an neuem Stoff aufnehmen, bis hin zu DevOps und den toolgetriebenen Entwicklungen dieser Zeit. Man wirft also nicht über Bord, was früher gut war, sondern ordnet es neu ein.
Requirements Engineering hat das größte ungenutzte KI-Potenzial auf kurze Distanz
Wenn die niedrige Nutzung im Requirements Engineering kein Wahrnehmungsfehler der befragten Tester ist, dann liegt hier auf kurze Distanz das größte Potenzial. Requirements lassen sich nach vielen Dimensionen klassifizieren, auswerten und vergleichen, sobald sie erfasst sind.
Ein einfacher, wirksamer Anwendungsfall ist das Erkennen von Dubletten. Zwei Personen formulieren leicht verschieden dasselbe Requirement: eine bekannte Fehlerquelle in der Entwicklung.
Das Werkzeug soll dabei nicht selbst entscheiden, welche Dublette bleibt. Es funktioniert wie ein Code-Analyse-Tool: eine Warnung, dass zwei ähnliche Requirements existieren, mit der Aufforderung, noch einmal zu prüfen oder zu mergen. KI als Checker und Assistent, nicht als Entscheider.
Was ist szenariobasiertes Testen, und warum gibt es zwei Varianten?
Szenariobasiertes Testen existiert in zwei Ausprägungen, die man nicht verwechseln sollte. Die erste ist der Oberbegriff aus ISTQB- und GTB-Sicht: Man schreibt Anwendungsszenarien wie eine User Story auf, bildet Ablaufvarianten A, B, C ab und prüft, wie das Testobjekt darauf reagiert. Das ist eine Generalisierung der bekannten Testprozeduren und Klassifikationen.
Die zweite Variante ist die spezielle Form beim Testen autonomer Fahrzeuge. Hier ist das Szenario ein Verkehrsszenario, etwa eine modellierte Kreuzung mit Fußgängern, Ampeln und Autos in verschiedenen Richtungen. Das Szenario wird formal beschrieben, in einen Simulator gegeben, und die Steuerung des Fahrzeugs muss die Kreuzung ohne Crash bewältigen.
Diese zweite Form ist das eigentlich neue szenariobasierte Testen und deutlich schwerer zu handhaben, weil sich viele autonome Agenten unabhängig voneinander bewegen.
Die zwei Herausforderungen beim szenariobasierten Testen autonomer Fahrzeuge
Die erste Herausforderung ist die Auswahl. Welches Szenario ist es wert, modelliert zu werden? Schafft ein Fahrzeug eine Kreuzung, heißt das nicht, dass es alle Kreuzungen schafft. Die Frage, ob ein Szenario relevant und repräsentativ ist, entspricht einer abstrakten Form der Äquivalenzklassenbetrachtung. Daran wird über verschiedene Formalismen und Normungsinitiativen gearbeitet.
Die zweite Herausforderung ist der Modellierungsaufwand. Ein Szenario muss detailliert genug sein, um den Testzweck zu erfüllen und das Fahrzeug genau den Aspekten auszusetzen, die geprüft werden sollen. Gleichzeitig darf der Aufwand nicht ausufern, damit Modellierung, Review und neue Versionen mit vertretbarem Einsatz machbar bleiben.
Beides macht szenariobasiertes Testen anspruchsvoll. Deshalb wird es noch nicht so stark genutzt, wie die ursprüngliche Hoffnung es vorsah. Gearbeitet wird daran: an Rezepten, Sprachen und Simulatoren, die das Verfahren mit weniger Aufwand möglich machen.
Relevant wird das Verfahren über Autos hinaus. Es betrifft jeden autonomen Agenten, der sich selbstständig bewegt, vom kleinen Roboter bis zur Lieferdrohne.
