Im ersten Teil des Beitrags haben wir erläutert, wie mit Cross-Browser bzw. Cross-Device Tests begonnen werden kann. In diesem zweiten Teil betrachten wir die Vorteile von echten Geräten im Gegensatz zu Simulatoren und Browsern.

Einzelne, echte Geräte verwenden

Echte Hardware zeigt echtes Verhalten, reales Multi-Touch und keine unbekannten Abweichungen bei der Implementierung. Die Performance basiert hier auf der wirklich vorhandenen CPU, Grafikkarte und dem Arbeitsspeicher des Gerätes. Wir können weiterhin mit den uns bekannten Browsertools die Anwendungen auf den Geräten untersuchen und verändern. Leistungsanalysen führen wir auf dem mobilen Gerät durch und erhalten realistische Daten zu Engpässen bei Skripten, Verzögerungen durch Darstellungsberechnungen oder unerwünschte Datenübertragung wegen fehlerhaftem Conditional Loading (Conditional Loading: Bedingtes Laden von Inhalten z. B. abhängig nach Viewportgröße).

Dafür verbinden wir die Geräte per USB-Kabel mit dem Computer. Bei Android-Geräten kann der Desktop-Chrome mit dem mobilen Chrome verbunden werden. Aus Sicherheitsgründen muss der Modus „Remote Debugging“ erst am Gerät aktiviert werden. Details dazu listet Google unter den Suchbegriffen „Chrome Dev Tools Remote Debugging“ auf (https://developers.google.com/chrome-developer-tools/docs/remote-debugging). Im Desktop-Chrome kann anschließend unter der URL „chrome://inspect/#devices“ das Remote-Gerät ausgewählt und der mobile Chrome gesteuert und untersucht werden. Unter Mac OS kann Safari angeschlossene Apple Geräte remote debuggen. Safari → Develop → [Menüpunkt mit Gerätename]. Beide Anbieter zeigen in einem Fenster auf dem Hostsystem die Browseransicht des mobilen Gerätes. Interaktionen werden sowohl vom Touchscreen zum Desktop und in die andere Richtung synchronisiert.

Dieser Entwicklungsmodus eignet sich beispielsweise auch, um Performance-Betrachtungen und mögliche Optimierungen unterwegs oder beim Kunden auf einer geringen Anzahl von Endgeräten durchzuführen, ohne aufwändiges Setup aufbauen zu müssen. Nachteilig bei der Kabelverbindung ist die begrenzte Anzahl von Anschlüssen am Computer. Natürlich können über einen USB-Hub mehrere Geräte angeschlossen werden. Dennoch ist dies kein praktikables Testlabor-Setup, mit dem synchrones Testen möglich ist.

Mehrere Geräte synchronisiert Testen

Bisher hatten wir uns auf Interaktionen mit genau einem Gerät fokussiert. Für ein effizienteres Testen werden wir die Interaktionen von einem Hauptfenster gleichzeitig auf andere Geräte spiegeln. Durch synchrones Cross-Browser Testen steigt die Effizienz.

Um einen großen „Gerätepark“ vorzuhalten, zu synchronisieren und zu testen existieren zwei Möglichkeiten: Web Services, als entfernte Dienste in der Cloud, oder einelokale Umgebung mit den Geräten vor Ort. Beleuchten wir beide Varianten etwas detaillierter.

Web Services, entfernte Dienste in der Cloud

Für Web Services spricht, dass ein schneller Zugriff auf viele Kombinationen aus Gerät, Betriebssystem sowie Browser existiert. In diesem Bereich existieren viele Anbieter, die das Cross-Browser-Testing als Tool anbieten. Wichtige Kriterien für die Auswahl eines Angebots sind die Kombinationsvielfalt, die Möglichkeit interaktiv mit entfernten Geräten zu interagieren und mehrere ausgewählte Geräte synchron zu testen. Anbieter werben dann für Cross-Browser-Tests mit Kombinationen von über 100 Browsern sowie unterschiedlichen Betriebssystem und Geräten.

Mit der Produktvielfalt steigt jedoch oft auch der Preis für den Cloud Service, während kostenfreie Anbieter meist auf wenige Browser spezialisiert sind. Auch gibt es Unterschiede im Zugriff auf URLs. Tools einiger Anbieter können nur auf öffentliche, im World Wide Web zugängliche Seiten navigieren. Wenn Auftraggeber jedoch eine Geheimhaltung bis zum offiziellen Release einfordern, reduziert sich die Anzahl der Cloud Services auf jene, welche lokal gehostete Projekte übertragen und auswerten können. Denn das öffentliche Listen von Screenshots aus diesen Tests ist bei einigen Anbietern nicht abwählbar. Der Sicherheitsaspekt kann also ein wichtiges Auswahlkriterium sein.

Die Anforderung nach Interaktion und einer Fernsteuerung der entfernten Geräte schränkt die Dienste weiter ein. So gibt es z. B. für die Testkombinationen Screenshots zum manuellen Vergleich, Videoaufzeichnungen von allen Testgeräten und/oder Layoutvergleiche mit automatischer Analyse von Differenzen. Erwähnt sei, dass nicht jeder Cloud Service echte Hardware für die Tests bereitstellt. Vor allem die günstigen Anbieter bieten oft nur servergehostete Simulatoren und Emulatoren, mit den bereits beschriebenen Vor- und Nachteilen. Schwierig wird die Beurteilung der Performance von entfernten Geräten. Besonders auffällig wird es, wenn per Bildschirmübertragung zugegriffen wird und die Ansicht latenzbedingt verzögert oder übertragungsbedingt fragmentiert aktualisiert. Eine realistische Beurteilung des Anwendererlebnisses ist hierbei kaum möglich.

Lokale Umgebung

In einer lokalen Umgebung greifen wir auf echte Geräte zu. Ohne Zeitverzögerung ist Performance wahrnehmbar, anders als bei den Web Services. Da wir die Hardware direkt vor uns haben, können wir Geräte in die Hand nehmen, reale Touch-Interaktionen, vom Single Touch bis hin zum Multi-Touch mit vier Fingern, durchführen. Das Erlebnis ist wesentlich näher am Anwender als bei entfernten Diensten. Ein weiterer Vorteil: Wenn wir eine offline-fähige Webanwendung entwickeln, können wir bei lokalen Geräten die Seite laden, die Internetkonnektivität deaktivieren und anschließend die korrekte Funktionsweise überprüfen.

Die Synchronisierung mehrerer Browser übernehmen Produkte wie GhostLab, BrowserSync oder Adobe Edge, um nur einige zu nennen. Diese starten einen Webserver auf dem Hostsystem, registrieren alle per WLAN oder LAN verbundenen Klienten und übertragen die Interaktionen zwischen den Klienten. Die Steuerung erfolgt meist innerhalb der einzelnen Webseite im Browser mittels JavaScript und Endgeräte benötigen daher keine zusätzliche Software. Diese Architektur vereinfacht das Setup für weitere Testgeräte und erleichtert deren schnelle Austauschbarkeit. Die Programme bieten teilweise die Möglichkeit, lokale Daten selber via Webserver bereitzustellen oder den Webserver nur als Interaktionsvermittler (Proxy) zwischen den Geräten und einer vorhandenen Webseite zu verwenden. So kann beispielsweise der Zugriff auch auf das Webfrontend in einem komplexen Application Server erfolgen. Hilfreich ist ein Beobachtungsmodus (watch mode), der in definierten Verzeichnissen auf Veränderungen des Quellcodes reagiert und die Klienten-Ansichten aktualisiert.

Eine wichtige Entscheidung bezüglich des lokalen Geräteparks ist, ob alle benötigten selber Geräte gekauft werden oder ob ein temporäres Mieten wirtschaftlicher wäre. Die Kriterien differenzieren sicherlich zwischen den Firmen oder auch den Projekten. Einige Kriterien sind: die Häufigkeit der Verwendung, die finanziellen Aufwendungen, Anforderungen des Kunden, technische Administration der Geräte, ausreichend Räumlichkeiten für ein Testlabor. Vor dem Kauf diverser Smartphones, Tablets und Co. sollte auch die Frage geklärt werden, wie weitreichend getestet werden soll und wo Cross-Browser Testen endet. Tendiert die Entscheidung in Richtung Mietkonzept, lohnt sich ein Blick auf „Device Labs“. In Deutschland und auch Berlin existieren immer mehr Firmen, die bei sich vor Ort komplett ausgestattete Arbeitsplätze für Cross-Browser und Cross-Device Testen vermieten. Der Wartungsaufwand wird hier gespart.

Nächster Teil
Im letzten Beitrag der Reihe werden wir die Unterscheidungskriterien zusammenfassen, unsere Testlabor-Settings nennen und von unseren Erfahrungen aus Festpreisprojekten berichten.

Autoren: Daniel Süß und Nicole Charlier, akquinet tech@spree GmbH