Testen mobiler Applikationen

Artikel von Markus Gärtner

Wer, wie, was, wieso, weshalb, warum?

Mobile Software ist weiterhin auf dem Vormarsch. Mit der weiten Verbreitung von Plattformen wie Android, iPhone und Windows 8 befinden sich mobile Apps auf dem aufsteigenden Ast. Immer mehr beeinflussen diese kleinen Helferchen unser tägliches Leben. Umso wichtiger ist es, dass sie auch funktionieren. Doch was bedeutet das für die jeweilige Applikation?

Werfen wir einmal einen Blick darauf, warum (oder auch warum nicht) man mobile Applikationen testen sollte, was man testen sollte und wie man testen sollte. Mit der Antwort auf diese Fragen können wir sicherstellen, dass Bewertungen anderer Nutzer für unsere Applikationen im App-Store und auf Google Play potentielle Kunden anziehen können und nicht abschrecken.

Warum sollte man mobile Applikationen testen?

Mobile Applikationen sind längst in unseren Alltag eingedrungen. Wenn ich abends mit meiner Frau vor dem Fernseher sitze und mich frage, wer in diesem Abend füllenden Film so alles mitspielt, dann gucke ich eben schnell in meiner Filmdatenbank-Applikation nach. Wenn ich mit dem Auto unterwegs bin und mich mal wieder verfahren habe, dann weist mir die Navigationssoftware auf meinem Handy den Weg. Wenn ich laufen gehe, dann kann mir meine Lauf-App regelmäßig ansagen, wie weit ich schon gelaufen bin und wie schnell ich unterwegs bin.

Diese Applikationen haben alle einen unterschiedlichen Fokus und bringen mir als Nutzer einen unterschiedlichen Mehrwert. Von Spielen und Entertainment über soziale Netzwerke wie Facebook und Twitter bis hin zu Tools wie Dropbox und Evernote kann da alles dabei sein. Für jede dieser Anwendungen gibt es unterschiedliche Gründe, warum sie getestet werden sollten.

Eine mögliche Begründung ist dabei, dass wir durch Tests herausfinden wollen, ob wir die Applikation für den Endkunden freigeben können. Dazu gehört, dass sie ihren Zweck erfüllt. Außerdem soll sie nützlich sein und einen Mehrwert beispielsweise gegenüber dem Webinterface auf dem Smartphone bereitstellen. Zu guter Letzt soll sie natürlich die Akkulaufleistung des Geräts nicht negativ beeinflussen oder gar das Gerät physikalisch beschädigen. Außerdem sind viele Nutzer spätestens seit den NSA-Enthüllungen auf die eingeräumten Rechte bei der Installation einer Applikation aufmerksam geworden.

Fehler in allen diesen Bereichen führen leider zu oft dazu, dass im App-Store oder bei Google Play schlecht bewertete Applikationen landen. Kurz- bis mittelfristig führen derartige schlechte Bewertungen stets zu einem Reputationsverlust und verlorenem Vertrauen seitens der Endkunden. Natürlich variiert je nach Anwendungsfeld und Komplexität der Applikation der Umfang, den unsere Tests haben sollten. Letzten Endes hängt der Testbedarf vom Einsatzfeld der Applikation und der Kritikalität bei Fehlern ab. Lassen Sie uns deswegen einen Blick darauf werfen, was man so alles in mobilen Applikationen testen sollte.

Was sollte man in mobilen Applikationen testen?

Wenn ich zu Studentenzeiten zu meinem Professor gegangen bin, um ihn zu fragen, auf welche Themen ich mich für die Prüfung vorbereiten soll, dann war seine Antwort stets: „Es kann alles dran kommen.“ So ähnlich ist das auch mit dem Testen. Doch können wir realistisch alles testen? Und was heißt dieses ominöse „alles“ eigentlich?

Ich persönlich besitze zwei sogenannte Smartphones. Auf beiden habe ich eine Vielzahl von Applikationen installiert, die ich für meine tägliche Arbeit oder auch während meiner Freizeit und auf Reisen benutze. Dazu gehören E-Mail-Programme, diverse Browser, SocialMedia-Clients, Spiele, Applikationen für Sport, mobile Navigation sowie diverse Tools für Moderationen.

Nehmen wir einmal eine der einfachsten Applikationen. Wenn ich eine Gruppe moderiere, habe ich nicht immer eine Klangschale dabei. Stattdessen habe ich zwei kleinere Applikationen, die mir dabei helfen können, eine Gruppenübung disruptiv zu beenden: eine Polizeisirene und eine Handglocke.

Die Polizeisirene ist ziemlich einfach. Ich schalte die Applikation ein, die Polizeisirene ertönt. Natürlich gibt es eine schicke Animation dazu und ich muss dran denken, den Ton einzuschalten. Ansonsten kann normalerweise in den 10 bis 20 Sekunden, in denen ich die Applikation verwende, nicht viel schief gehen, oder?

Hier sind ein paar Testideen für die Polizeisirene:

  • Einschalten, Ton ausgeschaltet
  • Einschalten, Ton eingeschaltet
  • Ausschalten
  • Anruf bei eingeschalteter Applikation
  • Applikation starten und bis zur automatischen Sperre des Bildschirms warten
  • Langzeittest
  • Wie schnell ist der Akku leer?
  • Wann stürzt die Applikation ab?
  • Wie groß ist die Applikation?
  • Greift sie auf GPS, Bluetooth, WLAN etc. zu?

Zugegeben, die Polizeisirene ist eine ziemlich einfache Applikation. Die Testideen oben sind allerdings auch noch lange nicht erschöpfend. Was zum Beispiel passiert, wenn ich andere Applikationen im Hintergrund laufen lasse? Wenn zeitgleich Musik abgespielt wird? Und so fort. Trotzdem können wir für diese Applikation in ziemlich kurzer Zeit vermutlich ausreichend Informationen sammeln, um sagen zu können, dass wir genügend getestet haben, um die Applikation frei zu geben.

Wie sieht es mit einer etwas komplexeren Applikation aus? Nehmen wir einmal eine Applikation wie Google Maps. Was müsste ich hier testen, um alles getestet zu haben? Muss ich dafür an jeden Ort der Welt reisen? Muss ich von jedem Ort der Welt zu jedem anderen Ort der Welt eine Reise planen? Wie lange würde das dauern?

Ein anderes Beispiel: Dadurch, dass ich viel unterwegs bin, aber trotzdem Sport treiben möchte, gehe ich oftmals laufen. Ich habe auch eine Applikation auf meinem Telefon, die die GPS-Signale verwendet, um meine Laufstrecke zu bestimmen, und die mir an schließend sagen kann, wie weit und wie schnell ich gelaufen bin.

Vor einiger Zeit führte der Hersteller dieser App das Feature der automatischen Pause ein. Wenn ich jetzt an einer Ampel stehe, dann schaltet sich die Applikation automatisch in den Pausenmodus und die Wartezeit an der Ampel wird nicht länger auf meine Laufzeit addiert. Dadurch erhalte ich realistischere Ergebnisse über mein Laufergebnis.

Zufällig fiel mir irgendwann auf, dass die automatische Pause mit der manuellen Pause und den Ansagen alle 5 Minuten nicht gut zusammenarbeitet. Wenn ich zum Beispiel eine längere Pause mache, dabei etwas länger brauche, um mein Mobiltelefon aus der Tasche zu kramen, den PIN einzugeben, um das Telefon zu entsperren, und dann die manuelle Pause aktivieren möchte, kann es vorkommen, dass die Applikation erkennt, dass ich nicht mehr laufe, und die automatische Pause aktiviert. So weit, so gut. Doch wenn ich mich dann wieder bewege, wird der Lauf fortgesetzt. Das will ich vermeiden. Also reaktiviere ich den Lauf manuell, um ihn dann wieder zu pausieren.

Während einem dieser Läufe bemerkte ich anschließend, dass ich keine Ansagen über meinen Fortschritt alle fünf Minuten mehr bekam. In weiteren Testläufen stellte ich fest, dass das Zusammenspiel von manueller und automatischer Pause mit der fünfminütigen Ansage zu einem Problem führte. Ist das ein realistisches Szenario? Hätte der Hersteller der Applikation vor Auslieferung dieses Szenario durchspielen sollen, um mich vor diesen Problemen zu bewahren?

Ein inhärentes Problem im Softwaretesten allgemein ist, dass wir nicht alles testen können. Traditionelle wie moderne Testdesignmethoden zielen genau darauf, die Tests zu identifizieren, die notwendig sind, um eine möglichst genügende Testabdeckung zu erreichen. Doch was bedeutet das?

Das bedeutet vor allem, dass wir uns entscheiden müssen, welche Tests wir ausführen wollen und welche wir nicht ausführen wollen. Damit müssen wir abwägen, welcher Test uns die besten Informationen derzeit liefern kann und auf welchen Test wir in der uns zur Verfügung stehenden Zeit verzichten müssen.

Nehmen wir das Beispiel der Lauf-Applikation. Welche Tests sollte ich hier vor der Auslieferung durchführen? Die Standardfunktionalität sollte funktionieren, doch was bedeutet das ganz genau? Natürlich sollte ich in der Lage sein, einen normalen Lauf zu absolvieren. Manuelle Pause und Stopp sollten funktionieren, genauso wie das spätere Speichern meiner gemessenen Daten auf dem Server. Die Applikation sollte bei allen diesen Abläufen nicht abstürzen, regelmäßig Ansagen machen können und auch bei einem Marathon natürlich nicht den Akku überstrapazieren.

Doch wie sieht es mit meinem Fehlerfall aus, bei dem eine Kombination und Interaktion aus manueller und automatischer Pause zu einem Fehler führt? Sicherlich lässt sich dafür ein Test erstellen. Zumindest auf der Ebene des Endbenutzers sollte das doch möglich sein. Allerdings stellt sich dann schnell die Frage, ob die Investition darin, diesen Test bei jeder neuen Version laufen zu lassen, den gelieferten Mehrwert rechtfertigt. Vermutlich muss ich dafür in der Lage sein, Einfluss auf das GPS-Signal des Mobiltelefons zu nehmen, mit der App nach Eintreten einer automatischen Pausedurch manuelles Resume und Pauseinteragieren und dann weitere fünf Minuten bis zur nächsten Ansage warten.

Vielleicht warte ich noch besser 10 Minuten bis zur übernächsten Ansage. Diese Entscheidungen sind nicht ganz trivial. Im Beispiel der Lauf-Applikation wage ich einmal zu behaupten, dass, einen derart umständlichen Test zu automatisieren, den Mehraufwand für die Entwicklung des Tests, das kontinuierliche Laufenlassen und die langfristige Wartung des Testfalles nicht rechtfertigt. Vor diesem Hintergrund kann ich verstehen, dass sich so ein Fehler in meine Lauf-App eingeschlichen hat. Für mich als Anwender ist das vielleicht weniger schön, für mich als Teammitglied in einem Softwareprojekt kann ich die Entscheidung aber verstehen. Letzten Endes ist meine Nutzung der Funktionen vermutlich aus Entwicklungssicht sogar ein Grenzfall.

Das Stichwort bei dieser Betrachtung ist eine risikobasierte Betrachtung der getesteten Funktionalität zusammen mit einer KostenNutzung-Abwägung für die jeweiligen Tests. Doch wo steckt bei mobilen Applikationen das größte Risiko?

Zunächst wären da das Verhalten der Applikation auf dem Gerät und, falls zutreffend, die Interaktionen der Applikation mit einem Server, der die Daten bereitstellt. Darüber hinaus müssen wir auf dem Gerät noch Abhängigkeiten zu gerätespezifischen Faktoren berücksichtigen. Das ist zum Beispiel die Interaktion mit anderen Applikation wie Telefon und Nachrichten (SMS), außerdem die jeweiligen Einstellungen der Applikation und wo sie gespeichert werden. Überdies verfügen Mobiltelefone nur über begrenzten Speicher. Das bedeutet vor allem, dass das Betriebssystem selbständig Applikationen, die nicht länger benötigt werden, aus dem Hauptspeicher löscht. Diesen Fall sollte unsere Applikation auch sinnvoll behandeln können. Zu guter Letzt spielen natürlich auch der Speicherverbrauch, der Energieverbrauch und die Usability eine große Rolle.

Wie testet man eigentlich mobile Applikationen?

Allgemein sollte ich für eine Applikation im Auge behalten, wo Probleme entstehen können. Das betrifft die Schnittstelle zu einem potentiellen Backend im Internet und die Funktionen, die auf dem Gerät direkt ausgeführt und berechnet werden. Diese Dinge kann ich effizient mit automatisierten Tests entweder auf der Unit oder auf der Oberfläche mehrfach testen. Durch die Automatisierung erhalte ich eine Wiederholbarkeit der Tests, die mir langfristig Gewissheit liefern können, dass zumindest die Grundfunktionalität weiterhin gegeben ist.

Für gute Unit-Testbarkeit bedeutet das normalerweise, dass ich meine Klassen nicht zu sehr an die Oberfläche koppeln darf. Kleine modulare Klassen sind auf diesem Mikrolevel besonders effizient testbar. Darüber hinaus muss ich natürlich noch sicherstellen, dass meine kleinen Klassen auch vernünftig in die Oberfläche eingebunden sind. Dafür dienen in aller Regel spezielle Frameworks wie Frank auf der iOS-Plattform und Robotium auf der Android-Plattform. Mit diesen lassen sich Oberflächenelemente programmatisch ansteuern und somit eine realitätsnahe Bedienung eines Nutzers nachstellen.

Doch wie finde ich Probleme wie den Fehler in der Lauf-App? Je nach Kritikalität der Applikation greifen wir dabei zu explorativen Tests. Diese basieren auf der direkten Interaktion des Testers mit der Applikation. Dabei informiert jeder ausgeführte Test den nächsten Test, so dass der Tester sich beispielsweise bewusst auf komplizierte Abläufe konzentrieren kann, die nicht von den automatisierten Tests abgedeckt wurden.

Exploratives Testen lässt sich dabei gut mit dem Vorgehen des Session-basierten Testmanagements verbinden. Dabei wählt der Tester einen zeitlichen Rahmen für ein Thema. Beispielsweise habe ich einmal eine mobile Applikation innerhalb eines Tages in Sessions von 25 Minuten Länge getestet. Dafür habe ich mir in der ersten Session einen Überblick über die Applikation verschafft. Anschließend war ich in der Lage, die verschiedenen Bereiche der Applikation für die weiteren Sessions des Tages zu notieren und so meinen Tagesablauf weiter zu planen. Diese Sessions habe ich dann nacheinander abgearbeitet, bis ich am Ende des Tages noch zwei Themen offen hatte, die die niedrigste Priorität in meiner Gesamtliste hatten.

Über den Tag verteilt habe ich zudem eine stetig wachsende Mindmap über meinen Testfortschritt, die Funktionen und die Fehler erstellt, die ich anschließend als Grundlage für meinen Testreport zum Product Owner und Entwicklungsteam verwenden konnte.

Sessiontypen lassen sich dabei unterteilen in Sessions, um einen Überblick zu bekommen, die Testabdeckung zu erhöhen, die Testtiefe zu erhöhen oder um Fehlern nachzutesten. Alle diese Missionen haben einen unterschiedlichen Einsatzzweck. Nach jeder Session dient außerdem eine kurze Reflektion und gegebenenfallseine Anpassung des weiteren Vorgehens dazu, dass ich mich auf das Wesentliche konzentrieren kann.

Für Tests zur Usability und Speicherverwendung kommt noch der Einsatz spezieller Tools zumTragen. Diese werden auf den gängigsten Plattformen vom Hersteller mitgeliefert und können parallel zum explorativenTesten als Live-Monitor Informationen über eventuelle Speicherlücken im Programm liefern.

Von automatisiert bis explorativ

Mobile Anwendungen sind ein wesentlicher Bestandteil unseres täglichen Lebens geworden. Umso wichtiger ist es, dass unsere Applikationen das tun, wofür wir sie einsetzen möchten, und dass sieihren Nutzern nicht schaden oder sie frustrieren. Ein wohl ausbalancierter Testansatz, der die Kosten und den Nutzen der einzelnen Tests bedenkt, ist dafür von großer Bedeutung.

Eine gute Mischung besteht dabei aus einer Vielzahl automatisierter Tests kombiniert mit explorativenTests und spezieller Toolunterstützung für Aussagen zur Speicher- und Resourcennutzung und der Usability. Natürlich sollten wir eine sinnvolle Auswahl mit Bedacht finden. Denn jeder Test, den ich ausführe, hält mich von einem anderen Testab, den ich stattdessen ausführen könnte. Dieses Phänomen wird in der Betriebswirtschaft auch Opportunitätskosten genannt.

Umso wichtiger ist, dass wir uns im Klaren über die Risiken unserer Applikation sind. Dadurch können wir als gemeinsames Entwicklungsteam eine informierte Entscheidung darüber treffen, welche Testaktivitäten wir vor der Auslieferung betrachten wollen – aber auch welche wir ganz bewusst vernachlässigen.

Schreibe einen Kommentar

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

Kategorien

Recent Posts