Testautomatisierung in Legacy-Systemen

Inhaltsverzeichnis

Aus modernen Softwareentwicklungsprojekten sind automatische Tests nicht wegzudenken. Was jedoch ist mit Altsystemen, die keine Tests enthalten, aber weiterentwickelt werden sollen? Ohne automatische Tests ist Refactoring hochgefährlich – ohne Refactoring ist der Code kaum testbar. Am Beispiel eines Legacy-Projekts wird gezeigt, wie sich sukzessive Testbarkeit erreichen lässt.

Automatische Tests haben ihren Exotenstatus verloren. Agile Verfahren wie eXtreme Programming oder Scrum sind ohne Testautomatisierung nicht durchführbar. Aber auch im klassischen Projektmanagement sind Regressionstests angekommen. Wieso eigentlich?

Testautomatisierung: mehr Ackergaul als Ponyhof

Die Einführung automatischer Tests ruft bei Entwicklungsteams nicht unbedingt Begeisterungsstürme hervor. Tests zu schreiben erleben sie zunächst oft als Ballast. Die Entwicklung dauert länger. Für ein neues Feature in der Software gibt es Anerkennung – Tests halten jedoch dabei auf. Auch für das Management ist die Automatisierung von Tests zunächst einmal ein Kostenpunkt.

Doch das Blatt wendet sich beim Betrachten der Alternative: manuelle Tests. Bei einer klassischen Projektdurchführung folgt nach der Implementierung und vor der Inbetriebnahme die (manuelle) Testphase.

Wenn kein Wunder geschieht, werden in der Testphase Fehler in der Software gefunden. Also zurück in die Entwicklung: Die Bugs werden gefixt. Dann folgt ein erneuter Test. Doch was genau wird nun getestet? Nur der Fehlerfall? Und was ist, wenn bei der Beseitigung des einen Bugs ein neuer Fehler an anderer Stelle eingebaut wurde? Oder wenn der Fehler ein Problem aufgedeckt hat, das einen größeren Umbau der Software erforderlich macht? Im Prinzip wäre nach jedem Fix und jeder Änderung die gesamte Software vollständig zu testen. Das dauert lange und ist kaum leistbar – jedenfalls für Menschen.

Computer hingegen lieben stumpfsinnige Wiederholungen und führen die immer gleichen Tests jeden Tag klaglos und pedantisch aus. Programmierte Regressionstests stellen sicher, dass die Software nach einer Änderung noch so funktioniert wie zuvor definiert (also keine "Regression" stattgefunden hat). Wenn eine Software durch automatische Regressionstests abgedeckt ist, hat das enorme Vorteile:

• Nebeneffekte einer Änderung werden sofort aufgedeckt. Es kann nicht mehr geschehen, dass die Bug-Beseitigung an der einen Stelle unbemerkt einen neuen Fehler an anderer Stelle zur Folge hat.
• Diese Sicherheit ermöglicht bei Bedarf auch tiefgreifende Änderungen an der Software, die man sonst kaum wagen könnte. Grundlegende Refactorings, zum Beispiel zur Performanceoptimierung, stellen kein unkalkulierbares Risiko mehr dar.
• Die Möglichkeit, die Software zu refaktorieren, verbessert wiederum die Codequalität. Die Aussage "Der Code ist schlecht, aber den können wir jetzt nicht mehr ändern" gehört der Vergangenheit an.
• Automatische Tests sind schnell – viel schneller als manuelle Tester. Das Feedback auf eine Änderung erfolgt also prompt. Entwickler erhalten Minuten nach dem Einchecken ihres Codes die Information, ob sie etwas zerstört haben – und nicht erst Tage später wie beim manuellen Test.

Entwicklungsteams, die die Vorteile automatischer Tests eine Weile erlebt haben, wollen im Allgemeinen darauf nicht mehr verzichten. Bei agilen Projekten mit ihren häufigen Releases sind automatische Tests ohnehin unverzichtbar. Das Schreiben von Tests ist nach wie vor Arbeit und kein Ponyhof – aber der Ackergaul Regressionstest wird für seine Unermüdlichkeit und Zuverlässigkeit geschätzt.