© istockphoto.com/kycstudio
Frontend Testing mit Codeception ist einfach, schnell und zuverlässig

Fast and Furious


Ein wichtiges Ziel der Webentwicklung ist es, effektiver zu werden. Doch es gibt nur wenig neues gutes Personal, und der Markt ist stark umkämpft. So muss davon ausgegangen werden, dass derzeit bis zu 20 Prozent Webentwickler fehlen. Wäre es also nicht viel einfacher, Teams um 20 Prozent effektiver zu machen? Automatisierte Tests mit Codeception könnten hierbei eine große Hilfe sein.

Die Kosten eines Bugs steigen mit der Zeit, die es braucht, ihn zu entdecken. Findet der Entwickler den Bug im Moment der Entwicklung, kostet er praktisch gar nichts. Wird er aber erst später vom Testteam auf dem Staging-System gefunden, so bindet das zusätzliche Ressourcen beim Personal und der Kommunikation und ist damit schon wesentlich teurer. Danach geht das Ganze zurück zum Entwickler. Hierdurch können Spannungen zwischen den Teams entstehen, und das kann sich zuspitzen. Denn der Entwickler hat zwischenzeitlich schon etwas anderes angefangen, muss sich also erst wieder in den „alten“ Stand hineindenken, um den Fehler beheben zu können. Folge: Seine aktuelle Arbeit wird blockiert. Das führt zu einer nur schwer kalkulierbaren Mehrbelastung und mündet nicht selten in einem Produktionsengpass.

Die größten Kosten verursachen Bugs, die es ins Livesystem geschafft haben. Abgesehen von den enormen Schäden, die auf Seiten des Kunden entstehen können, sind auch die Korrekturwege unverhältnismäßig länger. Das fällt dann in die Kategorie eines Hotfixes: Entwickler beginnen, den Fehler gemeinsam im Vier-Augen-Prinzip zu beheben, Tests werden mehrfach manuell durchgeführt, und alle anderen Ressourcen, die eigentlich für den Rollout benötigt werden, müssen ebenfalls verfügbar gemacht werden. Der Druck auf die Entwicklungsabteilung ist in solchen Momenten enorm. Dadurch steigt die psychische Belastung, und die Arbeit wird zusehends unangenehmer.

Das Pferd nicht von hinten aufzäumen

Es gilt also, die Ursachen von Bugs zu analysieren. Doch der Arbeitsalltag eines Entwicklers ist nicht einfach. So wird oft fälschlicherweise davon ausgegangen, dass die Entwicklungsabteilung der Engpass im Produktionsprozess ist, und Projektmanager versuchen dann, den Engpass mit zusätzlichem Personal zu umgehen. Damit packt man das Problem aber nicht an der Wurzel. Denn Fakt ist: Bugs entstehen unter Zeitdruck. Insofern hilft es wenig, wenn zuvor an der Softwarequalität und dem Refactoring gespart wurde, nur weil das Ganze möglichst schnell live soll. Nur um dann hinterher das Team aufzustocken, um die Situation wieder in den Griff zu bekommen. Damit zäumt man das Pferd von hinten auf.

Denn was beim geringsten Testumfang auf der lokalen Umgebung mit Testdaten funktioniert, ist meist noch lange nicht ausgereift. Im Ernst: Würden Sie auf solch ein Pferd setzen? Nur wer tatsächlich Tests schreibt, fängt an, seine Software viel kritischer zu betrachten und auszuhärten. Erst der neue Blickwinkel ist es, der die Qualität steigert. Auch „Klickdummies“ sind ein Schlüssel zur Zeitersparnis, und hierbei sollten dann auch die kompletten Realdaten eingepflegt werden.

Sind automatisierte Tests die Lösung?

Die maschinelle Fertigung ist der Schlüssel zum technischen Fortschritt und eine zentrale Errungenschaft für uns alle. Warum also vertraut man nicht auch in der Anwendungsentwicklung darauf? Als die Stiftung Warentest vor Kurzem ihr Jubiläum feierte, gab es ein Video, in dem Testroboter hunderte Male den Sprung auf Bettmatratzen ausführten. Könnten nach dem gleichen Prinzip nicht auch Slider geklickt, gestaucht und auseinandergezogen werden? Und das auf Internet Explorer, Firefox, Chrome und Safari – in den beiden letzten Versionen in je drei Auflösungen. Das ist ohne Weiteres machbar und schnell aufgesetzt. Doch oft sind es Unwissenheit und Vorurteile gegenüber Tests, die deren Einführung verhindern.

Frontend Testing binnen fünf Minuten

Zum ausführlichen Testen klickt man sich nach und nach durch eine komplette Website. Gerade bei komplexen Interaktionen in Zusammenhang mit Formularen kann das sehr zeitaufwändig sein – etwa bei Internetseiten, mit denen Geld verdient wird, denn die bestehen aus sehr komplexen Formularen. Sorgfältige Tests sind hier erfolgsentscheidend.

Auch Acceptance Tests sagt man sehr lange Ausführungszeiten nach. Angeblich können diese aber nur nachts in so genannten Nightly Builds ausgeführt werden. Und schon kommt der Einwand: „Wir können nicht immer eine Nacht lang warten, bis wir etwas ausrollen!“ Hier sind die Prämissen falsch. Und auch, dass nur Browser benutzt werden, die kein User nutzt (Stichwort „Phantom“), stimmt so nicht. Allerdings können ausführliche Testszenarien auf mehreren Browsern und in verschiedenen Auflösungen tatsächlich sehr lange dauern. Aber das ist nicht der Einstiegsanwendungsfall und letztlich auch nicht zielführend.

Generell kann man festhalten, dass man schon mit fünf Minuten sehr weit kommt. In solch einer Testsuite sollte man einen Browser in einer Auflösung nutzen. So spart man nach der Einführung und den weiteren Tests viel Zeit und steigert bereits die Softwarequalität, indem man nicht in die Breite, sondern in die Tiefe geht. Für den Anfang nehmen wir uns ein Szenario aus dem Bereich E-Commerce. Dafür erstellen wir Testsuiten, wie in Listing 1 zu sehen.

Listing 1

Startseite Slider Beinhaltet mindestens 4 Elemente Jedes Element hat ein Bild mit einem Alt-Text einen anderen Link Teaser Hat eine Liste aus mindestens 5 Elementen Jedes Element hat einen Tool Tip, der beim Mouseover erscheint Produkt Karoussel Jedes Item hat ein Bild mit Alt-Text Preis durchgestrichen ist größer als angegebener Preis Kann vorwärts geklickt werden, beim letzten Elemen...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang