Cross-Browser und Cross-Device-Tests (Teil 3 von 3)

Wie die Qualität von Cross-Browser und Cross-Device Testen durch echte Geräte gesteigert werden kann, hatten wir im zweiten Teil des Beitrags betrachtet.  Im letzten Teil fassen wir noch einmal die Unterscheidungskriterien zusammen, nennen unsere Testlabor-Settings und schließen mit unseren Erfahrungen aus Festpreisprojekten.
CBT Teil 3

Varianten und Klassifizierung

Wir listen als Übersicht alle Varianten und Kriterien auf, die unsere Auswahl der Tools beeinflusst haben:

  • Simulation oder Hardware
  • Einzel- oder Multi-Browsertest
  • Lokal Ausführung oder Cloud Service
  • Öffentliche oder private Auswertung der Daten
  • Software kostenfrei oder kostenpflichtig
  • Geräte kaufen, vor Ort mieten oder virtuell im Cloud Service nutzen

Für welche Methoden und Werkzeuge entscheiden wir uns?

Viele unserer Kunden fordern eine Geheimhaltung der Projekte, bis sie von ihnen selbst offiziell veröffentlicht werden. Daher setzen wir verstärkt auf unser lokales Testlabor. Die Kosten-Nutzen-Abwägung führt jedoch zu einer Kombination aus lokalem Setup und Cloud-Diensten. Wir haben uns hierbei entschieden, nicht jedes Gerätemodell vorzuhalten, sondern beschaffen primär Testsysteme mit einem hohen Marktanteil bezüglich Endgerät, Betriebssystem und Browser. Exotische Modelle werden gegebenenfalls gemietet oder über Web Services getestet. Öffentliche Projekte erleichtern das breite Testen durch die Verwendung von Cloud-Diensten.

Bei den lokalen Synchronisierungsprogrammen haben wir noch nicht das „komplett zufriedenstellende Produkt“ gefunden. Bei interaktiven Tests werden hierbei nicht alle Klicks oder Touch-Eingaben abgeglichen. Häufig tritt dies bei Buttons mit JavaScript-Aktionen auf. Aktuell setzen wir daher sowohl ein kommerzielles als auch ein freies Produkt ein.

Erfahrungen aus Festpreisprojekten

Natürlich beeinflussen die Anforderungen des Kunden das Testsetup bei jedem Projekt. Erfahrungen aus unseren Festpreisprojekten zeigen schnell, dass es auf die richtige Kommunikation mit den Kunden und die vollständige Anforderungsanalyse ankommt, um die zu unterstützenden Geräte zu identifizieren und zu definieren. Wir haben vor dem synchronen Testen auf unterschiedlichen Browsern und Geräten nur die Möglichkeit gehabt, einzelne Geräte nacheinander zu testen. Mit dem synchronen Testen haben wir nun einen zeitlichen Vorteil, der uns in geringerer Zeit die gleichen qualitativen Ergebnisse sicher stellt. Es steigt zwar immer noch der Aufwand für die Tests, je nachdem wie umfangreich die Browser und Geräte definiert wurden, aber bei der stetig steigenden Geräteanzahl auf dem Markt haben wir einen Testablauf, der uns darin unterstützt. Es darf hierbei aber nicht der Anpassungsaufwand an der Anwendung nach der Testauswertung vergessen werden bezüglich Konzeption und Entwicklung. Werden die Anforderungen zu „weich“ spezifiziert, können beim Kunden Erwartungen entstehen, die während eines Festpreisprojektes nicht gehalten werden können. Daher sind die Absprachen bezüglich Verbindlichkeit bei der Geräteunterstützung wichtig. Hierbei gibt es mehrere Möglichkeiten, die der Kunde nennen kann. Der Kunde möchte seine Mitarbeiter erst beim Release der Software mit Smartphones ausstatten. In diesem Fall wünschte der Kunde eine Geräteempfehlung, die im angemessenen Kosten-Nutzen-Verhältnis steht, und wir konnten gezielt Optimierungen für dieses Gerät umsetzen. Bei Bring-Your-Own-Device (BYOD) gibt es diesen Luxus nicht. Oft besteht aber die Möglichkeit, zum Beispiel das Alter der Geräte oder bestimmter Browser einzugrenzen. Möchte der Kunde jedoch eine Anwendung, die weitreichend optimal verfügbar ist, bedeutet es im schlimmsten Fall eine hohe Abwärtskompatibilität anzubieten. Mit dieser Anforderung steigen sehr schnell die Aufwände in Konzeption, Implementierung und Qualitätssicherung. Der Vorteil bei einem Testlabor ist, das die Geräte vor Ort kontinuierlich getestet werden können. Die mit dem Kunden abgesprochenen zusätzlichen Geräte können dann entweder virtuell getestet oder nach Kauf einfach zu den Testgeräten hinzugesteckt werden. Geräteparks des Kunden sind so unter Kontrolle und die Testaufwände können besser vor dem Angebot kalkuliert werden. Diese Möglichkeiten sollten bei der Anforderungsanalyse betrachtet und benannt werden, damit daraus später im Projekt keine Selbstverständlichkeitsanforderung wird.

Fazit

Unser Workflow vom Cross-Browser-Testing unterteilt sich in mehrere Phasen und die Methoden verändern sich mit dem Voranschreiten des Projekts. Lokale Entwicklungswerkzeuge und Simulatoren erlauben uns eine schnelle, effektive Umsetzung von ersten Ergebnissen. Sobald die Entwicklung voranschreitet und die Anforderungen spezifischer sind, testen wir regelmäßig mit echten Endgeräten. Nur mit diesen können wir die Nutzererfahrung hinsichtlich Interaktion und Performanz realistisch beurteilen. Für effektivere Tests verwenden wir unser Testlabor mit einem Gerätepark. Wenn möglich verwenden auch die Entwickler das Testlabor während der Implementierung, um schnelle Rückmeldung bezüglich der Darstellung, Funktion und Bedienung zu erhalten. Noch eine subjektive Beobachtung zum Schluss: Der echte Gerätepark schafft, im Gegensatz zu zwei Bildschirmen mit vielen Simulatorfenstern, bei den Kunden ein höheres Vertrauen in unsere Arbeit. Die Kunden sehen die Tests auf realen Smartphones und Tablets und können sogar vor Ort selber testen. Autoren: Daniel Süß und Nicole Charlier, akquinet tech@spree GmbH

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s