Seminar Testinium Device Farm – CI/CD-Integration und Testorchestrierung

Mobile Qualitätssicherung entfaltet ihren Nutzen erst dann vollständig, wenn Device-Farm-Ausführungen in Build-, Integrations- und Bereitstellungsprozesse eingebunden sind. Das Seminar entwickelt eine kontrollierte Orchestrierung von der Pipeline-Anforderung bis zur Rückmeldung des Testergebnisses.

Inhaltsverzeichnis

1. Seminarziel
2. Zielgruppe
3. Voraussetzungen
4. Seminarinhalte
5. 1. Zielbild der Pipeline-Integration
6. 2. Zugangsdaten und technische Verbindung
7. 3. Build- und App-Artefakte übergeben
8. 4. Geräte- und Testmatrix dynamisch auswählen
9. 5. Testläufe starten und überwachen
10. 6. Parallelisierung und Ressourcensteuerung
11. 7. Ergebnisse, Artefakte und Quality Gates
12. 8. Fehlerbehandlung und Wiederanlauf
13. Praxisübungen

Seminarziel

Ziel ist die belastbare Integration automatisierter mobiler Tests in CI/CD-Prozesse. Nach dem Seminar können Auslöser, Artefaktübergabe, Gerätezuteilung, Parallelisierung, Ergebnisbewertung, Fehlerbehandlung und Freigaberegeln technisch und organisatorisch gestaltet werden.

Zielgruppe

DevOps Engineers, Testautomatisierer, Build- und Release-Management, Plattformadministration und technische Testleitung.

Voraussetzungen

Grundkenntnisse von CI/CD-Pipelines, Versionsverwaltung und automatisierten Tests. Kenntnisse in Appium oder vergleichbaren Frameworks sind hilfreich.

Seminarinhalte

Die Inhalte werden anhand eines durchgängigen Übungsszenarios erarbeitet. Jeder Themenblock folgt einer nachvollziehbaren Arbeitsfolge aus Einordnung, Konfiguration, Durchführung, Kontrolle und Dokumentation.

1. Zielbild der Pipeline-Integration

Die Integration beginnt mit einem fachlich klaren Zielbild. Nicht jeder Test gehört in jede Pipeline-Stufe; Laufzeit, Aussagekraft und Ressourcenbedarf müssen abgestimmt werden.

1. Schritt 1: Bestehende Build-, Test- und Release-Stufen erfassen.
2. Schritt 2: Mobile Testarten nach Geschwindigkeit, Stabilität und Freigaberelevanz klassifizieren.
3. Schritt 3: Geeignete Auslöser für Smoke-, Regressions- und Freigabetests festlegen.
4. Schritt 4: Verantwortlichkeiten und erwartete Rückmeldungen je Stufe dokumentieren.

2. Zugangsdaten und technische Verbindung

Automatisierte Zugriffe benötigen geschützte technische Identitäten und reproduzierbare Verbindungsparameter. Geheimnisse dürfen nicht in Skripten oder Protokollen erscheinen.

1. Schritt 1: Technisches Konto mit minimalen Rechten definieren.
2. Schritt 2: Zugangsdaten in der Secret-Verwaltung der Pipeline hinterlegen.
3. Schritt 3: Endpunkte, Projektbezüge und Umgebungsvariablen standardisieren.
4. Schritt 4: Verbindung mit einem ungefährlichen Prüfaufruf testen und protokollieren.

3. Build- und App-Artefakte übergeben

Die Pipeline muss exakt den Build testen, den sie erzeugt hat. Artefaktkennung, Prüfsumme und Metadaten bilden die Verbindung zwischen Entwicklung und Test.

1. Schritt 1: Erzeugtes APK- oder IPA-Artefakt eindeutig benennen.
2. Schritt 2: Prüfsumme, Versionsnummer und Build-Informationen ermitteln.
3. Schritt 3: Artefakt in das vorgesehene Testprojekt übertragen.
4. Schritt 4: Übertragene Version prüfen und ihre Kennung für nachfolgende Schritte bereitstellen.

4. Geräte- und Testmatrix dynamisch auswählen

Die Geräteauswahl wird aus Risiko, Änderung und Pipeline-Stufe abgeleitet. Eine kleine Smoke-Matrix unterscheidet sich von einer vollständigen Freigabematrix.

1. Schritt 1: Parameter für Plattform, Betriebssystem, Modellklasse und Verfügbarkeit definieren.
2. Schritt 2: Eine minimale Matrix für schnelle Rückmeldung festlegen.
3. Schritt 3: Eine erweiterte Matrix für nächtliche oder releasebezogene Läufe konfigurieren.
4. Schritt 4: Nicht verfügbare Geräte durch geregelte Ersatzregeln behandeln.

5. Testläufe starten und überwachen

Der Startvorgang muss wiederholbar sein und eine eindeutige Laufkennung liefern. Statusabfragen verhindern, dass eine Pipeline ohne belastbares Ergebnis weiterläuft.

1. Schritt 1: Testplan, Artefakt und Geräteauswahl in einem Ausführungsauftrag verbinden.
2. Schritt 2: Lauf starten und Ausführungskennung in der Pipeline speichern.
3. Schritt 3: Status in geeigneten Intervallen abfragen und Zeitgrenzen beachten.
4. Schritt 4: Zwischen erfolgreich, fachlich fehlgeschlagen, technisch abgebrochen und nicht gestartet unterscheiden.

6. Parallelisierung und Ressourcensteuerung

Parallelisierung verkürzt die Rückmeldezeit, kann aber Geräte und Infrastruktur überlasten. Deshalb werden Grenzwerte und Warteschlangen bewusst gesteuert.

1. Schritt 1: Testfälle nach Unabhängigkeit und Ressourcennutzung gruppieren.
2. Schritt 2: Zulässige Parallelität aus verfügbarem Gerätebestand ableiten.
3. Schritt 3: Warteschlangen-, Reservierungs- und Zeitüberschreitungsregeln festlegen.
4. Schritt 4: Laufzeit und Auslastung messen und die Parallelität iterativ anpassen.

7. Ergebnisse, Artefakte und Quality Gates

Die Pipeline benötigt eine maschinenlesbare Entscheidung und zugleich aussagekräftige Diagnoseartefakte. Ergebnisse werden deshalb strukturiert ausgewertet.

1. Schritt 1: Ergebnisstatus, Fehlertypen und Qualitätskennzahlen abrufen.
2. Schritt 2: Logs, Screenshots, Videos und Berichte als Pipeline-Artefakte sichern.
3. Schritt 3: Grenzwerte für fehlgeschlagene Tests, Instabilität und Abdeckung definieren.
4. Schritt 4: Quality Gate auswerten und Freigabe, Wiederholung oder Abbruch auslösen.

8. Fehlerbehandlung und Wiederanlauf

Netzwerkstörungen, Geräteausfälle und instabile Tests müssen anders behandelt werden als echte Produktfehler. Eine differenzierte Wiederanlaufstrategie verhindert falsche Freigaben.

1. Schritt 1: Fehler nach Produkt, Test, Gerät, Plattform und Infrastruktur klassifizieren.
2. Schritt 2: Wiederholbare technische Fehler von fachlichen Fehlern trennen.
3. Schritt 3: Begrenzte Wiederholungen mit klaren Abbruchkriterien konfigurieren.
4. Schritt 4: Fehlerdaten an zuständige Teams übergeben und den Pipeline-Status nachvollziehbar setzen.

Praxisübungen

• Entwurf einer Pipeline mit Artefaktübergabe, Device-Farm-Ausführung und Quality Gate.
• Konfiguration einer schnellen Smoke-Matrix und einer erweiterten Regressionsmatrix.
• Auswertung eines Testlaufs einschließlich Logs, Screenshots und maschinenlesbarem Status.
• Erarbeitung einer Wiederanlaufmatrix für Produkt-, Test-, Geräte- und Infrastrukturfehler.