Maestro ist ein Open-Source-Framework für Mobile-UI-Testing. Testfälle werden als YAML-Flows beschrieben statt in Testcode geschrieben, und dieselbe Datei kann gegen iOS und Android laufen. Wartebedingungen für Animationen und Ladezustände sind Teil des Werkzeugs, nicht Handarbeit im Test.

Maestro vs. Appium oder Detox — wann was?

Maestro spielt seine Stärke aus, wenn Flows schnell entstehen und lesbar bleiben sollen — auch für Menschen, die keinen Testcode schreiben. Appium ist der breitere, ältere Standard mit sehr weitgehender Steuerbarkeit und entsprechend mehr Setup. Detox ist eng auf React Native zugeschnitten und arbeitet dafür sehr nah am App-Prozess. Wir wählen nach Team, Plattformen und dem, was in Ihrer CI wartbar bleibt.

Wie lange dauert der Aufbau einer Flow-Suite?

Das hängt vom Umfang ab — von der Zahl der Bildschirme, Zustände und Plattformen. Erste lauffähige Flows für die zentralen Wege entstehen in Tagen; eine belastbare Suite über eine gewachsene App wächst danach schrittweise mit. Eine seriöse Aussage geben wir erst, nachdem wir Ihre App gesehen haben.

Funktioniert das mit React Native und Flutter?

Ja. Maestro testet Black-Box auf UI-Ebene und interessiert sich nicht dafür, womit die App gebaut wurde — React Native, Flutter oder nativ. Voraussetzung ist lediglich, dass die zu prüfenden Elemente über Test-IDs oder sichtbaren Text ansprechbar sind.

Konditionen auf Anfrage. Aufwand und Umfang unterscheiden sich pro App zu stark für eine Listenpreisangabe — wir schauen uns Ihren Stand an und nennen dann einen konkreten Rahmen.

Mobile E2E Testing

Mobile E2E Testing mit Maestro

Reproduzierbare Release-Qualität für iOS und Android — statt vor jedem Store-Release die halbe App manuell durchzuklicken. Maestro beschreibt Testfälle als YAML-Flows, die auf beiden Plattformen dieselbe Oberfläche prüfen.

Erstgespräch buchen Zum Maestro-Tutorial im Blog

Warum Mobile-E2E anders ist

Was auf dem Web funktioniert, trägt auf dem Gerät nicht eins zu eins. Drei Unterschiede, die den Aufwand bestimmen.

Gerätevielfalt & OS-Versionen

Dieselbe App verhält sich auf einem aktuellen iPhone anders als auf einem drei Jahre alten Android-Gerät: Bildschirmgrößen, Berechtigungsdialoge, Systemschriftgrößen und OS-Versionen erzeugen Kombinationen, die niemand mehr von Hand abdeckt.

Flakiness durch Animationen & Timing

Übergänge, Ladezustände und Netzwerklatenz machen naiv geschriebene Tests unzuverlässig. Stabile Flows warten auf Zustände statt auf Sekunden — sonst kippt die Suite bei jedem zweiten Lauf und wird ignoriert.

Store-Release-Zyklen ohne Hotfix-Weg

Ein Fehler im Web ist in Minuten deployt. Eine App muss durch das Store-Review — bis der Fix bei den Nutzern ankommt, vergehen Tage. Was vor dem Release nicht getestet wurde, bleibt sichtbar.

Werkzeuge, mit denen wir arbeiten

Maestro für die Oberfläche, Jest für die Logik, eigene Open-Source-Werkzeuge für Testdaten und zeitabhängige Abläufe — alles in der CI verankert.

Maestro

Open-Source-Framework für Mobile-UI-Testing. Testfälle sind YAML-Flows statt Testcode — dieselbe Datei läuft gegen iOS und Android, Wartebedingungen sind eingebaut statt nachträglich eingestreut.

Jest

Für alles, was keinen Bildschirm braucht: Berechnungen, Zustandsmaschinen, Datenmodelle. Logikfehler fallen dort in Millisekunden auf, statt später eine E2E-Suite auszubremsen.

nanook & bitdiver — eigene Open Source

nanook erzeugt Testdaten aus Äquivalenzklassen, statt Beispielwerte von Hand zu pflegen. bitdiver deckt zeitabhängiges End-to-End-Testing über eine YAML-Konfiguration ab. Beide entstanden aus unserer eigenen Testarbeit und sind frei verfügbar.

nanook.xhub.io ansehen bitdiver.xhub.io ansehen

CI/CD-Integration

Flows laufen automatisiert bei jedem Pull Request und vor jeder Store-Einreichung. Ergebnisse und Screenshots landen im Build — nicht auf dem Rechner einer einzelnen Person.

Woher wir das wissen

Wir betreiben Maestro-Flow-Suiten nicht nur für Kundenprojekte, sondern für unsere eigenen Apps im Store.

Eigene Apps im Store

TankKosten und LadeKosten sind unsere eigenen mobilen Apps. Ihre Release-Flows — App-Start, Onboarding, Anlegen von Datensätzen, Export — sind als Maestro-Suiten hinterlegt und laufen vor jeder Einreichung. Was wir empfehlen, tragen wir selbst durch das Store-Review.

Zur App-Entwicklung

Verantwortlich für QA

Torsten Link

CTO & Gründer

Erfahrener Software-Architekt mit Schwerpunkt Qualitätssicherung, Testautomatisierung und CI/CD-Pipelines. Verantwortete unter anderem die QA-Strategie für das Fahrgastinformationssystem der Deutschen Bahn und architektierte Testautomatisierung über hunderte Microservices hinweg. Über 11 Jahre Node.js- und TypeScript-Entwicklung.

So sieht ein Flow aus

Ein vereinfachtes Beispiel in der Struktur, die wir auch in unseren eigenen Suiten verwenden.

vehicle/add-vehicle.yaml

# Smoke-Flow: Fahrzeug anlegen
appId: com.example.app
tags:
  - smoke
  - regression
name: "Fahrzeug anlegen"
---
- launchApp:
    clearState: true
    permissions:
      notifications: allow

# Auf einen Zustand warten, nicht auf Sekunden
- extendedWaitUntil:
    visible: "Übersicht|Willkommen"
    timeout: 15000

- tapOn:
    id: "add-vehicle-button"
- assertVisible: "Neues Fahrzeug"

- tapOn:
    id: "manufacturer-input"
- inputText: "Beispielhersteller"
- pressKey: enter

- tapOn:
    id: "model-input"
- inputText: "Beispielmodell"
- pressKey: enter

- tapOn:
    text: "Fahrzeug speichern"

# Ergebnis prüfen — nicht nur "kein Absturz"
- assertVisible:
    text: "Beispielhersteller Beispielmodell"
    timeout: 10000

- takeScreenshot: vehicle-created

Der Flow startet die App mit geleertem Zustand, damit jeder Lauf identisch beginnt. Statt fester Wartezeiten hält "extendedWaitUntil" an, bis ein erwarteter Bildschirm sichtbar ist — das ist der Hebel gegen Flakiness. Elemente werden über stabile Test-IDs angesprochen, nicht über Positionen; am Ende steht eine echte Zusicherung plus Screenshot als Beleg im Build.

Was wir übernehmen

Von der Frage, was überhaupt automatisiert gehört, bis zur Suite, die in Ihrer Pipeline läuft.

E2E-Strategie & Flow-Design — welche Wege automatisiert werden und welche bewusst manuell bleiben
Aufbau der Flow-Suite — wiederverwendbare Teilflows, stabile Test-IDs, verlässliche Wartebedingungen
CI-Integration — Flows laufen bei jedem Pull Request und vor jeder Store-Einreichung
Testdaten-Strategie — reproduzierbare Ausgangszustände statt zufälliger Datenlage auf dem Gerät

Konditionen auf Anfrage

Umfang und Aufwand hängen davon ab, wie viele Flows Ihre App wirklich braucht. Wir schauen uns Ihre App an und sagen, womit ein sinnvoller Anfang gemacht ist.

Erstgespräch buchen

30 Minuten, unverbindlich.

Häufige Fragen

Was Teams vor dem Einstieg in Mobile-E2E-Testing meistens wissen wollen.

Was ist Maestro?: Maestro ist ein Open-Source-Framework für Mobile-UI-Testing. Testfälle werden als YAML-Flows beschrieben statt in Testcode geschrieben, und dieselbe Datei kann gegen iOS und Android laufen. Wartebedingungen für Animationen und Ladezustände sind Teil des Werkzeugs, nicht Handarbeit im Test.
Maestro vs. Appium oder Detox — wann was?: Maestro spielt seine Stärke aus, wenn Flows schnell entstehen und lesbar bleiben sollen — auch für Menschen, die keinen Testcode schreiben. Appium ist der breitere, ältere Standard mit sehr weitgehender Steuerbarkeit und entsprechend mehr Setup. Detox ist eng auf React Native zugeschnitten und arbeitet dafür sehr nah am App-Prozess. Wir wählen nach Team, Plattformen und dem, was in Ihrer CI wartbar bleibt.
Wie lange dauert der Aufbau einer Flow-Suite?: Das hängt vom Umfang ab — von der Zahl der Bildschirme, Zustände und Plattformen. Erste lauffähige Flows für die zentralen Wege entstehen in Tagen; eine belastbare Suite über eine gewachsene App wächst danach schrittweise mit. Eine seriöse Aussage geben wir erst, nachdem wir Ihre App gesehen haben.
Funktioniert das mit React Native und Flutter?: Ja. Maestro testet Black-Box auf UI-Ebene und interessiert sich nicht dafür, womit die App gebaut wurde — React Native, Flutter oder nativ. Voraussetzung ist lediglich, dass die zu prüfenden Elemente über Test-IDs oder sichtbaren Text ansprechbar sind.
Was kostet das?: Konditionen auf Anfrage. Aufwand und Umfang unterscheiden sich pro App zu stark für eine Listenpreisangabe — wir schauen uns Ihren Stand an und nennen dann einen konkreten Rahmen.

Sprechen wir über Ihre Testabdeckung

Erzählen Sie uns, wie Ihre App heute vor einem Release geprüft wird — wir sagen Ihnen, was sich davon automatisieren lässt.

Erstgespräch buchen Zur App-Entwicklung

30 Minuten, unverbindlich. Antwort innerhalb 24 Stunden.

# Smoke-Flow: Fahrzeug anlegen appId: com.example.app tags: - smoke - regression name: "Fahrzeug anlegen" --- - launchApp: clearState: true permissions: notifications: allow # Auf einen Zustand warten, nicht auf Sekunden - extendedWaitUntil: visible: "Übersicht|Willkommen" timeout: 15000 - tapOn: id: "add-vehicle-button" - assertVisible: "Neues Fahrzeug" - tapOn: id: "manufacturer-input" - inputText: "Beispielhersteller" - pressKey: enter - tapOn: id: "model-input" - inputText: "Beispielmodell" - pressKey: enter - tapOn: text: "Fahrzeug speichern" # Ergebnis prüfen — nicht nur "kein Absturz" - assertVisible: text: "Beispielhersteller Beispielmodell" timeout: 10000 - takeScreenshot: vehicle-created