Werkzeuge mit künstlicher Intelligenz können inzwischen Quellcode erzeugen und Tests automatisieren. In Entwicklungsteams löst das eine naheliegende Frage aus: Wird die Rolle der QA-Engineers — also jener Fachleute, die Software systematisch auf Fehler und Schwachstellen prüfen — damit mittelfristig entbehrlich? Ein aktueller Ratgebertext auf Golem.de greift genau diese Sorge auf und kommt zu einer gegenläufigen Einschätzung: Ausgerechnet der KI-Boom könnte die Arbeit von Testfachleuten wichtiger machen.

Für Unternehmen, die Webauftritte, Portale oder Fachanwendungen betreiben lassen, ist das keine akademische Debatte. Sie entscheidet darüber, wie Budgets in Projekten verteilt werden und welche Zusicherungen eine Agentur oder ein internes Team überhaupt noch geben kann.

Was Automatisierung leisten kann — und wo sie endet

Automatisierte Tests sind in der Softwareentwicklung nichts Neues. Neu ist, wie schnell sich Testfälle heute aus bestehendem Code oder aus Anforderungsbeschreibungen generieren lassen. Das senkt die Einstiegshürde: Projekte, in denen früher aus Zeitgründen gar nicht getestet wurde, kommen überhaupt erst zu einer Testabdeckung.

Gleichzeitig verschiebt sich das Problem nur. Ein generierter Test prüft zunächst das, was der Code ohnehin tut. Ob das auch das ist, was fachlich gewollt war, steht damit nicht fest. Diese Unterscheidung zwischen technischer Korrektheit und fachlicher Richtigkeit ist der Kern der Qualitätssicherung — und sie lässt sich nicht allein aus dem Quelltext ableiten, weil die fachliche Absicht dort gar nicht vollständig enthalten ist.

Mehr Code bedeutet mehr Prüfbedarf

Wenn KI-Assistenz die Menge an produziertem Code erhöht, wächst auch die Menge an Code, die niemand im Detail gelesen hat. Das erzeugt zusätzlichen Prüfbedarf an mehreren Stellen:

  • Hat die Änderung unbeabsichtigte Nebenwirkungen in angrenzenden Modulen?
  • Werden Randfälle abgedeckt, die in der Aufgabenbeschreibung nicht erwähnt waren?
  • Stimmen Zugriffsrechte, Datenschutzanforderungen und Barrierefreiheit weiterhin?
  • Bleibt die Lösung wartbar, oder entsteht technische Schuld, die später teuer wird?

Keiner dieser Punkte lässt sich durch die bloße Zahl grüner Testläufe beantworten. Eine hohe Testabdeckung sagt aus, wie viele Codezeilen beim Testen durchlaufen wurden — nicht, ob die richtigen Fragen gestellt wurden.

Die Rolle verschiebt sich vom Ausführen zum Beurteilen

Testarbeit bestand lange zu einem erheblichen Teil aus Wiederholung: dieselben Klickstrecken nach jedem Release, dieselben Formulare, dieselben Browser. Genau dieser Anteil ist automatisierbar, und KI-Werkzeuge beschleunigen ihn weiter. Was bleibt, ist anspruchsvoller: Risiken einschätzen, Prioritäten setzen, Testfälle aus Geschäftsprozessen ableiten, Fehlerbilder deuten.

Diese Tätigkeiten sind weniger handwerklich und stärker analytisch. Sie setzen voraus, dass jemand das Fachgebiet der Anwendung versteht — den Bestellprozess, die Förderlogik, die Redaktionsabläufe im Content-Management-System. Wer diese Zusammenhänge kennt, erkennt Abweichungen, die ein generierter Test nie als Abweichung einstufen würde, weil ihm der Vergleichsmaßstab fehlt.

Neue Prüfaufgaben durch KI-Funktionen im Produkt

Hinzu kommt eine zweite Entwicklung: KI steckt nicht nur im Entwicklungsprozess, sondern zunehmend im Produkt selbst — als Suchfunktion, Assistenzsystem oder Textgenerator. Solche Funktionen verhalten sich nicht deterministisch, liefern also bei gleicher Eingabe nicht zwingend dieselbe Ausgabe. Klassische Tests nach dem Muster „erwartetes Ergebnis gleich tatsächliches Ergebnis“ greifen hier nur eingeschränkt.

Qualitätssicherung muss in diesen Fällen mit Bandbreiten, Stichproben und Bewertungskriterien arbeiten statt mit festen Soll-Werten. Das ist methodisch neu und erfordert Menschen, die beurteilen können, welche Antwort noch akzeptabel ist und welche nicht. Eine Rolle, die eher aufgewertet als abgebaut wird.

Was das für die Projektplanung heißt

Aus unserer Sicht ergeben sich daraus einige praktische Konsequenzen für Auftraggeberinnen und Auftraggeber:

  1. Testbudget nicht automatisch kürzen. Dass Tests schneller entstehen, heißt nicht, dass weniger Prüfaufwand nötig ist. Der Aufwand verlagert sich in die Konzeption und Bewertung.
  2. Abnahmekriterien schriftlich festhalten. Je klarer beschrieben ist, was die Software fachlich leisten soll, desto besser lassen sich sowohl automatisierte als auch manuelle Prüfungen daran ausrichten.
  3. Fachabteilungen einbinden. Wer den Prozess täglich bedient, erkennt Abweichungen schneller als jedes Werkzeug. Strukturierte Testphasen mit echten Anwenderinnen und Anwendern bleiben wertvoll.
  4. Regressionstests aufbauen. Automatisierte Prüfungen, die bei jeder Änderung laufen, sichern vor allem bestehende Funktionen ab — gerade dann, wenn Code schneller entsteht als früher.

Kein Entweder-oder

Die Gegenüberstellung „KI oder Testteam“ führt in die Irre. Realistischer ist eine Arbeitsteilung: Werkzeuge übernehmen Wiederholung, Abdeckung in der Breite und erste Entwürfe von Testfällen. Menschen entscheiden, was überhaupt geprüft werden muss, wo das Risiko liegt und ob ein Ergebnis fachlich tragfähig ist.

Wer Qualitätssicherung als reinen Kostenblock betrachtet, wird versucht sein, sie durch Automatisierung zu ersetzen. Wer sie als Absicherung gegen teure Produktionsfehler versteht, wird sie eher ausbauen — nur mit anderem Schwerpunkt als bisher.

Einordnung für Web- und Softwareprojekte

Für laufende Projekte heißt das: Geschwindigkeitsgewinne durch KI-Assistenz sollten teilweise in Prüfqualität zurückfließen, statt vollständig als Zeitersparnis verbucht zu werden. Sonst verschiebt sich lediglich der Zeitpunkt, an dem Fehler auffallen — vom Test in den Live-Betrieb. Für die Auswahl von Dienstleistern wird damit relevanter, wie strukturiert deren Qualitätssicherung arbeitet und wie nachvollziehbar sie Abnahmen dokumentiert.

Quellen