App Testing: So testen wir iOS & Android Apps — Methoden, Tools und Best Practices

Eine App zu entwickeln ist das eine. Sicherzustellen, dass sie auf hunderten Geräten, verschiedenen OS-Versionen und unter realen Bedingungen zuverlässig funktioniert, das andere. In diesem Artikel zeigen wir unseren kompletten Testing-Workflow — von Unit Tests über E2E-Tests mit Maestro bis zur Verteilung via TestFlight und Google Play Internal Testing.

---

TL;DR — Die Testing-Pyramide für mobile Apps

Das Prinzip: Viele schnelle, günstige Tests an der Basis (Unit Tests). Wenige, aber aussagekräftige Tests an der Spitze (E2E). Dazwischen Integration Tests, die das Zusammenspiel prüfen. Manuelles Testing fängt auf, was Automatisierung nicht abdeckt.

---

Warum Testing bei Apps besonders wichtig ist

Web-Anwendungen können Sie innerhalb von Minuten hotfixen — ein Deployment, und der Bug ist behoben. Bei mobilen Apps ist das fundamental anders:

1. App Store Reviews dauern 24–48 Stunden. Ein kritischer Bug in Produktion bedeutet, dass Ihre Nutzer mindestens einen Tag lang betroffen sind. Bei Apple kann es bei Rückfragen sogar eine Woche dauern.

2. Schlechte Bewertungen sind permanent. Ein Nutzer, der auf einen Crash stößt, hinterlässt eine 1-Stern-Bewertung. Selbst wenn Sie den Bug fixen — die Bewertung bleibt. Und sie beeinflusst Ihr Ranking im Store.

3. Gerätefragmentierung ist enorm. Ihre App muss auf einem iPhone SE (2020) mit iOS 16 genauso funktionieren wie auf einem Samsung Galaxy S25 Ultra mit Android 15. Das sind unterschiedliche Bildschirmgrößen, Prozessoren, Betriebssysteme und Speicherkapazitäten.

4. OTA-Updates haben Grenzen. Mit Expo EAS Update können wir JavaScript-Änderungen sofort ausliefern — aber native Änderungen erfordern einen neuen Build und ein Store-Review.

5. Nutzer deinstallieren schnell. Im Web drückt man F5. Bei einer App, die crasht, wird deinstalliert — und ein verlorener Nutzer kommt selten zurück.

Fazit: Gründliches Testing vor dem Release ist bei Apps keine Best Practice, sondern eine Notwendigkeit.

---

Unit Testing mit Jest

Unit Tests sind das Fundament unserer Testing-Pyramide. Sie testen einzelne Funktionen, Hooks und Komponenten isoliert — schnell, zuverlässig und günstig.

Wir nutzen Jest als Test-Runner in Kombination mit der React Native Testing Library (RNTL). Das Setup ist bei Expo-Projekten ab SDK 52 bereits vorkonfiguriert.

Was wir mit Unit Tests abdecken

• Utility-Funktionen: Formatierung (Datum, Währung), Validierung (E-Mail, Telefonnummer), Berechnungen
• Custom Hooks: useAuth, useCart, useForm — State-Logik, die in mehreren Screens verwendet wird
• Reducer und State-Management: Zustandsübergänge in Zustand/Redux Stores
• Komponenten-Rendering: Wird die richtige Ausgabe bei gegebenem Input gerendert?
• Conditional Logic: Zeigt der Button „Kaufen" oder „Ausverkauft" — abhängig vom Lagerbestand?

Was wir nicht mit Unit Tests abdecken

• Navigation zwischen Screens — das ist ein Integration Test
• API-Aufrufe an echte Server — wir mocken APIs in Unit Tests
• Plattformspezifisches Verhalten — iOS vs. Android Unterschiede testen wir manuell oder per E2E
• Visuelle Darstellung — ob ein Button „gut aussieht", prüft kein Unit Test

Richtwert

Für ein typisches App-Projekt schreiben wir 100–300 Unit Tests. Die Testdauer liegt bei unter 30 Sekunden. Unit Tests laufen bei jedem Commit automatisch in der CI-Pipeline.

---

Integration Testing

Integration Tests prüfen, ob mehrere Komponenten zusammen korrekt funktionieren. Einzeln kann alles grün sein — aber im Zusammenspiel treten oft Fehler auf.

Was wir testen

• API-Integration: Komponente ruft Daten ab → zeigt Ladezustand → rendert Ergebnis → zeigt Fehler bei Timeout
• Navigation Flows: Login → Dashboard → Profilseite → Logout → Login-Screen
• AsyncStorage / SecureStore: Daten werden gespeichert, gelesen und korrekt gelöscht
• Formular-Flows: Eingabe → Validierung → Absenden → Erfolgsmeldung → Redirect

API Mocking mit MSW

Statt echte API-Aufrufe zu machen, verwenden wir Mock Service Worker (MSW). MSW fängt Netzwerk-Requests auf Netzwerk-Ebene ab und gibt definierte Antworten zurück — ohne den Produktionscode zu verändern.

Vorteil: Wir testen den realen Fetch-/Axios-Code unserer App. Nur der Server wird simuliert. Das ist deutlich näher an der Realität als jest.mock('axios').

Richtwert

Pro Projekt schreiben wir 30–80 Integration Tests. Sie dauern 1–3 Minuten und laufen ebenfalls in der CI-Pipeline — allerdings nur bei Pull Requests, nicht bei jedem Commit.

---

E2E Testing mit Maestro

End-to-End-Tests simulieren echte Nutzerinteraktionen auf einem Gerät oder Emulator. Sie tippen auf Buttons, füllen Formulare aus, navigieren durch Screens und prüfen, ob alles funktioniert.

Warum Maestro?

Wir haben Detox, Appium und Maestro evaluiert. Unsere Wahl: Maestro.

Der größte Vorteil: YAML-basierte Tests sind extrem lesbar — auch für Nicht-Entwickler. Ein Projektmanager kann einen Maestro-Test lesen und verstehen, was getestet wird.

Test Flows schreiben

appId: at.exponent.kundenapp
---
- launchApp
- tapOn: "E-Mail"
- inputText: "test@example.com"
- tapOn: "Passwort"
- inputText: "sicheresPasswort123"
- tapOn: "Anmelden"
- assertVisible: "Willkommen zurück"

Wir schreiben Maestro-Flows für alle geschäftskritischen Pfade:

• Onboarding / Registrierung — vom ersten Screen bis zur Aktivierung
• Login / Logout — inkl. Biometrie und „Passwort vergessen"
• Kernfunktionalität — je nach App: Bestellung aufgeben, Termin buchen, Nachricht senden
• Bezahlvorgang — wenn zutreffend, mit Test-Kreditkarten
• Push-Benachrichtigungen — Empfang und Deep Linking

CI-Integration

Maestro-Tests laufen in unserer GitHub Actions Pipeline auf jedem Pull Request. Wir nutzen Maestro Cloud für parallele Ausführung auf echten iOS- und Android-Geräten. Ein Testlauf mit 10–15 Flows dauert ca. 8–12 Minuten.

---

Platform-specific Testing

iOS: TestFlight

TestFlight ist Apples offizielle Plattform für Beta-Testing. Jede App, die über EAS Build gebaut wird, kann direkt an TestFlight übermittelt werden.

Internal Testing (bis 100 Tester):

• Keine App Store Review nötig
• Build ist sofort verfügbar (nach Processing, ca. 5–15 Minuten)
• Ideal für das Entwicklungsteam und den Kunden
• Tester müssen im App Store Connect eingeladen werden

External Testing (bis 10.000 Tester):

• Erfordert eine Beta App Review von Apple (24–48 Stunden)
• Tester können per Link eingeladen werden
• Ideal für größere Beta-Gruppen oder öffentliche Betas
• 90 Tage gültig pro Build

Was wir an TestFlight nutzen:

• Gruppen: Wir erstellen separate Gruppen für „Entwicklung", „Kunde" und „Beta-Tester"
• Feedback-Tool: Tester können direkt aus der App Screenshots mit Annotationen senden
• Automatische Updates: Neue Builds werden automatisch an alle Tester verteilt
• Crash Reports: TestFlight liefert detaillierte Crash-Logs

Android: Release Tracks

Google Play bietet ein mehrstufiges Testing-System über sogenannte Release Tracks:

Unser Workflow: Wir nutzen primär Internal Testing für die laufende Entwicklung und Closed Testing für Kundenfeedback. Der Vorteil von Internal Testing: Kein Review, der Build ist in Minuten verfügbar.

---

Gerätefragmentierung testen

Das größte Testproblem bei mobilen Apps: Es gibt tausende verschiedene Geräte. Allein Android läuft auf über 24.000 unterschiedlichen Gerätemodellen.

Unsere Testgeräte

Wir testen jede App physisch auf mindestens diesen Geräten:

Warum das Budget-Gerät? Ein Samsung Galaxy A15 hat 4 GB RAM und einen Mittelklasse-Prozessor. Wenn die App darauf flüssig läuft, läuft sie überall. Viele Bugs zeigen sich nur auf schwächerer Hardware — Memory Leaks, langsame Renders, ANR-Fehler (Application Not Responding).

Simulatoren vs. echte Geräte

Unsere Regel: Entwicklung auf Simulatoren, alle Release-Tests auf echten Geräten.

Cloud Device Farms

Für Geräte, die wir nicht physisch besitzen, nutzen wir Firebase Test Lab (Googles Cloud-Plattform, kostenloser Tier mit 15 Tests/Tag) und AWS Device Farm (breites Sortiment, minutengenau abgerechnet).

Was wir auf verschiedenen Geräten prüfen

• Screen Sizes: Layout-Umbrüche, abgeschnittene Texte, überlappende Elemente
• OS Versions: iOS 16–18, Android 12–15 — wir unterstützen die letzten 3 Major Versions
• Notch/Dynamic Island: Inhalte dürfen nicht von der Notch verdeckt werden
• Faltbare Geräte: Samsung Galaxy Fold — App muss auf beiden Bildschirmformaten funktionieren

---

Performance Testing

Eine App kann funktional korrekt sein und trotzdem eine schlechte User Experience bieten — weil sie langsam startet, ruckelt oder den Akku leersaugt.

Startup Time (Time to Interactive)

Die Zeit vom Tap auf das App-Icon bis zur ersten nutzbaren Ansicht. Unsere Zielwerte:

• Cold Start: unter 2 Sekunden
• Warm Start: unter 800 Millisekunden

Wir messen mit Expo's expo-splash-screen Timing und React Native's PerformanceObserver. Bei Überschreitung optimieren wir: Lazy Loading, weniger Initialisierungslogik, Bundle-Size-Reduktion.

Memory Leaks

Memory Leaks sind bei React Native ein häufiges Problem — besonders bei unbereinigten Event Listeners, Timer und Subscriptions. Wir prüfen:

• Android: Android Studio Profiler zeigt Heap-Größe über Zeit
• iOS: Xcode Instruments → Leaks und Allocations
• Symptom: Die App wird langsamer, je länger man sie nutzt. Oder sie crasht nach 20–30 Minuten Nutzung.

FPS Monitoring

Flüssige 60 FPS sind der Standard. Wir monitoren:

• JS Thread FPS: Logik und State-Updates
• UI Thread FPS: Rendering und Animationen
• React DevTools Profiler: Identifiziert unnötige Re-Renders

Drop unter 50 FPS bei Scroll-Listen oder Animationen ist ein Blocker — das wird vor dem Release gefixt.

Battery Usage

Exzessive CPU-Nutzung, GPS-Polling oder Netzwerk-Requests im Hintergrund leeren den Akku schnell. Wir prüfen: keine aktiven Timer im Hintergrund, GPS nur bei Bedarf, Netzwerk-Requests gebündelt und Hintergrund-Tasks korrekt registriert.

---

CI/CD Pipeline

Automatisierung ist der Schlüssel zu konsistenter Qualität. Unsere CI/CD-Pipeline stellt sicher, dass kein fehlerhafter Code in Produktion gelangt.

GitHub Actions + EAS Build

Unser Standard-Setup für React Native Apps mit Expo:

Bei jedem Commit:

• TypeScript Type Check (tsc --noEmit)
• ESLint + Prettier
• Unit Tests (Jest)

Bei jedem Pull Request:

• Alles von oben, plus:
• Integration Tests
• Maestro E2E Tests (auf Maestro Cloud)
• Bundle Size Check (Warnung bei >5 % Anstieg)

Bei Merge in main:

• EAS Build für iOS und Android
• Automatische Verteilung an TestFlight (Internal Testing)
• Automatische Verteilung an Google Play (Internal Testing Track)

Bei Release-Tag:

• Production Build
• Submission an App Store und Google Play
• EAS Update für OTA-fähige Änderungen

Preview Builds für Stakeholder

Für jeden Feature-Branch können wir einen Preview Build erstellen. Der Kunde bekommt einen QR-Code, scannt ihn, und hat die neueste Version der App auf seinem Gerät — ohne technisches Wissen.

Das nutzen wir aktiv für Kundenfeedback während der Entwicklung. Statt Screenshots zu verschicken, bekommt der Kunde die echte App zum Anfassen.

---

Accessibility Testing

Barrierefreiheit ist kein Nice-to-have — es ist eine rechtliche Anforderung (European Accessibility Act ab Juni 2025) und erweitert Ihre Zielgruppe.

Was wir prüfen

• VoiceOver (iOS) und TalkBack (Android): Alle interaktiven Elemente müssen per Screenreader bedienbar sein. Labels, Hints und Roles müssen korrekt gesetzt sein.
• Schriftgrößen: Die App muss mit vergrößerter Systemschrift (Dynamic Type) funktionieren — keine abgeschnittenen Texte, keine überlappenden Elemente.
• Kontraste: Mindestens 4,5:1 für normalen Text, 3:1 für großen Text (WCAG AA).
• Touch Targets: Mindestens 44x44 Punkte für interaktive Elemente (Apple HIG) bzw. 48x48 dp (Material Design).
• Reduce Motion: Animationen müssen sich deaktivieren lassen, wenn der Nutzer „Bewegung reduzieren" aktiviert hat.

Unsere Tools: Accessibility Inspector (Xcode), Accessibility Scanner (Android) und eslint-plugin-react-native-a11y — Letzteres fängt fehlende Labels bereits im Code ab.

---

Unsere Testing-Checkliste vor jedem Release

Diese Checkliste arbeiten wir vor jedem App Store / Google Play Release ab:

Funktional:

• Alle Unit Tests grün
• Alle Integration Tests grün
• Alle E2E Tests (Maestro) grün
• Kernfunktionen manuell auf iOS + Android getestet
• Login/Logout/Registrierung funktioniert
• Bezahlvorgang funktioniert (falls vorhanden)
• Push-Benachrichtigungen kommen an
• Deep Links funktionieren

Geräte & Performance:

• Getestet auf mindestens 3 iOS- und 3 Android-Geräten
• Cold Start unter 2 Sekunden
• Keine sichtbaren Frame Drops bei Scroll-Listen
• Keine Memory Leaks bei 30-minütiger Nutzung
• App funktioniert bei schlechter Netzwerkverbindung

Plattform-spezifisch:

• iOS: Keine Warnings in Xcode Console
• iOS: Korrekte Darstellung mit Dynamic Island / Notch
• Android: Korrekte Darstellung auf verschiedenen Screen Sizes
• Android: Back-Button verhält sich korrekt

Qualität:

• Alle Texte auf Rechtschreibfehler geprüft
• App-Icon und Splash Screen korrekt
• Store-Screenshots aktualisiert (falls UI-Änderungen)
• Release Notes geschrieben
• Accessibility-Check bestanden

---

Häufig gestellte Fragen (FAQ)

Wie lange dauert das Testing einer App?

Für ein typisches Release planen wir 2–3 Tage Testing ein. Das beinhaltet automatisierte Tests (laufen in der CI/CD-Pipeline, ca. 15 Minuten) und manuelles Testing auf echten Geräten (1–2 Tage). Bei einem Erstrelease oder großen Feature-Updates kann es auch eine Woche sein.

Braucht jede App E2E-Tests?

Nicht zwingend, aber wir empfehlen es für jede App, die in den App Store geht. E2E-Tests kosten initial mehr Aufwand, sparen aber langfristig enorm viel Zeit — weil Sie bei jedem Update sicher sein können, dass die Kernfunktionen noch laufen. Für MVPs und Prototypen reichen oft Unit Tests und manuelles Testing.

Was kostet App Testing?

Testing macht bei uns ca. 15–20 % des Gesamtbudgets einer App aus. Bei einer App mit einem Budget von 50.000 € sind das 7.500–10.000 € für Testing. Das klingt viel, ist aber deutlich günstiger als die Kosten eines fehlerhaften Releases: schlechte Bewertungen, Nutzer-Verlust und Notfall-Hotfixes.

Können wir als Kunde beim Testing mithelfen?

Ja, und wir ermutigen das sogar. Über TestFlight (iOS) und Internal Testing (Android) können Sie und Ihr Team die App auf eigenen Geräten testen. Sie kennen Ihre Nutzer und Ihre Use Cases am besten — Ihr Feedback ist extrem wertvoll. Wir richten das für Sie ein und erklären den Prozess.

Was passiert, wenn nach dem Release ein Bug auftaucht?

Bei JavaScript-Bugs nutzen wir EAS Update für einen sofortigen Over-the-Air-Fix — ohne Store Review. Bei nativen Bugs erstellen wir einen Hotfix-Build und reichen ihn mit dem Vermerk „Bug Fix" ein — Apple und Google priorisieren solche Reviews und sind oft innerhalb von 24 Stunden durch.

---

Fazit

App Testing ist Investitionsschutz. Jeder Euro, den Sie in Testing investieren, spart ein Vielfaches an Kosten für Bug-Fixes, Notfall-Releases und verlorene Nutzer. Unser Ansatz:

1. Automatisierung — Unit Tests, Integration Tests und E2E-Tests in der CI/CD-Pipeline fangen 90 % aller Fehler ab, bevor ein Mensch die App anfasst.
2. Echte Geräte — Simulatoren sind gut für die Entwicklung, aber kein Ersatz für Testing auf echter Hardware.
3. Strukturierte Verteilung — TestFlight und Google Play Release Tracks sorgen dafür, dass die richtige Version an die richtigen Tester geht.
4. Klare Checkliste — Kein Release ohne abgehakte Checkliste. Das schützt vor „Haben wir das getestet?"-Momenten nach dem Release.

Bei exponent ist Testing fest in unseren Entwicklungsprozess integriert — nicht als nachträglicher Schritt, sondern als Teil jedes Sprints und jedes Features.

---

Nächster Schritt: App entwickeln lassen

Sie planen eine App und möchten sicherstellen, dass sie professionell getestet und zuverlässig ausgeliefert wird? Wir beraten Sie gerne — von der Technologiewahl bis zum Release.

Jetzt Angebot anfordern → · Erstgespräch vereinbaren →

Weiterführende Artikel:

• iOS App veröffentlichen: Der komplette App Store Guide
• Android App veröffentlichen: Play Store Guide
• React Native Probleme & Lösungen
• App Entwicklung — unsere Leistungen
• iOS App Entwicklung
• Android App Entwicklung

---

Dieser Artikel wurde im März 2026 veröffentlicht. Die genannten Tools und Versionsnummern beziehen sich auf den Stand Q1/2026. Alle Angaben basieren auf unserer Projekterfahrung mit React Native und Expo.