Eine Spezifikation ist erst die halbe Arbeit. Ob ein System hält, was das Konzept verspricht, entscheidet sich im Test, und zwar bevor der Fehler im Produktivbetrieb ankommt. Business-Analyse und Test sind deshalb bei mir kein Anhängsel der Interim-Projektleitung, sondern ein eigener Arbeitsschritt mit eigenem Kalender.
Was diese Disziplin wert ist, zeigt eine M&A-Integration: Ein internationaler Konzern übernahm ein Beratungsunternehmen mit 80 Mitarbeitenden, alle Systeme und Daten mussten in die Konzern-Landschaft. Nach detailliertem Daten-Mapping und mehreren Testläufen, mit geschriebenen Runbooks und einem trainierten Team, fand der Cut-Over an einem einzigen Wochenende statt. Am Montag lief der Geschäftsbetrieb normal weiter, ein Rollback war nicht nötig. Die Fallstudie steht unter Referenzen.
Testfälle und Abnahmekriterien
Testfälle schreibe ich, bevor gebaut wird, nicht danach. Jeder Fall hat ein erwartetes Ergebnis, jede Abnahme ein messbares Kriterium: Welche Daten gehen rein, was muss rauskommen, was gilt als bestanden? “Sieht gut aus” ist kein Abnahmekriterium. Integrationstests führe ich nicht nur durch, ich setze sie auch durch, gegen den verständlichen Wunsch, den Go-Live-Termin durch gestrichene Testzyklen zu retten. Ein gestrichener Test verschiebt den Fehler nur in den Betrieb, wo er teurer wird.
Testen gegen Echtdaten
Konstruierte Testdaten prüfen, ob das System tut, was der Entwickler erwartet hat. Echtdaten prüfen, ob es mit dem zurechtkommt, was tatsächlich in den Altsystemen steht: Dubletten, Sonderzeichen, gewachsene Sonderfälle. Deshalb teste ich gegen Echtdaten, gerade bei Migrationen im Rahmen von ERP-Wechsel & Migration. Warum die Datenqualität dabei so oft der eigentliche Engpass ist, steht im Beitrag Warum Projekte an der Vorbereitung scheitern.