Der Wert des Softwaretests zeigt sich erst, wenn Tester ihre Arbeit in der Sprache des Geschäfts beschreiben statt in technischen Kennzahlen. Wer das Testen mit Umsatzzielen und Nutzerzufriedenheit verknüpft, findet im Unternehmen mehr Rückhalt als mit Zahlen zur Codeüberdeckung. Domänenwissen, Prompting-Kompetenz und ein Verständnis der Systemarchitektur gewinnen an Gewicht, je mehr Code von KI generiert wird.
Das Wichtigste in Kürze
- Das Kernproblem des Testens ist nicht die KI, sondern das jahrzehntelange Versäumnis, den Wert des Testens in geschäftlichen Größen wie Umsatz und Nutzerzufriedenheit zu vermitteln statt in technischen Metriken wie der Codeüberdeckung.
- Prompt Reviews sind eine neue Form von Shift Left: Kleine Änderungen im Wortlaut führen zu deutlich anderen KI-Ergebnissen, deshalb wird das Review der Prompts, aus denen Code entsteht, zu einem eigenen Quality Gate.
- Domänenwissen wird wichtiger als tiefe technische Kenntnisse, weil Tester immer öfter KI-generierte Ergebnisse beurteilen, statt selbst Code zu schreiben oder zu pflegen.
- Nicht-funktionale Anforderungen wie Last, Performanz und Barrierefreiheit werden regelmäßig übersehen, und wer die Architektur nicht früh mitdenkt, zahlt nach der Auslieferung teuer für Korrekturen.
- Tester im Abschwung zu entlassen spart kurzfristig Geld und erzeugt langfristig einen Mangel an Menschen, die Systemarchitekturen verstehen und prüfen können, gerade wenn KI-generierte Codebasen wachsen.
Den Wert des Softwaretests zu verkaufen ist die eigentliche Schwierigkeit
Tester können Probleme gut benennen. Schwer tun sie sich damit, zu erklären, was ihr Handwerk einem Unternehmen wert ist. Diese Lücke beim Wert des Softwaretests begleitet die Branche seit fast zwei Jahrzehnten, und keine einzelne Technologie ist dafür verantwortlich.
Das Muster kehrt mit jedem Hype zurück. Um 2010 und 2011 machten Frameworks wie Selenium die Automatisierung zum Trendthema, und das Versprechen klang wie heute: alles automatisieren, die Tester einsparen. Die KI kommt mit genau derselben Botschaft. Die Technologie wechselt, das Missverständnis bleibt.
Die Folgen sieht man in den sozialen Netzwerken. Erfahrene Leute tragen das “Open to work”-Banner, und jedes Mal stellt sich die Frage: Warum sucht jemand, der so gut ist, einen Job? Ein Teil der Antwort ist, dass die Branche nie gelernt hat, ihr Handwerk in den Begriffen zu erklären, auf die Entscheider achten.
Warum Unternehmen im Abschwung zuerst beim Testen sparen
Wenn die Wirtschaft stockt, ist Qualitätsarbeit das Erste, was man streicht. Entwickler schreiben den Code, Designer gestalten die Oberfläche, und das Produkt geht trotzdem raus. Aus diesem Blickwinkel wirkt Testen verzichtbar, also wird hier zuerst gespart.
Das Testen auf die Entwickler abzuwälzen, trägt kurzfristig vielleicht. Oft laden dieselben Unternehmen noch mehr drauf: Code schreiben, testen, Pipelines pflegen, das Produkt in Produktion betreiben. Wer Tester und Junior-Entwickler durch das KI-Tool ersetzt, das gerade auf dem Markt ist, hält das Tempo womöglich eine Weile.
Langfristig geht das nicht auf. Daniel Knott erwartet in fünf bis zehn Jahren eine stark steigende Nachfrage nach Menschen, die Systemarchitekturen wirklich verstehen. Eine App, ein Webprodukt, fast alles, was sich veröffentlichen lässt, entsteht heute in Minuten. Wenn dabei niemand mehr versteht, was generiert wurde, sammeln sich Probleme an.
Tempo ohne Architektur ist eine Schuld, die später fällig wird
Generierter Code ohne tragfähige Architektur ist der Nährboden für nicht-funktionale Probleme. Performanz- und Sicherheitsprobleme liegen selten an der Oberfläche. Sie stecken in der Architektur, in einem schlechten Entwurf oder einer Lücke in der Struktur.
Nach dem Release ist die Architektur das Teuerste, was man noch ändern kann. Deshalb war nicht-funktionales Testen schon vor der KI wichtig, und es wird wichtiger, wenn Code schneller entsteht, als ihn jemand durchdenken kann.
Nicht-funktionale Anforderungen rutschen still vom Radar. Auf die Frage, wann sie zuletzt daran gedacht hätten, mussten manche Produktmanager erst nachfragen, was der Begriff überhaupt bedeutet. Barrierefreiheit bekommt wieder etwas mehr Aufmerksamkeit, auch durch Regulierung. Last- und Performanztests bekommen deutlich weniger. Für Sicherheitstests holt man sich immerhin oft externe Fachleute, trotzdem gerät das Thema insgesamt leicht in Vergessenheit.
Wie Tester den Wert des Testens an Manager vermitteln
Ein Patentrezept gibt es nicht. Was wirkt, hängt davon ab, wer dir gegenübersitzt und woher diese Person kommt.
Kläre zuerst den Hintergrund. Wer aus der Betriebswirtschaft oder dem Marketing kommt, reagiert auf geschäftlichen Nutzen. Verknüpfe das Testen mit dem Ergebnis, für das diese Person verantwortlich ist. Hängt an einem Feature Umsatz, dann argumentiere dort: Der KPI lautet eine Million Umsatz im nächsten Monat, und ohne umfassende Überdeckung in bestimmten Bereichen wird dieses Ziel unwahrscheinlich.
Bei technisch geprägten Leuten brauchst du einen anderen Einstieg. Öffne die Übersicht der Systemarchitektur, zeig, was schon automatisiert ist und wo die Schwachstellen liegen, und schlag dann Maßnahmen vor, die zu diesem Bild passen: mehr API-Tests, Contract Testing, die nicht-funktionalen Themen, je nachdem, was in den Werkzeugkasten dieser Person passt.
Zahlen aus dem Geschäft und aus Nutzersicht kommen an. Umsatz und Nutzerzufriedenheit verschaffen dem Testen Akzeptanz. Mit “Wir haben 20 Prozent Codeüberdeckung und brauchen 80” erreichst du wenig. Für die meisten Manager ist das nur eine Zahl, und Codeüberdeckung klingt zu kompliziert, um daraus etwas abzuleiten.
Ehrlich gesagt bleibt eine Lücke zwischen der täglichen Testarbeit und einem hohen KPI wie der Nutzerzufriedenheit. Eine saubere Formel dafür gibt es nicht. Was das Unternehmen verkauft, was die Konkurrenz in ihre Produkte einbaut, was Kunden im Feedback verlangen: Erst wenn du diese Datenpunkte verbindest, wird der nächste Schritt klar.
Warum Domänenwissen durch KI wichtiger wird
Jahrelang lautete der Rat an fachlich orientierte Tester: Werde technischer, lern eine Programmiersprache, beschäftige dich mit Architekturmustern und Clean Code. Das Wissen hilft weiterhin. Es entscheidet aber nicht mehr darüber, ob die Rolle Bestand hat.
Die KI verschwindet in den nächsten Jahren und Jahrzehnten nicht wieder. Mit Vibe Codern und Tools, die Features auf Zuruf erzeugen, verschiebt sich die Arbeit: Statt jede Zeile Testcode selbst zu schreiben, beurteilst du die Ergebnisse eines Modells. Wie gut dir das gelingt, hängt davon ab, wie tief du die fachliche Domäne kennst.
Die Grundlagen des Softwaretests brauchst du trotzdem, ebenso ein Grundverständnis davon, wie ein System funktioniert. Was ist ein Request, was eine Response, wie läuft die Client-Server-Kommunikation, wie sieht ein moderner Tech-Stack aus? Dieses Wissen liefert neue Testideen und hilft dir, die richtigen Fragen zu stellen, auch die, welche Teile eines Features generiert wurden und wofür noch ein menschlicher Entwickler verantwortlich ist.
Über den eigenen fachlichen Tellerrand zu denken, wird wertvoller. Wenn die KI den Code liefert und alles fertig aussieht, verdient sich ein Tester sein Geld an den Rändern und bei den Fällen abseits des offensichtlichen Pfads.
Prompt Reviews als neue Form des Shift-Left-Testens
Das Review der Prompts, aus denen Code entsteht, ist ein kaum genutzter Ansatzpunkt für Qualität. Im Prompt können Fehler entstehen, bevor die erste Zeile Code existiert.
Beim Prompten entscheidet der Kontext alles. Ändere einen kleinen Teil eines Satzes, und das Ergebnis kann völlig anders aussehen. Ein Entwickler, der ein Modell promptet, trifft Entscheidungen, die den entstehenden Code prägen, und diesen Schritt prüft derzeit fast niemand.
“Für mich ist das eine neue Art von Shift-Left-Testing: die Prompts zu reviewen, die ins System gehen.”
(Daniel Knott)
Solange Menschen ihre Prompts selbst schreiben, können Prompt Reviews zu einer echten Praxis werden. Weiter nach vorn lässt sich eine Qualitätsprüfung kaum verlegen.
Gute Testwerkzeuge überzeugen durch Bedienbarkeit
Ein Testwerkzeug verlängert deine Arbeit, also muss es sich leicht installieren und angenehm bedienen lassen. Was erst tagelange Konfiguration, Abhängigkeitsprüfungen und Gigabytes an Bibliotheken braucht, bremst genau das Testen, das es beschleunigen sollte. Hersteller sollten das als Anforderung sehen, nicht als nettes Extra.
Die KI-Funktionen, die sich lohnen, gibt es bereits in ausgelieferten Produkten. Jenseits des Marketings fallen ein paar Kategorien auf:
| Fähigkeit | Was das Werkzeug tut |
|---|---|
| Testfall-Generierung | Ein Plugin liest Anforderungen und Entwürfe im Ticketsystem und leitet daraus Testfälle ab |
| Testvorschläge aus der Nutzung | Eine versteckte Bibliothek protokolliert, was Nutzer anklicken, bildet die echte User Journey ab und zeigt, welche Fälle sich zu automatisieren lohnen |
| Automatisierung per Prompt | Eine Prompt-Oberfläche macht aus einer schriftlichen Anweisung lauffähige Testautomatisierung oder Konfiguration |
Nichts davon ersetzt das Urteil des Testers. Du wählst weiterhin das Werkzeug, das zu deinem Tech-Stack und deiner Situation passt. Was für ein Team richtig ist, ist für ein anderes falsch, deshalb lässt sich diese Hausaufgabe nicht überspringen.
Probier die Werkzeuge selbst aus, statt dem Pitch zu glauben
Teste die Werkzeuge selbst, statt den Whitepapers zu vertrauen. Hersteller zeigen ihr Produkt immer im besten Licht, so wie du es an ihrer Stelle auch tun würdest. Das Marketing zeigt also, was möglich sein könnte, nicht, was bei dir funktioniert.
Installiere Testversionen, lass sie laufen und schau, was hält und was auseinanderfällt. Wer das regelmäßig macht, bekommt ein Gefühl dafür, wohin sich die Branche bewegt und was in der eigenen Umgebung wirklich zählt. Eine Standardwahl für alle gibt es nicht mehr. Früher griffen alle zu Selenium, im Mobile-Bereich zu Appium, und damit war die Diskussion beendet. Heute ist das richtige Werkzeug eine individuelle Entscheidung.
Auch der Weg, auf dem Hersteller Tester erreichen, verändert sich. Suchmaschinen verlieren an Bedeutung, weil Menschen zu Chat-Oberflächen wechseln, also setzen Hersteller stärker auf soziale Netzwerke und auf Konferenzen, auf denen sie vor dem richtigen Publikum vorführen können. Ein Testautomatisierungs-Lab auf einer Konferenz, mit Arbeitsplätzen zum Ausprobieren abseits des Messestands, ist besser als die übliche Hürde: ein Verkäufer, der dich anspricht, sobald du langsamer wirst, um etwas zu lesen.
Unterschätze nicht, was du schon kannst
Die grundlegenden Testfähigkeiten aus den letzten zehn, fünfzehn, zwanzig Jahren gelten weiterhin, und sie helfen auch beim Umgang mit KI. Ignoriere alle, die behaupten, Testen werde nicht mehr gebraucht oder dein Wissen sei überholt.
Was du jetzt tun solltest: dich ernsthaft mit KI beschäftigen. Lerne Prompting, lerne, wie große Sprachmodelle intern funktionieren, einschließlich Vektordatenbanken und der zugrunde liegenden Prinzipien. Wenig davon hat direkt mit Testen zu tun, und trotzdem schärft es deinen Blick beim Testen.
Das Tempo ist der Grund, heute anzufangen. Die mobile Revolution um 2010 haben manche Unternehmen erst nach mehr als fünfzehn Jahren aufgeholt, und einige liefern bis heute eine schwache App oder gar keine. Die KI bewegt sich um eine Größenordnung schneller. Abwarten ist keine sichere Position.
Häufig gestellte Fragen
Macht KI-generierter Code Software-Tester überflüssig?
Nein. Das gleiche Versprechen kursierte bereits um 2010 und 2011, als Selenium die Automatisierung zum Trendthema machte: alles automatisieren, die Tester entlassen. Die KI kommt mit genau demselben Versprechen daher, und das Missverständnis dahinter hat sich nicht geändert. Was sich verändert, ist die Arbeit selbst: Es geht nun darum, die Modellausgaben zu bewerten und zu hinterfragen, welche Teile einer Funktion generiert wurden und für welche ein menschlicher Entwickler weiterhin verantwortlich ist.
Was sind die langfristigen Kosten, wenn man in einer Konjunkturflaute Tester abbaut?
Eine kurzfristige Einsparung, die sich zu einem langfristigen Mangel entwickelt. Das Abwälzen der Testaufgaben auf Entwickler, die gleichzeitig Pipelines warten und den Produktivbetrieb betreuen, kann die Geschwindigkeit eine Zeit lang aufrechterhalten. Daniel Knott rechnet in fünf bis zehn Jahren mit einer stark steigenden Nachfrage nach Leuten, die Systemarchitekturen wirklich verstehen, denn das Veröffentlichen einer App oder eines Webprodukts dauert heute nur noch Minuten, und vielleicht versteht gar niemand mehr, was da eigentlich generiert wurde.
Warum ist die Behebung von Performanz- und Sicherheitsproblemen so teuer?
Weil sie in der Architektur liegen und nicht an der Oberfläche: ein schlechtes Design oder eine Lücke in der Struktur. Die Architektur ist das Teuerste, was man ändern kann, sobald ein Produkt veröffentlicht wurde. Generierter Code ohne echte Architektur im Hintergrund ist genau der Ort, an dem solche nicht-funktionalen Probleme ihre Wurzeln schlagen, und sie werden meist erst nach der Veröffentlichung sichtbar.
Warum überzeugen Code-Überdeckungs-Zahlen Manager nicht?
Für die meisten Manager ist eine Überdeckungs-Zahl nur eine Zahl, und der Begriff klingt zu kompliziert, um darauf zu reagieren. Mit „Wir haben 20 Prozent und brauchen 80“ zu kommen, bringt nichts. Umsatz und Nutzerzufriedenheit kommen dagegen an. Verknüpfe fehlende Überdeckung in bestimmten Bereichen mit dem Ergebnis, für das die Person verantwortlich ist, zum Beispiel einem KPI von einer Million Umsatz im nächsten Monat.
Sollten Tester immer noch in das Erlernen einer Programmiersprache investieren?
Es hilft zwar immer noch, entscheidet aber nicht mehr darüber, ob die Rolle bestehen bleibt. Fachwissen, Kompetenz im Umgang mit Prompts und ein Verständnis der Systemarchitektur haben mehr Gewicht, wenn es darum geht, generierte Ergebnisse zu bewerten. Die Grundlage, die du brauchst, umfasst die Grundlagen des Softwaretests sowie die technischen Abläufe: Was eine Anfrage und eine Antwort sind, wie die Client-Server-Kommunikation abläuft, wie ein moderner Tech-Stack aussieht.
Können Fehler in ein System gelangen, bevor auch nur eine einzige Zeile Code geschrieben wurde?
Ja, über den Prompt. Der Kontext entscheidet alles, wenn man ein Modell promptet: Ändere einen kleinen Teil eines Satzes, und die Ausgabe kann völlig anders ausfallen. Ein Entwickler, der diesen Prompt schreibt, trifft Entscheidungen, die den resultierenden Code prägen, und fast niemand prüft diesen Schritt. Das macht Prompt Reviews zu einem Quality Gate, das so früh wie möglich im Prozess angesiedelt ist.
Wie sollte ein Team heute ein Tool für die Testautomatisierung auswählen?
Installiere Testversionen und probiere sie aus, anstatt Whitepapers zu vertrauen, denn Anbieter stellen ihr Produkt im besten Licht dar und das Marketing zeigt, was möglich sein könnte, nicht, was in deiner Umgebung tatsächlich funktioniert. Es gibt keine universelle Wahl mehr, anders als in den Jahren, als alle zu Selenium und Appium griffen. Ein Tool, das tagelange Konfiguration und Gigabytes an Bibliotheken erfordert, arbeitet gegen dich.
Lohnt es sich, zu lernen, wie große Sprachmodelle funktionieren, wenn du nur Software testest?
Ja. Lerne, wie man Prompts verfasst, und befasse dich mit den internen Abläufen, einschließlich Vektordatenbanken und den zugrunde liegenden Prinzipien. Nur wenig davon hat direkten Bezug zum Testen, doch es schärft deinen Blick dafür, wie du testest. Das Tempo ist das Argument dafür, jetzt anzufangen: Manche Unternehmen brauchten mehr als fünfzehn Jahre, um den mobilen Wandel um 2010 herum aufzuholen, und KI entwickelt sich um eine Größenordnung schneller.
