Das Dokument beschreibt den mobilen Testprozess bei Xing, inklusive der Organisation von Releases alle zwei Wochen für iOS und Android. Es werden Methoden zur Sicherstellung der App-Qualität vorgestellt, darunter manuelle und automatisierte Tests sowie Regressionstests. Die Erfahrungen zeigen, dass die Skalierung erfolgreich ist und keine zusätzlichen Tools erforderlich sind.

1. Mobile Testing @ XING - ist
der Release Train pünktlich?
Düsseldorf, 27.04.2016

2. Sergej Mudruk
Team Lead QA
Daniel Knott
Senior Software Test Engineer
@dnlkntt
www.adventuresinqa.com
2

3. XING AG
• Gegründet 2003 als OpenBC
• Seit 2006 XING AG
• > 15 Mio. Mitglieder weltweit
• die meisten in der DACH Region
• > 50% Mobile Traffic
• App Releases jede 2 Wochen
3

4. Bedeutung
• iPhone-Einführung im 2007
• Verbraucher zunehmend mobil
• Apps immer noch nicht
selbstverständlich
• Weitere rapide „Mobilisierung“ der
Entwicklung
4

5. 5
2014

6. 6
X
W
S
+10

7. Release-Prozess
• 1 mobiles Entwicklungsteam pro Plattform
(iOS/ Android)
• Features-Anforderungen von Domain-
Teams
• Zentrale Priorisierung und Entwicklung
• Team-KooperationBackend / Mobile
• Releases – unregelmäßig / nach Bedarf
• ca. 1 Mal im Monat
• Kein Koordinationsbedarf
7

8. Warum verändern?
8

9. 9
#Skalierung

10. 10
#API-Calls in den Teams

11. 11
#zentrales Team - Engpass

12. 12
#Domainwissen

13. 13
#Koordination BE<->App

14. 14
#Full Stack Product thinking

15. 15
2016

16. Team-Aufbau / Plattform Team
• Feature-bezogene Änderungen
- Patterns
- Maintenance
- Zentrale Komponenten
• Nicht zugeordnete
Komponenten
• Vorantreiben der Innovationen
16

17. Team-Aufbau / FrameworkTeam
• Infrastrukturelle Änderungen
- Bibliotheken
- Zentrale Komponenten
• Deployment
• CI-Infrastruktur (Jenkins)
• Tools:
- Development
- Automatisierung
• Crash Reports (Evaluierung)
17

18. 18
X
W
S
+10

19. Release-Prozess
Wie die Releases heute organisiert sind.
19

20. Release-Train
• 2 zentrale Sub-Teams pro Plattform
• Features in den jeweiligen Domain-
Teams
• Team-Kooperation DSTs / mobile
Teams
• Vorgaben / Patterns
• Einheitlicher Release-Train-Prozess
20

21. 21
Entwicklung asynchron
Feature Freeze
Public Release
Pre-Release / Beta-Test
1,5 Wochen
Sprintende 1,5 Wochen
insg. 4
Wochen

22. Wie stellt man die App Qualität sicher ?
• Abgeschlossenes Testen der neuen Features
• manuell
• Automatisierte Tests
• Erfolgreiche manuelle Regressionstests
• Testautomatisierung
• Frühe Fehlererkennung
22

23. Regressionstests
• jedes „unleashed“ Team
• eigener Bereich– einzeln und integriert
• zentrales Team
• generelle Koordination
• allgemeines Testen (Tracking, Update, etc.)
• Bereiche in der Teamverantwortung
23

24. Testautomatisierung- Android
• Unit Tests
• Statische Code Analyse
• UI Tests- „Espresso for
Android“
• Simulatoren / echte Geräte
• tägliche Builds
• tägliche Deployments
24

25. Frühe Fehlererkennung - Android
• „Beta Tests“ - Phase
- 1 Woche
- Google Play Store Tools
- User melden sich an
• „Staged rollout“
- 20%
- 50%
- 100%
25

26. 26

27. 27

28. 28

29. Testautomatisierung- iOS
• Unit Tests + FB Snapshot-
Tests
• UI Tests – KIF
• mehrere Testsuiten
• iOS Simulatoren
• 2 Test Systeme
• tägliche Builds
• automatisches Deployment
29

30. Frühe Fehlererkennung - iOS
• Pre-release Phase
- 1,5 Wochen
- XING-intern
- jeder Mitarbeiter mit iOS
30

31. 31

32. 32

33. 33

34. 34

35. 35

36. 36

37. Erfahrungen
• Skalierung funktioniert
• keine zusätzlichen Tools benötigt
• versetzte Releases Android / iOS
• Knowhow Erweiterung benötigt
• zentrales Team koordiniert
• strikt sein
37

38. Vielen Dank für Ihre
Aufmerksamkeit!
www.xing.com
Daniel Knott
@dnlkntt
Sergej Mudruk