re-lounge
Nur gute Seiten

Melanie Kurz

Melanie Kurz

hatte schon das Praxissemester ihres Medieninformatik-Studiums bei re-lounge verbracht und kam dann für ihre Bachelorthesis zurück, bevor es sie ins Allgäu zog. Als gelernte Grafikdesignerin schlägt ihr Herz nicht nur für die Webentwicklung, sondern generell für die schönen Dinge des Lebens. Dazu gehört neben Kunst und Fotografie auch die Musik – am liebsten live und in Farbe, als Flötistin mittendrin im Orchester.



Alle Artikel von
Melanie Kurz bei Xing

Melanie Kurz
Von Melanie Kurz 18. Mai 2016
1 Star2 Stars3 Stars4 Stars5 Stars
5,001 Stimme(n)
Loading...
Alle sprechen von responsive, jeder will Webseiten auf allen seinen Geräten optimal erleben können, und das bei zig verschiedenen Möglichkeiten. Alles selbstverständlich. Doch warum ist das so, und was bedeutet das für die Entwicklung? Genau diesen Fragestellungen bin ich im Rahmen meiner Bachelorthesis für die Freiburger Digitalagentur re-lounge nachgegangen.

Hintergrund

In den letzten Jahren ist die Smartphone-Nutzung in Deutschland stetig gestiegen und hat sich mit 46 Millionen Usern im Jahr 2015 im Vergleich zu 2009 mehr als versiebenfacht. Es nutzt also durchschnittlich jeder zweite ein Smartphone, wobei man hier bedenken muss, dass auch Kinder und sehr alte Menschen eingerechnet wurden.
Der Zugriff auf Websites erfolgt folglich über eine große Zahl verschiedenster Endgeräte. Dies reicht von klassischen Desktop-Rechnern über Tablets bis hin zu Smartphones. Allein auf dem Smartphone-Markt weltweit haben in den letzten sechs Jahren über zehn verschiedene Hersteller mitgemischt und dementsprechend sind auch verschiedene Modelle und Versionen auf dem Markt:

Marktanteile der führenden Hersteller am Absatz von Smartphones weltweit

Infolgedessen entsteht somit auch eine große Bandbreite an Auflösungen.

Die Auflösungen reichen von 320 x 480 bis hin zu 2560 x 1440 Pixeln. Dazwischen variieren die Auflösungen und Seitenverhältnisse enorm. Einen Eindruck hierzu vermittelt folgende Abbildung:

Übersicht verschiedener Screen-Auflösungen

Seit dem 21. April 2015 spielt die Mobiloptimierung bei Websites eine noch größere Rolle als die Jahre zuvor, denn Google hat die Mobiloptimierung als neues Kriterium für das Ranking in der Suchmaschine eingeführt (https://webmasters.googleblog.com/2015/04/rolling-out-mobile-friendly-update.html).

Gerade im Hinblick auf die Indizierung der Website bei Google – was das Ziel eines jeden Website-Betreibers sein sollte, denn Google ist mit einem Marktanteil von 94,84 % in Deutschland immer noch Marktführer im Bereich Suchmaschinen (siehe SEO-united 2015) – sollte die Performance hinsichtlich Ladezeit einer Website generell gut funktionieren. Immerhin ist die Ladegeschwindigkeit eines der Kriterien, anhand derer Google die Webseiten im Suchindex positioniert, wie Google selbst im Webmaster Central Blog bereits April 2010 bekannt gab (https://webmasters.googleblog.com/2010/04/using-site-speed-in-web-search-ranking.html). Ein Wegfall oder eine deutliche Verschlechterung der eigenen Platzierung in Google kann für viele Website-Betreiber enorme finanzielle Einbußen bedeuten.

Was tun?

Mit Blick auf diese Hintergründe ist es gerade für Online-Agenturen wie re-lounge, die nur noch responsive Websites entwickelt, und Entwickler wichtig, die von ihnen entwickelten Webseiten bestmöglich hinsichtlich der oben genannten Kriterien zu testen. Denn nur so können sie ihren Kunden ein optimales Ergebnis liefern.

Da Testing und Qualitätssicherung im Frontend-Bereich der responsiven Web-Entwicklung aufgrund der Vielfalt verschiedener Endgeräte, Auflösungen und Browser sehr zeitintensiv ist, wird eine Lösung für eine möglichst einfach zu handhabende Entwicklungs- und Testumgebung benötigt, die Web-Entwickler bei der Qualitätssicherung unterstützt oder sogar Teile der Arbeit abnimmt.

Im Rahmen meiner Bachelorthesis entstand so eine Testautomation, die – zunächst prototypisch umgesetzt – künftig die Entwickler bei re-lounge noch besser in der Qualitätssicherung unterstützt und dabei auch die anspruchsvollen Development-Workflows berücksichtigt.

Automatisierte Tests

Nach ausführlicher Recherche verschiedenster Tools und Möglichkeiten entstanden dabei automatisierte Tests, die in drei Bereiche unterteilt werden können:

Das Frontend

Da re-lounge-Frontend-Projekte i.d.R. mit PatternLab (http://patternlab.io)  gebaut und somit über Grunt (http://gruntjs.com) kompiliert werden, bietet es sich an, auch die automatisierten Tests über Grunt laufen zu lassen. Hierfür kommen also Tools in Frage, die auf Grunt/Node basieren, bzw. die über die Kommandozeile gesteuert werden können.

Das Visual Regression Tool Wraith (http://bbc-news.github.io/wraith), entwickelt von den Entwicklern von BBC News, bietet sich in diesem Falle besonders an. Es bietet die Möglichkeit über Headless Browser wie PhantomJS, CapserJS oder SlimerJS Vorher- Nachher-Screenshots zu erstellen, die übereinander gelegt werden und damit Bilddifferenzen farblich markieren können.

Das direkte Frontend bestreffend wurden folgende Use Cases erstellt:

Überprüfung des Frontends auf Designtreue der vorgegebenen Screen-Designs

Hierbei wird besagtes Visual Regression Testing mit Wraith über Grunt gestartet. Die Konfiguration wurde bereits so an den Workflow angepasst, dass die Entwickler den Prozess mit einem einzigen Befehl starten können. Dabei werden die vorgegebenen Screen-Designs mit den neu entwickelten Templates verglichen. Die Ausgabe erfolgt als HTML-Galerie sowie zusätzliche als Konsolenausgabe mit den farblich gekennzeichneten Unterschieden.

Galerie-Ausgabe der Differenzen als HTML-Datei in verschiedenen Auflösungen. Ausgabe der Differenzen in der Kommandozeile

 

Überprüfung des Designs bei Layoutänderungen schon vorhandener Projekte Visual Regression Testing mit Wraith (s. o.)

Dieser Use Case befasst sich mit der Problematik unbeabsichtigter Änderungen bei Änderungen an schon bestehenden Seiten („Seiteneffekte“). Ein typisches Beispiel hierfür ist die Änderung an einem Inhaltselement, welches auf verschiedenen Seitenvorlagen vorkommt. Dabei kann es leicht geschehen, dass das Element an der gewünschten Stelle nach der Änderung völlig korrekt angezeigt wird, aber auf einer der anderen Seiten plötzlich ungewollt (und unbemerkt) eine fehlerhafte Darstellung aufweist.

Zur Lösung wird zunächst vollautomatisch ein Set Screenshots des Ausgangszustands hinterlegt und dann mit dem neuen Stand nach der Änderung abgeglichen. Ein Vorteil hierbei sind sicherlich die vielen Auflösungen die individuell definiert werden können. Als Ergebnis entsteht so eine gute Übersicht über die Seiten in den mobilen Varianten.

Die Besonderheit dieses Falles ist es, dass vorher auch JavaScript-Funktionen ausgeführt werden können. Es können also zum Beispiel Menus geöffnet werden etc.

Außerdem kann die Erstellung von Screenshots mit Hilfe von Selektoren gezielt auf spezielle Container und spezielle Elemente beschränkt werden. Der Entwickler kann also direkt die Elemente separat prüfen, an denen er gerade arbeitet. (Abbildung 3 zeigt all diese Möglichkeiten auf.)

Die CMS-Integration

Wird eine Website durch ein Content Management System gepflegt, so werden die Frontend- bzw. HTML-Markup-Templates stets dort nochmals separat eingebunden. Bei diesem Prozess besteht trotz vorherigem, frontendseitigen Testen immer noch die Gefahr, dass durch gegenseitige Beeinflussungen und Abhängigkeiten sowie die CMS-bedingte sich oftmals von Pattern Lab unterscheidende Modul-Struktur, Layout und Design verändert werden. Da diese Integration häufig nicht vom gleichen Entwickler erledigt wird, der auch das HTML-Markup erstellt hat, ist es für ihn schwierig, selbst direkt Abweichungen zu erkennen. Deshalb kann er, genau wie der Frontend-Entwickler, einen Grunt-Befehl ausführen, der die ursprünglichen Frontend-Templates mit den Templates des Content Management Systems (CMS) vergleicht.

Zudem besteht die Möglichkeit, über das von Yahoo entwickelte und von Google empfohlene Tools YSlow Ladezeit und Dateigewicht der Website zu überprüfen. YSlow lässt sich über die Kommandozeile ausführen und wurde im Rahmen meiner Thesis so angelegt, dass über die Konfigurationsdatei die verschiedensten Ausgabeformate gesteuert werden können. So kann definiert werden, ob nur die Basisdaten wie Seitengewicht, Benotung anhand eines vorgegebenen Algorithmus, URL, Request-Anzahl, Ladezeit geprüft wird, oder ob noch der Cache und verschiedene Seitenkomponenten mit einberechnet werden sollen. Außerdem können sowohl useragent als auch viewport, also Gerät und Seitenverhältnisse, vorher definiert werden. Das Ergebnis wird dann je nach Wunsch im json, xml, reinen text, tap ode junit-Format ausgegeben.

Continuous Integration zur Routinekontrolle

Um permanent Änderungen unter Kontrolle zu haben, wurde zusätzlich der Test-Prozess in den Continuous Integration Prozess bei re-lounge integriert. Dafür wird bei jeder Aktualisierung des zuvor definierten Git-Branches (Zweig des genutzen Repositorys zur Versionsverwaltung) eine automatisierte Überprüfung über einen Jenkins-Server ausgeführt.

Mit der jeweiligen Konsolenausgabe werden die Fehler-Reports direkt als Link abgelegt, sodass späteres Nachlesen jederzeit möglich ist. Außerdem zeigt die mit Jenkins kommende visuelle Aufbereitung direkt erfolgreiche Tests an.

Es findet also permanent eine Überprüfung statt, ohne dass der jeweilige Entwickler zusätzliche Befehle ausführen muss.

Fazit

Das Frontend-Testing ist enorm wichtig um bei Responsive Design Projekten eine hohe Güte und Qualität über alle Auflösungen hinweg zu ermöglichen. Mit der vorgestellten Testautomation können nun tendenziell fehleranfällige und gleichzeitig enorm aufwändige, manuelle Tests weiter reduziert werden. Und das bei gleicher oder gar besserer Qualität. Das Ergebnis sind über alle Devices hinweg funktionierende Webseiten, bei denen die Nutzer nicht durch Darstellungsfehler gestört werden, sondern sich auf das wesentliche konzentrieren können: tolle Inhalte.

Kommentar abgeben

*Pflichtfeld