Ersetzt AI den Test Engineer?
Vom Tischler zum Agile Engineering Coach: Wie ein Berufswechsel und ein Buch über Systemtest eine ganze Karriere im Testen ausgelöst haben.

Der Wechsel vom Handwerker zum Software-Tester gelingt, wenn man bestehende Stärken wie Genauigkeit und Qualitätssinn bewusst einsetzt und sich parallel zur Arbeit neue Kenntnisse aneignet. Der ISTQB Foundation Level schafft dabei die fachliche Grundlage. KI-Tools wie ChatGPT ersetzen Tester nicht, sondern übernehmen Routineaufgaben, sofern man den Umgang mit ihnen aktiv lernt.
Das Wichtigste in Kürze
- Wer sich nicht mit KI beschäftigt, wird ersetzt, wer sie nutzt, nicht: Rudolf Groetz setzt ChatGPT täglich ein, mahnt aber, Ergebnisse immer kritisch zu prüfen und anzupassen.
- Der ISTQB Foundation Level liefert das Handwerkszeug für agiles Testen: Konzepte wie Äquivalenzklassen und Entscheidungstabellen helfen auch in Scrum-Teams beim Testentwurf.
- Automatisierte Routinetätigkeiten wie das manuelle Prüfen von Excel-Listen wird KI übernehmen, komplexe Qualitätsurteile über Anforderungsabdeckung bleiben menschliche Aufgabe.
- Rudolf Groetz gründete vor sechs Jahren die Testbusters-Community in Wien, die heute rund 1500 Mitglieder zählt und Tester aus aller Welt in remote Meetups vernetzt.
- Das Format New Voices gibt Menschen ohne Bühnenerfahrung einen geschützten Raum für ihren ersten Vortrag, weil der Einstieg in klassische Konferenzen durch hohe Anforderungen an Titel und Abstract blockiert wird.
Vom Tischler zum Tester: warum Quereinstieg in der IT funktioniert
Ein abgeschlossenes Handwerk schließt eine IT-Karriere nicht aus, es kann sie sogar tragen. Rudolf Groetz ist gelernter Tischler, mit Gesellenbrief, bevor er Operator, Cobol-Entwickler, Datenbankadministrator, Systemadministrator und schließlich Softwaretester wurde.
Der Wechsel begann mit einer Fernsehsendung um 1985. Die Frage darin: Braucht man in Zukunft noch Handwerker, wenn Maschinen alles übernehmen? Groetz übertrug die Frage auf seinen eigenen Beruf und entschied, etwas anderes zu lernen, bevor die Roboter den Tischler ersetzen.
Der Einstieg lief parallel zum Vollzeitjob. Von sieben bis fünf an der Hobelbank, danach von 19 bis 22 Uhr EDV-Kurse am Wifi, abends Aufgaben bis teils drei Uhr früh, am nächsten Morgen wieder an der Hobelbank. Sein erster Kurs hieß “Grundlagen der EDV”, dort lernte er Bits, Bytes, MS-DOS, Supercalc und Turbo Pascal.
Die Lehre daraus: Ein Berufswechsel in die IT gelingt auch ohne klassischen Studienweg, wenn die Bereitschaft da ist, parallel und hart zu lernen. Das Handwerk verschwindet dabei nicht zwangsläufig. Groetz betreibt bis heute eine Werkstatt im eigenen Haus und baut Palettenmöbel, die er auseinandernimmt, hobelt und neu zusammensetzt.
Woran erkennt man das “Testergen”?
Das Gespür fürs Testen zeigt sich, bevor jemand den Titel Tester trägt. Bei Groetz fiel es bei einem Beratungseinsatz auf: Er sollte für eine Software Schulungsunterlagen schreiben, schaute sich das Programm 50 Minuten an und erklärte dann, es sei in diesem Zustand nicht verwendbar. Der Entwickler war fassungslos, dass er die Fehler selbst nicht gefunden hatte.
Dieses Gefühl beschreibt Groetz konkret: Er sieht sofort, wenn irgendwo ein Punkt fehlt. Er weiß beim Hinschauen, dass an einer bestimmten Stelle nichts passieren wird, wenn er klickt. Er erkennt einen toten Link oder ein fehlendes Bild, bevor andere darauf stoßen.
Die Wurzel führt er auf seine Herkunft zurück. Sein Vater stammt aus Berlin, Genauigkeit und Pünktlichkeit gehörten zum Alltag. Groetz nennt sich selbst halb augenzwinkernd “preußischer Qualitätsbeamter”. Wer ein solches Gespür mitbringt, hat eine Grundlage, auf der sich Testkompetenz aufbauen lässt.
Warum Zertifizierung trotz Kritik ihren Platz hat
Die ISTQB-Zertifizierung ist umstritten, ihr Wissensfundament aber nützlich. Groetz kennt beide Seiten: Er hat für das Austrian Testing Board an ISTQB-Lehrplänen und Prüfungsfragen mitgearbeitet und seinen eigenen Weg über Foundation Level, Technical Test Analyst, Functional Test Analyst bis Testmanager genommen, vieles davon autodidaktisch über Syllabus und Selbststudium.
Sein Argument hat nichts mit dem Papier zu tun. Es geht ihm um das Wissen dahinter. Wer Tests entwirft, kommt schneller voran, wenn er weiß, was Äquivalenzklassen sind. Wer Business Rules aufdröselt, arbeitet sauberer mit einer Decision Table.
So wie jedes Kind lesen und schreiben lernt, sollte jeder Tester dieses Foundation Level haben. Rudolf Groetz
Eine Ausnahme nennt er selbst: Wer 30 Jahre im Beruf steht, kennt diese Grundlagen ohnehin. Für Einsteiger dagegen ist das Foundation-Level-Wissen die gemeinsame Sprache, auch und gerade im agilen Umfeld.
KI ersetzt keine Tester, sondern Routine
Künstliche Intelligenz wird das Berufsbild verändern, aber nicht den Tester abschaffen. Groetz sieht die Veränderung an einer klaren Grenze: KI ersetzt Tätigkeiten, die standardisiert ablaufen. Excel-Listen auf Gültigkeit prüfen, Spalten in andere Spalten übertragen, repetitive Verarbeitung. Solche Aufgaben werden eng.
Das Kerngeschäft des Testens bleibt. Auch wenn ein Sprachmodell auf Zuruf Code für einen Cypress-Testfall generiert, braucht es jemanden, der den Prompt schreibt. Und es braucht jemanden, der prüft, ob das Ergebnis zusammenpasst und ob alle Requirements umgesetzt sind.
Wer betroffen sein wird, formuliert Groetz scharf: Ersetzt werden die Menschen, die sich nicht mit KI beschäftigen. Wer sich damit beschäftigt, bleibt im Spiel. Interessant ist seine Einschätzung, dass der Druck eher die Entwicklerseite trifft als die Tester.
Wie KI im Testalltag tatsächlich hilft
KI ist ein Werkzeug zur Vorarbeit, kein fertiges Ergebnis. Groetz nutzt sie regelmäßig: für Beispiele in Schulungen, für Testpläne, für agile Testpläne. Wenn er ein neues Training entwirft, unterhält er sich zuerst eine halbe Stunde mit dem Sprachmodell und lässt sich eine Agenda zusammenstellen.
Am Ende passt das Rohergebnis nie eins zu eins. Es muss verfeinert und angepasst werden, manche Aussagen stimmen schlicht nicht. Wer den KI-Output ungeprüft übernimmt und als gut verkauft, handelt fahrlässig.
Eine offene Flanke benennt Groetz ehrlich: das Testen der KI selbst. Bei manchen Antworten habe er den Eindruck, sie seien überhaupt nicht getestet worden. Den Ansatz, KI stärker zu regulieren und in sinnvolle Schranken zu lenken, hält er für berechtigt.
Das Prinzip dahinter fasst er in einem Satz zusammen: work smarter, not harder.
Communitys entstehen, wenn jemand die Lücke füllt
Wenn die Community nichts hergibt, muss man sie selbst aufbauen. Genau das tat Groetz vor sechs Jahren mit einem Test-Automation-Meetup in Wien, das mittlerweile rund 1500 Mitglieder zählt. Die Veranstaltungsreihe heißt Testbusters Night.
Vor etwa zwei Jahren kam ein zweites Meetup dazu. Eine Test-Automation-Gruppe in Kiew lag brach, die Mitglieder baten Groetz, sie zu übernehmen und neuen Schwung hineinzubringen. Er öffnete den Fokus von reiner Testautomatisierung hin zu Themen rund um Engineering.
Das Format wechselte mit Corona von Präsenz zu remote. Der Effekt: leichter zu organisieren und mehr Reichweite. Heute reicht das Netzwerk bis zu Testern in Peru und Australien. Die Themen folgen der Nachfrage der Mitglieder, aktuell KI, autonomes Testen, Model Based Test Automation, synthetische Testdaten und das Testen von Lambda-Funktionen in Amazon.
New Voices: erste Bühne für Einsteiger
Konferenzen verlangen Titel, Abstract und oft einen Probetalk, das hält Neulinge fern. Groetz hat dieses Problem selbst erlebt und mit dem Format “New Voices” eine Antwort gebaut: Menschen, die noch nie auf einer Bühne standen, bekommen die Möglichkeit für ihren ersten Vortrag, ob physisch oder virtuell.
Wie gut das vernetzt funktioniert, zeigt ein Beispiel aus seiner eigenen Community. Ein junger Mann aus Wien fragte auf einer Konferenz in Holland einen Vortragenden um Rat, wie er starten könne. Die Antwort: In Wien gibt es Rudi Groetz, der genau das anbietet, ruf ihn an. Sein erster Vortrag wird davon handeln, wie er KI in seine Firma gebracht hat.
Lernen funktioniert besser am Menschen als am Syllabus
Effektive Weiterbildung stellt die lernende Person in den Mittelpunkt, nicht den Lehrplan. Bei der Raiffeisenbank International arbeitet Groetz als Agile Engineering Coach und hat dafür das Format “Agile Learning Guides” eingeführt. Statt den Syllabus abzuarbeiten, lernt die Person das, was sie braucht, per Learning by Doing, begleitet von einem Guide.
Der Hintergrund ist ein wiederkehrender Satz. Viele kommen und sagen, sie wollen Testautomatisierung lernen, wissen aber nicht, wo sie anfangen sollen. Genau dort setzt die Begleitung als Mentor, Guide oder Coach an.
Klassische Mehrtagestrainings scheitern oft an der Praxis. Vorgesetzte brauchen die Person im Team, drei Tage Abwesenheit am Stück gehen nicht. Rund 90 Prozent der Angebote sind deshalb E-Learning, das laut Groetz gut ankommt.
Aus derselben Beobachtung entstand das Testbusters Learning Lab. An Schulen wie BFI und Fortitude Vienna wird Studierenden vor allem Entwicklung beigebracht, C und C++, agile Methoden, während Testen untergeht. Mehrere Studierende fragten Groetz, wo sie Testkenntnisse lernen könnten, weil viele Stellenanzeigen sie verlangen. Das Lab startete mit vier Personen und einem ersten Learning Sprint, ausgewertet nach dem Prinzip Inspect and Adapt.
So bleibst du als Tester am Ball
Neugier plus tägliche Routine schlägt punktuelle Großaktionen. Groetz nimmt sich jeden Morgen zehn Minuten beim Kaffee, um seine Streams zu prüfen: Gibt es Neues, gibt es etwas zum Thema, das er sich anschauen sollte? Was trägt, verfolgt er weiter, was nichts bringt, lässt er liegen.
Aus diesem Filtern entsteht oft mehr als reines Lernen. Häufig wird daraus die Idee für einen Vortrag und die Frage, wer aus der Community zu einem Thema sprechen könnte.
Für Einsteiger lässt sich der Rat in zwei Punkte bündeln:
- Das Foundation-Level-Wissen aufbauen, nicht wegen des Zertifikats, sondern um die Grundbegriffe sicher zu beherrschen.
- Am Laufenden bleiben und neugierig sein, mit einer festen, kleinen täglichen Routine statt seltener Trainings.
Aktuelle Felder, die diese Neugier verdienen, nennt Groetz konkret: automatisiertes Testen sowie Low-Code- und No-Code-Ansätze und die Frage, wie man sie sinnvoll ins Spiel bringt.
Ähnliche Beiträge

Richard Seidl
•2. Juni 2026
Patient Agilität: Liegt agiles Arbeiten im Sterben?

Richard Seidl
•26. Mai 2026