Testautomatisierung: der Nachweis, dass der Bestand weiter funktioniert

Testautomatisierung bezeichnet Prüfungen, die ein Programm ohne menschliches Zutun ausführt und deren Ergebnis eindeutig ist: bestanden oder nicht. In einem System, das seit Jahren arbeitet, hat sie eine bestimmte Aufgabe. Sie hält fest, was der Bestand heute leistet, damit ein Ausbau nicht unbemerkt etwas anderes daraus macht.

Testautomatisierung: was automatisierte Prüfungen leisten

Ein automatischer Test beschreibt einen Fall, führt ihn aus und vergleicht das Ergebnis mit einer Erwartung. Läuft er bei jeder Änderung mit, wird aus einer Sammlung solcher Fälle ein Warnsystem: Es meldet nicht, dass Code schön ist, sondern dass eine Änderung etwas verschoben hat, was vorher anders war.

Der Wert steigt mit der Häufigkeit der Ausführung. Ein Test, den jemand von Hand anstößt, wenn er daran denkt, entdeckt Abweichungen zufällig. Dieselbe Prüfung, an jeden Stand des Codes gebunden, entdeckt sie an dem Tag, an dem sie entsteht — und zu diesem Zeitpunkt weiß noch jemand, was er geändert hat.

Davon zu unterscheiden ist die manuelle Prüfung durch die Fachabteilung. Sie beurteilt, ob eine Funktion fachlich richtig ist; die Maschine beurteilt, ob sie sich gegenüber gestern verändert hat. Beides ist nötig, und keines ersetzt das andere.

Die Ebenen: Einheit, Zusammenspiel, Oberfläche

Üblich sind drei Ebenen, die sich in Reichweite und Preis unterscheiden:

• Einheitstests prüfen eine einzelne Berechnung oder Regel ohne Datenbank und ohne Netz. Sie laufen in Sekunden und zeigen genau, welche Stelle nicht mehr stimmt.
• Zusammenspieltests prüfen mehrere Bausteine gemeinsam, meist mit Datenbank und angebundenen Diensten. Sie finden Fehler an den Nahtstellen, dort, wo in gewachsenen Systemen die meisten Störungen sitzen.
• Oberflächentests bedienen die Anwendung wie ein Anwender. Sie sind die teuersten in Pflege und Laufzeit, decken dafür einen ganzen Ablauf ab und eignen sich für die wenigen Wege, an denen das Tagesgeschäft hängt.

Die Mischung entscheidet über den Nutzen. Wer alles über die Oberfläche prüft, bekommt eine langsame Sammlung, die bei jeder Kleinigkeit rot wird und deshalb bald niemanden mehr interessiert. Wer nur einzelne Berechnungen prüft, übersieht die Nahtstellen, an denen alte Systeme brechen.

Was in geerbtem Code zuerst abgedeckt wird

Unbekannten Code vollständig abzudecken, ist weder bezahlbar noch nötig. Die Reihenfolge ergibt sich aus dem Schaden: Zuerst kommen die Abläufe, deren Ausfall den Betrieb anhält oder Geld bewegt — Preisfindung, Rechnungsstellung, Bestandsführung, Übergaben an fremde Systeme. Danach folgt der Bereich, der ohnehin umgebaut werden soll.

Dort ist die Reihenfolge umgekehrt zur Neuentwicklung: Erst wird das heutige Verhalten in Tests festgehalten, auch wenn es merkwürdig aussieht, dann wird umgebaut. Fällt dabei auf, dass eine alte Regel fachlich falsch ist, wird sie als eigene Änderung behandelt und nicht nebenbei korrigiert. Ohne diese Trennung weiß nach dem Umbau niemand mehr, welche Abweichung Absicht war.

Auch nützlich: Jeder gemeldete Fehler bekommt zuerst einen Test, der ihn zeigt, und danach die Behebung. So wächst die Sammlung entlang der Stellen, die in diesem System tatsächlich brechen, statt entlang einer Quote.

Was Testautomatisierung nicht beweist

Eine grüne Sammlung sagt: Die geprüften Fälle verhalten sich wie beschrieben. Sie sagt nicht, dass die Anwendung fachlich richtig ist, dass die Beschreibung stimmt oder dass die ungeprüften Fälle in Ordnung sind. Eine hohe Abdeckungszahl misst durchlaufene Zeilen, nicht geprüfte Erwartungen — Code lässt sich durchlaufen, ohne dass irgendetwas verglichen wird.

Zwei Lücken sind besonders häufig. Tests laufen auf erfundenen Daten, während im Betrieb Sätze aus vielen Jahren liegen, die keine Annahme mehr erfüllen. Und Verhalten unter Last, Zusammenspiel mit Fremdsystemen oder die Bedienbarkeit tauchen in keiner dieser Prüfungen auf. Die Tests sind deshalb ein Teil der Grundlage für die Abnahme, nicht ihr Ersatz.

Typische Fehler

• Tests nach dem Umbau. Wer erst danach prüft, hält nicht den alten Zustand fest, sondern bestätigt den neuen.
• Wackelkandidaten stehen lassen. Prüfungen, die mal rot und mal grün sind, erziehen ein Team dazu, Rot zu ignorieren. Sie werden repariert oder entfernt.
• Abdeckungsquote als Ziel. Eine Zahl in der Auswertung ersetzt keine Erwartung im Test.
• Prüfungen ohne Beschreibung. Was ein Test sichert, muss aus seinem Namen hervorgehen; sonst wird er beim nächsten Umbau gelöscht statt verstanden. Den fachlichen Bezug liefert die Leistungsbeschreibung.

Wie wir Tests in ein bestehendes Projekt bringen

Wir behandeln Tests als Teil der Lieferung, nicht als Zusatzposten: Zu jeder Etappe der Software-Weiterentwicklung gehören die Prüfungen, die ihr Ergebnis absichern, und der Nachweis, dass die vorhandenen Abläufe unverändert arbeiten. Vor dem ersten Umbau halten wir das heutige Verhalten des betroffenen Bereichs fest, danach läuft die Sammlung bei jeder Änderung automatisch mit. Welche Ebenen ein Vorhaben braucht, legen wir im Angebot fest; den Rahmen dafür beschreibt die Seite Softwareentwicklung.