Björn Lemke ist Managing Consultant bei der trendig technology services GmbH. Die Schwerpunkte seiner Arbeit sind Softwarequalitätssicherung, Integrated Technology and Operations (ITOps), IT-Service-Management (ITIL), Testmanagement, Testdatenmanagement, Testinfrastrukturmanagement sowie Mobile Application Testing in kleinen bis hin zu sehr großen Projekten.
Nils Röttger arbeitet bei der imbus AG in Möhrendorf als Berater, Projektleiter und Speaker und ist u. a. verantwortlich für die Ausbildung und den Bereich Mobile Testing. In seinen Vorträgen beschäftigt er sich immer wieder mit Themen wie exploratives Testen, Usability oder Ethik im Softwaretest.
|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Aus- und Weiterbildung zum
Certified Mobile Application Tester –
Foundation Level Specialist nach ISTQB®-Standard
Björn Lemke · b.lemke@gmx.de
Nils Röttger · nils.roettger@imbus.de
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Layout & Satz: Birgit Bäuerlein
Herstellung: Stefanie Weidner
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Fachliche Beratung und Herausgabe von dpunkt.büchern zum Thema »ISTQB® Certified Tester«: Prof. Dr. Andreas Spillner · Andreas.Spillner@hs-bremen.de
ISBN:
Print 978-3-86490-748-7
PDF 978-3-96910-118-6
ePub 978-3-96910-119-3
mobi 978-3-96910-120-9
1. Auflage 2021
Copyright © 2021 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Hinweis:
Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.
Schreiben Sie uns:
Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: hallo@dpunkt.de.
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
1Einleitung
2Die mobile Welt
3Tests mit Bezug zur mobilen Plattform
4Übliche Testarten und der Testprozess für mobile Apps
5Mobile App-Plattformen, Werkzeuge und Umgebungen
6Automatisierung der Testausführung
Anhang
AMapping zwischen den Kapiteln dieses Buches und dem ISTQB®-MAT-Syllabus
BGlossar
CVerzeichnis der Praxisbeispiele
DVerzeichnis der Übungen
EReferenzen
Index
1Einleitung
1.1Warum wir dieses Buch schreiben
1.2Dieses Buch im Kontext des ISTQB®-Syllabus »Mobile Application Testing Foundation Level«
1.3Das ISTQB® und das »Certified Tester«-Ausbildungsschema
1.4Schlüsselbegriffe
1.5Grundlegende Hinweise und Erklärungen
2Die mobile Welt
2.1Geschäftliche Faktoren
2.1.1Analyse mobiler Daten
2.1.2Geschäftsmodelle für Apps
2.2Technische Faktoren
2.2.1Mobile Gerätetypen
2.2.2Mobile App-Arten
2.2.3Mobile Anwendungsarchitekturen
2.3Herausforderungen und Risiken im Mobile App Testing
2.4Teststrategien für mobile Apps
2.4.1Reaktionen auf die Marktfragmentierung
2.4.2Reaktionen auf das Geschäftsmodell
2.4.3Reaktionen auf neue Geräte oder neue Betriebssystemversionen
2.4.4Reaktionen auf die vielfältigen Möglichkeiten zur Installation
2.4.5Reaktionen auf die Umgebungsbedingungen
2.5Übung: Ermittlung Geräteportfolio anhand von Marktdaten
3Tests mit Bezug zur mobilen Plattform
3.1Testen der Kompatibilität mit der Gerätehardware
3.1.1Testen von physikalischen Schnittstellen
3.1.2Übung: Hardwareschnittstellen
3.1.3Testen von unterschiedlichen Gerätebildschirmen
3.1.4Übung: Bildschirmgröße und Auflösung
3.1.5Testen der Bildschirmorientierung
3.1.6Übung: Bildschirmorientierung
3.1.7Testen der Gerätetemperatur und deren Auswirkungen
3.1.8Testen des Batterieladestands und Energieverbrauchs
3.1.9Übung: Energieverbrauch
3.1.10Testen der Eingabesensoren der Geräte
3.1.11Testen der unterschiedlichen Eingabemethoden
3.1.12Übung: Eingabemethoden
3.2Testen in Bezug auf die mobile Betriebsplattform
3.2.1Testen von typischen Unterbrechungen
3.2.2Übung: Unterbrechungen
3.2.3Testen von Benachrichtigungen
3.2.4Übung: Benachrichtigungen
3.2.5Testen von Links für den Schnellzugriff
3.2.6Testen der Benutzereinstellungen innerhalb des Betriebssystems
3.2.7Übung: Benutzereinstellungen
3.2.8Testen der Zugriffsberechtigungen für Gerätefunktionen
3.2.9Übung: Berechtigungen
3.2.10Testen der verschiedenen Arten von Apps
3.2.11Testen der Interoperabilität auf verschiedenen Betriebssystemen und Betriebssystemversionen
3.2.12Testen der Koexistenz mit anderen Apps auf dem Gerät
4Übliche Testarten und der Testprozess für mobile Apps
4.1Häufig verwendete Testarten im Mobile App Testing
4.1.1Installationstests
4.1.2Security Tests
4.1.3Performanztests
4.1.4Lasttests
4.1.5Stresstests
4.1.6Benutzbarkeitstests
4.1.7Barrierefreiheitstests
4.1.8Datenbanktests
4.1.9Globalisierungs- und Lokalisierungstests
4.2Zusätzliche Teststufen und weitere geeignete Testmethoden für mobile Apps
4.2.1Feldtests
4.2.2Testen der Store-Richtlinien
4.2.3Post-Release-Tests
4.3Warum erfahrungsbasiertes Testen gerade in mobilen Projekten so wertvoll ist
4.3.1Personas
4.3.2Eselsbrücken
4.3.3Heuristiken
4.3.4Testtouren für mobile Apps
4.3.5Session Based Testing (SBT)
4.4Der mobile Testprozess
4.4.1Das mobile Testkonzept
4.4.2Die umgedrehte Testpyramide
4.5Übung: Übliche Testarten angewendet für mobile Apps
5Mobile App-Plattformen, Werkzeuge und Umgebungen
5.1Entwicklungsplattformen für mobile Apps
5.2Für den Test geeignete Werkzeuge der Entwicklungsplattformen
5.3Emulatoren und Simulatoren
5.3.1Vergleich von Emulatoren und Simulatoren
5.3.2Nutzung des iOS-Simulators
5.3.3Nutzung des Android-Emulators
5.4Testlabore für den manuellen Test
5.4.1Lokales Testlabor
5.4.2Entferntes Testlabor
5.4.3Testlabor als Dienstleistung
5.4.4Vor- und Nachteile der verschiedenen Beschaffungsvarianten für Mobile Devices
5.5Übung: Mobile Plattformen, Werkzeuge und Umgebungen
6Automatisierung der Testausführung
6.1Automatisierungsansätze
6.1.1User-Agent-basierte Testautomatisierung
6.1.2Gerätebasierte Testautomatisierung
6.1.3Herkömmliche Testautomatisierungsansätze
6.2Testautomatisierungsframeworks
6.3Automatisierungsmethoden
6.3.1Bildvergleich
6.3.2Optische Zeichenerkennung
6.3.3Native Objekterkennung
6.4Auswahl eines Testautomatisierungswerkzeuges
6.5Einrichtung von Testautomatisierungslaboren
6.6Bewertung der Testautomatisierung für mobile Apps
Anhang
AMapping zwischen den Kapiteln dieses Buches und dem ISTQB®-MAT-Syllabus
BGlossar
CVerzeichnis der Praxisbeispiele
DVerzeichnis der Übungen
EReferenzen
Index
In diesem Kapitel erläutern wir unsere Motivation, dieses Buch zu schreiben, geben grundlegende Hinweise und Erklärungen und skizzieren, wie dieses Buch zum ISTQB®-Syllabus »Mobile Application Testing Foundation Level« [URL: ISTQB Materials] steht. Fachliche Inhalte aus dem Syllabus sind in diesem Kapitel nicht enthalten. Diese findest du ab Kapitel 2.
Wir beide hatten das Glück, im Rahmen unserer beruflichen Tätigkeit schon in einer frühen Phase der Marktverbreitung von Smartphones in Mobile-App-Projekten arbeiten zu können. Für uns hatten fast alle Kundenprojekte seit den frühen 2010er-Jahren mit mobilen Apps zu tun. Darunter gab es sowohl reine App-Projekte als auch Projekte, in denen mobile Apps nur ein Teilaspekt waren. Somit kann jeder von uns auf fast 10 Jahre Erfahrung im Testen mobiler Apps zurückblicken. Die Erfahrungen zum Testen von anderen Applikationen reichen noch weiter zurück.
Zudem arbeiten wir beide bei Unternehmen, die neben der Projektunterstützung für Kunden auch Schulungen zu Softwaretests und verwandten Themen anbieten. Da wir nicht nur in Kundenprojekten tätig sind, sondern auch gelegentlich Trainings durchführen, war es nur natürlich, dass wir unser Wissen und unsere Erfahrungen rund um das Mobile App Testing bereits seit einigen Jahren an Kollegen und Kunden weitergeben. Diese Weitergabe erfolgt sowohl in individuellen Schulungen, Workshops und Coachings als auch in standardisierten Schulungen, wie z.B. dem »Certified Mobile App Professional – Foundation Level« (CMAP-FL). Der CMAP-FL diente als Basis für die Erstellung des ISTQB®-Syllabus »Mobile Application Testing Foundation Level« (ISTQB® MAT).
Als sich für uns dann die Möglichkeit bot, am Syllabus für den ISTQB® MAT mitzuwirken, haben wir dies gerne getan. Neben den wertvollen Erfahrungen, die wir dabei sammeln durften, führte die Erstellung des Syllabus dazu, dass wir uns kennenlernten.
Auch wenn wir beide bei Trainingsanbietern arbeiten und den Besuch eines professionellen Trainings empfehlen, wissen wir trotzdem, dass nicht jeder an solch einem Training teilnehmen kann, darf oder will. Zudem haben wir selbst auch viel aus Büchern gelernt. Daher haben wir uns entschieden, gemeinsam dieses Buch zu schreiben, in dem wir versuchen, die Inhalte des Syllabus so zu vermitteln, wie wir dies auch bei unseren Trainings tun. Unsere Absicht ist es, mit diesem Buch eine Möglichkeit zum Selbststudium für die ISTQB®-MAT-Zertifizierung bereitzustellen. Wichtiger für uns ist jedoch, dir Kenntnisse zu vermitteln, die bei der Erfüllung deiner Aufgaben rund um mobile Apps hilfreich sind.
Der ISTQB®-MAT-Syllabus zeigt in erster Linie die unterschiedlichen mobilspezifischen Themenbereiche rund um den Test mobiler Apps auf. Aus unserer Sicht ist er allein nicht als Lehrbuch geeignet und auch nicht als solches gedacht. Sofern der Syllabus zum Selbststudium genutzt wird, sind zusätzliche Informationsquellen notwendig, um sich die Inhalte der einzelnen Themenkomplexe in angemessener Tiefe zu erarbeiten. Diese Informationsquellen müssen zudem durch eigene Recherchen gefunden werden. Diesen Aufwand wollen wir unseren Lesern ersparen und daher erläutern wir den gesamten Inhalt des Syllabus im Rahmen dieses Buches. Zudem haben wir exemplarische Übungen zu fast allen Kapiteln entworfen, in denen der Syllabus diese vorsieht. Weiterhin führen wir Praxisbeispiele aus unserem Projektalltag auf. Diese sollen dabei unterstützen, die Inhalte in die eigene berufliche Praxis zu übertragen.
Aufbau und Struktur des Buches entsprechen weitestgehend dem Syllabus. Dadurch wird es einfacher, im Selbststudium parallel mit dem Syllabus und diesem Buch zu arbeiten. Zusätzlich haben wir im Anhang ein Mapping zwischen den Kapiteln dieses Buches und den zugehörigen Kapiteln des ISTQB®-MAT-Syllabus bereitgestellt.
Aufgrund unserer Mitwirkung am Syllabus und unserer Erfahrungen als Trainer für den ISTQB® MAT und dessen Vorgänger CMAP-FL sind wir überzeugt, dass dieses Buch als Prüfungsvorbereitung für die Zertifizierung dienen kann.
Zur Kontrolle der eigenen Kenntnisse empfehlen wir, die gemeinsam mit dem Syllabus veröffentlichten ISTQB®-MAT-Übungsfragen [URL: ISTQB Materials] zu bearbeiten. Da die englische Sprache der originalen Veröffentlichung eine Herausforderung sein kann, möchten wir auch die deutschsprachige Übersetzung des German Testing Board aufführen. Das German Testing Board stellt sowohl den Syllabus als auch die Übungsfragen in deutscher Sprache bereit [URL: GTB MAT].
Das International Software Testing Qualification Board, kurz ISTQB®, ist eine global agierende Organisation, die das erfolgreichste Ausbildungs- und Zertifizierungsschema zum Testen von Software entwickelt hat. Es ist in regionalen bzw. nationalen Boards organisiert. So gibt es im deutschsprachigen Raum das Austrian Testing Board (ATB), das German Testing Board (GTB) und das Swiss Testing Board (STB).
Das Ausbildungsschema des ISTQB® ist in drei Stufen organisiert: dem Foundation Level, dem Advanced Level sowie dem Expert Level. Innerhalb jeder Stufe gibt es Lehrpläne zu mehreren Themenbereichen rund um den Softwaretest, die von ehrenamtlich tätigen Autoren aus Industrie und Forschung erstellt werden.
Weitere Informationen zur Organisation, dem Ausbildungs- und Zertifizierungsschema sowie den Lehrplänen finden sich auf der Webseite des ISTQB® [URL: ISTQB] sowie auf den Seiten der nationalen Testing Boards [URL: ATB; URL: GBT; URL: STB].
Wir haben am Anfang jedes Kapitels die Schlüsselbegriffe und die dazugehörigen englischen Begriffe aus dem englischen Syllabus aufgelistet. Zum Teil haben wir zusätzliche, aus unserer Sicht wichtige Begriffe in dieser Auflistung ergänzt.
Wie bereits in den vorangehenden Abschnitten zu sehen war, verzichten wir im gesamten Buch auf gendergerechte Sprache. Wir verwenden immer die kürzeste Form. Zum Beispiel werden wir »der Nutzer« schreiben und nicht »die Nutzerin oder der Nutzer«. Dies machen wir einzig und allein zur leichteren Lesbarkeit. Wir beabsichtigen damit keinerlei Diskriminierung. Sollten sich Leserinnen durch diese Entscheidung diskriminiert fühlen, möchten wir uns dafür entschuldigen und versichern, dass dies nicht unsere Absicht ist.
Nach unserer Erfahrung werden mobile Apps meist in jungen und agilen Teams entwickelt. In diesen steht das Team im Mittelpunkt. Daher ist auch der Kommunikationsstil angepasst, sodass sich in der Regel alle Teammitglieder duzen. Diesen Kommunikationsstil haben wir für dieses Buch übernommen und duzen den Leser daher. Selbstverständlich darf auch jeder uns duzen.
Wir hoffen, dass du dich durch diesen Kommunikationsstil nicht unangemessen angesprochen oder sogar angegriffen fühlst. Falls dies doch der Fall sein sollte, möchten wir uns dafür entschuldigen.
Die enthaltenen Praxisbeispiele stammen ausschließlich aus unserer beruflichen Praxis. Um den Schutz von Kunden und Geschäftsgeheimnissen zu wahren, mussten wir jedoch teilweise abstrahieren oder kleine Anpassungen vornehmen. Durch diese Anpassungen kann eventuell der Eindruck entstehen, dass es sich um konstruierte Beispiele handelt. Dies ist aber nicht der Fall. Alle Praxisbeispiele haben wir im Kern so in unserem Berufsalltag erlebt. Die Praxisbeispiele sind folgendermaßen gekennzeichnet:
Bei diesem Kasten handelt es sich um ein Beispiel, das zeigen soll, wie Beispiele aus unserem Projektalltag im weiteren Verlauf des Buches dargestellt werden.
Wir haben teilweise echte Screenshots von Webseiten oder den Mobilgeräten eingefügt, um das Geschriebene bildlich zu verdeutlichen. Leider gibt es manche Bilder nur mit englischem Inhalt. Da die Bilder jedoch zumeist selbsterklärend sind und den Text ergänzen sollen, haben wir auf eine Übersetzung in den Abbildungen verzichtet.
Wir empfehlen dringend, die im Buch enthaltenen Übungen praktisch durchzuführen und nicht nur zu lesen. Testen lernst du nur dadurch, dass du testest! Theoretische Kenntnisse wirken nur unterstützend für die praktische Anwendung. Sie helfen, Ideen zu generieren und festzulegen, wie mit der aktuellen Aufgabenstellung umgegangen werden kann. Vielleicht findet sich für die Übungen ein Sparringspartner aus der Testing Community oder unter den Arbeitskollegen. Viele der Übungen können so durchgeführt werden, dass gemeinsam und remote an der Lösung gearbeitet wird.
Alle im Buch genutzten Namen und Bezeichnungen unterliegen dem Copyright des jeweiligen Eigentümers. Diese Aussage gilt auch, wenn die Namen oder Bezeichnungen nicht explizit als dem Copyright unterliegend gekennzeichnet sind.
Wir haben unser Glossar mit dem domänenspezifischen Glossar im MAT-Syllabus und dem allgemeinen Glossar des ISTQB® abgeglichen. Bei den Begriffen kann es andere Formulierungen geben. Der Inhalt stimmt aus unserer Sicht aber überein. Sollten in diesem Buch dir unbekannte Worte oder Begriffe vorkommen, empfehlen wir dir als erste Anlaufstelle die beiden genannten Quellen des ISTQB® [URL: ISTQB Glossary; URL: ISTQB Materials].
Einige der im Buch genannten Lehrpläne wurden vom GTB (German Testing Board) auch ins Deutsche übersetzt, und es werden deutsche Zertifizierungen angeboten. Wir haben im Buch dann neben dem Link zum ISTQB® zusätzlich auch den Link zur Webseite des GTB aufgelistet, den Lehrplan beim GTB aber nicht explizit aufgeführt.
Quellen und Links wurden von uns zuletzt im August 2020 überprüft. Sollten sich nach diesem Datum Änderungen ergeben haben, sind diese nicht im Buch berücksichtigt.
Dieses Kapitel beinhaltet eine allgemeine Einführung in die Welt der mobilen Applikationen. Neben einem Überblick über den Markt und warum dessen Kenntnis wichtig ist, beschreiben wir, welche geschäftlichen und technischen Faktoren eine Rolle spielen. Zudem skizzieren wir Herausforderungen und die daraus resultierenden Risiken und erläutern Beispiele, auf welche Art und Weise diese Risiken im Rahmen der Teststrategie behandelt werden können.
Schlüsselbegriffe aus dem englischen Syllabus:
Risikoanalyse (risk analysis), Risikominderung (risk mitigation), risikoorientierter Test (risk-based testing), Teststrategie (test strategy)
Weitere Schlüsselbegriffe in diesem Kapitel:
Geräte, Nutzer, Plattform, App-Art
In der mobilen Welt tummeln sich viele Mitspieler. Neben den Herstellern der Betriebssysteme, Geräte und Werkzeuge sind auch die Nutzer und die benutzten Geräte wichtige Informationen, die hilfreich sind, um eine App marktgerecht entwickeln und testen zu können. Weiterhin ist es wichtig, zu wissen, wie eine App monetarisiert, also zu Geld gemacht werden kann. In den seltensten Fällen wird eine App nur gebaut, um eine App zu bauen. In der Regel wird ein geschäftliches Interesse hinter den für die Entwicklung notwendigen Investitionen stehen. Jeder Tester und andere Projektbeteiligte sollten dies bei ihrer Arbeit berücksichtigen.
Zum Glück ist es nicht notwendig, selbst entsprechende Marktstudien durchzuführen, um sich einen Überblick über die mobile Welt zu verschaffen. Stattdessen kannst du auf eine Vielzahl von öffentlich verfügbaren Informationen zugreifen. Diese sind teilweise frei nutzbar oder auch als kommerzielle Angebote verfügbar. Bei der Verwendung der Informationen ist es wichtig, darauf zu achten, was die jeweilige Datenquelle beinhaltet. So stellt z.B. Google für Android im Developer Dashboard [URL: Dashboard] Informationen über die prozentuale Nutzerverteilung über die verschiedenen Android-Versionen bereit. Zudem bietet Google eine Übersicht, welcher prozentuale Anteil der Nutzer welche Kombination aus Displaygrößenklasse und Pixeldichteklasse nutzt (vgl. Abb. 2–1).
Abb. 2–1Matrix der Nutzeranteile in Prozent nach Displaygrößen- und Dichteklasse, Stand 18.01.2020 [URL: Dashboard]
Diese Zahlen beziehen sich jedoch nur auf Android. iOS wird dabei nicht berücksichtigt. Zudem sind es globale Daten. In lokalen Märkten kann die Verteilung anders aussehen. Beispielsweise kam Android 9.0, laut Google, im Mai 2019 weltweit bei 10,4% aller Android-Nutzer zum Einsatz. Laut GS Statcounter [URL: Statcounter] wurde im gleichen Zeitraum in Deutschland Android 9.0 bereits von 26,23% der Nutzer eingesetzt. Eine Erklärung für diesen Unterschied besteht darin, dass in hoch entwickelten Industrienationen wie Deutschland, Österreich und der Schweiz tendenziell andere Geräte genutzt werden als in weniger weit industrialisierten Ländern, wie z.B. Kenia oder Indonesien.
Die bereits im vorstehenden Absatz genannte Informationsquelle GS Statcounter erlaubt es, über ein einfach zu bedienendes Webinterface diverse Auswertungen zu erstellen. Für jeden einsehbar finden sich dort Informationen bezüglich folgender Aspekte:
Außerdem ist es möglich, die Auswertungen u.a. nach folgenden Kriterien einzuschränken:
Die Parameter der Auswertungen kannst du selbst aus einem vorgegebenen Set wählen, woraufhin die Seite die grafische Aufbereitung des Ergebnisses anpasst (vgl. Abb. 2–2). Diese Information ist sehr hilfreich, um das im Test genutzte Geräteportfolio für das eigene Projekt und dessen Zielmärkte anzupassen.
Abb. 2–2Exemplarische Darstellung einer Auswertung mit GS Statcounter zu Marktanteilen mobiler Betriebssysteme in Deutschland im Zeitraum Jan. 2019 – Jan. 2020 [GS Statcounter]
Als eine mögliche dritte Datenquelle zur Verbreitung von Plattformen und Geräten empfehlen wir Perfecto Mobile. An sich ist Perfecto Mobile ein Anbieter für Cloud-Testing-Dienste. Perfecto Mobile veröffentlicht aber auch regelmäßig den sogenannten »Mobile & Web Test Coverage Index« [Perfecto 2020]. Dieser kann nach kostenloser Registrierung heruntergeladen werden und enthält Empfehlungen zu konkreten Geräten für ausgewählte Zielmärkte (vgl. Abb. 2–3).
Abb. 2–3Beispiel für Geräteauswahlliste von Perfecto Mobile für Deutschland [Perfecto 2020]
Die oben aufgeführten und auch die meisten weiteren Datenquellen beziehen sich auf die Verbreitung der Plattformen bzw. Plattformversionen. Diese Informationen können genutzt werden, um zu ermitteln, welche Geräte im eigenen Geräteportfolio enthalten sein sollten. Somit ermöglichen sie, dass im Test ein repräsentativer Querschnitt der im jeweiligen Markt genutzten Geräte zum Einsatz kommt.
Daneben können aber auch weitere Marktdaten, wie z.B. erzielte Umsätze oder App-Downloadzahlen, interessant sein. Insbesondere wenn es um die Entscheidung geht, ob überhaupt eine App und – wenn ja – welche Art von App gebaut werden soll. Auch die Teststrategie und Testkonzeption können von weiteren Marktinformationen profitieren. Je besser uns der Markt bekannt ist, desto besser können wir Teststrategie und Testkonzeption an die Bedürfnisse des Marktes anpassen.
Neben den oben genannten Datenquellen gibt es noch eine Vielzahl von anderen Quellen. Alle diese möglichen Bezugsquellen für Marktdaten und die jeweiligen Arten von Daten aufzuführen, die sie bereitstellen, würde den Rahmen dieses Buches sprengen. Daher möchten wir dich, werter Leser, an deine bevorzugte Suchmaschine verweisen und vertrauen dabei auf deine eigenen Fähigkeiten zur Onlinerecherche.
Die Recherchen und die Aufbereitung der Daten können sehr zeitaufwendig sein. Das Ergebnis steht weiterhin im Zusammenhang mit dem allgemeinen Markt. Dies ist meist ein guter Startpunkt, aber nicht zwangsläufig identisch mit der eigenen Nutzerbasis. Daher ist es häufig lohnend, sich mit anderen Projekten im eigenen Unternehmen auszutauschen, welche Informationen zum Markt und den Nutzern vorhanden sind und wie diese erarbeitet wurden. Durch diesen Austausch können redundante Aktivitäten zum Erarbeiten der Informationen reduziert werden. Auch ist es sinnvoll, eine unternehmensweite Initiative anzustoßen, die die folgenden Punkte für alle Projekte abarbeitet:
Eine solche Initiative ermöglicht es, den Aufwand über viele Projekte zu verteilen. Zudem kann damit sichergestellt werden, dass alle Projekte immer auf aktuelle Informationen zugreifen und das Risiko von Fehlern in der Analyse und Aufbereitung der Marktdaten reduziert wird. Wir empfehlen daher, dieses Vorgehen unbedingt zu adaptieren.
Weiterhin empfehlen wir die Integration von Analysewerkzeugen in die App. Solche Analysewerkzeuge erlauben es u.a., festzustellen, auf welche Art und Weise und mit welchen Geräten die App genutzt wird. Diese Informationen sind sehr wertvoll, um den im Test genutzten Gerätepool entsprechend an die Geräte der eigenen Nutzer anzupassen. Zudem können wir so feststellen, wie häufig einzelne Teile der App genutzt werden. Dies wiederum erlaubt es, die Testintensität auf die Nutzungsintensität abzustimmen. Ein weiterer Vorteil liegt darin, dass Geräte, die häufig Probleme mit der App haben, identifiziert und anschließend in den Gerätepool mit aufgenommen werden können.
Zusätzlich zu den genannten Marktdaten sollten Tester auch die tatsächlich im Gerätepool vorliegenden Geräte, deren Funktionsumfang und die eingebaute Hardware analysieren. Es ist möglich, dass dies Einfluss auf den Testumfang hat, da Funktionsumfang und in den Geräten verbaute Komponenten es erfordern, spezifische Tests durchzuführen (vgl. Praxisbeispiel 2–1).
In einer Android-App konnten mithilfe der Kamera Bilder in den selbst erstellten Inhalt integriert werden. Standardmäßig griff die App dabei auf die nach hinten gerichtete Kamera zu. Über den Kundensupport erhielten wir die Meldung, dass bei einem Kunden die App immer abstürzt, wenn er die Kamera nutzen will, um Bilder in den von ihm erstellten Inhalt zu integrieren.
Es stellte sich heraus, dass das Gerät des Kunden nur eine nach vorne gerichtete Kamera hatte. Bei der Implementierung des Zugriffs der App auf die Kamera-API war der Entwickler aber davon ausgegangen, dass entweder keine Kamera oder zwei Kameras vorhanden sind. Da aber nur eine Kamera gefunden wurde, entstand ein undefinierter Zustand in der App, der zum Absturz führte. Nach Korrektur des Zugriffs der App auf die Kamera-API konnte die App auch auf Geräten mit nur einer Kamera genutzt werden.
In der Regel stehen geschäftliche Ziele hinter der Entwicklung einer mobilen App. Im Zuge dessen wurden im Laufe der letzten Jahre vielfältige Geschäftsmodelle für Apps entwickelt. Wir werden wichtige, weitverbreitete Modelle in diesem Kapitel vorstellen und kurz ihre Vor- und Nachteile diskutieren. Dabei ist zu beachten, dass die Modelle sowohl in Reinform als auch in Mischformen zum Einsatz kommen und daher die Grenzen häufig nicht eindeutig erkennbar sind. Für den Tester ist ein Verständnis der Modelle wichtig, um in der Teststrategie und bei der Testplanung entsprechende Tests berücksichtigen zu können. Solche Tests prüfen, ob das Geschäftsmodell für die App sinnvoll anwendbar ist oder aber negativen Einfluss auf das Nutzererlebnis hat.
Apps können verkauft werden wie jede andere Software auch. In der Regel stellen die Stores der Plattformbetreiber sowie Stores von Drittanbietern Funktionen bereit, über die der Anwender einen festgelegten Betrag bezahlt, bevor er die Applikation herunterladen und installieren kann.
Aufgrund der vielen Apps in den Stores, von denen viele kostenfrei heruntergeladen und genutzt werden können, ist dieses Modell nur für wenige Apps geeignet. Dies ist mit einer der Gründe, warum die meisten Apps in den Stores kostenfrei verfügbar sind. Zu fast jeder Kauf-App gibt es kostenlose Konkurrenz mit mehr oder weniger gleichem Funktionsumfang (vgl. Abb. 2–4).
Abb. 2–4Anteil Kauf-Apps (Paid) in Google Play Store und iOS App Store [URL: 42matters]
Außerdem sollten wir in der Wirtschaftlichkeitsrechnung berücksichtigen, dass die Store-Betreiber relative hohe Verkaufsprovisionen einbehalten. Hinzu kommt, dass laut Bitkom in 2018 nur ca. 5 % des gesamten Umsatzes im deutschen App-Markt durch direkten Verkauf von Apps erwirtschaftet wurde [URL: Bitkom].
Apps, für die dieses Modell nutzbar ist, sollten über einzigartige, schwer zu kopierende Funktionen verfügen. Eine andere Möglichkeit, sich vom Wettbewerb abzusetzen, ist eine bessere Benutzbarkeit. Oft bietet gerade die Benutzbarkeit dem Anwender einen hohen Mehrwert, für den er zu zahlen bereit ist.
In einer Umfrage von Perfecto Mobile haben Nutzer die sie am meisten störenden Auffälligkeiten oder Fehler nach ihrer Art bewertet. Auch für uns war es auf den ersten Blick überraschend, dass Benutzbarkeit und Performanz noch vor Funktionalität genannt wurden. Je mehr wir darüber nachdachten, desto mehr wurde uns klar, dass es uns selbst ebenso geht. Intuitive Benutzung oder keine Wartezeiten sind häufig wichtiger als Funktionalität und anderes (vgl. Abb. 2–5).
Abb. 2–5Häufigkeit von Fehlerarten, die durch Anwender berichtet werden [URL: Perfecto 2014]
Für die Testplanung ist zudem zu berücksichtigen, dass Budgets geplant und Zahlungswege bereitgestellt werden müssen, die es ermöglichen, die App nach der Veröffentlichung aus dem jeweiligen Store zu kaufen. Durch den Kauf können wir prüfen, ob die veröffentlichte Version der letzten getesteten Version entspricht.
Bei Freemium-Apps stehen den Nutzern Basisfunktionalitäten kostenfrei zur Verfügung. Für zusätzliche Funktionen muss der Nutzer bezahlen. Wie die Bezahlung durch den Nutzer erfolgt, kann auf vielfältige Weise realisiert werden. Dies reicht von In-App-Käufen über Zusatzpakete, die in den Stores für die jeweilige Plattform zum Kauf angeboten werden, bis hin zu Abo-Modellen, bei denen der Nutzer eine monatliche Gebühr bezahlt.
Eine andere Variante der Freemium-Apps erlaubt die kostenfreie Nutzung der App für eine gewisse Zeit. Für die weitere Nutzung muss bezahlt werden.
Das Modell der Freemium-Apps ist sehr weit verbreitet. Es findet in den verschiedensten Bereichen Anwendung. Bekannte Beispiele sind Spiele, die kostenlos gespielt werden können, aber den Nutzern die Möglichkeit bieten, zusätzliche Level, besondere Ausrüstung und Ähnliches käuflich zu erwerben. Ein anderes Beispiel sind Nachrichtenseiten, bei denen gewisse Artikel kostenfrei gelesen werden können, andere Inhalte jedoch zahlenden Kunden vorbehalten sind.
Die Verbreitung und wirtschaftliche Bedeutung dieses Modells zeigt sich auch in dem bereits oben aufgeführten Bitkom-Bericht [URL: Bitcom]. Laut diesem wurden in 2018 77% des Umsatzes im deutschen App-Markt über kostenpflichtige Angebote innerhalb der Apps erzielt. Allerdings beinhalten diese 77% auch die später noch aufgeführten transaktionsbasierten Apps.
Im Test darf nicht vergessen werden, die zahlungspflichtigen Erweiterungen zu testen. Diese müssen funktionsfähig verfügbar sein, unabhängig davon, ob sie in die laufende App integriert werden oder ob die App nach dem Kauf erneut installiert wird, z.B. weil der Nutzer sein Smartphone durch ein neues Gerät ersetzt. Dadurch erhöht sich der Testaufwand stark!
Diese Apps sind in der Regel kostenfrei nutzbar. Kosten entstehen erst, wenn Transaktionen ausgeführt werden. Dabei muss der Anwender pro Transaktion eine Gebühr bezahlen. Diese Gebühr kann dabei als Pauschalbetrag oder als prozentualer Anteil am Transaktionsvolumen realisiert sein.
Dieses Modell wird eher selten genutzt, da es nur für Apps nutzbar ist, in denen Transaktionen einen wichtigen Teil der Funktionalität darstellen. Ein Schwerpunkt der Nutzung dieses Modell liegt bei Finanz-Apps wie z.B. digitalen Geldbörsen (Wallet), bei denen der Anwender für jede Übertragung von Geld auf ein anderes Konto bezahlt. Weitere Beispiele sind Apps zum Handel von Aktien, bei denen für jeden Kauf oder Verkauf eine Gebühr zu bezahlen ist.
Auch bei Nachrichten-Apps kommt dieses Modell manchmal zum Einsatz, häufig in Kombination mit einem Abo-basierten Modell. Dabei können Nutzer, die kein Abo haben, einzelne Artikel käuflich erwerben, die ansonsten nur Nutzern mit Abo vorbehalten sind.
Werbung innerhalb von Apps anzuzeigen ist eine sehr weit verbreitete Methode, mit deren Hilfe App-Anbieter Umsatz generieren. Sie ist in fast allen Arten von Apps zu finden.
Die Einbindung von Werbung ist relativ einfach umzusetzen, da sowohl die Plattformanbieter als auch Drittanbieter entsprechende Programmbibliotheken zur Verfügung stellen. Diese müssen durch den App-Anbieter lediglich in die App eingebunden werden. Die Werbeinhalte werden dabei von den Anbietern der Bibliotheken bereitgestellt, sodass sich der App-Betreiber nicht einmal um Werbepartner kümmern muss. Auch die Ausschüttung des erzielten Umsatzes erfolgt über diese Anbieter. Somit handelt es sich um eine gute Möglichkeit für einen App-Anbieter, ohne großen Aufwand Umsatz zu erzielen (vgl. Abb. 2–6).
Abb. 2–6Podcast-App »Overcast« – werbefinanziert
Die größte Herausforderung besteht darin, die Werbung so in das User Interface zu integrieren, dass die Werbung durch die Nutzer wahrgenommen wird, ohne die Nutzbarkeit stark zu beeinträchtigen. Wird die Nutzbarkeit der App durch die Werbung zu stark eingeschränkt, z.B. indem die Werbung wesentliche Teile der App überlagert, kann dies dazu führen, dass die App nicht genutzt wird. Wird die App nicht genutzt, wird auch keine Werbung angezeigt und somit kein Umsatz über angezeigte Werbung generiert. Dies ist auch der Grund, warum in der Regel der mit dieser Art der Finanzierung erzielbare Umsatz mit der Dauer der Nutzersessions steigt. Denn je länger die App genutzt wird, desto mehr Werbung wird dem Anwender gezeigt.
Beim Test von Apps, die dieses Geschäftsmodell nutzen, sollten wir darauf achten, dass bereits im Test echte Werbung aus den gleichen Quellen wie später in der produktiven Nutzung bezogen wird. Wenn im Test nur simulierte Quellen genutzt werden, besteht das Risiko, dass Probleme mit der Schnittstelle zur produktiven Quelle nicht gefunden werden.
Häufig werden Werbefinanzierung und Freemium kombiniert. Bei dieser Kombination kann eine werbefinanzierte App durch Bezahlung in eine werbefreie Version gewandelt werden. Im Test ist daher darauf zu achten, dass in der werbefreien Version wirklich alle Werbung entfernt wurde.
Das Feld der Gratis- und Unternehmens-Apps ist sehr groß. Es lässt sich dabei in drei Hauptgruppen einteilen. Zum einen in die Gruppe der Apps, die für die eigenen Mitarbeiter und Partner entwickelt werden, damit diese geschäftliche Aufgaben direkt von ihrem Smartphone oder Tablet aus erledigen können (vgl. Praxisbeispiel 2–2).
Ein Abrechnungsdienstleister im Energiesektor hat eine Android-App entwickeln lassen, mit der die Ableser vor Ort beim Kunden die Verbrauchswerte für Strom, Heizung und Wasser erfassen konnten. Jeder Ableser erhielt ein entsprechendes Android-Gerät. Erfasste Daten wurden bei bestehender Netzwerkverbindung direkt übertragen. Wenn während der Erfassung keine Netzwerkverbindung bestand, wurde die Übertragung verzögert, bis das Gerät das nächste Mal eine Netzwerkverbindung aufbauen konnte.
