Wie viel Testen ist genug? Warum Code Coverage nicht die Antwort ist
„Wir haben 90 % Testabdeckung.“ Das klingt zunächst einmal ziemlich gut. Eine hohe Zahl vermittelt Sicherheit und lässt sich hervorragend in Reports, Dashboards und Management-Präsentationen darstellen.
Gleichzeitig bleibt oft offen, was diese Zahl eigentlich aussagt. Ist eine Anwendung mit 90 % Testabdeckung automatisch gut getestet? Sind 70 % zu wenig? Und wie viele automatisierte Tests braucht ein Projekt überhaupt?
Eine einzelne Prozentzahl kann diese Fragen nicht beantworten. Testabdeckung ist ein wertvolles Werkzeug, aber kein Qualitätsziel. Es geht nicht darum, möglichst viel Code zu testen, sondern die relevanten Risiken eines Produkts abzusichern. Dabei spielen für mich vier Bereiche eine zentrale Rolle.
1. Die Testpyramide: Der richtige Mix an Tests
Die Testpyramide ist für mich nach wie vor eine gute Orientierung für eine sinnvolle Teststrategie. Die Grundidee ist einfach: Je höher ein Test in der Pyramide steht, desto größer ist typischerweise sein Scope. Und desto aufwendiger und langsamer ist seine Ausführung.
Am unteren Ende stehen viele schnelle Tests, beispielsweise Unit Tests. Darüber folgen Integrationstests und weitere Tests mit größerem Scope. An der Spitze befinden sich wenige, gezielte End-to-End-Tests. Dabei geht es nicht darum, eine bestimmte Anzahl oder ein festes Verhältnis einzuhalten.
Die Pyramide soll vor allem helfen, Testaufwand und Risiko sinnvoll auszubalancieren. Eine Anwendung mit komplexen Preisberechnungen lässt sich zum Beispiel sehr gut mit vielen schnellen Tests auf niedriger Ebene absichern. Jedes Szenario über die Benutzeroberfläche zu testen, wäre dagegen unnötig langsam. Außerdem ließen sich Fehler schwerer lokalisieren.
Auf der anderen Seite kann ein End-to-End-Test für einen geschäftskritischen Kaufprozess sehr wertvoll sein. Er überprüft, ob mehrere Komponenten gemeinsam tatsächlich funktionieren. Wichtiger als die reine Anzahl ist deshalb die Frage: Auf welcher Testebene lässt sich ein Risiko am effektivsten absichern?
Die Testpyramide ist damit weniger eine mathematische Formel als eine Orientierung für die Teststrategie.
2. Testabdeckung: 90 % sind nicht automatisch besser
Code Coverage ist eine nützliche Metrik. Sie zeigt, welcher Anteil des Codes während der automatisierten Tests tatsächlich durchlaufen wurde. Damit lässt sich erkennen, welche Bereiche möglicherweise gar nicht von Tests erreicht werden.
Das macht Coverage wertvoll. Problematisch wird es allerdings, wenn aus der Metrik ein starres Ziel wird. Etwa nach dem Muster: „Wir müssen mindestens 90 % erreichen.“ Denn Code Coverage beantwortet zunächst nur eine Frage: Welcher Code wurde durch unsere Tests ausgeführt?
Sie beantwortet nicht automatisch, ob dieser Code auch sinnvoll getestet wurde. Stell dir beispielsweise eine Funktion vor, die entscheidet, ob ein Benutzer eine bestimmte Aktion ausführen darf. Ein Test könnte die Funktion ausführen und damit die entsprechende Codezeile abdecken. Trotzdem prüft er vielleicht nur den Happy Path. Ungültige Eingaben, Grenzwerte, fehlende Berechtigungen oder andere Benutzerrollen bleiben dann ungetestet.
Die Code Coverage kann trotzdem sehr hoch sein. Deshalb ist wichtiger, was getestet wird, als wie viel Code die Tests ausführen. Besonders relevant sind zum Beispiel kritische Geschäftsprozesse, sicherheitsrelevante Funktionen und komplexe Berechnungen. Dazu kommen Bereiche, die sich häufig ändern oder in denen oft Fehler auftreten, und Schnittstellen zu anderen Systemen.
Eine Anwendung mit 70 % Coverage kann deshalb unter Umständen besser abgesichert sein als eine Anwendung mit 95 % Coverage. Die Prozentzahl ist nicht nutzlos. Sie ist nur nicht die Antwort auf die Frage, ob ausreichend getestet wurde.
3. Schnelles Feedback: Tests müssen rechtzeitig reagieren
Ein guter automatisierter Test sollte nicht nur korrekt sein. Er sollte auch rechtzeitig Feedback liefern. Denn der Wert eines Tests hängt stark davon ab, wann ein Problem entdeckt wird.
Stell dir vor, ein Entwickler macht eine Änderung und erfährt wenige Minuten später, dass ein wichtiger Prozess kaputt ist. Dann kann er das Problem direkt beheben. Kommt dasselbe Feedback erst Stunden später oder kurz vor dem Release, sieht die Situation ganz anders aus.
Der Fehler muss möglicherweise erst analysiert werden. Andere Änderungen sind inzwischen hinzugekommen. Der Kontext ist nicht mehr präsent. Vielleicht muss sogar ein kompletter Releaseprozess unterbrochen werden. Je später Fehler erkannt werden, desto höher sind meist Aufwand und Kosten für ihre Behebung.
Das bedeutet nicht, dass langsame Tests grundsätzlich schlecht sind. Ein langsamer End-to-End-Test kann sehr wertvoll sein, wenn er ein relevantes Risiko absichert. Problematisch wird es, wenn ein großer Teil der Teststrategie aus langsamen oder instabilen Tests besteht.
Besonders kritisch sind dabei sogenannte Flaky Tests. Das sind Tests, die manchmal erfolgreich sind und manchmal fehlschlagen, obwohl sich am Produkt nichts geändert hat. Auf Dauer verliert das Team dadurch oft das Vertrauen in die Tests. Fehlschläge werden ignoriert, Testreports weggeklickt und rote Builds werden zur Normalität. Damit verliert die Automatisierung einen ihrer wichtigsten Vorteile: vertrauenswürdiges Feedback.
Eine kleinere Anzahl schneller und stabiler Tests kann deshalb wertvoller sein als eine riesige Testsuite. Vor allem, wenn deren Ergebnisse erst spät vorliegen und ständig manuell geprüft werden müssen. Wie Continuous Integration und klare Testregeln dabei helfen, beschreibe ich im Artikel Welche Entwicklungspraktiken sich bewährt haben.
4. Production Feedback: Tests enden nicht beim Release
Auch die besten automatisierten Tests können nicht jede Situation abdecken. Eine Testumgebung bildet die Realität nur begrenzt ab. In der Produktivumgebung gibt es reale Benutzer, reale Daten und reale Last. Dazu kommen Kombinationen von Bedingungen, die in einer Testumgebung vielleicht nie auftreten.
Deshalb endet eine gute Teststrategie nicht mit dem erfolgreichen Deployment. Monitoring, Observability, Canary Releases und Feature Flags können automatisierte Tests sinnvoll ergänzen.
Ein Canary Release stellt eine neue Version zum Beispiel zunächst nur einem kleinen Teil der Benutzer bereit. Über Monitoring und relevante Metriken siehst du, ob sich das Verhalten gegenüber der bisherigen Version verändert. Mit Feature Flags aktivierst du eine Funktion kontrolliert und schaltest sie bei Problemen wieder ab.
Damit entsteht eine weitere Ebene der Qualitätssicherung. Es geht also nicht nur darum, vor dem Release zu testen. Du beobachtest das Verhalten einer Anwendung auch danach aufmerksam.
Das bedeutet nicht, dass Fehler einfach in der Produktivumgebung gefunden werden sollen. Im Gegenteil: Je besser die automatisierten Tests sind, desto weniger Risiken gelangen überhaupt bis zur Produktion. Production Feedback ist eine zusätzliche Sicherheitslinie für die Risiken, die sich vorher nicht vollständig erkennen lassen.
Also: Wie viel Testen ist genug?
Die vielleicht wichtigste Erkenntnis: Es gibt keine universelle Prozentzahl. 90 % Coverage sind nicht automatisch gut. 50 % Coverage sind nicht automatisch schlecht. Und auch die Anzahl der automatisierten Tests sagt allein wenig über die Qualität einer Teststrategie aus.
Die wichtigere Frage lautet: Welche Risiken sind für unser Produkt relevant? Und wie gut erkennen wir sie, bevor sie unsere Kunden treffen? Daraus lassen sich konkrete Entscheidungen ableiten:
- Welche Funktionen sind geschäftskritisch?
- Welche Komponenten ändern sich besonders häufig?
- Wo entstehen die meisten Fehler?
- Welche Fehler hätten die größten Auswirkungen auf Kunden oder Unternehmen?
- Welche Tests liefern schnelles und vertrauenswürdiges Feedback?
- Welche Risiken können wir durch Monitoring, kontrollierte Releases oder Feature Flags zusätzlich absichern?
Aus diesen Antworten entsteht eine sinnvolle Teststrategie, nicht aus einer möglichst hohen Prozentzahl.
Fazit
Testautomatisierung bedeutet nicht, möglichst viele Tests zu schreiben. Eine gute Teststrategie bedeutet auch nicht, eine möglichst hohe Code Coverage zu erreichen. Das Ziel ist, mit dem vorhandenen Testaufwand die relevanten Risiken abzudecken und schnell zuverlässiges Feedback zu bekommen.
Die Testpyramide hilft beim richtigen Mix der Testarten. Code Coverage hilft dabei, blinde Flecken zu erkennen. Schnelle und stabile Tests sorgen für schnelles Feedback. Monitoring, Canary Releases und Feature Flags begrenzen Risiken auch nach dem Deployment. Über die Qualität entscheidet am Ende nicht die Anzahl der Tests. Es zählt, ob wir die richtigen Risiken zur richtigen Zeit absichern.
Mein Vorschlag für den Anfang: Nimm dir die Fragen aus der Liste oben vor. Beantworte sie gemeinsam mit deinem Team für eure drei wichtigsten Abläufe. Das ist eine bessere Grundlage für eure Teststrategie als jede Zielquote. Wie du eine Teststrategie Schritt für Schritt aufbaust, ist auch Teil der Schulung Testautomatisierung für Einsteiger mit Playwright.
