Ein praxisnaher Blick auf Entscheidungen, Risiken und den Weg ins Doing
Viele sind sich einig: KI wird in der Software-Entwicklung und der Qualitätssicherung (QS) ihren Platz haben. In der Praxis sehen wir jedoch eine große Bandbreite im Kundenumfeld – von großer Zurückhaltung bis hin zu Aktionismus.
Wir beleuchten den Einsatz von KI in der QS aus Unternehmensperspektive: Welche Möglichkeiten sind grundsätzlich realistisch, welche Faktoren bremsen, und wie kommt man mit einer pragmatischen Strategie ins „Doing“, ohne zentrale QS-Prinzipien zu gefährden? Zur Veranschaulichung nutzen wir ein fiktives Unternehmensbeispiel.
KI in der Software-Qualitätssicherung – aktueller Stand der Technik
In Beiträgen zur Nutzung von KI in der QS stehen Effizienzgewinne gerne im Vordergrund, während Details zu den eingesetzten Techniken oft vage bleiben. Dennoch lohnt sich ein kurzer Blick, weil Technikentscheidungen auch Grenzen und Risiken mitbestimmen.
Sprachmodelle (LLMs) sind besonders gut darin, Sprache zu erzeugen und zu strukturieren: Inhalte ordnen, Alternativen formulieren, Unklares zusammenfassen. Für QS-Aufgaben ist das nützlich – und zugleich begrenzt. Ein LLM kennt jedoch firmenspezifische Begriffe und Produkte nicht automatisch und kann plausible, aber falsche Aussagen erzeugen. Wo Nachvollziehbarkeit und Belegbarkeit zählen, ist das eine zentrale Einschränkung.
Daher werden häufig RAG-Ansätze (Retrieval Augmented Generation) genutzt: Das Modell wird bei einer Anfrage gezielt mit passenden Unternehmensinformationen angereichert – z. B. Anforderungen, Spezifikationen, Testfälle, Ticket-Historien oder Prozessbeschreibungen. Das reduziert Halluzinationen deutlich, aber nicht vollständig. Entscheidend ist die Qualität der Wissensbasis: Sind Dokumente aktuell? Welche Version gilt? Wo liegen die relevanten Informationen? Und wer darf was sehen?
Darüber hinaus gewinnen derzeit agentische Ansätze an Bedeutung, bei denen Systeme Aufgaben in Teilschritte zerlegen und mit angebundenen Tools, z. B. über das Model-Context-Protokoll (MCP) eingebunden, Ergebnisse weiterverarbeiten. Für QS ist das interessant, weil viele Tätigkeiten aus wiederkehrenden Schritten bestehen (Informationen sammeln, prüfen, dokumentieren). Der Mehrwert entsteht, weil Systeme nicht nur „antworten“, sondern umfassende Arbeitsabläufe innerhalb klarer Grenzen unterstützen.
Was mit KI in der Qualitätssicherung möglich ist
So vielfältig generative KI-Systeme sind: Im Test und Testmanagement lohnt sich ein fokussierter Einsatz. Ein Blick auf den ISTQB®-Testprozess (vgl. Abb. 1) – oder den des eigenen Unternehmens – hilft, passende Aktivitäten zu identifizieren. Nicht jede profitiert vermutlich gleichermaßen, aber in fast jeder Phase gibt es Assistenzpotenziale:
Analyse & Design: Sprachmodelle können beim Review von Anforderungen helfen (Inkonsistenzen, Widersprüche), strukturierte Testideen aus der Testbasis ableiten, Randfälle ergänzen oder Negativtests vorschlagen. Mit konkret zitierten Quellen in den Ausgaben (z. B. per RAG) steigt deren Verlässlichkeit und ihre Prüfung durch Menschen ist erheblich leichter.
Realisierung/Automatisierung: Nutzen zeigt sich besonders dort, wo viel Routinearbeit anfällt. KI kann Testgerüste nach Standards erzeugen, Redundanzen erkennen oder Skripte/Schlüsselwörter zu mehr Lesbarkeit refaktorieren. Wichtig sind klare Leitplanken: Coding-Standards, Test-Patterns, Review-Regeln und eine saubere Einbettung ins bestehende Framework.
Durchführung & Abschluss: Häufiger Mehrwert liegt in Auswertung und Kommunikation. Testläufe erzeugen Protokolle, Screenshots, Logs, Tickets und Messwerte. Hier sind LLMs stark: strukturieren, zusammenfassen, clustern, Formulierungen vereinheitlichen – und damit Statusarbeit beschleunigen.
Ein roter Faden bleibt: KI liefert in der QS oft die größten Vorteile als Entwurfs-, Struktur- und Assistenzsystem. Der Mensch prüft, entscheidet und verantwortet.

Abbildung 1: Schematische Darstellung der Aktivitäten im Testprozess nach ISTQB® z.T. mit beispielhaften Einsatzmöglichkeiten von KI.
Wo deutsche Unternehmen gerade stehen
Aus der sicher nicht-repräsentativen Projekterfahrung der imbus AG sehen wir dennoch oft ein ähnliches Bild: Unternehmen wissen, dass KI relevant wird, sind aber unsicher, wie sie sie produktiv und zugleich sicher in die Organisation bringen.
Ein kleiner Teil der Unternehmen hat es früh geschafft, klare Rahmenbedingungen zu setzen: Welche Daten dürfen wofür genutzt werden? Welche Modelle/Tools sind erlaubt? Wie werden Ergebnisse gekennzeichnet und geprüft? Und wie fließen sie in Prozesse ein? Lernen ist meist organisiert, und KI-Nutzung wird als Veränderung von Arbeitsweisen verstanden – nicht als reine Ablöse menschlicher Tätigkeiten.
Häufiger begegnen uns aber zwei typische Muster. Zum einen: Tools sind da, aber ihre Wirkung klein. Es gibt Copiloten/LLMs (oft auch in VPCs), aber ohne gemeinsamen Erfahrungsaustausch, ohne Priorisierung von Use-Cases und ohne Qualitätskriterien für KI-Ergebnisse bleiben es Einzelversuche. Viele versanden, obwohl die Technologie grundsätzlich nützlich wäre.
Zum anderen: Übervorsichtiges Abwarten. Es fehlen Leitlinien und sichere Spielwiesen. Motivierte Mitarbeitende experimentieren dennoch (privat oder lokal), Knowhow entsteht – wirkt aber selten in Entscheidungen und Prozesse hinein, weil ein geeigneter ‚Kanal‘ fehlt.
In beiden Mustern sind Potenziale für KI in der QS vorhanden, aber ungenutzt. Wie aber kommen solche Unternehmen kontrolliert ins Handeln?
KI zur Qualitätssicherung einsetzen – aber wie?
Wie das gelingen kann, beschreiben wir am Beispiel der fiktiven HeliMedTec Devices AG (siehe Kasten), die eher in die abwartend-vorsichtige Situation passt.
Für HeliMedTec waren und sind regulatorische Anforderungen gesetzt. Compliance- und Audit-Vorgaben, Datenschutz/IT-Security sowie die Abstimmung zwischen Entwicklung, QS und Zulassung machten „einfach mit KI loslegen“ schwierig. Gleichzeitig stiegen Termindruck und QS-Aufwände sichtbar – der Wunsch nach produktiver KI-Unterstützung war also nachvollziehbar.
Das Management holte erste Werkzeuge ins Haus: eine DSGVO-konforme Umgebung (VPC) mit LLM-Chat-UI und einer angebundenen RAG-Wissensbasis. Die ersten Versuche lieferten jedoch stark schwankende Qualität – teils wegen unscharfer Anfragen, teils wegen unkoordiniert gepflegter Wissensbasis.
Die ersten Gegenmaßnahmen waren unspektakulär pragmatisch: Workshops für strukturiertes Prompting halfen Testern, gezielter formulierte Anforderungsanalysen, Testideen, Testfälle, usw. zu erhalten. Die Aufstellung einer gemeinsamen Wissensbasis durch grundlegende Begriffsdefinitionen und fachspezifische Beschreibungen von Infusionspumpen in der RAG-Datenbank half, fachlich korrekte Ausgaben zu erzeugen. Die dabei mitgelieferten Quellenverweise unterstützen eine einfachere Prüfung der Ergebnisse.
Prompting wurde zuerst als „persönliche Fähigkeit“ wahrgenommen und war schwer teilbar. HeliMedTec löste das, indem wiederverwendbare Textmuster für typische QS-Aufgaben erarbeitet wurden, mit Regeln für Rückfragen bei fehlenden Informationen und Vorgaben für Ausgabeformate. Deren Einbettung als sog. System-Prompts erlaubte so eine hohe Reproduzierbarkeit der Ergebnisse für alle im Team.
Sehr früh stand – typisch im regulierten Umfeld – die Kernfrage im Raum: „Dürfen wir das überhaupt?“ Deshalb formulierte HeliMedTec eine KI-Governance, ausdrücklich als Arbeitsunterstützung: klare, alltagstaugliche Leitplanken. Besonders wirksam waren einfache Regeln, u.a.:
- Welche Tools sind freigegeben?
- Wann müssen KI-Ausgaben geprüft werden?
- Wie werden KI-Ergebnisse gekennzeichnet (Entwurf vs. geprüft)?
- Wer trägt die Verantwortung?
Mit diesen Antworten wurde aus Unsicherheit wieder Arbeitsfähigkeit.
Die regulatorische Perspektive (z. B. mögliche Anforderungen aus der EU-KI-Verordnung) wurde dabei mitgedacht: Da HeliMedTec keine KI-Komponenten im Produkt in Verkehr bringt, lag der Fokus für den internen Einsatz auf Datenschutz/IT-Security, Validierung sowie Audit-Trail und Nachvollziehbarkeit.
Als nächste Schritte plant HeliMedTec, die Aufbereitung von Feld-Rückmeldungen zu verbessern: besser strukturierte Tickets, sauberere Reproduktionsschritte und verständlichere Zusammenfassungen. Das sind Aufgaben, bei denen KI Zeit sparen kann, ohne direkt über Produktqualität zu „entscheiden“. Ziel ist, KI als assistierende Funktion in bestehende Workflows zu integrieren.
Das Beispiel mag fiktiv sein, doch die Effekte sind real, denn sie beschreiben, in veränderter Form, was wir in unseren Kundenprojekten sehen: Auf Sichtweite KI Schritt für Schritt in der QS etablieren ist möglich.
Der Einsatz kann gelingen
KI wird in der QS ihren Platz haben. Entscheidend ist, die Technik realistisch einzuordnen und an konkrete QS-Aufgaben zu koppeln: LLMs liefern Struktur und Entwürfe, RAG schafft Nähe zu Unternehmensfakten, agentische Ansätze unterstützen wiederkehrende Abläufe. Gleichzeitig braucht es klare Regeln, Kennzeichnung und Verantwortung, die letztlich Menschen tragen.
Der pragmatische Weg führt häufig über wenige, gut prüfbare Use-Cases zum Einstieg, organisierten Erfahrungsaustausch und eine anwendbare KI-Governance als Leitplanke. So kommt man ins Doing, ohne die Kernprinzipien der QS zu verlieren: Nachvollziehbarkeit, Vertrauen und klare Verantwortlichkeit.
Als separate Box, die das fiktive Unternehmen skizziert:
Fiktiver Firmensteckbrief: Die HeliMedTec Devices AG
Medizintechnikhersteller für vernetzte Infusionspumpen und Patientenmonitoring. Die Software umfasst Geräte-Firmware, eine Mobile App fürs Klinikpersonal sowie ein Cloud-Portal für Verwaltung, Alarmierung und Reporting.
Hohe QS-Aufwände entstehen insbesondere durch Nachweisführung & Dokumentation rund um Anforderungen, Risiken und Tests, durch Impact-Analysen bei Änderungen sowie durch die strukturierte Bearbeitung von Feld-Rückmeldungen (Incidents/Maßnahmen).
Es besteht grundsätzliches Interesse an KI in der QS. Entscheidungen sind jedoch geprägt durch Compliance-/Audit-Anforderungen, Datenschutz/IT-Security und die Abstimmung zwischen Entwicklung, QS und Zulassung. Die Skepsis, ob KI gerade in QS-Kontexten ausreichend vertrauenswürdig ist, überwog anfänglich.
Über den Autor:
Dr. Gerhard Runze hat an der Universität Erlangen-Nürnberg Elektrotechnik studiert und promoviert. Nach langjähriger Tätigkeit als Entwickler, Projekt- und Teamleiter in der Telekommunikationsindustrie, arbeitet er seit 2015 bei der imbus AG als Testmanager, Trainer und Berater für Qualitätssicherung von KI, Embedded Software und agiles Testen. Er ist Mitautor des Buches “Basiswissen KI-Testen”.

Recent Comments