Der Wechsel von der Softwareentwicklung zur Testautomatisierung bringt konkrete Vorteile: Clean Code, Design Patterns und Software-Craftsmanship-Prinzipien fließen direkt in die Testautomatisierung ein. Testsoftware folgt denselben Qualitätsprinzipien wie die zu testende Anwendung. Wer zusätzlich Testmethodik beherrscht, kombiniert beide Welten und steigert so den Qualitätsimpact messbar.
Das Wichtigste in Kürze
- Testsoftware ist echte Software und muss denselben Clean-Code- und Design-Pattern-Prinzipien folgen wie die Anwendung, die sie testet.
- Wer mit Testautomatisierung anfängt, sollte zuerst Prinzipien lernen, nicht Tools: ein konkretes Werkzeug zu beherrschen ersetzt kein Verständnis dafür, was darunter abläuft.
- Die Kombination aus Softwareentwicklungs-Hintergrund und tiefem Testwissen entsteht am wirkungsvollsten durch gegenseitiges Lernen im Team, nicht durch Schulungen allein.
- Wenn KI-generierter Code zum Standard wird, steigt der Bedarf an qualifiziertem Testen, weil die Qualität dieses Codes unbekannt ist und irgendjemand sie prüfen muss.
Vom Entwickler zum Test Automation Engineer: ein Berufsweg ohne Studium
Der Weg in die Testautomatisierung führt nicht zwingend über ein Informatikstudium. Benjamin Bischoff begann mit einer Ausbildung zum Fachinformatiker für Anwendungsentwicklung, weil er sofort in die Praxis wollte. Danach arbeitete er sechseinhalb Jahre selbstständig als Web- und Flash-Entwickler, bevor ihn die Flash-Entwicklung in die Spielebranche brachte.
Der Kontakt zum Testen entstand erst im Job. In einem Team, das Software für weltweit verteilte Spiele-Teams baute, kam er erstmals mit QA, Testprozessen, verschiedenen Testverfahren und Selenium in Berührung. Aus diesem Kontakt wurde Interesse, aus dem Interesse eine neue Rolle.
Der entscheidende Moment war ein Perspektivwechsel. Software zu schreiben war die eine Sache. Dass diese Software möglichst fehlerfrei sein und eine gute Usability haben muss, war die andere. Als Benjamin zum ersten Mal sah, wie Browser-Tests mit Selenium automatisiert ablaufen, stand für ihn fest, dass er diese Richtung weiterverfolgen will. Weil es im damaligen Umfeld keinen Weg in die Testrichtung gab, wechselte er in eine Test-Automation-Engineer-Rolle, die er inzwischen seit fast zehn Jahren ausfüllt.
Testsoftware ist Software und folgt denselben Prinzipien
Wer aus der Softwareentwicklung in die Testautomatisierung kommt, bringt ein Mindset mit, das Testcode wie Produktionscode behandelt. Das ist der größte Unterschied zu Automatisierern, die vom explorativen Testen kommen.
Beide Richtungen haben ihre Stärken. Vom explorativen Testen kommt ein großes Wissen über Testmethoden und ein Instinkt dafür, wo man suchen muss, um Fehler zu finden. Diesen Instinkt baut sich Benjamin nach eigener Aussage auch nach zehn Jahren noch auf.
Aus der Entwicklung kommen dagegen Clean-Code-Prinzipien, Design Patterns und Software-Craftsmanship. Die Kernhaltung dahinter: Testsoftware ist auch Software und muss denselben Prinzipien folgen wie die Applikation unter Test. Das schließt ein, dass Testcode getestet, erweiterbar und über Jahre wartbar ist.
Ob Spaghetti-Code in der Automatisierung ein Problem ist, hängt von der Lebensdauer ab. Code, der schnell etwas prüft und danach weggeworfen wird, braucht keine hohen Standards. Ein internes Test-Framework, das über Jahre das Werkzeug der Wahl bleibt, schon. Genau weil es den Prinzipien folgt, getestet und erweiterbar ist, hält es so lange.
Warum sich Test- und Entwicklungswissen gegenseitig hochziehen
Die Kombination aus Entwicklungswissen und Testmethodik wirkt am stärksten, wenn beide Seiten voneinander lernen. In der Praxis funktioniert das über direkte Zusammenarbeit.
Benjamin beschreibt einen Kollegen, der aus der tiefen QA kam und die Testautomatisierungsrolle übernahm. Der Kollege lernte die technische Seite schnell, Benjamin lernt von ihm über Testmethoden. Beide ziehen sich gegenseitig hoch.
Für Benjamin ist das die ideale Rolle. Er macht etwas, das die Software in allen Belangen besser macht, und behält gleichzeitig das volle Potenzial, zu entwickeln und zu coden. Genau das war der Grund, warum er überhaupt in den Testbereich gegangen ist.
Warum Selenium trotz neuer Tools das Werkzeug der Wahl bleibt
Für Browser-Tests setzt Benjamin weiterhin auf Selenium, weil tiefe Tool-Kenntnis mehr wert ist als das jeweils aktuelle Tool. Wer den Code kennt und weiß, wie ein Werkzeug intern funktioniert, kann beurteilen, was es kann und was nicht.
Playwright und Cypress sind im Blick, aber Selenium bleibt das Tool der Wahl. Zwei konkrete Grenzen nennt Benjamin bei Playwright: Es bildet nicht die real genutzten Browser ab, sondern die Engines, und beim Testen auf echten Mobilgeräten ist Selenium weiterhin besser. Zugleich erkennt er an, dass Playwright eine große Community hat und ein gutes Tool ist, in das viel Arbeit fließt.
Ein Punkt wird beim Vergleich oft übersehen. Selenium ist nicht nur ein Werkzeug zur Browser-Steuerung. Ein Teil der Selenium-Gruppe definiert Standards, etwa die W3C-Standards für bidirektionale Kommunikation mit Browsern. Auch Playwright nutzt mit BiDi ein Prinzip, das aus der Selenium-Welt stammt.
Daraus folgt eine einfache Einordnung: Ein älteres Tool ist nicht automatisch ein schlechtes Tool. Selenium entwickelt sich weiter und passt sich an.
Wie man sich Testwissen aneignet, wenn man aus der Entwicklung kommt
Der wirksamste Weg führt über Menschen, nicht über Material. Kollegen, Kolleginnen und Mentoren mit langer Testerfahrung hatten bei Benjamin den größten Einfluss auf den Lernweg.
Konkret heißt das, erfahrenen Leuten über die Schulter zu schauen: Wie finden sie die Ursachen für Defekte? Welche Tools nutzen sie? Welchen Gedankengängen folgen sie? Manche Kolleginnen kennen die Produktfeatures so genau, dass sie einen Fehler einer bestimmten Feature-Kombination zuordnen können, bevor sie nachschauen.
Blogs und Konferenzen ergänzen das. Benjamin schaut sich dort bewusst nicht nur technische Vorträge an, sondern auch Erfahrungsberichte und Beiträge zum explorativen Testen, weil er auf diesem Feld noch wachsen will.
KI im Testalltag: täglich genutzt, mit klaren Grenzen
KI-Tools sind im Arbeitsalltag angekommen, aber sie ersetzen die Arbeit nicht. Benjamin nutzt sie täglich, und auch das Management steht dahinter, allerdings nicht zum Selbstzweck, sondern um zu lernen, was die Werkzeuge können und wo sie helfen.
Im Einsatz und in der Evaluierung sind unter anderem Copilot, Claude, Cursor, Juni und Code Rabbit für Reviews. Über ein internes Tool besteht Zugriff auf rund zwanzig verschiedene LLMs zum Ausprobieren. Mit der täglichen Nutzung kommen auch die Grenzen und Risiken täglich zum Vorschein.
Die Versprechen mancher Test-Tools hält Benjamin für überzogen. Aussagen wie “das löst alles” oder “wir können unser QA-Team abschaffen” hat er gesehen. Beim Evaluieren zeigt sich aber, dass auch dort nur mit Wasser gekocht wird. Es verkauft sich gerade gut, hält der Praxis aber oft nicht stand.
Ich schwanke zwischen großer Angst vor der Zukunft und der Hoffnung, dass es wirklich funktioniert. Das wechselt bei mir eigentlich stündlich. — Benjamin Bischoff
Wenn KI den meisten Code schreibt, wird Testen wichtiger
Je mehr Code von KI erzeugt wird, desto größer wird die Rolle des Testens. Das ist Benjamins zentrale Prognose für die Zukunft der Rolle.
Vom reinen Vibe-Coding hält er wenig, abgesehen von Prototypen. Die Erwartung, man beschreibe nur eine Software und bekomme sie zu hundert Prozent funktionierend zurück, sieht er kritisch. Sollte das eintreten, müsste er sich nach eigener Aussage eine andere Karriere suchen.
Wahrscheinlicher ist ein anderes Szenario, und es ist kein angenehmes. Es wird sehr viel Software geben, deren Qualität unbekannt ist. Dazu wird dieselbe Software vielfach kopiert, auch von Leuten ohne Programmierkenntnisse, die das Ergebnis verkaufen wollen. Daraus kann ein großes Chaos entstehen, wenn nicht gegengesteuert wird. Irgendwer muss diesen Code anschauen, und das verschiebt das Gewicht klar in Richtung Testen.
Erst Prinzipien, dann Tools: ein Einstieg in die Testautomatisierung
Wer vom Testen kommt und in die Automatisierung will, sollte nicht mit einem Tool starten, sondern mit Prinzipien. Clean Code und Design Patterns sind der bessere Ausgangspunkt als die Frage, welches Framework gerade angesagt ist.
Der pragmatische erste Schritt ist klein: eine Tätigkeit, die du täglich zwei- oder dreimal machst, in ein kurzes Skript packen. Ob Bash oder Python ist dabei zweitrangig. Wenn dir drei Zeilen Code wiederkehrende Arbeit sparen, bist du im Thema drin.
Der häufige Fehler ist der umgekehrte Weg. Wer Playwright nur lernt, weil alle es nutzen, lernt die Bedienung des Tools, aber nicht, was darunter passiert. Das Verständnis dafür ist wichtiger.
Hier hilft der Hintergrund aus dem Testberuf. Als Tester oder QA Engineer steckst du ohnehin im Software-Development-Lifecycle und hast Grundkenntnisse. Es geht darum, an der richtigen Stelle tiefer zu gehen.
Ein letzter Punkt entlastet beim Einstieg. Wer programmieren kann, ist nicht an eine Sprache gebunden, weil die Konzepte übertragbar sind. Benjamin arbeitet inzwischen mit Python, ohne es vorher gemacht zu haben. Die Konzepte kennt er, Syntax und Befehle muss er lernen. Es ist wie eine neue Sprache, wenn man eine verwandte bereits spricht.
Häufig gestellte Fragen
Braucht man ein Informatikstudium, um in die Testautomatisierung einzusteigen?
Nein. Benjamin Bischoff begann mit einer Ausbildung zum Fachinformatiker für Anwendungsentwicklung, arbeitete sechseinhalb Jahre selbstständig als Web- und Flash-Entwickler und kam über die Spielebranche zum Testen. Der Kontakt zu QA, Testprozessen und Selenium entstand erst im Job. Daraus wurde eine Test-Automation-Engineer-Rolle, die er seit fast zehn Jahren ausfüllt.
Muss Testcode dieselben Qualitätsstandards erfüllen wie Produktionscode?
Das hängt von der Lebensdauer ab. Ein Skript, das schnell etwas prüft und danach weggeworfen wird, braucht keine hohen Standards. Ein internes Test-Framework, das über Jahre das Werkzeug der Wahl bleibt, schon: Es hält nur so lange durch, weil es Clean-Code-Prinzipien folgt, selbst getestet und erweiterbar ist.
Was bringen Automatisierer mit, die vom explorativen Testen kommen?
Sie bringen breites Wissen über Testmethoden mit und einen Instinkt dafür, wo man suchen muss, um Fehler zu finden. Manche kennen die Produktfeatures so genau, dass sie einen Defekt einer bestimmten Feature-Kombination zuordnen, bevor sie nachschauen. Aus der Entwicklung kommen dagegen Clean Code, Design Patterns und Software-Craftsmanship. Beide Seiten ziehen sich im Team gegenseitig hoch.
Ist Selenium gegenüber neueren Werkzeugen wie Playwright und Cypress veraltet?
Ein älteres Tool ist nicht automatisch ein schlechtes Tool. Selenium bleibt für Browser-Tests das Werkzeug der Wahl, weil Playwright nicht die real genutzten Browser abbildet, sondern die Engines, und beim Testen auf echten Mobilgeräten schwächer ist. Ein Teil der Selenium-Gruppe definiert zudem Standards, etwa die W3C-Standards für bidirektionale Kommunikation mit Browsern.
Reichen Bücher, Blogs und Konferenzen, um sich Testmethodik anzueignen?
Sie ergänzen, tragen aber nicht allein. Den größten Einfluss haben Kollegen und Mentoren mit langer Testerfahrung: erfahrenen Leuten über die Schulter schauen, sehen, wie sie Ursachen für Defekte finden, welche Tools sie nutzen, welchen Gedankengängen sie folgen. Bei Konferenzen lohnen sich neben technischen Vorträgen auch Erfahrungsberichte und Beiträge zum explorativen Testen.
Können KI-Tools ein QA-Team ersetzen?
Nein. Versprechen wie “das löst alles” oder “wir können unser QA-Team abschaffen” halten der Praxis meist nicht stand, auch wenn sie sich gut verkaufen. Beim Evaluieren zeigt sich, dass auch dort nur mit Wasser gekocht wird. KI-Tools wie Copilot, Claude, Cursor oder Code Rabbit für Reviews sind im täglichen Einsatz, ersetzen die Arbeit aber nicht.
Macht KI-generierter Code das Testen überflüssig?
Das Gegenteil ist wahrscheinlich. Je mehr Code von KI erzeugt wird, desto mehr Software gibt es, deren Qualität unbekannt ist. Dazu kommt vielfaches Kopieren derselben Software, auch durch Leute ohne Programmierkenntnisse, die das Ergebnis verkaufen wollen. Irgendwer muss diesen Code anschauen. Das verschiebt das Gewicht klar in Richtung Testen.
Sollte man den Einstieg in die Testautomatisierung mit einem verbreiteten Framework beginnen?
Besser nicht. Wer ein Tool nur lernt, weil alle es nutzen, lernt dessen Bedienung, aber nicht, was darunter passiert. Sinnvoller sind Clean Code und Design Patterns als Ausgangspunkt. Der pragmatische erste Schritt ist klein: eine Tätigkeit, die du täglich zwei- oder dreimal machst, in ein kurzes Skript packen, ob in Bash oder Python.
