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)
Wer von „mehr Testkapazität für KI“ spricht, meint je nach Team etwas anderes.
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.
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“.
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.
Matthias Lutz, Business Development Consultant bei sepp.med, zeigt darin in 20 Minuten, wie Sie Ihre Make-or-Buy-Entscheidung entlang konkreter Kriterien strukturieren.
Die Teilnahme ist kostenlos, und Sie nehmen eine belastbare Entscheidungsgrundlage mit in Ihre nächste Budgetrunde.
Nicht automatisch. KI kann Routineaufgaben wie die Testfallgenerierung beschleunigen, verlangt aber Skills, Werkzeuge und laufende Pflege. Zusätzlicher KI-Code erhöht zugleich den Prüfbedarf.
Häufig ja. Bei lernenden oder probabilistischen Komponenten reichen Testfälle mit festem Sollergebnis oft nicht aus. Für Hochrisiko-KI-Systeme kommen Anforderungen der KI-Verordnung (EU) 2024/1689 hinzu.
Er stellt das Gehalt einer Stelle dem Tagessatz eines externen Spezialisten gegenüber. Wartungsaufwand, Auslastung, Einarbeitung und Wissenstransfer bleiben dabei außen vor.
Für budgetentscheidungsberechtigte Führungskräfte mit Sourcing- und Make-or-Buy-Verantwortung für Software-Test, insbesondere in regulierten Umfeldern.
Vorname:
Nachname:
E-Mail-Adresse:
Telefonnummer:
Betreff:
Ihre Nachricht:
Ja, ich bin einverstanden, dass meine personenbezogenen Daten elektronisch erhoben und gespeichert werden. Meine Daten werden nur zum Zweck der Beantwortung meiner Anfragen verwendet. Die Datenschutzhinweise habe ich zur Kenntnis genommen.