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.
