Als Gründer einer Agentur für E2E Website-Testing und Cypress.IO-Ambassador habe ich sehr viele Projekte gesehen. Seit über 10 Jahren bringe ich das Thema in der deutschen Open-Source-Szene nach vorne. Ich habe Voll- und Teilzeit langfristig Projekte betreut und ein GitHub-JavaScript-Template erstellt, mit dem jedes Projekt in unter einer Minute Basis-Tests bekommt. Cypress.IO ist dabei das führende Website-Testing-Framework. Die Herausforderungen, Akzeptanz für Tests und Anwendungsfälle sind dabei technologisch gleich. E2E-Website-Tests sind ein sehr wichtiger Teil in der agilen Softwareentwicklung und ein elementarer Bestandteil für gute Softwarequalität. Damit sind sie eine wichtige Säule für den unternehmerischen Erfolg im Wettbewerb.
E2E Website Testing sparen Zeit und Geld, wenn sie zum richtigen Zeitpunkt ausgeführt werden
Die Kosten von einem Bug steigen mit seiner Lebenszeit. In der Zeile bei der Entwicklung, in der er entsteht, liegen die Kosten für die Behebung praktisch bei nicht zählbaren 0 Euro. Auf Staging- und Prerelease-Umgebungen entstehen schon Kosten in der Infrastruktur. Der zeitliche Versatz macht – je nach Dauer von der Pipeline bis zum entscheidenden Test – schnell einen ganzen Tag aus, eine Zeit, die Kunden nicht gerne in Rechnung gestellt wird. Wäre das so, würde deutlich mehr in Effizienz investiert werden. Dazu kommen noch Kommunikationskosten und aufwendigere Auswertungen, bis hin zu Live-Systemen, in denen Bugs je nach Szenario ganze Existenzen vernichten können. Und alle werden später abgerechnet, weil es einfach nicht live gehen kann. Deshalb liegt es klar auf der Hand: Developer müssen selbst Tests ausführen und alles gegen Bugs einsetzen haben. Und das bezieht sich nicht nur auf statische Code-Analyse, sondern schließt E2E-Website-Tests bei der lokalen Entwicklung ein.
Cypress.IO Website Tests stehen mit einer Zeile zur Verfügung – Selenium und Wartung sind Geschichte
In den Anfängen meiner Karriere als Website-Tester habe ich mit DalekJS gearbeitet und mich dann auf das PHP-Testing-Framework Codeception spezialisiert. Als PHP-Developer hat es mir die Möglichkeit geboten, meine PHP-Skills direkt in meine Testlogik zu integrieren und auch das PHP-Umfeld mit Tools wie Respect (https://github.com/Respect/Assertion) für verbesserte Assertions zu verwenden. Ein Nachteil war das lokale Setup. Ein lokaler Selenium-Server muss über einen Chromedriver in gleicher Versionsnummer mit dem lokalen Chrome verbunden werden. Auf Windows war das eine echte Herkulesaufgabe und auch sonst einfach nur nervig. Dazu kommt noch die Tatsache, dass man moderne Frontends mit VueJS und React nicht testen kann. All das lassen moderne JavaScript-Website-Testing-Frameworks wie Cypress.IO und Playwright hinter sich. Hier reicht eine einfache lokale Node-V-16- und NPM-Installation. Alles andere kommt „out of the box“ und läuft auf jedem Betriebssystem. Cypress.IO hat dazu das unglaublich clevere lokale Testing-Tool. Ein echtes Highlight für jeden.
E2E Tests werden erfolgreich, wenn das eigene Dev Team sie als Tool einsetzt
Development-Teams bestehen leider noch immer zu großen Teilen aus Backend-Developern, die sich gerne als Fullstack-Developer ausgeben. Wenn sie mehr Frontend-Anteile in sich hätten, würden sie von alleine viel mehr auf lokale E2E-Testruns setzen und das Tool in ihren Workflow integrieren. Abgesehen davon sollten nicht als Console-Ausgaben im Browser rot sein. In einer solchen Ausgangslage können Frontend-Tests nicht erfolgreich sein, weil sie als Fremdkörper betrachtet werden und zudem sehr nervig sind.
Eine offene Fehlerkultur im Bereich der Backend-Developer lässt leider immer stärker nach. Die Hoffnungslosigkeit in Legacy-Systemen, gepaart mit der Konsequenzfreiheit aufgrund des aktuellen Arbeitsmarktes, führt dazu, dass Fehler lieber gerne verschwinden. Ein Tool, das zuverlässig Fehler findet, bekommt hier keine Freunde. Das merke ich auch immer wieder. Am liebsten möchten meine Kunden grüne Tests ohne Laufzeit, die am besten ein 100% fehlerfreies Siegel ausspucken. Das geht leider nicht, und deshalb werden Tests dann auch nicht beauftragt. Nur wer wirklich Fehler finden möchte und zuverlässige Software verkauft, nutzt alle zur Verfügung stehenden Tools, um Bugs zu finden, zu vermeiden und abzubauen. Und da gehören lokale Tests einfach dazu. Nicht alle, aber diejenigen, die man selber auch klicken würde. Und da kommen wir wieder ins Spiel und werden als Ressource gebraucht.
Fazit wie E2E Website Testing einen echten Vorteil für IT Projekte bringt
Wenn das klare Ziel eine hohe Softwarequalität ist, die Kunden, User, Unternehmen und alle zufrieden macht und ruhiger schlafen lässt, dann spielt alles eine Rolle, was auf dieses tolle und richtige Ziel einzahlt. Dann sind Bugs eine Plage und ein Problem, das angegangen wird. Am besten direkt an der Quelle und sonst sollen Bugs so schnell wie möglich gefunden werden. Und nicht erst „wenn der Kunde es merkt“. Und wenn man als Developer Wert darauf legt, ein entspanntes Leben mit zufriedenen Kunden zu führen, wird Bugs ablehnen. Dafür bildet man einen professionellen Rahmen, der auf das Ziel der nachhaltigen Softwareentwicklung mit allen zur Verfügung stehenden Mitteln einzahlt. Hier sollten E2E-Website-Tests auf jeden Fall mit eingesetzt werden und die eigene Arbeit des Klickens ersetzen. Und es ist ja mehr als nur Klicken und spart einfach eine Menge Zeit.
1 Kommentar
[…] nicht nachhaltig. Das neue Wissen kann nicht direkt angewendet werden, die Tests werden rot und die Success Story bleibt aus. Viel besser ist es, wöchentliche 90 Minuten Coachings zu machen. Das lässt sich gut […]