Wenn in einem SAP-Projekt das Wort „Testphase“ fällt, beobachte ich seit Jahren das gleiche Bild. Augen rollen am Tisch, der Fachbereich verschränkt die Arme, die IT seufzt leise, und der Projektleiter wirkt plötzlich sehr beschäftigt mit seinem Laptop. Niemand will testen. Und ehrlich gesagt: Ich verstehe das.
Tests sind in der Praxis selten das, was sie auf dem Papier sein sollten. Sie sind oft das, worüber am wenigsten gesprochen wurde, bis es plötzlich Pflicht wird. Drei Wochen vor dem Go-Live merkt jemand, dass da noch eine Phase ist, die niemand richtig geplant hat, und dann wird es ungemütlich.
Die Beschwerden, die ich höre, sind alle berechtigt. Ein Test-Manager auf 1.000 € pro Tag, der vor allem Excel-Listen pflegt. Endlose Workshops zur Abstimmung von Testfällen, die später so nie abgearbeitet werden. Der Fachbereich, der seinen UAT zwischen 17 und 19 Uhr macht, weil das Tagesgeschäft Vorrang hat und der Disponent bis 16 Uhr seine Bestellungen rausbekommen muss. Defects, die in einer geteilten Excel-Datei landen, in der niemand mehr weiß, wer was wann geprüft hat. Testdaten, die mit der Produktion nichts zu tun haben, weil sie aus einer alten Sandbox stammen, in der die Werke anders heißen und die Materialnummern längst nicht mehr existieren.
Wer das einmal mitgemacht hat, kommt zur logischen Frage: Bringt das überhaupt etwas?
Test-Theater bringt tatsächlich nichts
Ich gebe eine ehrliche Antwort. Es ist möglich, eine 200-seitige Test-Dokumentation zu erzeugen, die genau null Produktionsfehler verhindert. Ich habe das selbst miterlebt, und ich vermute, jeder andere SAP-Berater auch. Häkchen werden gesetzt, weil das Häkchen gefordert ist, nicht weil der Test eine reale Frage geklärt hätte. Das ist keine Übertreibung, das ist die Realität in zu vielen Projekten.
An dieser Stelle wird die Diskussion meistens falsch gedreht. Aus der Beobachtung „dieser Test war Theater“ wird die Schlussfolgerung „Tests bringen nichts“. Und genau das ist der Fehler.
Was passiert, wenn nicht getestet wird
Ich erinnere mich an einen Tier-1-Zulieferer, bei dem nach einem Support-Package-Einbau am Wochenende der Versand am Montag nicht funktionierte. Eine Konditionstabelle hatte sich durch den Einbau verändert, das fiel niemandem auf. Ergebnis: drei Schichten ohne ausgelieferte LKWs, der OEM rief am Mittag an, am Nachmittag standen die Manager im Großraumbüro. Die Pönalenforderung kam zwei Wochen später. Ich nenne keine Zahl, aber sie hatte mehr Stellen als ein üblicher Beraterauftrag.
Das ist nicht spektakulär. Das ist Alltag in der Tier-1-Welt. Wenn ein DELFOR- oder DELJIT-Abruf nicht rausgeht, wenn eine Auslieferung an einen Kunden mit Just-in-Sequence-Vertrag scheitert, wenn das EDI nach einem Hinweis-Einbau plötzlich eine andere Segmentstruktur sendet als erwartet, dann wird aus einem technischen Detail in Stunden ein finanzielles Problem, in Tagen ein Reputationsproblem und in Monaten ein Vertriebsproblem.
Die in der Branche kursierenden Größenordnungen für einen Bandstillstand bei einem deutschen OEM liegen je nach Werk und Modell zwischen 30.000 und 100.000 € pro Minute. Pönalen sind in vielen Lieferverträgen als Vielfaches des Lieferwerts kalibriert. Eine wiederholte Auffälligkeit führt zu einer schlechteren Lieferantenbewertung, was im nächsten Modellzyklus über Auslistung entscheiden kann. Diese Konsequenzen sind nicht hypothetisch, sie sind in der Branche kalkulatorisch erfasst.
Vor diesem Hintergrund ist die Aussage „Tests bringen nichts“ nicht nur falsch, sie ist betriebswirtschaftlich gefährlich. Ein einziger verhinderter Vorfall finanziert den Testaufwand mehrerer Jahre. Tests sind, richtig aufgesetzt, die billigste Versicherung, die ein Logistikunternehmen kaufen kann.
Pragmatische Tests, die wirklich helfen
Der Trick ist nicht, mehr zu testen, sondern besser. Was sich in meiner Praxis bewährt hat, lässt sich auf fünf Punkte zusammenfassen.
Risikobasiert priorisieren. Welche zwanzig Prozent der Prozesse machen achtzig Prozent des Volumens und nahezu hundert Prozent des Geschäftsrisikos? Genau diese werden voll durchtestet, alles andere stichprobenartig oder gar nicht. Niemand muss die Pflege des Drucker-Customizings im Test mit sechs Personentagen abdecken.
Mit echten Daten arbeiten. Eine produktionsnahe Mandantenkopie, idealerweise periodisch refresht, ist mehr wert als jede künstliche Testumgebung. Datenschutz lässt sich über Anonymisierungsläufe sauber lösen, der Aufwand dafür rechnet sich nach dem ersten gefundenen Fehler.
Regression automatisieren. Tools wie Tricentis Tosca, Worksoft Certify oder SAP CBTA gibt es seit Jahren. In Konzernen sind sie häufig schon lizenziert und werden trotzdem nicht genutzt. Wer einmal die Mühe in eine automatisierte Regression gesteckt hat, testet beim nächsten Support Package in Stunden statt in Wochen.
Defects im richtigen Werkzeug verwalten. Jira, ServiceNow, Azure DevOps. Nicht Excel. Excel-Defectlisten sind der häufigste Grund, warum Fehler verloren gehen, doppelt geprüft werden oder nach Go-Live wieder auftauchen.
Den UAT klein halten. Ein UAT mit klar vorab definierten Testfällen, der in zwei Wochen durchgezogen wird, ist effektiver als ein offen formulierter Sechs-Wochen-Marathon, in dem der Fachbereich „nochmal alles“ prüft.
Was Berater dazu beitragen müssen
An dieser Stelle ein selbstkritisches Wort an den eigenen Berufsstand. Tests sind in vielen Projekten so aufgesetzt, dass sie maximal Tagessätze generieren und minimal Risiko abdecken. Test-Manager-Rollen werden in Projekten unter fünfhundert Personentagen häufig installiert, obwohl ein Teilprojektleiter mit Testverantwortung völlig ausreichen würde. Die endlosen Abstimmungsmeetings sind oft kein methodischer Bedarf, sondern Konsequenz unklarer Verantwortlichkeiten. Beratungshäuser haben aus Tests an manchen Stellen ein eigenes Geschäftsmodell gemacht, und das ist mit ein Grund, warum die Reputation der Testphase im Mittelstand so schlecht ist.
Wer pragmatisch berät, baut kein Test-Theater auf, sondern hilft dem Kunden, mit weniger Aufwand mehr Risiko abzudecken. Das ist anstrengender als ein gut bezahltes Status-Reporting, aber es ist die einzige Variante, die für den Kunden wirklich Wert schafft.
Tests sind eine Versicherung, keine Pflichtübung
Niemand kauft eine Versicherung gerne. Niemand zahlt Beiträge mit Begeisterung. Aber wenn das Haus brennt, ist es genau diese Versicherung, die einen vor der Katastrophe bewahrt. Tests in SAP-Projekten sind exakt das gleiche Konzept. Sie kosten Aufwand, Zeit und Geld, ohne dass man sie im Erfolgsfall bemerkt. Erst wenn etwas schiefgeht, sieht man, was sie wert sind. Oder eben gewesen wären.
Wer Tests als reine Pflichtübung versteht, macht sie schlecht und hat dann zurecht den Eindruck, dass sie nichts bringen. Wer sie als das versteht, was sie sind, eine kalkulierte Versicherung gegen Bandstillstand und Pönalen, gestaltet sie pragmatisch und profitiert davon. Die schlechten Tests sind das Problem, nicht das Testen an sich. Und falls am Ende der Lenkungskreis sie trotzdem streichen will, hilft eine einzige Frage. Wie viele Stunden Bandstillstand könnten wir uns leisten, wenn wir das Testbudget streichen? Die Antwort ist meistens deutlich kürzer als die Diskussion