Sachsen: Wenn Behörden-Software live getestet wird

Was passiert ist

Sachsens Landesbehörden hatten monatelang ein Problem: Zahlungseingänge und -ausgänge konnten nicht mehr korrekt zugeordnet werden. Die Zentrale Bußgeldstelle musste alle Mahnverfahren stoppen. Hochschulen konnten Semesterbeiträge nicht verbuchen. Und bei Auslandsüberweisungen wurde die Währung falsch erfasst. Nicht Euro statt Dollar, nicht ein Rundungsfehler, sondern: die Währung komplett falsch im System.

Der Grund: eine Software-Umstellung bei der Hauptkasse des Freistaats Sachsen.

Das Landesamt für Steuern und Finanzen betont, die „Zahlungsfähigkeit des Freistaates war zu keiner Zeit beeinträchtigt". Mag sein. Aber wenn eine Bußgeldstelle keine Mahnungen mehr verschicken kann und Hochschulen nicht wissen, welche Studenten bezahlt haben, dann funktioniert der Staat an dieser Stelle nicht.

Das eigentliche Problem: Testing

Jeder, der in der Software-Entwicklung arbeitet, kennt den Satz: „Auf meinem Rechner funktioniert’s." In der Behörden-IT gibt es das Äquivalent: „Im Testsystem lief alles."

Die Frage ist: Was wurde getestet?

Ein Finanzsystem, das Zahlungen aus hunderten Dienststellen verarbeitet, Auslandsüberweisungen in verschiedenen Währungen abwickelt und mit Bußgeldverfahren, Hochschulverwaltungen und Gehaltssystemen zusammenspielt, lässt sich nicht mit ein paar Testbuchungen validieren. Realistische Tests brauchen:

• Reale Datenvolumen. Nicht 50 Testbuchungen, sondern 50.000. Erst unter Last zeigen sich Zuordnungsprobleme.
• Edge Cases aus dem echten Betrieb. Fremdwährungen, Teilzahlungen, Stornierungen, Doppelbuchungen, Sonderfälle. Die langweiligen Fälle, die niemand testen will, weil sie selten vorkommen, bis sie es tun.
• Parallelbetrieb. Alt und neu gleichzeitig laufen lassen und die Ergebnisse vergleichen. Ja, das kostet doppelt. Nein, es kostet nicht so viel wie monatelanges Chaos.
• Rückfall-Szenario. Was passiert, wenn die neue Software nicht funktioniert? Können wir zurück? Innerhalb von Stunden, nicht Wochen?

Keines dieser Elemente scheint in Sachsen ausreichend vorhanden gewesen zu sein. Sonst wäre aufgefallen, dass Währungen falsch erfasst werden. Das ist kein subtiler Bug. Das ist ein Fehler, den jeder einzelne Testfall mit einer Auslandsüberweisung sofort aufgedeckt hätte.

Ein Muster, kein Einzelfall

Sachsen steht damit nicht allein. Die Liste gescheiterter oder holpriger IT-Migrationen in deutschen Behörden ist lang:

• Berlins ISBJ (IT-System Berliner Jugendämter): jahrelange Verzögerungen, Millionenkosten, Jugendämter arbeiteten parallel mit Papier
• Hessens Polizei-IT (Hessendata): Datenschutzbedenken und technische Probleme beim Palantir-Einsatz
• Bundeswehr (Herkules-Projekt): 7 Milliarden Euro für eine IT-Modernisierung, die nie vollständig funktionierte
• Toll Collect: Jahre verspätet, hunderte Millionen Mehrkosten

Das Muster ist immer dasselbe: Ambitionierter Zeitplan, politischer Druck, unzureichende Testphasen, und dann der Go-Live in der Hoffnung, dass es schon irgendwie läuft.

Was Praktiker wissen

In der Privatwirtschaft würde man bei einem System dieser Kritikalität niemals einen Big-Bang-Rollout machen. Die bewährte Praxis:

1. Stufenweise Migration. Erst eine Dienststelle, dann fünf, dann alle. Nicht alles auf einmal.

2. Schattenläufe. Das neue System läuft wochenlang parallel, verarbeitet die gleichen Daten, aber ohne operative Wirkung. Abweichungen werden analysiert.

3. Automatisierte Regressionstests. Jede Änderung am System durchläuft hunderte vordefinierte Testfälle. Währungsumrechnung, Zuordnungslogik, Schnittstellen. Automatisch, reproduzierbar, dokumentiert.

4. Rollback-Plan. Ein getesteter, dokumentierter Weg zurück zum Altsystem. Nicht theoretisch, sondern geprobt.

5. Go/No-Go-Kriterien. Klare Metriken, die vor dem Go-Live erfüllt sein müssen. Nicht „fühlt sich gut an", sondern „99,9% korrekte Zuordnungsquote im Parallelbetrieb über 4 Wochen".

Die unbequeme Wahrheit

Software-Migrationen scheitern selten an der Technik. Sie scheitern an zu knappen Zeitplänen, zu kleinen Budgets für Testing und an der Illusion, man könne ein komplexes System „einfach austauschen".

Das Landesamt schreibt, die Umstellung sei „umfangreich und sehr komplex" gewesen. Ja, genau. Und komplexe Umstellungen brauchen komplexe Teststrategien. Wenn zehn von 300 Auslandsüberweisungen die falsche Währung hatten, dann wurden Auslandsüberweisungen entweder gar nicht oder mit synthetischen Daten getestet. Beides ist bei einem Finanzsystem ein grober Fehler.

Für alle, die gerade eine Software-Migration planen, ob in der Behörde, im Unternehmen oder im Verein: Investiert die Zeit ins Testing. Nicht weil es Spaß macht (tut es nicht), sondern weil die Alternative teurer ist. Immer.

Quellen: heise online (Sachsen Softwarepanne), MDR (IT-Bürokratie-Chaos Hauptkasse Sachsen)