Deutsch 
Magyar 
English (UK) iOS, Android, Versionen, Endgeräte: Mobile Testing wird schnell komplex. Wir zeigen, wann sich Automatisierung lohnt – und wie sie sich sinnvoll umsetzen lässt.
TL;DR
- Beim Mobile Testing vervielfacht sich die Zahl der Geräte-, Versions- und Konfigurationskombinationen sehr schnell.
- Gezielt eingesetzte Automatisierung kann bei mobilen Apps einen erheblichen ROI erzielen - im Vergleich zum manuellen Testen, das schnell teuer und zeitaufwendig wird.
- Automatisierung beginnt sich bei häufiger Wiederholung zu lohnen, insbesondere bei Regressionstests und Tests auf mehreren Geräten.
- Der Schlüssel zu langfristig tragfähiger Automatisierung liegt in einer gut aufgebauten Testarchitektur, die plattformübergreifend wiederverwendet werden kann.
- Mobile-Automatisierung lohnt sich auch bei bestehenden Anwendungen, doch je früher die Testbarkeit berücksichtigt wird, desto geringer fallen die späteren Kosten und Risiken aus.
- Der Schlüssel zu einer optimalen Infrastruktur liegt in der bewussten Auswahl und - wo nötig - Kombination von Emulatoren, physischen Geräten und cloudbasierten Device Farms.
Inhaltsverzeichnis
Mobile Testing für iOS und Android: So werden aus 2 Plattformen am Ende 20
Wenn die Entwicklung einer neuen mobilen Anwendung beginnt, wird in der Regel bereits ganz am Anfang entschieden, dass sie sowohl für iOS als auch für Android entwickelt wird. Das Team kalkuliert daher frühzeitig mit erheblichen Zusatzkosten: Die Besonderheiten zweier Plattformen müssen berücksichtigt werden - mit unterschiedlichem UI-Verhalten, abweichenden Systemfunktionen, Berechtigungsmanagement und verschiedenen technischen Einschränkungen. Der tatsächliche Kostenanstieg zeigt sich jedoch oft erst später, denn die Anwendung muss nicht nur entwickelt, sondern auch kontinuierlich überprüft, also getestet werden.
Auf dem Papier haben wir weiterhin nur zwei Plattformen. In der Praxis verhält sich jedoch nicht jedes iPhone exakt wie das andere, und auch Android ist kein einzelnes, klar abgegrenztes Umfeld. Unterschiedliche Betriebssystemversionen, verschiedene Hersteller, Displaygrößen, Hardwareprofile und gerätespezifische Besonderheiten kommen hinzu. Dazu kommen verschiedene Versionen der Anwendung selbst und natürlich die Funktionen, die nach jedem Release erneut überprüft werden müssen.
Irgendwann geht es also nicht mehr nur darum, ob die Anwendung grundsätzlich auf iOS und Android funktioniert, sondern ob sie auf den tatsächlichen Geräte- und Systemkombinationen läuft, die unsere Nutzer wirklich verwenden.
Wenn wir beispielsweise 100 kritische Geschäftsprozesse haben und diese auf 10 relevanten Geräte- oder Betriebssystemkonfigurationen prüfen möchten, kommen wir bereits auf 1.000 Testausführungen. Und das nicht nur einmal, sondern bei jedem größeren Release. All das erhöht den Zeitaufwand für manuelles Testen erheblich.
Wenn manuelles Testen auf Mobilgeräten zu zeitaufwendig wird
An diesem Punkt beginnen wir in der Regel, Kompromisse einzugehen:
- Wir testen nicht auf jedem Gerät, sondern nur auf den wichtigsten.
- Wir führen nicht die vollständige Regressionstest-Suite aus, sondern nur einen Teil davon.
- Wir priorisieren auf Basis einer Risikoanalyse.
Fachlich ist es völlig legitim, nicht jede denkbare Variante zu 100 % zu testen. Problematisch wird es, wenn dies nur geschieht, um Zeit zu sparen. Wenn wir deshalb etwas nicht überprüfen, optimieren wir in Wahrheit nicht das Testen, sondern reduzieren die Testabdeckung. Genau an diesem Punkt wird Testautomatisierung wirklich interessant.
Automatisierte Tests können bei mobilen Apps einen erheblichen ROI liefern
Automatisiertes Testen wird oft als schnellere Variante des manuellen Testens verstanden: Was früher ein Mensch erledigt hat, übernimmt nun ein Skript. Das ist teilweise richtig, doch bei mobilen Anwendungen bietet Automatisierung weit wichtigere Vorteile als nur Geschwindigkeit.
Ein gut geschriebener automatisierter Test wird nicht nur einmal ausgeführt. Derselbe Test kann auf mehreren Geräten, unter verschiedenen Betriebssystemversionen und mit unterschiedlichen App-Versionen laufen, und mit der passenden Infrastruktur kann all das sogar parallel erfolgen. Ein einmal erstellter Test erzeugt somit bei jeder weiteren Ausführung erneut Wert.
Dieser Unterschied ist entscheidend, denn die Erstellung eines automatisierten Tests erfordert selbstverständlich mehr Aufwand als eine einzelne manuelle Ausführung. Wenn ein Test nur einmal durchgeführt werden soll, ergibt Automatisierung wahrscheinlich wenig Sinn. Wenn wir jedoch denselben Prozess bei jedem Release, auf mehreren Plattformen und auf mehreren Geräten überprüfen möchten, verändert sich die Rechnung sehr schnell.
Deshalb amortisiert sich Automatisierung nicht beim ersten Durchlauf, sondern beim 20., 50. oder 100.
Die Rentabilität der Testautomatisierung: Wann lohnt sie sich und wie wird sie berechnet?
Die Rentabilität der Testautomatisierung ist für Unternehmen entscheidend. Erfahren Sie, welche Faktoren den ROI beeinflussen, wann sich die Investition lohnt und wie sich die häufigsten Fallstricke vermeiden…
Wann lässt sich eine mobile Anwendung sinnvoll automatisieren?
Gute Automatisierung beginnt lange vor den eigentlichen Tests. Es gibt jedoch eine Voraussetzung: Die Anwendung muss automatisierbar sein.
Was sind die Voraussetzungen?
1. Die Testbarkeit wird bereits in der Entwicklungsphase berücksichtigt.
Das klingt trivial, aber in der Praxis werden viele spätere Probleme bereits in der Planungs- und Entwicklungsphase entschieden.
2. Es werden eindeutige Identifikatoren verwendet.
Eine mobile Anwendung kann so aufgebaut werden, dass sie der Testautomatisierung eine stabile, klar identifizierbare und vorhersehbare Oberfläche bietet - oder so, dass nach jeder kleinen UI-Änderung ein halber Tag für die Anpassung der Tests aufgewendet werden muss.
Nehmen wir ein sehr einfaches Beispiel: Wenn eine Schaltfläche einen stabilen, eindeutigen Identifikator erhält, findet der automatisierte Test immer dasselbe Element. Fehlt ein solcher Identifikator, stützt sich der Test möglicherweise auf Text, Hierarchien oder andere visuelle Merkmale. Das funktioniert nur so lange, bis jemand die Beschriftung der Schaltfläche ändert, die Sprache umstellt oder den Bildschirm neu anordnet. Bei einem einzelnen Test ist das nur eine Kleinigkeit, bei Hunderten oder Tausenden von Tests jedoch ein erheblicher Wartungsaufwand.
3. Es wird eine konsistente UI-Struktur verwendet.
Ebenso wichtig ist, dass die logische Struktur der iOS- und Android-Anwendung nach Möglichkeit nicht unnötig voneinander abweicht. Nicht jedes Pixel muss identisch sein, und selbstverständlich sollten die jeweiligen UX-Konventionen der beiden Plattformen nicht ignoriert werden. Wenn jedoch derselbe Geschäftsprozess in zwei völlig unterschiedlichen Strukturen umgesetzt wird, ist auf der Automatisierungsseite deutlich mehr plattformspezifische Logik erforderlich.
4. Komplexere Funktionen werden bereits im Voraus geplant.
Push-Benachrichtigungen, Deep Links, biometrische Funktionen, Interaktionen mit externen Anwendungen oder verschiedene Berechtigungsanfragen sind ebenfalls Bereiche, in denen die Testbarkeit bereits in der Planungsphase viel gewinnen oder verlieren kann.
5. Unterstützende Schnittstellen werden integriert.
Auch eine technische Schnittstelle zur Unterstützung des Testens kann zahlreiche Automatisierungsprobleme verhindern.
Die gute Nachricht ist, dass die meisten dieser Entscheidungen keinen besonders hohen zusätzlichen Entwicklungsaufwand bedeuten.
Und was, wenn Automatisierung nicht Teil der Planung war?
Viele Automatisierungsprojekte beginnen nicht bei einer neu gestarteten Anwendung. Meist gibt es bereits ein funktionierendes Produkt, mehrere Releases liegen schon hinter ihm, bestimmte technische Kompromisse haben sich etabliert, und erst später entsteht der Bedarf, einen Teil der Regressionstests zu automatisieren. In solchen Fällen besteht die Aufgabe darin, die bestehende Anwendung mit vertretbarem Aufwand automatisierbar zu machen.
Glücklicherweise ist dafür in der Regel keine vollständige Neugestaltung erforderlich. Moderne Mobile-Automatisierungs-Frameworks können viele Probleme bereits selbst abfangen, und häufig ist Entwicklerunterstützung nur in einigen wenigen kritischen Bereichen notwendig. Typische Beispiele sind die Einführung stabiler Accessibility IDs, die Testbarkeit von Notification-Flows oder eine einfachere Steuerbarkeit bestimmter umgebungsabhängiger Faktoren.
Dabei können heute auch KI-basierte Entwicklerwerkzeuge helfen. Sie unterstützen Entwickler vor allem dabei, Apps auf eine einfache Automatisierbarkeit vorzubereiten. Das bedeutet für sie einen geringeren Ressourcenaufwand. Wichtig ist jedoch, dass Tester und Entwickler in solchen Fällen immer eng zusammenarbeiten, um festzulegen, in welchen Bereichen Änderungen erforderlich sind. Die Verantwortung der Tester liegt darin, die notwendigen Anpassungen zu sammeln, die der Entwickler in ihrer Umsetzung innerhalb des bestehenden Frameworks.
Womit sollten Mobile-Tests automatisiert werden?
Bei der Mobile-Testautomatisierung ist die Werkzeugauswahl ein häufiges Thema. Appium, native Frameworks, verschiedene Cross-Platform-Lösungen sowie unterschiedliche Ausführungs- und Integrationsmöglichkeiten stehen dabei oft zur Diskussion. Technische Aspekte sind selbstverständlich wichtig, doch das Werkzeug allein entscheidet nur selten über den Erfolg eines Automatisierungsprojekts.
Ein konkreter und häufig gut nutzbarer Technologie-Stack ist beispielsweise die Kombination aus Appium, WebdriverIO und TypeScript. Dieser Stack kann zusammen mit Playwright-basierten Web-UI- und API-Tests in ein Framework integriert werden, was die Entwicklung möglicher End-to-End-Autotests erheblich unterstützt. Mit Appium lassen sich sowohl iOS- als auch Android-Anwendungen steuern, WebdriverIO bietet einen gut nutzbaren Rahmen für die Organisation und Ausführung von Tests, und TypeScript unterstützt bei größeren Testcodebasen durch Typsicherheit und eine gut strukturierbare Entwicklungsumgebun
Das ist jedoch nur eine mögliche Technologieentscheidung. Für eine gute Entscheidung müssen die Erfahrung des Teams, der bestehende Entwicklungs-Stack, die CI/CD-Umgebung, die technische Architektur der Anwendung und natürlich auch die langfristige Automatisierungsstrategie berücksichtigt werden, die wir aufbauen möchten.
Software-Testwerkzeuge in der Praxis – Nach welchen Kriterien sollte man auswählen?
Selenium, Playwright, Appium, JMeter oder k6? Ein praxisnaher Leitfaden zur Auswahl nachhaltiger Testtools für KMU und Großunternehmen.
Eine weitaus wichtigere Frage ist jedoch, wie wir das Testsystem selbst aufbauen.
1 Anwendung, 2 Plattformen: idealerweise keine zwei vollständigen Testcodebasen
Die naheliegendste Lösung wäre natürlich, ein Testpaket für Android und anschließend ein weiteres für iOS zu schreiben. Einige Monate später wird klar, dass jede fachliche Änderung in zwei separaten Testcodebasen angepasst werden muss.
In einer besseren Architektur wird die Business-Logik nach Möglichkeit als gemeinsame Schicht behandelt, und nur das wird getrennt, was tatsächlich plattformspezifisch ist. Zum Beispiel kann der Test selbst einfach sagen, dass sich der Benutzer anmelden, sein Profil öffnen und die Spracheinstellung ändern soll:
await loginPage.login(user);
await homePage.openProfile();
await profilePage.changeLanguage(„English”);
Aus Sicht des Tests ist es unerheblich, mit welchem Locator die jeweilige Schaltfläche unter iOS gefunden wird und an welcher Stelle sie in der UI-Hierarchie unter Android genau liegt. Das sollte die plattformspezifische Schicht übernehmen.
Der Vorteil dieses Ansatzes besteht nicht nur darin, dass wir weniger Code schreiben. Wichtiger ist, dass wir Änderungen an einem Geschäftsprozess an einer einzigen Stelle vornehmen können. Plattformunterschiede sickern nicht in jeden einzelnen Testfall ein, sodass das System langfristig deutlich leichter wartbar bleibt.
Hier kommen die klassischen Entwurfsmuster der Automatisierung wirklich zum Tragen: Page- bzw. Screen-Objects, gemeinsame Business-Schichten, Plattform-Adapter, Testdatenmanagement und Konfigurationsabstraktionen.
"Sobald wir 500 Tests haben, taucht ein neues Problem auf "
Nehmen wir an, das Framework ist fertig, die Anwendung lässt sich gut testen, und im Laufe der Zeit haben wir 500 automatisierte Testfälle aufgebaut. Wenn jeder einzelne 1,5 Minuten Laufzeit hat, dann ergibt das bei sequentieller Ausführung mehr als 12 Stunden. Das heißt: Wir haben erfolgreich einen Regressionstest automatisiert, dessen Ergebnis wir erst am nächsten Morgen erhalten. Technisch funktioniert das, aber in einem schnellen Entwicklungsprozess ist es nur begrenzt nützlich. Ab hier wird die Parallelisierung zu einem grundlegenden Bestandteil der Automatisierungsstrategie.
Wenn wir dieselben 500 Tests parallel auf 10 Geräten ausführen, kann sich die Ausführungszeit grob auf ein Zehntel reduzieren. Bei 20 oder 30 parallelen Sessions kann sich die Feedback-Zeit weiter verkürzen. Je früher das Entwicklungsteam das Testergebnis erhält, desto schneller kann es auf Fehler reagieren. Eine Feedback-Schleife von wenigen Minuten oder einer halben Stunde gehört noch zum selben Entwicklungskontext. Ein Testergebnis, das erst am nächsten Morgen eintrifft, deutlich weniger. Daraus ergibt sich sofort die nächste Frage: Wo sollen so viele Tests laufen?
Was sollten wir wählen, wenn wir eine mobile App testen möchten: Emulator, eigener Gerätepark oder Cloud Device Farm?
Das hängt von mehreren Faktoren ab, denn alle drei Lösungen sind für unterschiedliche Probleme gut geeignet. Bevor wir einen Anbieter auswählen, sollten folgende Aspekte geprüft werden:
- Wie gut sind die Kosten im Voraus kalkulierbar und wie hoch sind sie überhaupt?
- Welchen Wartungs- und Betriebsaufwand erfordern sie?
- Wie plattformgetreu sind sie?
- Wie gut lassen sie sich in CI/CD integrieren?
Hier ist eine Zusammenfassung dessen, was man über die obigen Punkte wissen sollte.
Mobile-Testinfrastrukturen: PRO und KONTRA - Emulator, eigener Gerätepark oder Cloud Farm
| Kriterium | Emulator / Simulator | Eigener Gerätepark | Cloud Device Farm |
| Kosten | - Niedrig und gut kalkulierbar - Geringe Hardwarekosten | - Hohe versteckte Kosten (Beschaffung, Abschreibung, verlorene Engineering-Stunden) | - Höhere, feste Lizenzkosten oder nutzungsbasierte Gebühren |
| Wartung und Betrieb | - Minimal - Softwareseitig automatisiert verwaltbar | - Sehr hoch (Laden, Updates, physische Lagerung, Behebung von Netzwerkproblemen) | - Keine (alles wird vom Anbieter betrieben und aktualisiert) |
| Plattformtreue | - Mittel/Gering - Deckt hardwarebedingte und herstellerspezifische Fehler nicht auf | - Maximal - Reale Hardwareumgebung und physisches Verhalten | - Maximal - Eine breite Auswahl realer physischer Geräte und Betriebssysteme |
| Skalierbarkeit und CI/CD-Integration | - Hervorragend - Schnell startbar und in beliebiger Anzahl parallelisierbar | - Begrenzt - Die Anzahl physischer Geräte und ihre Instabilität können zum Engpass werden | - Hervorragend - Extrem schnelles Feedback durch hohe Parallelisierung |
| Insgesamt: Wann ist es die beste Wahl? | - Für schnelles Testen während der Entwicklung - Für frühe Regressionsläufe | - Für kontinuierliches Testen auf einigen strategisch besonders wichtigen Geräten | - Für breit angelegte Kompatibilitätstests - Zur Abdeckung seltenerer Geräte |
Emulatoren und Simulatoren
Emulatoren und Simulatoren lassen sich schnell starten, einfach skalieren und können für einen großen Teil der Tests vollkommen ausreichend sein. Besonders in der Entwicklung und in frühen Regressionsläufen sind sie sehr gut einsetzbar, da sich viele Instanzen kostengünstig und flexibel betreiben lassen. Gleichzeitig können sie jedoch nicht jedes Problem realitätsnah reproduzieren.
Bestimmte hardwarebezogene und gerätespezifische Funktionen (zum Beispiel Kamera, biometrische Authentifizierung, einige Sensoren, NFC oder Bluetooth) lassen sich in einer emulierten Umgebung nur eingeschränkt, nur simuliert oder gar nicht in derselben Weise testen wie auf einem realen Gerät. Dasselbe gilt für bestimmte herstellerspezifische Besonderheiten, Performance-Probleme und Systemintegrationen, für deren zuverlässige Prüfung weiterhin physische Geräte erforderlich sind.
Eigene Geräteparks
Diese Lücken lassen sich mit einem eigenen Bestand an physischen Geräten abdecken. Die Vorhaltung einiger strategisch wichtiger Geräte ist in vielen Projekten völlig sinnvoll. Die Schwierigkeiten beginnen dann, wenn aus fünf Telefonen 20 oder 30 werden. Diese müssen gekauft, gelagert, geladen, aktualisiert, konfiguriert und im CI/CD-Pipeline dauerhaft verfügbar gehalten werden. Ein Mobiltelefon weiß leider nicht, dass es Teil einer kritischen CI-Infrastruktur ist, und entscheidet sich deshalb manchmal einfach dafür, nach einem Update nicht mehr so verbunden zu sein wie gestern. Ab einer gewissen Größe ist ein eigener Device Lab daher bereits eine eigenständige Infrastruktur, die separat betrieben werden muss.
Cloud Device Farms
Die dritte Möglichkeit ist eine Cloud Device Farm, zum Beispiel BrowserStack, TestMU.AI (früher LambdaTest) oder Sauce Labs. Hier stellt der Anbieter die physischen Geräte und einen wesentlichen Teil der Infrastruktur bereit, während die Tests auf mehreren Geräten, auch mit hoher Parallelisierung, ausgeführt werden können. Das verursacht natürlich Lizenzkosten, weshalb häufig die Frage aufkommt: Ist es günstiger, eigene Telefone zu kaufen? Für eine präzise Antwort müssen wir alle Kosten berücksichtigen. Wenn wir den Anschaffungspreis eines Telefons auf die Monate seiner geplanten Nutzungsdauer verteilen, können wir ihn mit der monatlichen Lizenzgebühr eines Cloud-Dienstes vergleichen, aber das allein zeigt noch nicht die Gesamtkosten
Bei einem eigenen Gerätepark gehören zu den Gesamtkosten die Beschaffung der Geräte, ihre Abschreibung und ihr Austausch, die Infrastruktur, der Betrieb, das Management von OS-Updates, Störungen und natürlich auch die Engineering-Zeit, die all das beansprucht. Bei einer Cloud Device Farm setzen sich die Kosten typischerweise aus der Lizenz, dem erforderlichen Grad an Parallelisierung und gegebenenfalls dem Nutzungsvolumen zusammen.
Bei der ROI-Berechnung ist auch der Wert schnelleren Feedbacks ein wichtiger Faktor. Durch die Parallelisierung von Tests lässt sich die Durchlaufzeit deutlich reduzieren, sodass Entwickler früher über Fehler informiert werden und auch der Release-Prozess beschleunigt werden kann. Parallelisierung ist jedoch kein Vorteil, der ausschließlich Cloud Device Farms vorbehalten ist; sie lässt sich auch mit einem eigenen Gerätepark und in virtualisierten Umgebungen umsetzen.
Die optimale Infrastruktur hängt immer von den Testanforderungen ab. So kann das Testen während der Entwicklung auf Emulatoren und Simulatoren stattfinden, während Regressionstests auf eigenen physischen Geräten oder in einer Cloud Device Farm laufen. Das Ziel ist nicht zwingend die Kombination verschiedener Lösungen, sondern die Sicherstellung der erforderlichen Abdeckung, Ausführungskapazität und Feedback-Zeit.
Eine geeignete Infrastruktur ist also dadurch gekennzeichnet, dass sie mit der erforderlichen Abdeckung, der Ausführungsfrequenz und der Feedback-Zeit im Einklang steht.
Wartung großer automatisierter Testsuiten
Wenn all das gut funktioniert, stellt sich eine weitere Frage: Wie halten wir die Hunderte oder sogar Tausende von Tests instand, die wir zuvor automatisiert haben?
Denn die Anwendung entwickelt sich währenddessen weiter. Neue Screens kommen hinzu, andere verändern sich, und neue Geräte sowie neue Betriebssystemversionen kommen auf den Markt. Auch Testcode kann - genau wie jede andere Software - technische Schulden ansammeln. Wenn jede kleine UI-Änderung Anpassungen an Dutzenden von Tests nach sich zieht oder eine neue Plattformversion dazu führt, dass jeder zweite Lauf instabil wird, dann fließt ein Teil der anfangs eingesparten Zeit allmählich als Wartungsaufwand wieder zurück.
In einem ausgereiften Mobile-Automatisierungssystem sollte daher großer Wert darauf gelegt werden, wie sich die Automatisierung anpassungsfähiger machen lässt. Wie reduzieren wir die Menge an plattformspezifischer Logik, wie wählen wir die Ausführungsumgebungen aus, wie gehen wir mit unterschiedlichen Geräten um, und wie reagieren wir mit weniger manuellem Eingreifen auf Änderungen an der Anwendung?
Wo sollten wir automatisieren, und wann sollten wir bei manuellen Tests bleiben?
Manuelles Testen hat im Testen mobiler Anwendungen weiterhin seinen Platz, denn es gibt Bereiche, in denen menschliche Beobachtung, exploratives Testen oder fachliches Denken nach wie vor bessere Ergebnisse liefern können. Dort jedoch, wo die Aufgabe wiederholbar, klar definiert und häufig auszuführen ist, kommt Automatisierung ins Spiel. Und bei mobilen Anwendungen mangelt es daran in der Regel nicht.
Wenn wir gut automatisieren, wird jeder weitere Lauf nach der Erstinvestition immer günstiger. Und vielleicht ist genau das die wichtigste wirtschaftliche Eigenschaft der Mobile-Testautomatisierung: Wir sparen nicht unbedingt beim ersten Test am meisten, sondern dadurch, dass dieselbe Arbeit nicht auch zum hundertsten Mal wieder auf exakt dieselbe Weise ausgeführt werden muss.
FAQ
1. Wie lassen sich die Wartungskosten der Mobile-Testautomatisierung auf iOS- Und Android-Plattformen senken?
Die Wartungskosten steigen typischerweise dann schnell an, wenn iOS- und Android-Tests auf getrennter Logik basieren und jede Änderung an mehreren Stellen nachverfolgt werden muss. Nachhaltiger ist ein Ansatz, bei dem gemeinsame Geschäftsprozesse in einer einheitlichen Testschicht verbleiben und nur die plattformspezifischen Elemente getrennt werden. Unterstützt wird dies zusätzlich durch die Verwendung stabiler UI-Identifikatoren und dadurch, dass sich die Automatisierung auf stabile Prozesse mit hohem geschäftlichem Wert konzentriert.
2. Welche geschäftlichen Vorteile bietet die parallele Ausführung mobiler Tests im Hinblick auf Release-Geschwindigkeit und Fehlererkennung?
Die parallele Ausführung verkürzt die Feedback-Zeit erheblich, sodass sich ein mehrstündiger Regressionstest auf Minuten oder einige Dutzend Minuten reduzieren lässt. Aus geschäftlicher Sicht ist das wichtig, weil das Team schneller auf Fehler reagieren kann und es im Release-Prozess zu weniger Wartezeit kommt. Je schneller das Testergebnis vorliegt, desto besser unterstützt die Automatisierung häufige Releases und eine planbare Delivery.
3. Welche Kriterien sollten bei der Auswahl eines Mobile-App-Testing-Dienstleisters berücksichtigt Werden?
Bei der Auswahl eines Mobile-App-Testing-Dienstleisters sollte man nicht nur auf Testreferenzen achten, sondern auch darauf, wie gut die Dienstleistung zum Betriebsmodell des Projekts passt. Wichtige Faktoren sind die erforderliche Testabdeckung, die Ausführungshäufigkeit und die erwartete Feedback-Zeit. Darüber hinaus sollten auch das Servicemodell, die Geräte- und Infrastrukturbasis, die Wartungsverantwortung, die CI/CD-Integrationsfähigkeit, das Reporting, Sicherheits- und Compliance-Aspekte, fachliche Referenzen sowie die Skalierbarkeit berücksichtigt werden.
Autor: Győző Nagy, Testautomatisierungsarchitekt
