Tests sollen nicht beweisen, dass Software funktioniert, sondern Fehler finden, solange sie billig sind. Ein Fehler im Entwurf kostet Minuten, derselbe Fehler in Produktion kostet Tage.
Testen ist kein Arbeitsschritt am Ende, sondern eine begleitende Tätigkeit. Je später ein Fehler gefunden wird, desto teurer ist seine Behebung, weil mehr darauf aufgebaut wurde. Diese Kostenkurve ist der wirtschaftliche Grund für frühes und automatisiertes Testen.
Black-Box und White-Box
Beim Black-Box-Test wird ausschließlich das nach außen sichtbare Verhalten geprüft. Die interne Umsetzung bleibt unbeachtet, Grundlage sind die Anforderungen. Vorteil: Der Test bleibt gültig, auch wenn der Code umgebaut wird. Nachteil: Bestimmte Sonderfälle im Inneren bleiben womöglich unberührt.
Beim White-Box-Test ist die interne Struktur bekannt, Testfälle werden gezielt so gewählt, dass alle Zweige und Bedingungen durchlaufen werden. Vorteil: hohe Abdeckung auch seltener Pfade. Nachteil: Der Test hängt an der Umsetzung und muss bei jedem Umbau angepasst werden.
In der Praxis werden beide kombiniert. Faustregel: Fachliche Anforderungen als Black-Box prüfen, komplexe Algorithmen zusätzlich als White-Box.
Die Teststufen
- Unit-Tests prüfen einzelne Funktionen isoliert. Sie laufen in Millisekunden und bilden den größten Anteil.
- Integrationstests prüfen das Zusammenspiel mehrerer Bausteine, etwa Anwendung und Datenbank. Langsamer, aber sie finden Fehler an den Schnittstellen, die Unit-Tests systematisch übersehen.
- Ende-zu-Ende-Tests prüfen den kompletten Ablauf aus Nutzersicht. Sie sind am aussagekräftigsten und zugleich am langsamsten und störanfälligsten.
Die übliche Empfehlung ist eine Pyramide: viele Unit-Tests, weniger Integrationstests, wenige Ende-zu-Ende-Tests. Der häufigste Fehler ist die Umkehrung. Eine Testsammlung, die überwiegend aus langsamen Oberflächentests besteht, braucht Stunden, meldet regelmäßig Fehler, die keine sind, und wird deshalb ignoriert.
Manuell oder automatisiert?
Automatisierung lohnt sich bei allem, was oft und gleich abläuft: Regressionstests, Prüfungen über viele Datenkombinationen, Last- und Ausdauertests. Der Aufwand fällt einmal an, der Nutzen bei jedem Lauf.
Manuelles Testen bleibt unverzichtbar, wo Urteilsvermögen gefragt ist: bei der Beurteilung der Bedienbarkeit, beim explorativen Suchen nach unerwartetem Verhalten und bei Funktionen, die sich noch häufig ändern. Ein automatisierter Test für eine Funktion, die nächste Woche umgebaut wird, ist verschwendete Zeit.
Kernaussage: Automatisierte Tests prüfen, ob das Bekannte weiterhin funktioniert. Manuelle, explorative Tests finden das, woran beim Schreiben niemand gedacht hat. Beide Aufgaben lassen sich nicht gegeneinander eintauschen.
Testgetriebene Entwicklung
Bei testgetriebener Entwicklung wird zuerst ein fehlschlagender Test geschrieben, dann der einfachste Code, der ihn erfüllt, und anschließend der Code aufgeräumt, ohne das Verhalten zu ändern. Dieser Zyklus wird in kleinen Schritten wiederholt.
Der Nutzen liegt weniger im Test selbst als im Entwurf: Wer den Test zuerst schreibt, formuliert die Schnittstelle aus Sicht des Aufrufers und bemerkt umständliche Entwürfe früh. Nebeneffekt ist eine Testabdeckung, die entsteht, statt nachgereicht zu werden.
Die Methode passt gut zu klar umrissener Logik und weniger gut zu explorativer Arbeit, bei der das Ziel noch unklar ist.
Über die Abdeckungsquote
Testabdeckung misst, welcher Anteil des Codes bei einem Testlauf ausgeführt wurde. Das ist eine nützliche Kennzahl mit einer wichtigen Einschränkung: Sie misst Ausführung, nicht Prüfung. Ein Test ohne einzige Zusicherung erzeugt Abdeckung und findet nichts.
Sinnvoll ist die Zahl als Suchhilfe: Bereiche mit sehr niedriger Abdeckung sind ein Hinweis auf blinde Flecken. Als Zielvorgabe erzeugt sie dagegen leicht Tests, die nur der Statistik dienen. Deutlich aussagekräftiger ist die Frage, ob ein absichtlich eingebauter Fehler von der Testsammlung bemerkt würde.
Tests in der Pipeline
Ihren Wert entfalten Tests erst, wenn sie automatisch bei jeder Änderung laufen. Die schnellen Prüfungen gehören an den Anfang, damit Rückmeldungen früh kommen, die langsamen dahinter. Ein Test, der gelegentlich ohne Grund fehlschlägt, ist dabei besonders schädlich: Er gewöhnt das Team daran, rote Ergebnisse zu ignorieren. Solche Tests werden repariert oder entfernt, nicht wiederholt. Wie sich das in den Ablauf einfügt, steht im Artikel zu DevOps und CI/CD-Pipelines.
Zu einer vollständigen Prüfstrecke gehören außerdem automatische Sicherheitsprüfungen der Abhängigkeiten. Viele der verbreiteten Test-Werkzeuge sind quelloffen, was Prüfbarkeit und Verbreitung erklärt, siehe Open Source verstehen. Die Grundlagen der verwendeten Sprachen behandelt der Beitrag zu Programmiersprachen für Einsteiger.
Häufige Fragen
Was ist der Unterschied zwischen Black-Box- und White-Box-Test?
Der Black-Box-Test prüft nur das nach außen sichtbare Verhalten anhand der Anforderungen. Der White-Box-Test kennt die interne Struktur und wählt Testfälle so, dass alle Zweige durchlaufen werden.
Wie hoch sollte die Testabdeckung sein?
Eine feste Zielzahl ist wenig hilfreich, weil Abdeckung nur Ausführung misst, nicht Prüfung. Aussagekräftiger ist die Frage, ob ein absichtlich eingebauter Fehler von der Testsammlung bemerkt würde.
Was sollte automatisiert werden und was nicht?
Automatisieren lohnt sich bei allem, was oft und gleich abläuft, etwa Regressionstests. Manuell bleiben Bedienbarkeit, exploratives Testen und Funktionen, die sich noch häufig ändern.