Softwaretesten verändert sich durch KI grundlegend: Der Job als Tester wird nicht überflüssig, verschiebt sich aber weg von der reinen Testfallausführung hin zu Teststrategie, kritischem Hinterfragen und Qualitätssicherung. Flaky Tests gefährden das Vertrauen in Pipelines und sollten isoliert und analysiert werden. Shift Left gelingt am einfachsten über Refinements, wo gemeinsames Verständnis früh entsteht.
Das Wichtigste in Kürze
- Flaky Tests zerstören das Vertrauen in Pipelines: Wer sie im laufenden Betrieb lässt, riskiert, dass rote Builds ignoriert werden und echte Fehler unentdeckt bleiben.
- Testautomatisierung nahe 100 Prozent funktioniert nur, wenn die Softwarearchitektur von Anfang an darauf ausgelegt ist, nicht als nachträgliche Maßnahme in beliebige Projekte.
- Der Einstieg in Shift Left gelingt am direktesten über Planning und Refinements, weil Tester dort früh ein gemeinsames Verständnis von Anforderungen mitgestalten können.
- Ein Tool-Wechsel von Selenium zu Playwright rechtfertigt sich nicht durch Aktualität allein, sondern nur wenn konkrete Probleme wie fehlende Community oder schlechte Integration das auslösen.
- Manuelle Testerinnen müssen Programmieren nicht zwingend lernen, weil der größere Hebel in Teststrategien, Testdaten und dem gezielten Einsatz von KI-Unterstützung liegt.
Macht KI den Testerjob überflüssig?
Nein. Die Rolle des Testers verschwindet nicht, aber der Job verändert sich gerade massiv. Wer vor zwei Jahren gefragt hätte, hätte vielleicht eine andere Antwort bekommen. Heute spricht mehr dagegen, dass KI die Profession ersetzt.
KI verändert die Art, wie Software entwickelt wird. Teams probieren in alle Richtungen aus, manches klappt, manches nicht. Genau in dieser Findungsphase stecken aktuell viele Organisationen, und sie reiben sich dabei auch lauthals aneinander.
Einzelne Aktivitäten wandern an die Maschine, das ist absehbar. Aber das kritische Hinterfragen, das Aufspüren von Problemen, der Aufbau von Kommunikation und das Entwickeln von Teststrategien bleiben menschliche Arbeit. Eher kommt davon mehr als weniger.
Viele Entwicklungsprojekte geben gerade Gas bei der Code-Erstellung. Die Qualität dessen, was KI ausspuckt, steht mit Fragezeichen da. Irgendwer muss das prüfen. Testen bekommt damit als Vertrauensbildung für Software wieder mehr Gewicht, und das ist die Kernaufgabe von Testern und Testerinnen.
Manuelle Tester müssen nicht programmieren lernen
Wer manuell testet, muss nicht zwingend in die Programmierung einsteigen. Du kannst, aber du musst nicht. Programmieren ist nicht der Skill, der über die Zukunft entscheidet.
Wertvoller ist die Frage, wie sich Qualität verbessern lässt und wie die Prozesse aussehen. Ein technisches Verständnis dafür, wie Softwareentwicklung funktioniert, hilft, weil Tester damit an mehr Stellen wirken können. Hardcore programmieren zu lernen gehört nicht dazu.
Offenheit schadet trotzdem nicht. Etwas Scripting anzufangen ist ein guter Einstieg, und KI lässt sich heute auch zum Lernen nutzen, nicht nur zum Generieren von Code. Du kannst dir damit Programmierwissen aufbauen, statt nur fertige Ergebnisse abzunehmen.
Die wichtigeren Hebel liegen woanders: bei Teststrategien, bei Testdaten und beim Umgang mit KI selbst. Wie KI Tester in ihrer Arbeit unterstützt, ist ein Skill, der zunehmend gebraucht wird.
Warum ein Tool-Wechsel kein Selbstzweck ist
Ein Wechsel des Automatisierungswerkzeugs lohnt sich nur, wenn er ein konkretes Problem löst. Modernität allein ist kein Grund. Die richtige Frage lautet: Was will ich mit dem Umstieg eigentlich lösen?
Selenium gibt es seit vielen Jahren, hat eine große Community und läuft oft sehr stabil. Es gilt manchen als nicht mehr fancy, weshalb gerade einige von Selenium oder Cypress zu Playwright wechseln, weil das cool und en vogue ist.
Hier zeigt sich ein Kern-Skill von Testern: kritisch hinterfragen. Läuft die bestehende Lösung gut, ist niemand unzufrieden und wird das die nächsten Jahre tragen, dann darfst du auch dort bleiben, wo du bist, selbst wenn das Tool nicht das angesagteste ist.
Es gibt gute Gründe für einen Wechsel: Im Umfeld arbeiten mehr Leute mit dem neuen Werkzeug, oder es lässt sich näher an der Entwicklung andocken. Solche Fragen muss man vorher beantworten. Pauschal ist die Antwort nicht.
Die andere Seite ist genauso real. Irgendwann sind Werkzeuge überholt und landen im Archiv. Wer jeden Zug verpasst, steht am Ende am einsamen Gleis. Bei Selenium ist dieser Punkt aktuell nicht erreicht.
Hundert Prozent Automatisierung ist meistens Quatsch
Das Ziel, alles zu automatisieren, scheitert in den allermeisten Projekten. Es kommt darauf an, und in der Realität sprechen die Umstände oft dagegen.
Ein häufiges Missverständnis sitzt schon im Begriff. Testautomatisierung wird oft mit Oberflächen, Geschäftsprozessen und End-to-End gleichgesetzt. Dabei sind auch Unit-Tests automatisierte Tests, denn manuell führt sie niemand durch. Über alle Teststufen hinweg lässt sich automatisieren, und ein hoher Automatisierungsgrad ist möglich.
Es gibt Projekte, die nahe an hundert Prozent automatisieren und gute Erfahrungen damit machen. Dort passt alles zusammen: Die Softwarearchitektur ist darauf abgestimmt, ebenso die Fachlichkeiten, die Implementierungsprozesse und die Tools. Manuell wird dann nur noch kurz drübergeschaut. Das hängt vor allem an der Applikation und ihrer Struktur.
In den meisten Projekten geht irgendetwas nicht. Schlechte Architekturentscheidungen aus vergangenen Jahren, ein unpassender Tech-Stack, falsche Werkzeuge, fehlendes Wissen oder Entwickler, die nicht mitspielen. Dann wird herumgedoktert und mit dem neuesten Tool versucht, etwas zu erschlagen. Sinnvoller ist die Frage, wo Automatisierung wirklich trägt, und von dort aus zu arbeiten.
Flaky Tests zuerst isolieren, dann analysieren
Die größte Gefahr bei flaky Tests ist der Verlust von Vertrauen. Wenn ein Test in der Pipeline mal rot ist und mal nicht, und niemand weiß warum, geht das Vertrauen in die Pipeline und in die Tests verloren.
Der erste Schritt ist, flaky Tests sofort aus der Pipeline zu isolieren. Ziel ist eine durchgehend stabile Pipeline. Steht dann etwas auf Rot, ist es auch wirklich ein Problem.
Der zweite Schritt ist die Analyse. Woher kommt die Instabilität? Es gibt viele Gründe, warum ein Test nicht stabil läuft. Manche lassen sich mit mehr oder weniger Aufwand beheben, und dann entscheidest du, ob sich das lohnt.
Manchmal löscht man einen flaky Test und ersetzt ihn durch zwei neue oder deckt den Fall manuell ab, weil es technisch nicht anders geht. Das verweist zurück auf die Architektur: Was sich nicht stabil automatisieren lässt, war oft nie dafür ausgelegt. Das muss kein Mangel sein, wenn man es am Projektanfang bewusst entschieden hat.
Shift Left beginnt im Refinement, nicht im Code Review
Der beste Einstieg in Shift Left führt über Planning und Refinement, nicht über das Code Review. Tester müssen nicht sofort mit Entwicklern in den Code oder ihnen erklären, wie sie Unit-Tests besser machen.
In Refinements arbeiten Tester auf Augenhöhe mit den anderen Teammitgliedern an der Ausgestaltung der Anforderungen und User Stories. Dort lässt sich früh verstehen, was umgesetzt werden soll. Du kannst Fragen stellen und ein gemeinsames Verständnis mitformen, in das dein Qualitätsanteil einfließt.
Einfach ist das nicht immer. Oft beginnt es als Statusthema, weil das Refinement als Sache des Entwicklungsteams gilt und der Tester am Schluss noch seinen Testaufwand mitschätzen darf. Das ist nicht der Sinn. Wer sich etwas Vertrauen erarbeitet hat, kann hier wirklich wirken.
Im Kern geht es bei agilem Arbeiten immer um ein gemeinsames Verständnis. Ob über Examples, BDD oder einen anderen Weg, die Frage bleibt dieselbe: Was wollen wir umsetzen? Dieses Verständnis sollte für alle gleich sein, ob aus Business, Technik oder Test, damit die Umsetzung gelingt.
Teststrategie gehört wieder auf den Tisch
Die KI-Welle bringt vielen Teams die alte Frage zurück, was sie eigentlich mit dem Test machen. Unternehmen kramen alte Testkonzepte heraus, in denen eine Teststrategie steht, an die sich niemand mehr genau erinnert.
Oft entspricht das, was dort steht, nicht mehr der Realität. Getestet wird so, wie man es schon immer gemacht hat. Ein kritischer Blick darauf steht vielen wieder bevor.
Das betrifft den risikobasierten Ansatz und die Priorisierung. Welche Qualitätsmerkmale werden geprüft, wie tief und warum? Vor allem: Was ist das Ziel hinter dem Testen in diesem Projekt oder Produkt?
Diese Fragen gehören für das ganze Team auf den Tisch, mit der einfachen Anschlussfrage, ob das alles noch passt. Genau hier entsteht gerade neuer Bedarf, getrieben durch die Veränderungen, die KI in die Entwicklung bringt.
Transfer aus anderen Disziplinen lohnt sich
Themen, die auf den ersten Blick nichts mit Testen zu tun haben, zahlen direkt auf die Qualitätsarbeit ein. Konfliktmanagement und Soft Skills lassen sich auf den Test-Alltag übertragen und beantworten die Frage, was sie konkret für das Quality-Business bedeuten.
Genauso trägt die fachliche Bandbreite. Enterprise Testing, das Testen von Microservices oder die Modernisierung von Legacy-Systemen mit KI sind Felder, in die man als Tester nicht täglich tief eintaucht und aus denen sich viel mitnehmen lässt.
Der Lerneffekt geht in beide Richtungen. Wer regelmäßig neue Perspektiven sucht, findet immer wieder Ideen, die den eigenen Testeralltag bereichern. Auch dafür lohnt sich der Blick über den Tellerrand der reinen Testtechnik.
Häufig gestellte Fragen
Welche Aufgaben im Testen bleiben menschlich, wenn KI immer mehr Code und Tests erzeugt?
Kritisches Hinterfragen, das Aufspüren von Problemen, der Aufbau von Kommunikation und das Entwickeln von Teststrategien bleiben menschliche Arbeit. Einzelne Aktivitäten wandern an die Maschine, das ist absehbar. Weil viele Projekte bei der Code-Erstellung Gas geben und die Qualität der KI-Ergebnisse offen ist, muss jemand prüfen. Testen gewinnt dadurch als Vertrauensbildung für Software wieder Gewicht.
Welche Fähigkeiten bringen Testern mehr als Programmierkenntnisse?
Teststrategien, Testdaten und der Umgang mit KI selbst tragen weiter. Ein technisches Verständnis davon, wie Softwareentwicklung funktioniert, hilft, weil Tester dann an mehr Stellen wirken können. Hardcore programmieren zu lernen gehört nicht dazu. Wer mag, fängt mit etwas Scripting an und nutzt KI zum Lernen, statt nur fertige Ergebnisse abzunehmen.
Wann rechtfertigt ein Wechsel des Testautomatisierungswerkzeugs den Aufwand?
Nur wenn er ein konkretes Problem löst. Modernität allein ist kein Grund. Gute Auslöser sind, dass im Umfeld mehr Leute mit dem neuen Werkzeug arbeiten oder dass es sich näher an der Entwicklung andocken lässt. Läuft die bestehende Lösung stabil, ist niemand unzufrieden und trägt sie die nächsten Jahre, darfst du bleiben. Wer allerdings jeden Zug verpasst, steht am einsamen Gleis.
Zählen Unit-Tests eigentlich zur Testautomatisierung?
Ja. Manuell führt sie niemand durch, also sind sie automatisierte Tests. Häufig wird Testautomatisierung mit Oberflächen, Geschäftsprozessen und End-to-End gleichgesetzt, und genau darin steckt ein Missverständnis. Automatisieren lässt sich über alle Teststufen hinweg, und dadurch ist ein hoher Automatisierungsgrad überhaupt erreichbar.
Warum erreichen die meisten Projekte keine vollständige Testautomatisierung?
Weil irgendetwas nicht mitspielt: schlechte Architekturentscheidungen aus vergangenen Jahren, ein unpassender Tech-Stack, falsche Werkzeuge, fehlendes Wissen oder Entwickler, die nicht mitziehen. Projekte, die nahe an hundert Prozent kommen, haben Softwarearchitektur, Fachlichkeiten, Implementierungsprozesse und Tools aufeinander abgestimmt. Statt mit dem neuesten Tool etwas zu erschlagen, lohnt die Frage, wo Automatisierung wirklich trägt.
Was tut man mit Tests, die in der Pipeline mal rot und mal grün sind?
Zuerst isolieren, dann analysieren. Instabile Tests fliegen sofort aus der Pipeline, damit diese durchgehend stabil bleibt und ein rotes Ergebnis wieder ein echtes Problem bedeutet. Anschließend klärst du die Ursache und entscheidest, ob die Behebung den Aufwand lohnt. Manchmal wird ein Test gelöscht und durch zwei neue ersetzt oder der Fall manuell abgedeckt.
Warum ist es für Tester schwer, in Refinements wirklich Einfluss zu nehmen?
Oft beginnt es als Statusthema: Das Refinement gilt als Sache des Entwicklungsteams, und der Tester darf am Schluss seinen Testaufwand mitschätzen. Gemeint ist etwas anderes, nämlich auf Augenhöhe an der Ausgestaltung von Anforderungen und User Stories mitzuarbeiten, Fragen zu stellen und den Qualitätsanteil einzubringen. Wer sich Vertrauen erarbeitet hat, kann dort wirken.
Woran erkennt man, dass eine Teststrategie überarbeitet werden muss?
Ein deutliches Zeichen ist ein Testkonzept, dessen Strategie niemand mehr genau kennt, während getestet wird wie immer. Dann passt das Dokument nicht mehr zur Realität. Auf den Tisch gehören der risikobasierte Ansatz und die Priorisierung: Welche Qualitätsmerkmale werden geprüft, wie tief, warum, und was ist das Ziel hinter dem Testen in diesem Projekt oder Produkt?
