---
title: "Wir testen nicht mehr alles. Wir testen, was brechen kann."
source: "https://neckarshore.ai/blog/risikobasierte-teststrategie-ios"
site: "neckarshore.ai"
author: "German Rauhut"
date: "2026-11-05"
categories: "Testmanagement, KI-Agenten"
note: "Dieser Artikel ist mit KI-Unterstützung entstanden und von mir redigiert."
exported: "2026-11-05"
---

# Wir testen nicht mehr alles. Wir testen, was brechen kann.

> Wie wir die Teststrategie für zwei iOS-Apps neu aufgesetzt haben, mit KI-Agenten als Entwicklern und ISTQB als gemeinsamer Sprache.

## TL;DR / Zusammenfassung

Über 99 Prozent unserer Testzeit steckten in UI-Tests, und eine kleine Änderung kostete 77 Minuten Testlauf. Jetzt wählen wir Tests nach fachlichen **Risikobereichen** statt nach Dateien, prüfen jedes Kriterium auf der tiefsten möglichen Teststufe und schreiben den Test vor dem Code. Der vollständige Regressionstest bleibt, und zwar vor jedem Upload: **Der Upload ist das Tor.** Ziel sind 15 Minuten Testlauf pro Story statt über einer Stunde.


Bei neckarshore.ai entwickeln wir zwei iOS-Apps: Kaze, eine App für digitale Selbstbeschränkung, und MuscleCat, ein Trainingstagebuch fürs Fitnessstudio. Gebaut werden beide überwiegend von KI-Agenten. Tests sind für uns deshalb kein Nebenthema. Sie sind das Sicherheitsnetz, das zwischen einem Agenten und dem Kunden steht.

Vor ein paar Tagen haben wir gemessen, wie gut dieses Netz arbeitet. Das Ergebnis war unbequem.

## Was wir gemessen haben

Über 99 Prozent unserer Testzeit steckten in UI-Tests. Die rund 1.700 Komponententests beider Apps laufen zusammen in unter einer Minute. Die UI-Tests dagegen brauchen 53 bzw. 85 Minuten für einen vollständigen Lauf, und die Suiten hatten sich in vier Wochen verdoppelt bis vervierfacht.

Jede neue Story brachte neue UI-Tests mit. Aus jedem davon wurde ein dauerhafter Regressionstest, und jeder Pull Request bezahlte die ganze Suite. Unser sogenannter Teillauf, der eigentlich nur die betroffenen Tests ausführen sollte, dauerte bei einer kleinen Änderung 77 Minuten. Für einen Refactor von 0,3 Prozent des Codes wählte er 55 von 56 UI-Klassen aus.

Der Grund war die Körnung. Die Auswahl ordnete Dateien den Tests zu. Zusammen regrediert aber selten eine Datei, sondern ein fachlicher Bereich. Dateien wie das Theme oder die Hauptansicht berühren jeden Bildschirm, also lief am Ende fast immer alles.

Eine zweite Zahl hat uns noch mehr beschäftigt. Von 39 Fehlern, die in MuscleCat durchgerutscht waren, fand kein einziger ein UI-Test. 19 davon fand der Founder selbst, am Gerät. Fairerweise zeigt diese Zahl nur, was durchgerutscht ist; was ein Test im Pull Request abgefangen hat, wird nie ein Ticket. Die Richtung war trotzdem klar.

## Was wir geändert haben

Erstens: Risikobereiche statt Dateien. Jede App hat jetzt ein Register mit rund acht fachlichen Bereichen, etwa Datenintegrität, Training erfassen, Kauf oder Sperre. Jeder Bereich trägt eine Risikostufe und zwei Gruppen von Tests: wenige kritische Abläufe und den Rest im Detail. Ändert sich das Dashboard, laufen die Abläufe des Dashboards. Die Stammdatenerfassung bleibt draußen.

Zweitens: jedes Kriterium so tief wie möglich. Rechnungen, Regeln, Sortierungen und Texte prüfen wir im Komponententest, in Millisekunden. Für Layout, Dark Mode und große Schriftgrößen führen wir Snapshot-Tests ein. UI-Tests bleiben für echte Abläufe und für das, was nur das Betriebssystem zeigen kann.

Drittens: Test zuerst. Für jedes Abnahmekriterium entsteht der Test vor dem Code, und er muss auf dem alten Code rot sein. Ein Build-Fehler zählt dabei nicht, denn ein Test, der nicht kompiliert, sagt nichts über Verhalten.

Viertens: Der Mensch erkundet. Am Gerät prüft der Founder nur noch, was wirklich ein Gerät braucht: Haptik, echtes Verhalten im Hintergrund, Käufe. Den Rest seiner Zeit nutzt er für explorative Tests mit einem klaren Auftrag, denn dort findet er die meisten Fehler.

### Risikoregister und Teststufen-Regel für Kaze und MuscleCat

**Risikoregister je App**

| MuscleCat | Stufe |
| --- | --- |
| **Datenintegrität** · Backup, Migration, Katalog, Seeds | TM1 |
| **Training erfassen** · Sätze, Pausentimer, Trainingsende | TM1 |
| **Kauf und Berechtigung** · Paywall, Gratismonat | TM1 |
| **Nutzungszählung und Einwilligung** | TM1 |
| **Verlauf und Statistik** · Verknüpfung per UUID | TM2 |
| **Pläne, Stammdaten** | TM2 |
| **Navigation, Onboarding, Einstellungen** | TM2 |
| **Texte, Layout, Erscheinungsbild** | TM3 |

| Kaze | Stufe |
| --- | --- |
| **Sperre** · Shield startet und endet pünktlich | TM1 |
| **Notfallcode** · Relay-Mail, Entsperren | TM1 |
| **Strict-Mode-Asymmetrie** | TM1 |
| **Kauf und Abo** · Paywall, Ask to Buy | TM1 |
| **Erststart und Setup** · keine Sperre ohne Ausweg | TM1 |
| **Layout** · große Textgrößen, iPhone SE | TM2 |
| **Texte, Farben, Splash** | TM3 |

**Wer den Bereich einer Änderung bestimmt:** mechanisch aus den geänderten Pfaden, vereinigt mit Wendys Bereichs-Label am Ticket. Nie die Selbstangabe des Autors. Die Risikostufe ergibt sich qualitativ per Matrix aus Schadensausmaß (Wendys Ranking) und Eintrittswahrscheinlichkeit (Bug-Ledger, Änderungshäufigkeit). Jeder Bereich hat eine **Journey-Stufe** (1 bis 3 Abläufe) und eine **Detailstufe**.

**Teststufen-Regel: jedes Kriterium so tief wie möglich** (oben zuerst)

1. **Benutzerabnahmetest am Gerät**: Gefühl, Haptik, echtes Suspendieren, Kauf, Relay-Mail
2. **UI-Journey (XCUITest)**: eine Journey je Bereich, OS-Integration, a11y-Audit
3. **Snapshot-Test** (neu): Layout, Dark Mode, Dynamic Type, kleine Displays
4. **Komponentenintegrationstest**: Daten, Persistenz, Migration, Backup, Upgrade-Test
5. **Komponententest**: Rechnung, Regel, Zustand, Sortierung, Texte

unten: Millisekunden, maschinell · oben: Minuten bis Stunden, Mensch

_Startbelegung aus Wendys Impact-Ranking und dem Bug-Ledger seit 27.08.2026 · Kaze Erststart TM1 nach Wendy, 27.10. · MuscleCat Nutzungszählung und Einwilligung TM1 nach Wendy, 27.10._

## Der Upload ist das Tor

Die wichtigste Entscheidung war eine Risikoentscheidung. Eine Regression darf auf den Hauptzweig gelangen, solange sie vor dem nächsten Upload gefunden wird. Den vollständigen Regressionstest gibt es weiterhin, nur läuft er dort, wo ein Fehler den Kunden erreichen würde. Der Testlauf pro Story schrumpft dafür von über einer Stunde auf unser Ziel von 15 Minuten.

Die Restrisiken haben wir ausdrücklich aufgeschrieben, statt sie wegzulassen. Bis die Snapshot-Tests stehen, prüfen wir Layout-Änderungen erst vor dem Upload. Die Messung ist gleich mit eingebaut: Jeder Fehler, den eine spätere Stufe findet, bekommt die Stufe zugeordnet, die ihn hätte finden müssen.

### Welcher Testlauf wann läuft

| # | Testlauf | Inhalt | Auslöser | Bestanden, wenn |
| --- | --- | --- | --- | --- |
| 1 | **Komponententest-Lauf** | alle Unit- und Integrationstests, StoreKit, statische Wächter, ab Phase 2 Snapshots | jeder Push auf einen PR, CI auf der M5 | Zahlen aus xcresult, 0 fehlgeschlagen, jedes Bundle hat Tests ausgeführt |
| 2 | **Story-Testlauf** | Abnahmetests der Story, selektiver Regressionstest (Journeys der betroffenen Bereiche), Smoke-Test | PR-Head reviewreif; inerte oder TM3-Nachbesserungen nutzen das Ergebnis je Tree weiter | bestanden |
| 3 | **Vollständiger Regressionstest** | alle UI-Klassen, Journey- und Detailstufe | vor jedem Upload (Archive-Guard). Volle Pässe alle 2,6 Tage (MuscleCat) bzw. 3,1 Tage (Kaze) | bestanden; rot: rote Klassen den Bereichen der gemergten PRs zuordnen |
| 4 | **Benutzerabnahmetest** | nur Gerätekriterien plus explorative Testsitzung mit Test-Charta je TM1-Bereich | je TestFlight-Build | Founder-Urteil je Ticket |
| 5 | **Fehlernachtest** | genau der fehlgeschlagene Test oder Schritt | nach einem Fix | bestanden |

## Eine gemeinsame Sprache

Bei uns arbeiten Menschen und mehrere KI-Agenten an denselben Tickets. Hausbegriffe wie „Rule B“ oder „Progressionstest“ mussten jedes Mal erklärt werden. Deshalb haben wir unser Vokabular gegen das offizielle ISTQB-Glossar geprüft und angeglichen. Aus „Rule B“ wird der Story-Testlauf, aus der Geräteabnahme ein Benutzerabnahmetest mit Test-Charta. „Progressionstest“ steht im Glossar übrigens gar nicht.

### Unser Vokabular nach ISTQB-Glossar v4.8.1

Geprüft gegen das offizielle ISTQB-Glossar v4.8.1 (API, 1129 Begriffe). Umbenannt wird nur vorwärts: neue Texte, Skripte beim nächsten Anfassen, Tickets ab jetzt. „Progressionstest“ und „Flaky Test“ stehen nicht im Glossar.

| Bisher im Haus | Jetzt |
| --- | --- |
| Rule B, Teillauf, partial run | **Story-Testlauf** (Hausbegriff): Abnahmetests der Story, selektiver Regressionstest, Smoke-Test |
| Volllauf, Nachtlauf | **vollständiger Regressionstest**; „nachts“ oder „vor Upload“ sind Auslöser im Testausführungsplan |
| CI-Lauf, Unit-Lauf | **Komponententest**, **Komponentenintegrationstest** |
| Progressionstest, Geräteabnahme | **Benutzerabnahmetest** und **explorativer Test** mit **Test-Charta** |
| Story-Tests des Builders | **Abnahmetests** aus abnahmetestgetriebener Entwicklung |
| grün | **bestanden**; für den Release **Endekriterien erfüllt** |
| Kritikalitäts-Tier | **Risikostufe**; TM1 bis TM3 bleiben als Kürzel |
| „Test Charter“ (Org-Dokument) | **Testrichtlinie** und Teststrategie. Die ISTQB-Test-Charta leitet eine einzelne Testsitzung |

| Bleibt oder neu | Bedeutung |
| --- | --- |
| **Fehlernachtest** | bleibt: Bestätigung nach einer Fehlerbehebung |
| **Testablauf** | bleibt: Testfälle in Ausführungsreihenfolge |
| **Verfälschungsprobe** | bleibt Hausbegriff; Fehlereinpflanzung meint im Glossar etwas anderes |
| **Flaky Test** | Branchenbegriff, kein ISTQB-Eintrag |
| **Fehlerfindungsanteil** (neu) | Fehler einer Teststufe im Verhältnis zu allen später gefundenen |
| **Performanztest** (neu) | nicht-funktionaler Test: Startzeit, Speicher |
| **Abwärtskompatibilität** (neu) | die App läuft auf früheren Plattformversionen |
| **Upgrade-Test** (neu) | Hausbegriff: Wartungstest plus Installierbarkeit |

**Hausbegriffe, ausdrücklich kein ISTQB:** Story-Testlauf, Journey-Stufe, Detailstufe, Story, Upgrade-Test. Jeder setzt sich aus ISTQB-Begriffen zusammen.

_Quellen: ISTQB-Glossar v4.8.1 und CTFL-Lehrplan v4.0.1 · Apple WWDC21-10296, WWDC22-110361, WWDC24-10179, WWDC25-344 · Elbaum, Rothermel, Penix (FSE 2014) · Meta Predictive Test Selection · Google TAP · pointfreeco swift-snapshot-testing · Anthropic Claude Code Best Practices · eigene Messung an musclecat @1d0c254 und kaze @6edbc94_

## Was wir mitnehmen

Die Zahl der Tests sagt wenig über die Qualität einer Teststrategie. Unsere Pyramide sah nach Anzahl gesund aus und stand nach Laufzeit auf dem Kopf. Erst die Messung hat das gezeigt.

Wie handhabt ihr Regressionstests bei mobilen Apps? Läuft bei euch jeder Pull Request gegen die ganze Suite, oder wählt ihr aus?

## Weiterführend

- [Author fast and reliable tests for Xcode Cloud – Apple, WWDC22](https://developer.apple.com/videos/play/wwdc2022/110361/)
- [Certified Tester Foundation Level (CTFL) v4.0 – ISTQB](https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/)
- [Diagnose unreliable code with test repetitions – Apple, WWDC21](https://developer.apple.com/videos/play/wwdc2021/10296/)
- [ISTQB Glossary – ISTQB](https://glossary.istqb.org/)
- [Meet Swift Testing – Apple, WWDC24](https://developer.apple.com/videos/play/wwdc2024/10179/)
- [Predictive test selection – Engineering at Meta](https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/)
- [Record, replay, and review: UI automation with Xcode – Apple, WWDC25](https://developer.apple.com/videos/play/wwdc2025/344/)
- [swift-snapshot-testing – Point-Free, GitHub](https://github.com/pointfreeco/swift-snapshot-testing)
- [Taming Google-Scale Continuous Testing – Google Research](https://research.google/pubs/taming-google-scale-continuous-testing/)
- [Techniques for improving regression testing in continuous integration development environments – Elbaum, Rothermel, Penix, FSE 2014](https://doi.org/10.1145/2635868.2635910)