Mobility / Software-Test

Qualität in der Tasche – Mobile App-Testing

Apps für mobile Endgeräte spielen im Zeitalter der Smartphones eine wichtige Rolle im IT-Sektor. Insgesamt gibt es in den diversen Appstores mehr als 1,6 Millionen Apps, die nahezu in allen Lebensbereichen Anwendung finden. Sätze wie „… dafür gibt es ja schon eine App“ sind mittlerweile alltäglich geworden und auch auf internationalen Konferenzen behandeln immer mehr Vorträge das Thema „Mobile App-Testing“ (2014 findet sogar erstmalig eine eigene Konferenz dazu statt: http://www.mobileappeurope.com/).

Mobile App Testing

Der Markt wird dabei von wenigen großen Anbietern wie Samsung, HTC und Apple beherrscht. Deren Betriebssystem Android und iOS haben zusammen mehr als 85% Marktanteil und daher fokussieren sich viele Unternehmen auf diese beiden Betriebssysteme. Bei Apples iOS-Betriebssystem betrifft das eine überschaubare Anzahl an Endgeräten, bei Googles Android ist die Palette an Geräten jedoch um ein Vielfaches breiter. Hinzu kommen weitere Plattformen wie BlackBerry OS / BlackBerry 10,  Java ME oder Firefox OS die entweder weiterhin in bestimmten Bereichen stark vertreten sind oder deren zukünftige Entwicklung noch nicht absehbar ist. Ziel dieses Artikels ist es daher, eine Möglichkeit vorzustellen, wie Mobile-Apps auf dieser Vielzahl von Plattformen effizient getestet werden können.

Mobile App Testing_Mobile Phone Market Share 2012 (Quelle: Testing Experience Nr . 3)

Mobile Phone Market Share 2012 (Quelle: Testing Experience Nr . 3)

 

Herausforderungen beim Mobile App-Testing

Grundsätzlich ist Mobile App-Testing keine neue, eigenständige Disziplin und bedarf daher auch keiner speziellen Ausbildung – eine vertiefende Spezialisierung in Mobile-Automatisierungstools ist jedoch sehr wohl nützlich und notwendig. (Einige Herausforderungen und mögliche Stolperfallen bei der Testautomatisierung sind auch im Artikel „Testautomatisierung im Vormarsch!“ zusammengefasst.)

Als Teil- oder Unterdisziplin des herkömmlichen Sofwaretests sind auch beim Mobile-Testing die bekannten ISTQB®-Teststufen wie Komponententest, Systemtest, Abnahmetest gängig. Dennoch gibt es einige Besonderheiten und Herausforderungen, die zu beachten sind.
Dazu gehören:

  • Gerätevielfalt
  • diverse Betriebssysteme
  • multiple Betriebssystemversionen mit unterschiedlicher Funktionalität (vgl. Twitter-API ab iOS5)
  • unterschiedliche Hardware
  • variierende Displaygröße
  • Netzwerkperformance und unterschiedliche Typen von Netzwerkanbindung
  • unterschiedliche Netzbetreiber
  • Störquellen (Anrufe, SMS, Pushnachrichten)
  • unterschiedliche User Experience

Speziell die Vielzahl von Geräten und Betriebssystemen stellt die Qualitätssicherung vor eine enorme Anzahl an potentiell relevante Testfälle und Testkonfigurationen. Eine Herangehensweise, um dieses Problem zu beseitigen, ist die drastische Reduktion der Testplattformen (z.B. nur die Top 5 Betriebssysteme). Doch auch der funktionale Test der Top 5 Plattformen ist in vielen Fällen mit erheblichen Aufwand verbunden, wenn der Großteil der Testdurchführung über das mobile Endgerät durchgeführt wird. Dieser Artikel beschäftigt sich daher mit einem anderen Ansatz.

Fokus auf die Software-Architektur

Der Grundgedanke dabei ist, dass der Großteil der testrelevanten Artefakte nicht über ein mobiles Endgerät, sondern auf (Teilsystem-) Integrationstest- oder sogar auf Komponententeststufe abgedeckt wird. GUI-Tests auf mobilen Endgeräten werden nur durchgeführt, wenn das dadurch angestrebte Testziel nicht auf einer anderen Stufe erreicht werden kann. Dieses Vorgehen führt unter anderem zu den folgenden Vorteilen:

  • Reduktion der auf physischen Endgeräten durchzuführenden Tests, da komplexe Businesslogik bereits auf einer darunterliegenden Schicht getestet wurde
  • Die Komplexität der Automatisierung von Integrationstests (zum Beispiel von SOAP-/REST-konformen Webservices) ist geringer als die Automatisierung von UI-Tests.
  • Durch die geringere Komplexität und bessere Automatisierbarkeit sinken auch die Kosten für die Durchführung eines Testfalles.
  • Die Durchführungsgeschwindigkeit und Stabilität ist höher (zum Beispiel weil Vorbedingungen schneller hergestellt werden können).
  • Aufgrund der hohen Durchführungsgeschwindigkeit und der geringen Kosten pro Durchführung können pro Release umfangreiche Regressionstests durchgeführt werden.
Mobile App Testing_Mehrschichtige Architektur mit Ansatzpunkte für Mobile App-Testing (Quelle: Testing Experience Nr. 3)

Mehrschichtige Architektur (Quelle: Testing Experience Nr. 3)

Der Service Layer

Wie in der Abbildung oben dargestellt, gibt es je nach konkreter Anforderung unterschiedliche Ansatzpunkte, um die diversen Schichten eines zu testenden Systems anzusprechen. Die aufgrund der dafür verfügbaren Werkzeuge und der zur Verfügung gestellten Flexibilität am häufigsten genutzte Schnittstelle ist der Service Layer. Die im Business Layer implementierte Logik (Entitäten, Business Components, Workflows) werden durch diese Schicht gekapselt und stellen eine standardisierte Schnittstelle zu anderen (Teil-)Systemen dar.

Der Data Layer

Die zweite häufig angesprochene Schicht ist der Data Layer (auch Datenzugriffsschicht genannt). Anders als der Service Layer stellt dieser lediglich Funktionalität für die Persistierung der für das Softwaresystem relevanten Entitäten zur Verfügung. Dabei ist zu beachten, dass der direkte Zugriff auf die Datenbasis eines Systems nicht ohne Risiken ist. Beispielsweise besteht die Gefahr, dass

  • die Konsistenz der Daten nicht mehr gewährleistet wird (vor allem die logische Konsistenz wird leicht verletzt).
  • Seiteneffekte, die normalerweise durch andere Schichten ausgelöst werden, übersehen werden.
  • Einschränkungen von anderen Schichten (zum Beispiel Berechtigungen) nicht berücksichtigt werden.

Trotz dieser Risiken ist der Zugriff auf den Data Layer vor allem für die Herstellung von Vorbedingungen, die Verifikation von erwarteten Resultaten sowie die Überprüfung von Nachbedingungen in vielen Fällen ein gangbarer, effektiver und ausreichend stabiler Weg.

Ein mögliches Vorgehen

Ausgehend von der zuvor beschriebenen Architektur lässt sich nun beispielsweise das folgende Testvorgehen für den effektiven Test von mobilen Applikationen ableiten:

Ein hoher Anteil der funktionalen Anforderungen (ca. 80 %) sollte ausschließlich über den Service Layer getestet werden.

Da gerade im Businessumfeld häufig bestehende Funktionalität mobil verfügbar gemacht werden soll (man denke zum Beispiel an eine Mobile-App für das Internetbanking), ist in vielen Fällen ein wesentlicher Teil der eigentlichen serverseitigen Businesslogik bereits durch anderwärtige Tests abgedeckt und muss nicht erneut komplett getestet werden. Um den Aufwand für Tests der verbleibenden, geänderten oder hinzukommenden Funktionalität zu reduzieren, bietet sich die Automatisierung der auf dieser Schicht verfügbaren Schnittstellen (zum Beispiel SOAP, REST, RPC Interface) an. Auf diese Weise kann die Funktionalität einer Anforderung einfach verifiziert und gleichzeitig die Performanz-Eigenschaften eines Systems festgestellt werden.

Wie zuvor beschrieben, wird der Data Layer bei diesem Ansatz primär für das Sicherstellen von Vorbedingungen (z.B. das Anlagen der notwendigen Benutzer in einer Mandatsverwaltung) und der Verifikation von Nachbedingungen (z.B. ob eine aufgegebene Bestellung auch korrekt gespeichert wurde) eingesetzt.

Einsatz von Emulatoren

Die verbleibenden ca. 20 % der funktionalen Anforderungen müssen jedoch nicht ausschließlich mühsam am mobilen Endgerät getestet werden. Emulatoren können als Nachbildung der realen Endgeräte am Computer ausgeführt werden und können neben der eigentlichen App nahezu jede andere Funktion und Konfiguration, sowie unterschiedliche Zustände ebenfalls simulieren. Dazu gehören unter anderem Bildschirmauflösungen, Kamera, Netzwerke, GPS, Speicher und Akkuzustand. Auf diesem Weg können die Testfälle am mobilen Endgerät auf ein Minimum reduziert werden (ca. 2 – 10%).

Ganz ohne geht es dann doch nicht

Auf das Testen am realen Endgerät kann demnach nicht ganz verzichtet werden, da es eine notwendige Entscheidungskomponente für die produktverantwortlichen Personen darstellt, ob eine Mobile-App „live geht“ oder eben nicht. Das Look-and-Feel-Erlebnis einer App kann ebenso wie die Usability nur am Endgerät selbst effektiv getestet und nicht mittels Emulatoren oder Integrationstest verifiziert werden.

Unit Tests?

Bei diesem Ansatz wurden explizit keine Unit Tests erwähnt. Der Grund dafür ist, dass diese primär von der Entwicklung erstellt und gewartet werden. Allerdings soll das deren Bedeutung nicht schmälern – vielmehr sind Unit Tests bzw. Komponententests in der Praxis jene Tests die den Großteil der funktionalen Anforderungen verifizieren. Das zuvor beschriebene Vorgehen betrachtet die Applikation jedoch als Black-Box und beachtet Unit Tests daher nicht. Es gibt unterschiedliche Gründe, warum diese Betrachtungsweise sinnvoll sein kann:

  • Der Zugriff auf den Source Code ist nur eingeschränkt bzw. nicht möglich
  • Entwicklung und Qualitätssicherung werden von unterschiedlichen Unternehmen durchgeführt
  • Die Black-Box Betrachtung reduziert „Betriebsblindheit
  • Unit Tests stellen die Interpretation der Entwickler von Anforderungen dar – diese kann durch Black-Box Tests mit der Interpretation der Tester verglichen werden

Und in der Praxis?

In der Praxis findet man die beschriebene Architektur leider nicht immer vor und ist daher gezwungen, mehr Aufwand in die manuellen Tests am mobilen Endgerät zu investieren. Dementsprechend geringer fällt auch die Überdeckung mit automatisierten Testfällen aus. In diesem Fall muss man eventuell auch auf andere Ansätze zurückgreifen, um den Testaufwand in einem überschaubaren Rahmen zu halten. Eine Alternative ist zum Beispiel das Crowdtesting. Dabei kann eine Vielzahl von unterschiedlichen Geräten in relativ kurzer Zeit und zu geringen Kosten getestet werden. Zusätzlich erhält man auf diese Weise auch effizient Feedback zu nicht funktionalen Eigenschaften, wie der Benutzbarkeit oder der Zuverlässigkeit. Dessen ungeachtet kann das Crowdtesting keinen strukturierten Testansatz ersetzen, sondern diesen immer nur unterstützend begleiten.

Die Zukunft ist Hybrid

Derzeit dominieren native Apps den Markt, also Apps, die auf einem mobilen Endgerät installiert werden. Das könnte sich in naher Zukunft ändern und ist schon im Wandel, haben doch native Apps den signifikanten Nachteil, dass sie für jedes Betriebssystem erneut angepasst werden müssen und dadurch einen hohen Entwicklungs-und Testaufwand erzeugen. Hybrid-Apps, die in plattformübergreifender Sprache (HTML5, JavaScript) geschrieben werden und in einem nativen Container am mobilen Gerät laufen, sehen sich mit diesen Problemen nicht konfrontiert.

Mobile App Testing_Hyprid Apps

Beschreibung Hyprid Apps (Quelle: http://de.wikipedia.org/wiki/Datei:Hybrid_Apps.jpg)

In diesem volatilen Marktumfeld mit hohen Wachstumszahlen und rasanten technologischen Fortschritten ist es, sowohl für Tester als auch Entwickler, schwierig Schritt zu halten. Dessen ungeachtet können diese Entwicklungen nicht ignoriert werden, da sie immer wichtiger für den Erfolg eines Unternehmens sind und von den Konsumenten explizit gefordert werden. Damit ersetzen die dynamischen mobilen Applikationen sukzessive die bisher den Markt dominierenden, schwergewichtigeren Line-of-Business-Applikationen.

Für an der Qualitätssicherung beteiligte Personen bedeutet das, dass weitere effiziente und effektive Vorgehensmodelle entwickelt und implementiert werden müssen. Insgesamt tut sich mit dem Mobile App-Testing ein spannendes Feld auf, in dem auch der Test mittlerweile seinen notwendigen Platz eingenommen hat.

Auch wenn es einige neue Aspekte und Herausforderungen für die Qualitätssicherung in dieser boomenden Spielart von Software gibt, so muss doch das Rad nicht gänzlich neu erfunden werden. Es zeigt sich erneut (und wohl wenig überraschend): Eine schlüssige Architektur und ein wohlüberlegter, nachhaltiger Testansatz machen sich bezahlt.

Was ist Ihre Meinung zu diesem Thema? War die Device Fragmentation in einem Ihrer Projekte ein Problem? Wenn Ja, wie sind Sie damit umgegangen? Ist zum Beispiel Crowdtesting die Lösung für die Probleme beim Test von Mobile-Apps?

Passende Artikel

Kommentare gesperrt.