Seminar Mobile Device Cloud – Android-Testautomatisierung mit Espresso und Jetpack Compose

Dieses Praxisseminar behandelt einen klar abgegrenzten Fach- und Praxisbereich. Native Android-Tests für klassische Views und moderne Compose-Oberflächen werden erstellt, stabilisiert und auf realen Geräten parallel ausgeführt. Die Arbeitsweise verbindet fachliche Einordnung, demonstrierte Konfiguration, angeleitete Umsetzung und kontrollierte Positiv- sowie Negativtests.

Alle Übungen verwenden definierte Ausgangszustände, reale mobile Geräte, nachvollziehbare Prüfpunkte und dokumentierte Abschlusskriterien. Dadurch entstehen wiederholbare Arbeitsweisen statt isolierter Einzelaktionen.

Inhaltsübersicht

• Testarchitektur für native Android-Apps
• Espresso-Grundlagen und ViewMatcher
• Jetpack-Compose-Tests
• Synchronisation und Flakiness
• Geräte- und OS-Matrix
• Ausführung und Parallelisierung
• Diagnose und Reporting
• Wartung in der Delivery-Pipeline
• Praxisübungen und Laborszenarien
• Zielgruppe und Voraussetzungen
• Didaktik und Arbeitsweise

1. Testarchitektur für native Android-Apps

Im Mittelpunkt stehen App-Module, Testquellen, Build-Varianten, Abhängigkeiten, Testdaten und Geräteprofile. Praktisch wird eine wartbare Android-Teststruktur mit getrennten Verantwortlichkeiten umgesetzt und anhand von Buildbarkeit, Isolation, Wiederholbarkeit und Laufzeitverhalten geprüft.

1. Schritt 1: Ausgangslage, Schutz- oder Qualitätsbedarf und konkrete Zielkriterien für Testarchitektur für native Android-Apps erfassen.
2. Schritt 2: Relevante Objekte, Rollen, Daten, Zustände und Abhängigkeiten anhand von App-Module, Testquellen, Build-Varianten, Abhängigkeiten, Testdaten und Geräteprofile strukturiert modellieren.
3. Schritt 3: Die erforderliche Konfiguration oder Prozessfolge für eine wartbare Android-Teststruktur mit getrennten Verantwortlichkeiten schrittweise aufbauen.
4. Schritt 4: Den vorgesehenen Ablauf mit definierten Positivfällen ausführen und jeden Zustandswechsel protokollieren.
5. Schritt 5: Kontrollierte Negativ-, Abbruch- und Wiederanlauffälle aus Buildbarkeit, Isolation, Wiederholbarkeit und Laufzeitverhalten durchführen und Abweichungen klassifizieren.
6. Schritt 6: Als Arbeitsergebnis eine dokumentierte Testarchitektur für das Projekt erstellen, fachlich prüfen und in einen wiederholbaren Standard überführen.

2. Espresso-Grundlagen und ViewMatcher

Im Mittelpunkt stehen View-Hierarchie, Matcher, Actions, Assertions, Idling und Fehlerdiagnose. Praktisch wird einen stabilen Espresso-Test für einen vollständigen Benutzerpfad umgesetzt und anhand von Synchronisation, eindeutige Selektoren, Assertions und Wiederholbarkeit geprüft.

1. Schritt 1: Ausgangslage, Schutz- oder Qualitätsbedarf und konkrete Zielkriterien für Espresso-Grundlagen und ViewMatcher erfassen.
2. Schritt 2: Relevante Objekte, Rollen, Daten, Zustände und Abhängigkeiten anhand von View-Hierarchie, Matcher, Actions, Assertions, Idling und Fehlerdiagnose strukturiert modellieren.
3. Schritt 3: Die erforderliche Konfiguration oder Prozessfolge für einen stabilen Espresso-Test für einen vollständigen Benutzerpfad schrittweise aufbauen.
4. Schritt 4: Den vorgesehenen Ablauf mit definierten Positivfällen ausführen und jeden Zustandswechsel protokollieren.
5. Schritt 5: Kontrollierte Negativ-, Abbruch- und Wiederanlauffälle aus Synchronisation, eindeutige Selektoren, Assertions und Wiederholbarkeit durchführen und Abweichungen klassifizieren.
6. Schritt 6: Als Arbeitsergebnis eine wiederverwendbare Espresso-Basisklasse mit Hilfsfunktionen erstellen, fachlich prüfen und in einen wiederholbaren Standard überführen.

3. Jetpack-Compose-Tests

Im Mittelpunkt stehen Semantics Tree, Nodes, Tags, Actions, Zustände und Compose-Testregeln. Praktisch wird einen Compose-Test für dynamische und zustandsabhängige Oberflächen umgesetzt und anhand von Semantik, Sichtbarkeit, Zustandswechsel und Barrierefreiheitsmerkmale geprüft.

1. Schritt 1: Ausgangslage, Schutz- oder Qualitätsbedarf und konkrete Zielkriterien für Jetpack-Compose-Tests erfassen.
2. Schritt 2: Relevante Objekte, Rollen, Daten, Zustände und Abhängigkeiten anhand von Semantics Tree, Nodes, Tags, Actions, Zustände und Compose-Testregeln strukturiert modellieren.
3. Schritt 3: Die erforderliche Konfiguration oder Prozessfolge für einen Compose-Test für dynamische und zustandsabhängige Oberflächen schrittweise aufbauen.
4. Schritt 4: Den vorgesehenen Ablauf mit definierten Positivfällen ausführen und jeden Zustandswechsel protokollieren.
5. Schritt 5: Kontrollierte Negativ-, Abbruch- und Wiederanlauffälle aus Semantik, Sichtbarkeit, Zustandswechsel und Barrierefreiheitsmerkmale durchführen und Abweichungen klassifizieren.
6. Schritt 6: Als Arbeitsergebnis eine Compose-spezifische Selektor- und Assertion-Bibliothek erstellen, fachlich prüfen und in einen wiederholbaren Standard überführen.

4. Synchronisation und Flakiness

Im Mittelpunkt stehen asynchrone Daten, Animationen, Netzwerkzugriffe, Hintergrundarbeit und Zeitabhängigkeiten. Praktisch wird eine deterministische Synchronisationsstrategie ohne starre Wartezeiten umgesetzt und anhand von Fehlerrate, Laufzeitstreuung, Race Conditions und Wiederanlauf geprüft.

1. Schritt 1: Ausgangslage, Schutz- oder Qualitätsbedarf und konkrete Zielkriterien für Synchronisation und Flakiness erfassen.
2. Schritt 2: Relevante Objekte, Rollen, Daten, Zustände und Abhängigkeiten anhand von asynchrone Daten, Animationen, Netzwerkzugriffe, Hintergrundarbeit und Zeitabhängigkeiten strukturiert modellieren.
3. Schritt 3: Die erforderliche Konfiguration oder Prozessfolge für eine deterministische Synchronisationsstrategie ohne starre Wartezeiten schrittweise aufbauen.
4. Schritt 4: Den vorgesehenen Ablauf mit definierten Positivfällen ausführen und jeden Zustandswechsel protokollieren.
5. Schritt 5: Kontrollierte Negativ-, Abbruch- und Wiederanlauffälle aus Fehlerrate, Laufzeitstreuung, Race Conditions und Wiederanlauf durchführen und Abweichungen klassifizieren.
6. Schritt 6: Als Arbeitsergebnis einen Flakiness-Katalog mit priorisierten Gegenmaßnahmen erstellen, fachlich prüfen und in einen wiederholbaren Standard überführen.

5. Geräte- und OS-Matrix

Im Mittelpunkt stehen Android-Versionen, Displayklassen, Herstellerprofile, Berechtigungen und Systemeinstellungen. Praktisch wird eine risikobasierte Auswahl realer Android-Geräte umgesetzt und anhand von Kompatibilität, Layout, Berechtigungsdialoge und herstellerspezifische Abweichungen geprüft.

1. Schritt 1: Ausgangslage, Schutz- oder Qualitätsbedarf und konkrete Zielkriterien für Geräte- und OS-Matrix erfassen.
2. Schritt 2: Relevante Objekte, Rollen, Daten, Zustände und Abhängigkeiten anhand von Android-Versionen, Displayklassen, Herstellerprofile, Berechtigungen und Systemeinstellungen strukturiert modellieren.
3. Schritt 3: Die erforderliche Konfiguration oder Prozessfolge für eine risikobasierte Auswahl realer Android-Geräte schrittweise aufbauen.
4. Schritt 4: Den vorgesehenen Ablauf mit definierten Positivfällen ausführen und jeden Zustandswechsel protokollieren.
5. Schritt 5: Kontrollierte Negativ-, Abbruch- und Wiederanlauffälle aus Kompatibilität, Layout, Berechtigungsdialoge und herstellerspezifische Abweichungen durchführen und Abweichungen klassifizieren.
6. Schritt 6: Als Arbeitsergebnis eine freigegebene Android-Testmatrix erstellen, fachlich prüfen und in einen wiederholbaren Standard überführen.

6. Ausführung und Parallelisierung

Im Mittelpunkt stehen Build-Upload, Gerätebelegung, Testpakete, parallele Läufe, Rücksetzung und Ergebnisabruf. Praktisch wird eine reproduzierbare Ausführung auf mehreren Geräten umgesetzt und anhand von Durchsatz, Isolation, Ressourcenverbrauch und Fehlertrennung geprüft.

1. Schritt 1: Ausgangslage, Schutz- oder Qualitätsbedarf und konkrete Zielkriterien für Ausführung und Parallelisierung erfassen.
2. Schritt 2: Relevante Objekte, Rollen, Daten, Zustände und Abhängigkeiten anhand von Build-Upload, Gerätebelegung, Testpakete, parallele Läufe, Rücksetzung und Ergebnisabruf strukturiert modellieren.
3. Schritt 3: Die erforderliche Konfiguration oder Prozessfolge für eine reproduzierbare Ausführung auf mehreren Geräten schrittweise aufbauen.
4. Schritt 4: Den vorgesehenen Ablauf mit definierten Positivfällen ausführen und jeden Zustandswechsel protokollieren.
5. Schritt 5: Kontrollierte Negativ-, Abbruch- und Wiederanlauffälle aus Durchsatz, Isolation, Ressourcenverbrauch und Fehlertrennung durchführen und Abweichungen klassifizieren.
6. Schritt 6: Als Arbeitsergebnis eine skalierbare Run-Konfiguration mit Parallelitätsgrenzen erstellen, fachlich prüfen und in einen wiederholbaren Standard überführen.

7. Diagnose und Reporting

Im Mittelpunkt stehen Logcat, Screenshots, Videos, Testberichte, Stacktraces und Laufmetadaten. Praktisch wird einen strukturierten Diagnoseablauf für fehlgeschlagene Android-Tests umgesetzt und anhand von Ursachenzuordnung, Evidenzqualität und Wiederholbarkeit geprüft.

1. Schritt 1: Ausgangslage, Schutz- oder Qualitätsbedarf und konkrete Zielkriterien für Diagnose und Reporting erfassen.
2. Schritt 2: Relevante Objekte, Rollen, Daten, Zustände und Abhängigkeiten anhand von Logcat, Screenshots, Videos, Testberichte, Stacktraces und Laufmetadaten strukturiert modellieren.
3. Schritt 3: Die erforderliche Konfiguration oder Prozessfolge für einen strukturierten Diagnoseablauf für fehlgeschlagene Android-Tests schrittweise aufbauen.
4. Schritt 4: Den vorgesehenen Ablauf mit definierten Positivfällen ausführen und jeden Zustandswechsel protokollieren.
5. Schritt 5: Kontrollierte Negativ-, Abbruch- und Wiederanlauffälle aus Ursachenzuordnung, Evidenzqualität und Wiederholbarkeit durchführen und Abweichungen klassifizieren.
6. Schritt 6: Als Arbeitsergebnis einen standardisierten Fehlerbericht für Entwicklung und Testbetrieb erstellen, fachlich prüfen und in einen wiederholbaren Standard überführen.

8. Wartung in der Delivery-Pipeline

Im Mittelpunkt stehen Branching, Teststufen, Quality Gates, Quarantäne, Versionspflege und Verantwortlichkeiten. Praktisch wird eine belastbare Einbindung der Android-Tests in den Releaseprozess umgesetzt und anhand von Gate-Logik, Laufzeitbudget, Fehlalarmquote und Eskalation geprüft.

1. Schritt 1: Ausgangslage, Schutz- oder Qualitätsbedarf und konkrete Zielkriterien für Wartung in der Delivery-Pipeline erfassen.
2. Schritt 2: Relevante Objekte, Rollen, Daten, Zustände und Abhängigkeiten anhand von Branching, Teststufen, Quality Gates, Quarantäne, Versionspflege und Verantwortlichkeiten strukturiert modellieren.
3. Schritt 3: Die erforderliche Konfiguration oder Prozessfolge für eine belastbare Einbindung der Android-Tests in den Releaseprozess schrittweise aufbauen.
4. Schritt 4: Den vorgesehenen Ablauf mit definierten Positivfällen ausführen und jeden Zustandswechsel protokollieren.
5. Schritt 5: Kontrollierte Negativ-, Abbruch- und Wiederanlauffälle aus Gate-Logik, Laufzeitbudget, Fehlalarmquote und Eskalation durchführen und Abweichungen klassifizieren.
6. Schritt 6: Als Arbeitsergebnis einen Betriebsstandard für kontinuierliche Android-Tests erstellen, fachlich prüfen und in einen wiederholbaren Standard überführen.

Praxisübungen und Laborszenarien

• Implementierung eines Espresso-End-to-End-Pfads mit stabilen Matchern und Assertions.
• Aufbau eines Compose-Tests unter Verwendung des Semantics Tree.
• Paralleltest auf mehreren Android-Versionen mit dokumentierter Geräteauswahl.
• Analyse eines vorbereiteten Flakiness-Falls anhand von Logcat, Video und Laufdaten.

Zielgruppe und Voraussetzungen

Zielgruppe: Android-Entwicklung, Testautomation, Quality Engineering und technische Testarchitektur.

Voraussetzungen: Sichere Android-Grundlagen, Kotlin-Kenntnisse, Gradle-Grundlagen und Erfahrung mit automatisierten Tests.

Didaktik und Arbeitsweise

Kurze Fachimpulse werden unmittelbar durch Demonstrationen, strukturierte Konfigurationsschritte, praktische Übungen und kontrollierte Fehlerfälle vertieft. Jede Übung enthält Ausgangswerte, Arbeitsschritte, Prüfpunkte und Dokumentationsanforderungen. Die Übungsartefakte bilden zusammen einen unmittelbar nutzbaren Projekt- oder Betriebsstandard. Drei Seminartage sind erforderlich, weil 8 technische Module und 4 zusammenhängende Laborübungen mit mehreren Plattform- oder Frameworkvarianten praktisch aufgebaut und geprüft werden.