Der Kunde ist eine Online-Bildungsplattform mit interaktiven Unterrichtsstunden, Hausaufgaben, Konten für Schüler und Eltern sowie Online-Zahlung. Das Geschäft ist stark saisonabhängig: Im September beginnen die meisten neuen Schüler, und ein Plattformausfall in den ersten Schulwochen bedeutet, Kunden dauerhaft zu verlieren. Ein internes QA-Team gab es nicht; die Entwickler testeten zwischen ihren Aufgaben. Die Regressionstests vor einem Release dauerten drei Tage und übersahen dennoch kritische Abläufe wie Zahlung, Unterrichtsbuchung und den Zugang zum Kursraum. Der Kunde meldete sich nach einem weiteren Vorfall: Ein Zahlungsfehler hatte einen Teil der im Sommer gewonnenen Anfragen gekostet.
Einen Qualitätssicherungsprozess von Grund auf aufbauen:
eine Teststrategie nach Geschäftsrisiken, Automatisierung zentraler Szenarien, Integration der Prüfungen in CI und Lasttests vor dem Septemberhoch. Einschränkung: Die Entwicklung durfte nicht pausieren; Releases liefen weiterhin wöchentlich, und auf September konnte niemand warten.
Wir begannen nicht mit automatisierten Tests, sondern mit einer Risikoanalyse: Welche Abläufe brechen am häufigsten, und wo kostet ein Fehler am meisten? Die Automatisierung folgte genau dieser Prioritätenliste.
- Wir prüften die Qualität: Analyse der Fehler der vergangenen sechs Monate, Gespräche mit den Teams und eine Übersicht der kritischsten Abläufe – Zahlungen, Unterrichtsbuchungen, Zugang zum Kursraum und Elternbenachrichtigungen.
- Wir verfassten eine Teststrategie: Teststufen, Verantwortungsbereiche, Definition of Done für Funktionen und Regeln für Fehlerberichte, einheitlich für die drei Entwicklungsteams.
- Wir automatisierten den kritischen Ablauf: E2E-Szenarien mit Playwright für die Webplattform, API-Tests fürs Backend und eine Smoke-Testsuite vor jedem Release.
- Wir integrierten QA-Sperren in CI: Ohne erfolgreiche Smoke-Tests ist kein Release möglich; die vollständige Regression läuft jede Nacht, und die Ergebnisse sind für alle Teams in GitLab sichtbar.
- Wir führten Lasttests mit k6 durch: Wir simulierten den September-Spitzenverkehr, fanden Engpässe und beseitigten sie gemeinsam mit dem Backend-Team vor Saisonbeginn.
- Wir übergaben den Prozess an den Kunden: mit Dokumentation, Regeln und Schulung des QA-Engineers für die Arbeit mit automatisierten Tests und der Pipeline.
Entscheidend war die Priorisierung nach Geschäftsrisiko, nicht nach einer möglichst beeindruckenden Abdeckung. Wir strebten bewusst keine hundertprozentige Automatisierung an: 75% Abdeckung der kritischen Szenarien lieferten den größten Teil des Nutzens, weil sie genau die Abläufe schützten, mit denen die Plattform Kunden gewinnt und verliert. Die übrigen Bereiche werden vor wichtigen Releases durch manuelle explorative Tests geprüft.
Der wichtigste wirtschaftliche Effekt war, Fehler früher zu finden: Ein von einem CI-Autotest entdeckter Fehler kostet ein Vielfaches weniger als ein Fehler, den Eltern in der Produktionsplattform entdecken. Die Plattform ging mit Sicherheitsreserven in die Saison, und die Teams konnten Änderungen häufiger veröffentlichen, ohne den „Freitagseffekt“ zu fürchten. Ein zusätzlicher Vorteil war das Vertrauen des Geschäfts: Der Vertrieb kann Partnerschulen jetzt ehrlich eine stabile Plattform während der Anmeldehochsaison zusichern.
| Kennzahl | Ergebnis |
|---|---|
| Kritische Fehler in der Produktion | 5–7 pro Monat → 1–2 pro Quartal |
| Regression vor einem Release | 3 Tage manuell → 4 Stunden mit automatisierten Tests |
| September-Spitzenlast | Jährliche Vorfälle → 0 Vorfälle, ohne Leistungseinbußen |
| Zeitpunkt der Fehlererkennung | Meist in der Produktion → Autotests erkennen sie vor dem Release |
Die Kennzahlen wurden aus den ursprünglichen Fallstudienmaterialien übernommen. Der Zeitraum ist angegeben, sofern er in der Quelle festgehalten wurde.
- kritische Fehler pro Quartal (zuvor 5–7 pro Monat)
- 1–2
- Regression mit automatisierten Tests (zuvor 3 Tage manuell)
- 4 Std.
- der zentralen Szenarien sind durch automatisierte Tests abgedeckt
- 75%
- Vorfälle während der September-Spitze
- 0
Veranschaulichende Skala: 3 Tage werden in 72 Stunden umgerechnet. Für die Balkenlängen wird die monatliche Fehlerspanne mit drei multipliziert, um sie auf ein Quartal hochzurechnen; verglichen werden die oberen Grenzen.
- 01Commit
- 02Smoke-Testsuiteohne grünes Ergebnis kein Release
- 03Releasewöchentlich
- 04Jede Nachtvollständige Regression
Diese nächsten Schritte empfehlen wir der Plattform:
- Visuelle Regressionstests – automatische Prüfung des Layouts von Unterrichtsstunden, E-Mails und Benutzerkonten.
- Eine Testdatenfabrik zur Erzeugung realistischer Schüler, Gruppen und Zahlungen für jeden Testlauf.
- QA im Produktivbetrieb – Feature Flags und Canary-Releases, um neue Funktionen schrittweise zu aktivieren.
Wir haben aufgehört, Releases zu fürchten. Früher konnte jeder Freitag in einer Auswertung von Beschwerden enden; heute ist ein Produktionsrelease ein Routinevorgang von fünfzehn Minuten.
— CTO der Online-Schule