Wie Firmen ihre Mobile Apps testen

Mobile Apps testen

Jeder, der schon einmal in den Entwicklungsprozess einer Mobile-App eingebunden war, kennt die leidvolle Prozedur die App zu starten und jeden einzelnen Button und jedes einzelne Element der App durchzuklicken. Peinlichste Genauigkeit ist essentiell um sicherzustellen, dass alle neu entwickelten Features funktionieren und dass nichts im Laufe des Prozesses kaputt gegangen ist.

Als mein Team und ich in der Vergangenheit Apps designed und entwickelt haben, liefen unsere Testprozeduren tatsächlich auf sehr ähnliche Weise ab. Nach tausenden von manuellen Fingerklicks fragte ich mich, ob es nicht einen moderneren und effizienteren Weg gibt, die Funktionalitäten von Apps zu testen. In diesem Beitrag würde ich gerne teilen, was ich bis jetzt gelernt habe und was mich am Ende dazu bewogen hat, eine Firma zu gründen, um das Testen von Mobile Apps effizienter zu machen und den manuellen Aufwand zu reduzieren.

Ich fragte mich: Wie unterscheidet sich der Testprozess für mobile Apps zwischen Firmen unterschiedlicher Größe? Durch meine Arbeitserfahrung mit kleinen und großen Mobilfunkfirmen habe ich Einblicke in die Best Practices als auch in die Ineffizienzen aktueller Testmethoden bekommen.

Ein starker Zusammenhang, den ich bei meiner Marktrecherche entdeckt habe, besteht zwischen der Größe einer Firma und ihrem typischen Testsetup. Ich habe dementsprechend die typischen Eigenschaften mit der entsprechenden Firmengröße zusammen gruppiert um so diesen Zusammenhang darzustellen.[1]

1 bis 5 Personen-Firma

Kleine Firmen tendieren dazu, chaotisch zu sein und verschieben das End-User Testing bis ganz zum Schluss als eine Art “Überbleibsel”-Aufgabe vor der Auslieferung. Ein typisches Szenario, bevor die Firma die Anmeldung an den App Store einreicht, sieht so aus:

„Hey, wir sollten wirklich das andere iPad mit der älteren iOS Version nehmen und auch das ältere iPhone, nur um zu testen und sicher zu gehen, dass alles noch funktioniert.”

Eine Woche später:

„Verdammt… wir haben vergessen die Funktion X zu testen. Ich hab‘ gerade ein paar Nutzerbeschwerden bekommen und irgendjemand hat auch schon eine schlechte Bewertung geschrieben.”

Testpläne, die Anwenderszenarien enthalten, sind in kleinen Firmen nicht weit verbreitet. Das Testen von End-User-Szenarien (Testen verschiedener Szenarien, wie die App später vom User verwendet wird) ist sehr zeitaufwändig, sodass diese Tests so einfach wie möglich gehalten werden und eventuell nicht ausreichend Anwendungsfälle abdecken. Dies endet oft in Bedauern – normalerweise dann, wenn App-Ratings heruntergehen, wenn die App abgelehnt wird und Umsatz verloren geht.


Typisches Schreibtischsetup in der frühen Phase eines Startups.

Kleine Firmen verlassen sich stark auf Feedback und Fehlerberichte ihrer Alpha-Nutzer (vertrauensvolle Nutzer, die in der frühesten Entwicklungsphase, der Alpha-Phase, eine App testen dürfen) oder nutzen Online Dienste wie Hockeyapp oder Testflight, um eine „Pre-Release“ App an Beta-Nutzer (Nutzer in der zweiten Testphase vor dem Release) zu schicken. Es dauert sehr lange bis diese Nutzer Fehler entdecken und es ist nicht gesichert, dass sie alle finden werden. Die Firmen sind abhängig von dieser kleinen Nutzergruppe, um Ergebnisse in langen Email-Threads für jeden Fehler zu testen und mit ständigem Bedarf, weitere Dinge abzuklären. An Stelle von allgemeiner Aufregung und Freude über die neue App, senden Alpha-Nutzer Screenshots mit Problemen zurück und beantworten die Fragen der Entwickler, was genau den Fehler ausgelöst hat.

Eine andere übliche Praxis ist es, zusätzlich ein Crash-Reporting-System aufzubauen. Crashlytics oder Crittercism werden oft verwendet, um Statistiken und Stacktrace-Informationen (Informationen aus Datenspeichern) über Fehler in der App zu bekommen.

Nach großer Frustration, mehreren langen Nächten, Verspätungen und sehr gestressten Gründern kann das neue Release endlich herausgebracht werden (oder wieder herausgebracht werden). Das Programmieren von neuen Features bedeutet, dass umfangreicheres Testen erst mal für die nächsten drei bis fünf Wochen von der Agenda verschwindet [2]…und dann beginnt der ganze Kreislauf von vorn.

Anmerkung: Für diese kleinen Startups scheint der einzig übliche Automatisierungsansatz die Durchführung von Unit Tests (Testen einzelner Softwarekomponenten) zu sein. Entwickler finden es einfacher, Unit Tests zu automatisieren als das Testen der Benutzeroberfläche (User Interface (UI) Testing).

Firma mit 6 bis 15-Personen

Wenn die Firma größer wird, wird auch der Testprozess etwas formalisierter, aber nicht weniger zeitaufwändig. Eine typische Diskussion über Testing in dieser Firmengröße könnte in etwa so aussehen:

„Ich bin froh, dass wir diesen Testplan haben, auf dem alle Szenarien aufgeführt sind.”

 

„Ja, aber es nimmt einfach so viel Zeit in Anspruch um durch alle Details zu gehen. Lass‘ uns einfach nur auf die Hauptszenarien konzentrieren, sonst brauchen wir am Ende über eine Stunde pro Gerät und OS-Version.”

 

„Ja, oder vielleicht sollten wir jemanden einstellen.”

Sobald eine Firma etwas größer ist, Umsatz macht oder Kapital bekommt ist es üblich, dass eine offizielle Stelle für einen QA (Quality Assurance) Kollegen geschaffen wird. Der QA-Verantwortliche ist oft mit einer Reihe von Geräten mit verschiedenen OS-Versionen ausgestattet, welche innerhalb des Teams geteilt werden und unterstützt normalerweise auch die QA der Website.

Für eine Firma dieser Größe ist es ineffizient und teuer, sich bei allen möglichen Geräten und OS-Versionen auf dem neuesten Stand zu halten. In vielen Fällen ist die Firma hauptsächlich von Coverage Simulatoren/Emulatoren (Software-Simulation eines mobilen Geräts auf dem Computer, wodurch die App dort und nicht direkt auf einem mobilen Gerät getestet wird) abhängig. Dies jedoch setzt die App Geräte-spezifischen Fehlern und Abstürzen aus. Jeder erfahrene Entwickler wird bestätigen können, dass er eine Vielzahl von Apps und App-Funktionen gesehen hat, die auf einem Simulator perfekt funktioniert haben, aber nicht auf einem richtigen Gerät.


Ein Testplan mit Testszenarien

16 bis 50-Personenfirma

Mittelgroße Firmen verstehen in der Regel besser, wie wichtig es ist, adäquate Testing-Vorgänge eingerichtet zu haben. Viele haben mehrere QA-Mitarbeiter und suchen aktiv nach besseren Testingprozessen und Werkzeugen. Meiner Erfahrung nach kommt in einer solchen Organisation etwa auf drei Entwickler je eine Person im QA-Team.

Neben der Aufstockung des QA-Teams arbeiten Mobile Teams oft mit Testing Frameworks, die das Regressionstesten (Testen von Fehlern, die neu in einem Teil der App auftauchen, wenn in einem anderen Teil Veränderungen vorgenommen worden sind) erleichtern, einige bekannte Open Source Lösungen sind KIF, Calabash oder Appium (für iOS). Für Android sind dies unter anderem Robotium, Espresso, Selendroid, Calabash und Appium.

Wenn eines dieser Frameworks gewählt wird, dann wird normalerweise eine kontinuierliche Integration gestartet, deren Prozesse mit Tools wie Jenkins oder Travis noch weiter verstärkt werden. Manche Firmen nutzen auch xctool von Facebook oder Gradle (Android), um ihre App-Entwicklung zu automatisieren.

Firmen mit mehr als 51 Mitarbeitern

Größere Firmen haben in der Regel eine spezialisierte QA-Abteilung. Hier wird das QA typischerweise anhand von einer der beiden folgenden Ansätze organisiert:

Beim ersten Ansatz ist der Entwickler direkt für die QA verantwortlich. Der Senior Entwickler trifft seine eigenen Entscheidungen darüber, welches Testinstrument/Framework und welche Prozedur er verwenden will, ähnlich wie bei kleineren Firmen.

Wenn die Firma mehrere hundert Angestellte hat, helfen zusätzliche “Tool”-Ingenieure dabei, diese Frameworks auszuweiten und neue Tools zu entwickeln, die für den Testingprozess verwendet werden können. Dies wiederum hilft dabei, die Testingvorgänge und Regelwerke für die Firma zu entwickeln. Die firmenspezifischen Werkzeuge benötigen jedoch oft einen beträchtlichen Einsatz von Ressourcen und können zu einem Stagnationsprozess führen, der nötigen Veränderungen gegenüber resistent ist.

Der zweite Ansatz ist “QA basiert”, wobei gebaute Apps an spezialisierte QA-Mitarbeiter übergeben werden, die dann das (sehr oft) manuelle Testing übernehmen. Die QA-Abteilung wird eventuell von einem Offshore-Center unterstützt oder Teile des Testings werden an eine Firma outgesourct, die manuelle Testing-Services anbietet. Dieser Ansatz sucht im Prinzip nach günstigeren Ressourcen, welche die aufwändigen Prozesse übernehmen.[3]

Allgemeiner Ausblick

Eine unzählige Masse an chaotischem, manuellem Testing wird über alle Firmengrößen hinweg ausgeführt, um die beste App-Qualität und Nutzererfahrung zu erreichen. Sich nur auf manuelles Testing zu verlassen, ist umständlich und fehleranfällig. Der aufkommende Trend erhöhter Gerätefragmentierung macht den Job für Mobile Entwickler und ihre QA-Kollegen nur noch schwieriger.

Ich glaube, dass die meisten Firmen eine neue Mobile-Testing-Strategie benötigen, welche kürzere Iterationen zwischen Testing und Entwicklung möglich macht, die Reichweite der Tests erhöht und das Risiko von App-Fehlfunktionen und schlechten Bewertungen reduziert. Wenn Fehler gefunden, nachgebildet und im Entwicklungszyklus schneller behoben werden können, dann ist dies ein Erfolg auf ganzer Linie. Stressige “Geräteherumklickerei” in letzter Minute sollte nicht die Standardtestingmethode sein, egal wie groß die Firma ist.

Die Vorteile von automatisiertem Testing sollten Startups zur Verfügung stehen, um Innovation zu fördern und einen besseren App-Standard zu schaffen. Vorteile der Automatisierung werden sich schnell mit einem Ansatz vervielfachen, der nach dem Motto “einmal schreiben und auf mehreren Geräten laufen lassen” funktioniert.

Dies heißt natürlich nicht, dass Automatisierung manuelles Testing komplett ersetzen sollte. Um die Nutzererfahrung in Bezug auf “look and feel” einer App nachzuvollziehen, wird es immer essentiell bleiben, ein Telefon in die Hand zu nehmen und damit “herumzuspielen.” Automatisierung kann nicht alle Nutzerszenarien zu 100 Prozent abdecken.

Sich aber nur auf manuelles Device-Testing zu verlassen ist nicht effizient oder ökonomisch. Die Automatisierung eines guten Teils des Testing kann effektiv die Funktionalität der gebauten App auf echten Geräten testen und dem App-Entwickler/QA-Team einen umfassenden Bericht innerhalb weniger Minuten erstellen. Diese Testberichte fügen Fokus und Klarheit zu jedem immer noch nötigen manuellen Testing hinzu.

Mit dem Aufbau des App Stores und Play Stores (zu der Zeit Android Market), die ihr Debüt gerade mal vor sieben Jahren in 2008 gemacht haben denke ich, dass das Mobilzeitalter gerade erst begonnen hat. Mobile Entwicklertools und Frameworks befinden sich noch in den Kinderschuhen. Etwa 30 Prozent der Appentwicklungsressourcen werden für QA ausgegeben – es zahlt sich also aus, den Prozess effizienter zu gestalten.

Teams mit einem Mix aus Automatisierung und manuellen Fähigkeiten sind wesentlich effektiver als große, ausschließlich manuelle Testing Teams. Wirkungsvolle “State of the Art”-Tools und Techniken machen es Firmen jeder Größe möglich, neue Features auf bessere Weise einzuführen und damit am Ende von den App-Nutzern angenommen und unterstützt zu werden.

Anmerkungen

[1] Die Firmengröße schließt nur Angestellte mit ein, die Produkt bezogen arbeiten, so wie Ingenieure/Designer/ Produktmanager/QA, die an den mobilen Apps arbeiten.
[2] 3-5 Wochen scheinen der Standardzeitrahmen für kleine Firmen und Startups zu sein, der benötigt wird, bevor ein neues Release für die App oder in die Play Stores herausgebracht wird.
[3] Mobilfunkfirmen haben normalerweise ein Kernset an Testfällen, das sich mit neuen Releases nicht verändert. Demnach bedeutet ein neues Feature generell, dass ein neuer Testfall geschrieben werden muss.

Über den Autor: Martin Poschenrieder hat seine Karriere vor zehn Jahren bei Hagenuk, einer der ersten deutschen Handy Hersteller, gestartet. Nach einigen Jahren bei Accenture hat er sich zunächst im Bereich eigener Appentwicklung selbständig gemacht.

Bei der Entwicklung einiger Consumer Apps hat er das Problem des Apptestens entdeckt und Testmunk gegründet. Die Firma automatisiert das Testen von Mobile Apps.

Beitragsbild: Shutterstock

1 Kommentar

  1. Ich kann der Auffassung des Autors nicht so ganz zustimmen. Auch kleine Firmen erheben an sich den Anspruch die bestmögliche Qualität an ihre Kunden oder Benutzer zu liefern. Dieser Anspruch ist an der Teamgröße auch nicht festzumachen.

    Letztlich ist es der intelligent eingesetzte Technologie-Mix, der hilft frühzeitig Probleme zu erkennen und deren Lösung zeitnah an Benutzer auszuliefern. Neben Unit-Test zur Sicherstellung von nahezu fehlerfreiem Code bilden Tools wie Crashalytics, Xamarin.Insights & Co. dabei nur die Vorhut, um zu signalisieren, dass etwas nicht in Ordnung ist, bevor es ein Anwender im schlimmsten Fall via 1-Stern-Bewertung tut. HockeyApp oder TestFlight sind perfekt dafür geeignet um ein Feedback von ausgesuchten (internen und externen) Anwendern über neue Feature oder des anstehenden Release zu erhalten. Gelegentlich möchte man auch nur in kleiner Runde mal was ausprobieren ohne gleich das ganze Prüfungs- und Validierungsfeuerwerk abzufackeln.

    Aus eigener Erfahrung kann ich sagen, dass bis hierher alle Firmen gleich organisiert sind – egal ob groß oder klein.
    Üblicherweise erfolgt auch die „Endabnahme“ einer Version, in dem Projektbeteiligte die aktuelle Version eine Zeit lang „probe-nutzen“. Das funktioniert so lange, bis die App a) eine gewisse Komplexität nicht überschritten hat oder b) man nicht so richtig auf die Nase gefallen ist. Erst dann fangen die Meisten an über Automatisierung nach zu denken. Buildsysteme wie Jenkins oder TeamCity sind häufig aus anderen Projekten oder den Anforderungen der Entwickler schon vorhanden, so das es sich „nur“ noch um die Automatisierung von UI-Tests gekümmert werden muss.

    An der Stelle sind übrigens gerade die großen bis sehr großen Firmen sehr Budget-fixiert, während kleinere Firmen sich durchaus mal die nötigen Ressourcen zur Evaluierung nehmen.

1 Trackback / Pingback

  1. Unsere Top 5 Artikel im August 2015 | mobile zeitgeist

Kommentar hinterlassen

E-Mail Adresse wird nicht veröffentlicht.


Ich bestätige, dass die hier von mir eingegebenen persönlichen Daten in der von mobile zeitgeist genutzten Datenbank bis auf Widerruf gespeichert werden dürfen.