Das Ablösen eines gewachsenen Testautomatisierungs-Frameworks bedeutet: die bestehende XML-basierte Testorganisationsschicht herausschneiden und durch ein generisches Framework ersetzen, hier das Robot Framework mit einem eigens ausgebauten Remote Library Interface für .NET. Der Prozess dauert typischerweise ein Jahr, erfordert interne Überzeugungsarbeit mit konkreten Belegen und klare Freistellung vom laufenden Testablauf.
Das Wichtigste in Kürze
- Ein gewachsenes Testframework ohne klare Architektur wird zum Jenga-Tower: Jede Änderung riskiert, das Gesamtsystem zu destabilisieren, bis ein Neuanfang unvermeidbar ist.
- Überzeugungsarbeit gelingt nicht durch abstrakte Forderungen, sondern durch konkretes Aufzeigen des Ist-Stands: sechs parallel geöffnete Dateien, versteckte Fehler, instabile Ergebnisse.
- Das Robot Framework wurde erst durch einen selbst umgebauten Remote-Library-Interface-Server nutzbar, weil kein gepflegtes .NET-Core-Gegenstück existierte.
- Die Ablösung eines produktiv genutzten Frameworks dauerte ein volles Jahr und war nur möglich, weil das manuelle Testteam während der Umbauphase die Release-Zyklen vollständig übernahm.
- Messbarer Nutzen des neuen Systems zeigte sich vor allem durch kürzere Testlaufzeiten, deutlich weniger Code pro Testfall und den Wegfall selbst entwickelter Integrationen wie das Reporting.
Wann ein Testautomatisierungsframework abgelöst werden muss
Ein Framework gehört abgelöst, wenn die manuelle Arbeit drumherum mehr Aufwand frisst als der eigentliche Test. Genau das war der Auslöser bei Nikolaus Rieder, Test Automation Engineer bei Schrack Secunet im Bereich Kommunikationssysteme. Die alte Lösung lief nur scheinbar automatisch. Tatsächlich musste ein Mensch dauerhaft eingreifen.
Die frühere Automatisierung bestand darin, Prozeduren in XML-Dateien zu schreiben und das System dabei zu beobachten. Das Gerät reagierte, aber ohne menschliche Komponente lief gar nichts durch. Umschalten, umverkabeln, Konfigurationen ändern, viel Copy-Paste für jede kleine Anpassung: diese Handarbeit gehörte zu jedem Durchlauf dazu.
Dazu kam ein kaputtes Kontrollproblem. Tests zu kontrollieren, Ergebnisse zusammenzutragen und Fehler zu finden, die nichts mit dem zu testenden Gerät zu tun hatten, kostete enorm Zeit. Manche Fehler entstanden sogar nur während des Durchlaufs und tauchten im Testergebnis gar nicht erst auf.
Wie ein Jenga-Tower aus In-house-Code entsteht
Solche Frameworks scheitern selten an einem einzelnen Fehler, sondern an ungebremstem Wachstum ohne Zielbild. Das alte System bei Schrack Secunet stammte von einem Entwickler, der lange dabei war und für einen akuten Bedarf etwas baute, ohne klare Vorgabe, wie es aussehen sollte. Hauptsache, es funktioniert.
Aus dieser Haltung wuchs ein Monolith. Schicht auf Schicht wurde drübergelegt, immer nach dem Muster “das muss ich auch noch dazu bauen”. Nikolaus beschreibt das Ergebnis als Jenga-Tower: Zieht man ein Stück heraus, muss man hoffen, dass der Turm stehen bleibt.
Das Muster ist verbreitet. Eine Excel-Tabelle wird zu klein, daraus wird eine Datenbank, irgendwann steckt das gesamte Wissen darin, und niemand kann es mehr warten. Über 20 oder 30 Jahre verfestigt sich so ein Getriebe, in dem sich kaum noch etwas bewegen lässt.
Ein Teil des Problems ist psychologisch. Wer ein Projekt anfängt, ist von der Lernerfahrung getrieben und fügt ständig etwas Eigenes hinzu. Der Gegenimpuls fehlt oft: kurz innehalten und fragen, ob es das nicht schon gibt. Dahinter steckt auch Misstrauen gegenüber fremdem Code, nach dem Motto, eine Library von irgendwoher könne man doch nicht einfach übernehmen.
Der Schmerz muss sichtbar werden, nicht nur behauptet
Wer einen gewachsenen Monolithen ablösen will, braucht zuerst ein Agreement im Team und bei den Produktmanagern, kein fertiges neues Tool. Die initiale Arbeit war reine Überzeugungsarbeit, in mehreren Gesprächen aus verschiedenen Richtungen beleuchtet.
Der wirksame Hebel war nicht die Forderung nach etwas Neuem, sondern das Vorführen des Ist-Zustands. Nikolaus zeigte konkret die sechs Dateien, die er parallel betrachten musste, und die Zahl der Fehler, die nur während des Laufs entstanden und im Ergebnis nie auftauchten.
Ich bin da nicht hineingegangen mit “Wir brauchen was Neues”, sondern mit dem Ist-Stand, mit dem, was ich erlebt habe. Aber das muss man so rüberbringen, wie es aus meiner Sicht ist, nicht wie es aus deren Sicht ist. — Nikolaus Rieder
Den Schmerz vorzuführen statt ihn im Meeting nur zu behaupten, verschafft den Freiraum für eine Sanierung. In einem Review zeigt man, was geschafft wurde. Genauso wichtig ist, einmal zu zeigen, wo der Pain tatsächlich liegt. Ohne diese Freigabe wäre die Umstellung als Nebenbei-Projekt versandet, die volle Umstellung dauerte fast ein ganzes Jahr.
Warum die Tool-Wahl auf das Robot Framework fiel
Die Wahl fiel auf das Robot Framework, weil es ein generisches Test-Framework ist und nicht an eine einzelne Programmiersprache bindet. Davor wurden mehrere Optionen verglichen und wieder verworfen.
Ein kommerzielles Komplettprodukt wie TestStand wurde in der Testlizenz ausprobiert. Es tat, was es sollte, band aber zu stark: Man kommt nicht mehr davon weg. Diese Abhängigkeit machte vorsichtig.
Auch ein Unit-Test-Framework wurde umgebaut und zweckentfremdet. Konzeptuell passte das nicht. Auf System- und Integrationsebene Unit-Tests zu starten, die in Wahrheit mit etlichen Geräten kommunizieren statt Programmcode zu prüfen, fühlte sich falsch an.
Den Ausschlag gab, dass das Robot Framework potenziell mit verschiedenen Sprachen arbeitet. Dieses “potenziell” reichte, um es ernsthaft zu testen. Der Versuch, den vorhandenen C#-Code nach Python zu konvertieren, wurde schnell aufgegeben, weil das nur eine weitere Wartungsschicht bedeutet hätte.
Stattdessen griff Nikolaus auf den nRobot-Server zurück, ein Public-Domain-Projekt, das nicht mehr gepflegt wurde, und baute es selbst um. Diese Entscheidung bezeichnet er als die klügste im ganzen Kontext. Sich darauf zu verlassen, dass von außen noch etwas kommt, wäre nicht gut gegangen.
Refactoring heißt, das XML herauszuschneiden
Beim Portieren ging es vor allem darum, die XML-Testorganisationsschicht zu entfernen, nicht den gesamten Altcode wegzuwerfen. Vieles aus dem alten Framework blieb nützlich: Kommunikationsschnittstellen zu Servern, Klassenabbildungen von Protokollen, die Grundklassen der Libraries.
Die Codebasis bestand aus zwei Kernprojekten, je einem pro Gewerk, mit Projektreferenzen quer durcheinander und einer fertig kompilierten Konsolenapplikation. Das Vorgehen glich dem Abtragen des Jenga-Towers von unten: Baustein für Baustein die Grundklassen finden und ins neue Projekt überführen, dabei sortieren, was gebraucht wird und was nur an der XML-Schiene hing.
Das XML steckte fast überall. Nikolaus vergleicht die Arbeit mit einem chirurgischen Eingriff: An vielen Interfaces und Schnittstellen jede Referenz auf das XML herausschneiden und durch etwas Neues ersetzen. Er beschreibt das XML als Tumor, der sich durch die gesamte Codebasis verbreitet hatte.
Wer parallel die Zielstruktur baut, refactored leichter. Weil Nikolaus zeitgleich das Remote Library Interface aufbaute, kannte er die Keyword-Hierarchie und wusste, wie die Funktionsaufrufe später aussehen würden. Sein Kollege musste sich für denselben Schritt länger einlesen.
Parallelbetrieb statt Big Bang: die Migration absichern
Während der Umstellung muss der laufende Release-Betrieb anders abgedeckt werden, sonst blockiert er die Migration. Bei Schrack Secunet half die Aufteilung in zwei Gewerke. Der Brandbereich ist der stärkere Business-Zweig, der Kommunikationsbereich konnte sich für die Release-Testzyklen eine Pause nehmen.
Den Ersatz übernahm in dieser Zeit das manuelle Test-Team. Es testete für die betroffenen Releases vollumfänglich, was die Testzeit dort verlängerte und Stress verursachte, aber Nikolaus als alleinigen Entwickler freispielte. So konnte er sich voll auf das Remote Library Interface konzentrieren.
Die Reihenfolge ergab sich aus dem Aufbau: Erst stand das Remote Library Interface, dann ließ sich eine C#-Assembly nach der anderen hineinbringen. Den Brandteil portierte der Kollege in seinen freien Zwischenzeiträumen zwischen den Release-Zyklen, weil Nikolaus dessen produktspezifischen Code nicht vollständig kannte.
Hätte man das parallel zum vollen Release-Betrieb gemacht, wäre es nicht so sauber gelaufen. Das gibt einen klaren Hinweis für eigene Migrationen: Wenn möglich, eine verantwortliche Person aus dem Tagesgeschäft freispielen, statt die Umstellung nebenbei zu erwarten.
Das Jahr reichte am Ende nicht ganz. Ein neues Boost-System kam dazu, eine neue Protokollebene musste mitten im neuen Framework implementiert werden, und der dafür nötige Integrationstest dauerte länger als gedacht. Zusätzlich stand der Umbau der physischen Testumgebung an. Diese Überlappung sorgte für Verzug und Überlastung.
Warum sich der Erfolg nicht in eine einzige Kennzahl pressen lässt
Den Nutzen der Ablösung konnte Nikolaus nicht im Sinne klassischer Bug-Metriken quantifizieren, weil das alte Framework Probleme gar nicht erfasst hatte. Was nicht manuell als Bug eingetragen wurde, tauchte nirgends auf. Eine saubere Vorher-Nachher-Fehlerstatistik gab es schlicht nicht.
Stattdessen wurde mit greifbaren Vergleichen argumentiert. Für die gleiche Routine zeigte das Team, wie viele Code-Zeilen der alte Testfall brauchte und wie wenige der neue. Dazu kam die Laufzeit: Durchläufe, die im alten System 20 oder 30 Minuten dauerten, liefen im neuen messbar schneller.
Das stärkste Argument war weggefallener Entwicklungsaufwand. Integrationen wie die Anbindung an X-Ray für Jira sind im Robot Framework eingebaut. Was vorher in Eigenregie gebaut werden musste, ist nun vorhanden und kauft Zeit frei.
| Aspekt | Altes Framework | Robot Framework |
|---|---|---|
| Ausführung | Semi-automatisch, ständiger manueller Eingriff | Automatisch |
| Code pro Routine | Viele Zeilen | Deutlich weniger |
| Laufzeit | 20 bis 30 Minuten | Spürbar schneller |
| Reporting | Manuell, ein Graus | Eingebaut, lesbar |
| Integrationen (z. B. X-Ray/Jira) | Eigenregie, Eigenbau | Eingebaut |
Das eingebaute Reporting war ein eigener Verkaufspunkt. Im alten System bedeutete Reporting viel Handarbeit. Im neuen reicht ein Blick auf den Report, und es steht ein verständlicher Satz darin, was der Test tut.
Ein altes Framework gehört konsequent abgedreht
Ist die neue Lösung tragfähig, sollte das alte Framework nicht als Sicherheitsnetz weiterlaufen. Nikolaus hat es nach der erfolgreichen Umstellung nie wieder aktiv genutzt. Es existiert nur noch als Referenz, um nachzusehen, wie ein alter Testfall designt war, nicht um Tests damit auszuführen.
Beim Kollegen verlief der Übergang weniger glatt. Weil im Release-Zyklus teilweise noch nicht portierte Sachen liefen, gab es ein Hin und Her zwischen alt und neu, mit den entsprechenden Reibungen. Wer freigespielt ist, dreht das Alte schneller ab als jemand, der parallel im Tagesgeschäft steckt.
Die wichtigste Lektion aus dem Jahr ist Geduld. Etwas Neues aus etwas Altem zu machen braucht Zeit, und Stress verleitet dazu, sich im neuen System erneut zu verhuddeln und schlecht zu implementieren. Ruhe beim Refactoring schützt die Qualität der neuen Lösung. Wer einen Monolithen ablöst, baut nicht nur ein Framework um, sondern trainiert auch den eigenen Umgang mit langwierigen Prozessen.
