Was bleibt vom Tester, wenn die KI 80 Prozent übernimmt?

Wenn ich aktuell mit Tester-Kollegen schreibe — meistens in Teams oder als Slack-DM, zwischen zwei Meetings — tauchen zwei Sätze immer wieder auf. Der eine kommt schnell rausgehauen: „Ich komme gar nicht mehr hinterher.” Der andere kommt später am Tag, oft losgelöst vom vorherigen Thema und mit drei Sekunden Tippen-stoppt-Tippen davor: „Ich frage mich, ob die mich in zwei Jahren noch brauchen.”

Beide Sätze sind ehrlich, beide sind verständlich, und beide gehen am Kern vorbei. Das ist keine Beruhigung — die Verschiebung, die gerade passiert, ist real. Aber sie sieht anders aus als die Schlagzeilen.

Was sich gerade tatsächlich verschiebt

Die nüchternen Zahlen zuerst, dann das, was dahinter passiert.

Der World Quality Report 2025-26 von Capgemini sagt: 75 Prozent der Unternehmen sehen KI-gestütztes Testing als pivotalen Bestandteil ihrer Strategie. Skaliert haben es 16 Prozent. Das heißt: Es ist überall in den Powerpoints, aber selten geordnet im Maschinenraum. Wer im Berufsalltag das Gefühl hat, dass „alle reden, aber wenige liefern” — der hat recht.

Was ich konkret sehe: Test-Erstellung beschleunigt sich. KI-Tools generieren Test-Skeletons aus User Stories in Minuten — Coverage von 60 bis 80 Prozent der Szenarien, die ich selbst geschrieben hätte. Self-Healing-Locator reduzieren Wartung von UI-Tests um 70 bis 80 Prozent. Im SDLC verschwimmen die Phasen: Was vorher ein klarer Übergabepunkt zwischen Anforderungen, Entwicklung und Test war, wird zu einer Schleife. Diskrete Phasen werden zu kontinuierlichem Fluss mit strategischen Checkpoints.

Das ist nicht „SDLC ist tot”. Das ist „SDLC sieht anders aus”. Wer Testing als sequentiellen Schritt nach der Entwicklung versteht, arbeitet seit zwei Jahren gegen die Strömung.

Die echten Ängste — nicht die aus den Headlines

Die Klick-Statistik kennt jeder: 74 Prozent der IT-Profis fürchten, dass ihre Skills veralten. 69 Prozent fürchten, ersetzt zu werden. Diese Zahlen lese ich seit anderthalb Jahren in jedem zweiten LinkedIn-Post.

Die Sätze, die ich tatsächlich höre, sind andere — und konkreter:

„Ich verliere den Anschluss.” Das ist die Falling-behind-Angst. Sie ist nicht „KI ersetzt mich morgen”, sondern „während ich mich in eines einarbeite, kommen drei neue Tools raus, die alles besser machen”. In den Foren von Ministry of Testing taucht diese Sorge inzwischen häufiger auf als die Ersetzungs-Frage.

„Ich verstehe nicht mehr, wie der Output zustande kommt.” Black-Box-Anxiety. Die KI generiert einen Test, ich klicke „Ausführen”, er läuft grün — aber ich kann nicht sicher sagen, warum er das tut. Das nagt an einem Berufsbild, in dem Verstehen zur DNA gehört.

„Mir fällt das Denken schwerer.” Eine HBR-Studie hat dieses Phänomen „AI Brain Fry” getauft: Power-User von GenAI berichten von 45 Prozent höherer Burnout-Rate. Nicht weil sie weniger arbeiten — sondern weil sie ständig fremde Vorschläge bewerten müssen, ohne den Denkprozess selbst zu durchlaufen. Bewertung ohne eigene Erkenntnis erschöpft anders als Erkenntnis selbst.

„Wer bin ich, wenn die KI die Tests schreibt?” Das ist die unangenehmste Frage, weil sie keine Tool-Frage ist. Wer seine Identität an eine Aufgabenliste geknüpft hat — und davon haben wir im Testing einige — wird unruhig, wenn die Liste schrumpft.

Was menschlich bleibt — und warum das nicht trösten soll

Die Standard-Antwort in jedem zweiten Artikel lautet: „Exploratives Testing, Domain-Wissen, Judgment — bleibt menschlich.” Stimmt. Aber so allgemein hilft es niemandem.

Konkreter werden:

• Risiko-Bewertung im Geschäftskontext. Was bedeutet ein Bug für regulierte Systeme? Für Compliance? Für ein Audit? Eine KI kann eine Liste „kritisch / unkritisch” produzieren. Aber sie wiegt die Risiken nicht gegen Stakeholder-Politik, gegen Release-Zwänge, gegen das, was im Vertrag steht.
• Edge-Case-Bauchgefühl. Das kommt aus Erfahrung, nicht aus Trainingsdaten. Wer fünfmal erlebt hat, dass eine bestimmte Klasse von Bugs immer in derselben Komponente auftaucht, schaut dort zuerst hin. Das ist keine Heuristik, das ist Mustererkennung mit Geschichte.
• Stakeholder-Übersetzung. Der gleiche Defekt klingt für eine Entwicklerin nach „technische Schuld”, für eine PO nach „Velocity-Risiko”, für Compliance nach „Meldepflicht”. Diese Übersetzung leistet keine KI — und sie ist oft das, was am Ende den Unterschied macht.

Und dann ist da noch das, was schwer zu beschreiben ist und mir trotzdem als wichtigster Punkt erscheint.

Die schreienden Kinder auf dem Rücksitz

Stell dir vor, eine Familie ist im Sommer mit dem E-Auto unterwegs. Auf dem Rücksitz zwei Kinder, die seit einer Stunde quengeln. Der Akku zeigt das letzte Prozent. Die Eltern haben die nächste Schnellladesäule angesteuert — Reichweite gerade noch ausreichend, knapp. Sie kommen an, ziehen das Kabel, stecken ein. Die Säule blinkt kurz, gibt einen Fehler aus, der Vorgang bricht ab. Zweiter Versuch. Wieder Fehler. App neu starten, neuer Versuch, wieder Fehler. Inzwischen weinen die Kinder, die Frau ruft den Service an, der Mann versucht es an der Säule daneben — auch dort, irgendetwas funktioniert nicht.

Genau diese Szene ist es, an die ich denke, wenn jemand sagt: „Die KI testet das ja jetzt automatisch.”

Eine KI kann den Ladevorgang testen. Sie kann den Fehlercode erkennen, sie kann die Antwortzeit messen, sie kann sogar einen Retry simulieren. Was sie nicht kann: dieses Szenario priorisieren, weil sie nicht weiß, was diese Familie gerade fühlt. Sie kennt keinen Druck, keine Müdigkeit, keine schreienden Kinder. Sie kennt Codes und Zustände, aber sie kennt keine Verzweiflung an einem Sommertag.

Ich teste E2E-Strecken für Ladeinfrastruktur. Wenn ich einen Bug finde, ist die Frage nie nur „Funktioniert die Komponente?” Die Frage ist „Welcher Mensch erlebt das, in welcher Situation, mit welchen Konsequenzen?” Diese Übersetzung von technischem Verhalten in menschliche Realität — die ist es, die unsere Rolle ausmacht. Und sie wird nicht weniger wichtig, wenn die KI die Tests schreibt. Im Gegenteil.

Wie sich die Rolle real verschiebt

Ein einfaches Bild dafür, was sich gerade verlagert:

quadrantChart
    title "Tester-Aufgaben: Wo KI hilft, wo der Mensch bleibt"
    x-axis "Routine" --> "Strategisch"
    y-axis "Niedrige Konsequenz" --> "Hohe Konsequenz"
    quadrant-1 "Mensch entscheidet"
    quadrant-2 "Mensch priorisiert"
    quadrant-3 "KI automatisiert"
    quadrant-4 "KI assistiert, Mensch reviewt"
    "Test-Skeleton aus User Story": [0.18, 0.30]
    "Selektor-Healing": [0.12, 0.22]
    "Regressions-Lauf": [0.20, 0.45]
    "Edge-Case-Erkundung": [0.78, 0.62]
    "Risiko-Priorisierung": [0.85, 0.82]
    "Release-Gate-Entscheidung": [0.88, 0.90]
    "Stakeholder-Übersetzung": [0.70, 0.75]
    "Test-Daten-Generierung": [0.30, 0.35]

Routine plus niedrige Konsequenz wandert zuverlässig zu KI: Test-Skeletons, Selektor-Reparatur, Standard-Regressionen. Strategisch plus hohe Konsequenz bleibt menschlich: Risiko-Bewertung, Release-Entscheidungen, Übersetzung zwischen Stakeholdern. Dazwischen entsteht eine neue Zone: KI-Output, der menschlichem Review bedarf — der eigentliche Arbeitsplatz vieler Tester für die nächsten Jahre.

Was das für neue Rollen bedeutet, klingt in Konferenz-Vorträgen oft hochtrabend: „Agentic Test Automation Architect”, „AI Output QA Analyst”, „Continuous Quality Engineer”. Wer das hört, denkt an Buzzwords. In der Praxis bedeutet es etwas Bescheideneres und Greifbareres: jemand, der nicht mehr selbst tippt, sondern Test-Agenten orchestriert. Jemand, der nicht mehr selbst alle Bugs findet, sondern bewertet, welche Bugs aus dem KI-Strom überhaupt echte Bugs sind. Jemand, der nicht mehr nur das System überwacht, sondern auch das, was die KI-Vorschläge mit dem System anstellen.

Test-Manager: Was jetzt entschieden werden muss

Für Test-Manager verschiebt sich die Schwerpunktarbeit noch deutlicher. Die operative Frage „Wer testet was bis wann?” rückt in den Hintergrund. Stattdessen kommen Fragen, die vor zwei Jahren noch nicht auf dem Tisch lagen:

• Wer haftet, wenn ein KI-generierter Test ein kritisches Feature freigegeben hat — und der Bug erst in Produktion auffällt?
• Bei welchen Entscheidungen ist Human-in-the-Loop Pflicht, bei welchen nur Etikette?
• Wie dokumentieren wir, was ein Agent gemacht hat, wenn niemand mehr dabei zuschaut?

Das sind Governance-Fragen, und sie werden in den nächsten Monaten unangenehmer. Forrester nennt als größte Hürde für Shift-Left nicht Tools, sondern Kultur: Entwickler sehen Testing als QA-Sache, QA fürchtet, dass Shift-Left ihre Rolle eliminiert. Genau dieser Konflikt eskaliert, wenn KI dazwischenkommt — denn jetzt ist plötzlich noch unklarer, wer eigentlich verantwortlich ist, wenn etwas schiefgeht.

Mein Eindruck: Die Test-Manager, die in den nächsten zwei Jahren am wertvollsten werden, sind die, die diesen Konflikt aktiv moderieren — nicht die, die ihn vermeiden. Wer einen praktischen Einstieg sucht, wie sich das im Team einführen lässt, findet im 90-Tage-Plan den Workflow, mit dem ich es selbst angegangen bin.

Wie ich damit umgehe

Ich bin nicht hier, um eine fertige Antwort zu liefern. Aber drei Dinge haben sich für mich als brauchbar erwiesen:

Erstens: Identität nicht an die Aufgabenliste hängen. Wer sagt „Ich bin Tester, weil ich Tests schreibe”, wird nervös, wenn das Tippen wegfällt. Wer sagt „Ich bin Tester, weil ich dafür sorge, dass Software das tut, was Menschen brauchen”, behält den Kompass, auch wenn das Werkzeug wechselt. Klingt nach Coaching-Spruch, ist aber praktisch wirksam.

Zweitens: Bewusst skeptisch bleiben, ohne pauschal abzublocken. Ich teste die Tools selbst — Stack Finder, Prompt-Generator, KI-Code-Assistenten. Ich habe mit jedem davon Sachen gemacht, die mich beeindruckt haben, und Sachen, die mich an meinem Beruf zweifeln ließen. Beides ist gleichermaßen wichtig. Wer nur die guten Erfahrungen sammelt, wird hype-anfälliger. Wer nur die schlechten sammelt, verpasst die Verschiebung.

Drittens: Den menschlichen Anker nicht verlieren. Bei jedem Tool-Hype komme ich gedanklich zur Familie an der defekten Ladestation zurück. Wenn das, was ich tue, nicht dazu beiträgt, dass diese Familie weiterkommt, ist es nicht wichtig — egal wie elegant die KI-Pipeline aussieht.

Die Frage ist nicht, ob es uns Tester in zwei Jahren noch geben wird. Es wird uns geben, weil jemand die Verantwortung tragen muss, die kein Modell tragen kann. Die Frage ist, als was. Und das entscheiden wir gerade — Tag für Tag, Tool für Tool, Test für Test.

Wenn du tiefer in die Themen einsteigen willst, die ich hier angerissen habe: Im Komplett-Guide sind Strategie, Tools und Prompt-Engineering nach Rolle sortiert. Und falls du selbst gerade an dem Punkt stehst, an dem du nicht weißt, wo anfangen — dort findest du auch den Quick-Path für deine Rolle.