Test von Mobile­-Apps

Artikel von Philipp Strelka und Stefan Gwihs

Qualität in der Tasche

Apps für mobile Endgeräte spielen im Zeitalter der Smartphones eine wichtige Rolle im IT-Sektor. Insgesamt gibt es in den diversen App Stores 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.

Der mobile Markt wird unter wenigen großen Anbietern, wie Android und iOS, aufgeteilt. Diese beherrschen zusammen mehr als 85 % des Marktes, 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 um ein Vielfaches breiter, da das Betriebssystem auf vielen verschiedenen Geräten lauffähig ist.

Auch Unternehmen sehen sich zunehmend mit der Frage konfrontiert, wie bei der Menge an mobilen Geräten in ihrem Unternehmen die Verwendung von mobilen Applikationen gesteuert werden kann. Die Endanwender verlangen, dass ihre Business-Applikationen von einer möglichst breiten Palette an Smartphones und Tablets unterstützt werden und sowohl online als auch offline nutzbar sind.

Um diesen Qualitätsansprüchen gerecht zu werden, müssen mobile Applikationen, wie jedes andere Softwareprodukt, vor dem Einsatz getestet werden. Seit einigen Jahren ist Mobile-Testing auch im IT-Bereich omnipräsent und bezeichnet bis dato den funktionalen und nicht funktionalen Test von nativen Applikationen, die für ein mobiles Endgerät und ein bestimmtes Betriebssystem entwickelt wurden.

Neue Herausforderungen

Grundsätzlich ist Mobile-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.

Als Teil- oder Unterdisziplin des herkömmlichen Softwaretests sind auch beim mobilen Test die bekannten ISTQB ® Teststufen wie Komponententest, Systemtest, Abnahmetest gängig. Dennoch gibt es einige Besonderheiten, die zu beachten sind. Quality-Assurance-Teams in Mobile-Testing-Projekten stehen einer Vielzahl von Herausforderungen gegenüber. 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)

Das Testen sämtlicher Geräte mit all diesen Kombinationen ergäbe Millionen potenzieller Testfälle und ist somit nicht praktikabel.

Auswahl der Testgeräte

Um dieser kombinatorischen Vielfalt Herr zu werden, ist eine sinnvolle Auswahl der zu testenden Geräte und Softwareversionen nötig. Die untenstehende Grafik zeigt, auf wie vielen verschiedenen Android-Geräten allein die OpenSignal-App in den ersten sechs Monaten im Jahr 2013 heruntergeladen wurde. Die mehr als 11.000 (im Vorjahr lediglich rund 4.000) unterschiedlichen, auf dem Bild dargestellten Geräte belegen eindrucksvoll die Fragmentierung innerhalb eines mobilen Betriebssystems. Wie sich allerdings auch erkennen lässt, verzeichnen wenige Geräte sehr viele Downloads (die linke Bildhälfte) und der Großteil der Geräte sehr wenige Downloads (im rechten unteren Quadranten des Bildes).

Anhand dieser und ähnlicher, auch frei verfügbaren Statistiken können die für das Testprojekt 5, 10 bzw. 20 relevantesten Smartphones am Markt identifiziert werden. Da dies meist in einer frühen Projektphase geschieht, eignet sich eine risikobasierte Priorisierung der Geräte anhand von definierten Kriterien.

Es zeigt sich also, dass der Test mobiler Applikationen eine Herausforderung für die Qualitätssicherung darstellt, und um dieser in der Praxis begegnen zu können, ist ein differenziertes Vorgehen notwendig.

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.

Wie in Abbildung 3 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 implementiert Logik (Entitäten, Business Components, Workflows) werden durch diese Schicht überdeckt und stellen eine standardisierte Schnittstelle zu anderen (Teil-)Systemen dar.

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.

Ausgehend von der zuvor beschriebenen Architektur lässt sich nun ein effizientes Testvorgehen für den Test von mobilen Applikationen wie folgt 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 an (zum Beispiel SOAP, REST, RPC Interface) an. Auf diese Weise kann die Funktionalität einer Anforderung einfach verifiziert und gleichzeitig die Performanzeigenschaften eines Systems festgestellt werden.

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 als Programm am Computer ausgeführt werden und neben der Businesslogik des Gerätes 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 %). 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 App „live geht“ oder eben nicht. Das Look-and-feel-Erlebnis einer App kann ebenso wie die Usability nur am Endgerät selbst getestet werden und nicht mittels Emulatoren oder Integrationstest verifiziert werden.

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 nichtfunktionalen 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.

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 Test von mobilen Applikationen 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts