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 wieder mehr Gewicht als Vertrauensbildung für Software, 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.
