Testautomatisierung von Legacy-Software

Testautomatisierung von Legacy-Software

Teufelskreis Änderungen an Legacy-Software

Besitzen Sie eine langjährig gewachsene Software ohne automatische Tests?
Die aber weiterentwickelt werden soll?
Dann kennen Sie vermutlich diesen Teufelskreis:

Lösungsmöglichkeiten

Wir haben mehr als 15 Jahre Erfahrung mit der Sanierung und Testautomatisierung von Legacy-Systemen.

Fast immer ist es möglich, auch alten und schlecht strukturierten Code testbar zu machen und sukzessive zu sanieren. Manchmal ist eine Neuentwicklung von Anwendungsteilen sinnvoll. Sind die Aufwände dafür zu hoch oder schlecht zu schätzen, kann ein sukzessives und damit kalkulierbareres Refactoring infrage kommen.

Integrations-Tests oder GUI-Tests als Einstieg

Tests, die die Anwendung vollautomatisch und regelmäßig überprüfen, sind ein unverzichtbarer Bestandteil professioneller Softwareprojekte. Bei moderner Software schreibt man primär Unit-Tests isolierter Klassen – sie sind schnell und gut wartbar. Sind Unit-Tests aufgrund der Architektur nicht möglich, so kann man zunächst Integrations- oder GUI-Tests (Oberflächen-Tests) erstellen. Hat man die wichtigsten Geschäftsvorfälle auf diese Weise mit einem „Sicherheitsnetz“ versehen, kann man „unter der Haube“ Änderungen vornehmen.

Sukzessive Sanierung

Manche Aspekte alten Codes kann man gut nach und nach refaktorieren. Ein häufiges Problem sind riesige und verwobene Klassen oder Module. Diese kann man mithilfe von erprobten Refactoring-Mustern stückweise extrahieren und besser testbar machen.

Hat man testbare Klassen erzeugt, können (und sollten) Unit-Tests dafür geschrieben werden.

Neue Funktionen in neuer Architektur

Werden neue Funktionalitäten in die Software eingefügt, sollten diese in einer sinnvollen Architektur implementiert werden, die dann zunächst neben der alten Struktur existiert. Im Laufe der Zeit wird der neue Anwendungsteil größer und der alte sukzessive abgelöst.

Coaching Ihres Entwicklungsteams

Hat Ihr Entwicklerteam wenig Erfahrung im Schreiben von Tests? Gab es schon fehlgeschlagene und frustrierende Versuche, Tests einzuführen, sodass die Zweifel überwiegen?

Die gute Nachricht ist: Hat ein Team eine Weile mit automatischen Tests gearbeitet, wird es sie nicht mehr missen wollen. Und wirklich schwierig ist das Schreiben von Tests auch nicht – man braucht allerdings am Anfang etwas Unterstützung.

Wir können Sie in Test-Techniken schulen oder – noch besser – an Ihrem Projekt das Einführen von Tests durch Coaching begleiten.

Lohnt es sich?

Software-Sanierung, das Erlernen und nachträgliche Einziehen von Tests sind aufwändig. Wenn die Software in Kürze abgelöst werden soll, lohnt sich dieser Aufwand nicht. Wenn sie aber weiterentwickelt soll, muss man mit der Alternative vergleichen: manuellen Tests Diese sind ebenfalls aufwändig, und zwar gleichbleibend. Automatische Tests müssen einmal geschrieben werden und laufen dann (nahezu) ohne weitere Kosten beliebig oft: Manuelle Tests kosten jedes Mal wieder den gleichen Aufwand – automatische nur einmalig:

Aufwand manueller und automatischer Tests im Vergleich — [schematisch:] Aufwand manueller und automatischer Tests über den Zeitverlauf im Vergleich

Die Qualität wird besser: Unbemerkte Nebeneffekte einer Änderung werden sofort aufgedeckt.
Funktionen, die durch Tests abgedeckt sind, gehen nie wieder unbemerkt kaputt.
Die Sicherheit durch Tests ermöglicht Änderungen an der Software, die man sonst kaum wagen könnte, z.B. grundlegende Umbauten zur Performanceoptimierung.
Die "time to market" von Updates verringert sich, weil sich die manuellen Testphasen verkürzen.