Drei KI-Aufgaben im Software-Test, die oft vermischt werden

29.09.2026

Engineering, Künstliche Intelligenz, Software-Test

Das nächste Release ist terminiert, die Testkapazität ist knapp. Seit KI in der Entwicklung mitschreibt, entsteht Software schneller, und eine Frage wird lauter: Wie halten Qualitätssicherung (QS) und Nachweisführung mit? In regulierten Umfeldern muss jede Freigabe zusätzlich dokumentiert und begründet werden. Damit wird Software-Test zur Sourcing-Frage: Testkompetenz selbst aufbauen, externe Spezialisten einbinden oder beides gezielt kombinieren?

Bevor sich diese Frage beantworten lässt, lohnt ein genauer Blick auf das Stichwort „KI im Software-Test“. Dahinter stecken meist drei verschiedene Aufgaben.

Webinar: Testkompetenz im KI-Zeitalter: aufbauen, einkaufen oder kombinieren? (15.10.2026)

Drei Aufgaben, die in einem Topf landen

Wer von „mehr Testkapazität für KI“ spricht, meint je nach Team etwas anderes.

Absicherung KI-generierten Codes: Code, der mit KI-Unterstützung entsteht, muss geprüft werden, bevor er in ein Release geht.
Einsatz von KI im Testprozess: KI erzeugt Testfälle, priorisiert Regressionstests oder repariert Testskripte.
Qualitätssicherung KI-basierter Produkte: Ist KI Teil des Produkts, braucht es Prüfverfahren, die klassisches Testen mit festem Sollergebnis nicht mitbringt.

Die erste Aufgabe zeigt am deutlichsten, warum die Trennung zählt. In einer Befragung von mehr als 1.100 Entwicklerinnen und Entwicklern halten 96 Prozent KI-Code nicht für uneingeschränkt vertrauenswürdig, aber nur 48 Prozent prüfen ihn vor der Übernahme in die Codebasis durchgängig (Sonar, 2025). 38 bis 40 Prozent empfinden die Prüfung sogar als aufwendiger als bei menschlich geschriebenem Code.

Auch das gefühlte Tempo täuscht. In einer kontrollierten Studie brauchten erfahrene Open-Source-Entwickler mit KI-Unterstützung 19 Prozent länger, obwohl sie sich schneller fühlten (Becker et al., 2025). Mehr Code entsteht schneller, die Prüfung hält damit nicht automatisch Schritt.

Warum die Make-or-Buy-Frage ohne diese Trennung ins Leere läuft

Wer die drei Aufgaben nicht trennt, stellt bei der Entscheidung zwischen Aufbau und Zukauf Äpfel neben Birnen. Hinter der Anfrage „Wir brauchen mehr Test“ kann zusätzliche Prüfkapazität stehen, der Aufbau von Werkzeug- und Automatisierungswissen oder ein Spezialthema, für das im Haus niemand Erfahrung hat. Jede dieser Aufgaben hat andere Anforderungen an Kompetenz, Auslastung und Nachweisführung.

Ein einfacher Kostenvergleich, etwa das Gehalt einer Stelle gegen den Tagessatz eines externen Spezialisten, liefert dafür keine einheitliche Rechengrundlage. Die Folge ist eine Entscheidung auf unklarer Basis: Personal wird dauerhaft für die falsche Aufgabe gebunden, und Freigaben lassen sich schwerer belastbar begründen. Welche Kosten der Eigenaufbau allgemein bindet, beschreibt der Artikel „Software-Test selbst aufbauen: die versteckte Rechnung“.

Was eine saubere Trennung bringt

Sind die drei Aufgaben getrennt, lässt sich jede einzeln prüfen: Aufbau, Zukauf oder Kombination. Dabei bleibt interner Aufbau an vielen Stellen die richtige Wahl, etwa wenn produktnahes Wissen im Team ausschlaggebend ist oder die Testlast dauerhaft hoch und stabil bleibt.

Wie diese Prüfung im Einzelnen aussieht und wann die Kombination aus eigenem Team und externen Spezialisten wirtschaftlich besser abschneidet als eine der beiden Reinformen, bleibt an dieser Stelle bewusst offen. Genau das ist das Thema des Webinars.