Testabdeckung: wie viel Testen ist wirklich genug?

Was sagt eine Zeilenabdeckung von 80 Prozent wirklich aus?

Zeilenabdeckung misst, welcher Anteil des Programmcodes beim Testlauf durchlaufen wurde. Sie misst nicht, ob dabei irgendetwas geprüft wurde. Ein Test, der eine Funktion aufruft und das Ergebnis ignoriert, hebt die Prozentzahl genauso wie einer, der drei Sonderfälle sauber absichert.

Deshalb ist eine Vorgabe wie „mindestens 80 Prozent“ ein schwaches Steuerungsinstrument. Sie erzeugt vor allem Tests dort, wo sie leicht zu schreiben sind — bei Hilfsfunktionen und Datenklassen — und selten dort, wo das Geschäft weh tut.

Nützlicher ist die umgekehrte Frage: Welche Abläufe dürfen unter keinen Umständen falsch laufen, und sind genau die abgesichert? Eine Anwendung mit 45 Prozent Abdeckung, bei der Preisberechnung und Rechtevergabe lückenlos geprüft sind, ist belastbarer als eine mit 90 Prozent, bei der beides nur beiläufig vorkommt.

Als Trendwert taugt die Zahl trotzdem: Sinkt die Abdeckung über mehrere Monate, wächst der ungeprüfte Anteil schneller als der geprüfte. Das ist ein Signal, kein Ziel.

Aussagekräftiger als der Gesamtwert ist die Abdeckung derjenigen Dateien, die zuletzt geändert wurden. Neuer Code ohne Absicherung ist ein Risiko von morgen; alter Code ohne Absicherung, der seit drei Jahren unverändert läuft, ist meist keines. Wer nur eine einzige Zahl beobachten will, nimmt diese.

Wie ist die Testpyramide aufgebaut?

Die Testpyramide ordnet drei Stufen nach Anzahl und Kosten: unten viele schnelle Prüfungen, oben wenige langsame.

• Unit-Tests prüfen einzelne Funktionen isoliert. Sie laufen in Millisekunden, sind billig zu schreiben und zeigen genau, welche Stelle bricht.
• Integrationstests prüfen das Zusammenspiel mehrerer Teile, etwa Anwendung und Datenbank oder Anwendung und Fremdschnittstelle.
• End-to-End-Tests bedienen die fertige Anwendung wie ein Mensch, vom Anmelden bis zum abgeschlossenen Vorgang.

Je höher die Stufe, desto realistischer das Ergebnis und desto teurer der Unterhalt. Ein End-to-End-Test bricht schon, wenn sich eine Beschriftung ändert. Dort gehören deshalb nur die wenigen Abläufe hinein, deren Ausfall das Geschäft anhält — bei einer Lernplattform etwa Anmeldung, Kursbuchung und Zeugnisausgabe.

Die häufigste Fehlform ist die umgedrehte Pyramide: kaum Unit-Tests, dafür Dutzende langsamer Oberflächentests. Der Testlauf dauert dann eine halbe Stunde, niemand startet ihn freiwillig, und Fehler zeigen sich erst spät.

Die mittlere Stufe wird dabei am häufigsten unterschätzt. Genau dort brechen Anwendungen im Alltag: an einer Fremdschnittstelle, die einen leicht abweichenden Zeitstempel liefert, an einer Datenbankabfrage, die bei fünfzigtausend Datensätzen anders reagiert als bei fünfzig, an einer Dateiablage, die zeitweise nicht antwortet. Diese Fälle findet weder ein isolierter Unit-Test noch ein Klick durch die Oberfläche.

Welche Bereiche sichern Sie zuerst ab, wenn die Zeit knapp ist?

Sortieren Sie nach Schadenshöhe, nicht nach Nutzungshäufigkeit. Vier Bereiche stehen fast immer oben:

• Geldflüsse: Preise, Rabatte, Steuersätze, Zahlungsstatus, Gutschriften.
• Berechtigungen: Wer darf welche Daten sehen, ändern und ausleiten?
• Datenverlust: Löschvorgänge, Überschreiben, Importe, Sicherungen.
• Gesetzliche Pflichten: Aufzeichnungen, Nachweise, Protokollierung, dokumentierte Freigaben.

Ein Hersteller von Medizintechnik führt die vierte Gruppe zwangsläufig an erster Stelle, weil regulatorische Nachweise Teil der Zulassung sind. Ein Onlinehändler beginnt bei den Geldflüssen. Die Reihenfolge ergibt sich aus dem Geschäft, nicht aus dem Code.

Alles darunter — Sortierungen, Filter, Darstellungsdetails — darf bei begrenztem Budget ungetestet bleiben. Ein falsch sortiertes Listenfeld ärgert, eine falsch berechnete Gutschrift kostet.

Führen Sie diese Einordnung als kurze Liste, nicht im Kopf. Eine Tabelle mit den fünfzehn wichtigsten Abläufen, je einer Einschätzung des Schadens und einem Vermerk, ob und wie sie abgesichert sind, ist in zwei Stunden erstellt. Sie beantwortet die Frage nach dem richtigen Testumfang besser als jedes Werkzeug und lässt sich einem Aufsichtsgremium in fünf Minuten erklären.

Warum gehört zu jedem gemeldeten Fehler ein eigener Test?

Ein Fehler, der einmal aufgetreten ist, kann wiederkommen — besonders in Bereichen, die häufig geändert werden. Der Regressionstest hält den behobenen Zustand fest: Er schlägt fehl, solange der Fehler existiert, und danach nie wieder unbemerkt.

Die Reihenfolge lohnt sich einzuhalten: erst den Test schreiben, der den Fehler reproduziert, dann beheben. Wer umgekehrt vorgeht, weiß nicht sicher, ob der Test die richtige Ursache trifft.

Über die Zeit entsteht so eine Sammlung, die genau die Schwachstellen Ihres Systems beschreibt. Sie ist wertvoller als jede allgemeine Abdeckungsstatistik, weil sie aus echten Vorfällen stammt.

Unzuverlässige Tests beschädigen das Vertrauen

Tests, die mal durchlaufen und mal nicht, ohne dass sich der Code geändert hätte, heißen flaky. Ursachen sind meist Zeitabhängigkeiten, gemeinsam genutzte Testdaten oder Wartezeiten auf fremde Dienste. Ihr eigentlicher Schaden ist sozial: Sobald ein Team gelernt hat, rote Ergebnisse zu ignorieren, ignoriert es auch die echten. Behandeln Sie einen unzuverlässigen Test wie einen Fehler — reparieren oder entfernen, nicht dulden.

Woher kommen Testdaten, ohne dass echte Personendaten im Umlauf sind?

Drei Wege sind gängig und schließen sich nicht aus: erfundene Datensätze, verfremdete Kopien aus der Produktion und synthetische Massendaten für Lasttests.

• Erfundene Daten sind sauber, decken aber die schrägen Fälle der Realität nicht ab.
• Verfremdete Produktionskopien treffen die Realität, brauchen aber ein verlässliches Verfahren zum Ersetzen von Namen, Adressen, Kontaktdaten und Kennnummern.
• Synthetische Massendaten prüfen das Verhalten unter Last, sagen aber wenig über fachliche Richtigkeit.

Für die Anonymisierung gilt: ersetzen, nicht verkürzen. Ein auf drei Zeichen gekürzter Nachname bleibt in kleinen Beständen zuordenbar. Bewahren Sie stattdessen Struktur und Verteilung, tauschen Sie aber die Inhalte aus.

Bei einer Bildungseinrichtung mit Schülerdaten haben wir die Testumgebung vollständig auf ersetzte Datensätze umgestellt und den Zugriff auf die Produktivdatenbank auf zwei Personen begrenzt. Der Aufwand lag bei wenigen Tagen und hat eine ganze Klasse von Diskussionen beendet.

Was muss der Fachbereich trotzdem selbst prüfen?

Automatisierte Tests prüfen, ob die Anwendung tut, was jemand aufgeschrieben hat. Ob das Aufgeschriebene fachlich richtig war, prüfen sie nicht. Dafür braucht es Menschen aus dem Fachbereich, die den Ablauf an echten Vorgängen durchspielen.

Halten Sie diese Abnahme knapp und strukturiert: eine Liste konkreter Vorgänge, je Vorgang ein erwartetes Ergebnis, ein Termin, eine benannte Person. Freies Ausprobieren ohne Leitfaden produziert Meinungen statt Befunde.

Reservieren Sie dafür echte Arbeitszeit. Eine Abnahme, die jemand zwischen zwei Terminen erledigen soll, findet entweder nicht statt oder besteht aus einem hastigen Nicken. Ein halber Tag mit zwei Personen und einer vorbereiteten Vorgangsliste bringt mehr als drei Wochen unverbindlicher Zugriff auf eine Vorschauumgebung.

• Wählen Sie Vorgänge aus dem echten Tagesgeschäft, inklusive der unbeliebten Sonderfälle.
• Lassen Sie zwei Personen unabhängig prüfen, wenn ein Bereich strittig ist.
• Trennen Sie Fehler von Änderungswünschen — beides landet sonst im selben Topf und blockiert die Freigabe.
• Planen Sie eine zweite Runde nach der Korrektur fest ein, nicht als Option.

Wie viel Testaufwand sollten Sie im Angebot verlangen?

Fordern Sie, dass Testaufwand als eigene Position erscheint statt als unsichtbarer Bestandteil der Entwicklung. Üblich sind 15 bis 30 Prozent des Entwicklungsaufwands, je nach Risikoprofil. Bei einer Anwendung im mittleren Bereich individueller Software — sagen wir 60.000 € — reden Sie also über etwa 9.000 bis 18.000 € für Absicherung.

Ein Angebot ohne diese Position ist selten günstiger. Es verschiebt den Aufwand nur hinter die Übergabe, wo er als Fehlerbehebung, Nacharbeit und Ausfallzeit anfällt — dann allerdings ungeplant und zum ungünstigsten Zeitpunkt.

• Verlangen Sie eine Aussage, welche Bereiche automatisiert abgesichert werden und welche bewusst nicht.
• Lassen Sie sich zeigen, wie lange der Testlauf dauert und wann er startet — üblicherweise bei jeder Änderung in der Auslieferungsstrecke.
• Bestehen Sie auf einem Regressionstest zu jedem gemeldeten Fehler, auch während der Gewährleistung.
• Fragen Sie nach dem Umgang mit unzuverlässigen Tests, bevor der erste auftritt.

Was Sie nicht fordern sollten, ist eine feste Prozentzahl bei der Abdeckung. Sie bekommen sie — und bezahlen für Tests, die niemandem nützen.

Testen kostet Geld. Nicht zu testen kostet auch Geld, nur zu einem Zeitpunkt, den Sie nicht bestimmen.