Enterprise Testing bezeichnet das Testen von gekauften, konfigurierbaren Großsystemen wie SAP, bei denen nicht die lokale Änderung im Vordergrund steht, sondern deren Auswirkungen auf abhängige Prozesse und Schnittstellen. Die größte Herausforderung liegt in der Zusammenarbeit: Tester sind meist erfahrene Fachleute ohne Testhandwerk, und Konfigurationsänderungen können weitreichende, schwer vorhersehbare Nebeneffekte erzeugen.
Das Wichtigste in Kürze
- Konfigurationsänderungen in Enterprise-Systemen wie SAP wirken sich systemweit aus, weil viele Parameter voneinander abhängen. Der lokale funktionale Test reicht daher nie aus.
- Fachseitige Tester ohne Testausbildung prüfen fast ausschließlich den Happy Path, weil sie im Berufsleben gelernt haben, Probleme zu umgehen statt sie aktiv zu suchen.
- Defekte nach Kategorien auszuwerten, ob Ausbildungslücke, fehlende Rechte, zu spät entdeckter Funktionsfehler oder echter Integrationsfehler, erzeugt mehr Lerneffekt als jede abstrakte Retro.
- Managementfähige Visualisierungen der Testabdeckung, auch wenn die zugrundeliegende Metrik schwach ist, schaffen die Aufmerksamkeit, die Teams mehr Zeit zum Testen verschafft.
- Erfahrene Fachanwender sind die stärkste Ressource für exploratives Testen im Enterprise-Umfeld, weil sie jahrelange Systemkenntnis mitbringen und ein hohes Eigeninteresse am Funktionieren der Software haben.
Was Enterprise-Testing von normalem Softwaretest unterscheidet
Enterprise-Testing dreht sich um gekaufte Systeme, die für ein Unternehmen angepasst wurden und dessen Prozesse abbilden sollen. SAP ist das bekannteste Beispiel, aber die Gattung ist größer: Auch Fachsysteme für Sozialhilfe oder andere große Organisationen funktionieren nach diesem Muster. Vorkonfiguriertes System, riesige Nutzerschaft, lokale Anpassungen.
Der zentrale Unterschied liegt nicht in der lokalen Änderung, sondern in ihrer Wirkung. Der funktionale Test einer einzelnen Anpassung ist meist nebensächlich, weil Entwickler oder Konfigurator das selbst gut abdecken. Interessant wird es, sobald man nach links und rechts schaut: Wie wirkt sich dieser Parameter auf den Rest des Systems aus?
Ursula Beiersdorf bringt es auf ein griffiges Bild: SAP sei wie eine große globale Variable, bei der viel mit vielem zusammenhängt. Genau dieser Effekt einer Konfigurationsänderung ist der eigentliche Prüfgegenstand. Die Komplexität steckt zudem in den Schnittstellen von und zu SAP, also in Abhängigkeiten, die ein klassisches agiles Team in dieser Form nicht hat.
Ein verbreitetes Missverständnis lautet, eine Standardsoftware sei bereits getestet, also reichten ein paar Anpassungen. Das stimmt für die Software als Produkt oft, aber die Eingriffsmöglichkeiten und externen Abhängigkeiten erzeugen Nebeneffekte, die spät im Prozess auftauchen. Wer Konfiguration als harmlos abtut, unterschätzt sie.
Warum die wahre Komplexität in der Zusammenarbeit steckt
Das größte Problem im Enterprise-Test ist nicht die Technik, sondern die Koordination. “Ich kriege die Leute an den Tisch, die mitreden müssten” beschreibt den Kern der täglichen Arbeit besser als jede Testmethode.
Diese Abhängigkeit von vielen Beteiligten verschiebt die Rolle. Wer in einem großen System Qualität sichern will, übernimmt mehr Governance-Aufgaben als in kleineren Projekten. Es geht darum, schmale, umsetzbare Regeln vorzugeben, die zentral orchestriert werden, ohne jeden Schritt zentral umzusetzen.
Wer im Enterprise-Umfeld testet und warum das eine Herausforderung ist
Im Enterprise-Test gibt es meist keine ausgebildeten Tester. Stattdessen testen Fachleute, die das System als Anwender kennen, aber von Testen wenig Ahnung haben. Sie haben viele andere Aufgaben und prüfen nebenbei.
Diese erfahrenen Nutzer sind stark im erfahrungsbasierten Testen. Wer ein System zehn Jahre benutzt hat, weiß, wo die blöden Stellen sitzen, und schaut gezielt dorthin. Solange Änderungen klein bleiben, trägt das. Bei größeren Umbauten fehlt diesen Anwendern das Handwerkszeug, und sie müssen sich ohne Hilfe daran abarbeiten.
Der erste Schritt in der Befähigung ist nicht Methodik, sondern eine andere Denkhaltung. Fachleute haben gelernt, im Business um die Pfütze herumzulaufen. Testen heißt, mit beiden Füßen hineinzuspringen und sich darüber zu freuen.
Einfach mal grundsätzlich zu denken, was kann kaputtgehen, ist nicht die Denke, die man hat, wenn man im Business lernt, um die Pfütze herumzulaufen.
Ursula Beiersdorf
Am wirkungsvollsten ist es, an einer echten User-Story der Person anzusetzen. Sie schreibt ihren Test, danach wird er gemeinsam auseinandergenommen. Zwei Muster zeigen sich fast immer: Die Akzeptanzkriterien sind nie ausführlich genug, und es wird nur der Happy Path geprüft. Erst wenn die Person das selbst erlebt hat, lohnt sich der Einstieg in Entwurfsmethoden. Das ist meist drei Schritte später.
Befähigung funktioniert über gestaffelte Pakete, nicht über ein Methodenfeuerwerk
Statt allen die volle Methodik überzustülpen, hilft es, die Komplexität in der Ansprache zu reduzieren. Ein Team, das andere unterstützt, kann sein Angebot wie Produkte zuschneiden.
- Kleines Paket: für Leute, die nur mal eine einzelne User-Story testen müssen.
- Größeres Paket: für ernsthaft integratives Testen, inklusive Testmanagement und Tool-Nutzung.
- Optimierende Version: Pipelines und weiterführende Automation für die, die es brauchen.
Viele greifen zunächst zum kleinen Paket und merken schnell, dass sie damit nicht beliebig weit kommen. Wichtiger als jedes Paket ist, die Leute dort abzuholen, wo sie stehen. Die Überzeugungsarbeit, das Warum, ist organisationaler Wandel und damit der größte Teil der Arbeit. Methoden kommen erst danach, und wo ein Bereich wirklich kritisch ist, holt man gezielt einen Tester oder Berater dazu, der es kann.
Wie der Umstieg von Excel auf ein Testmanagement-Tool gelingt
Im Enterprise-Umfeld dominiert lange Excel, und ein harter Schnitt wirkt erst widersinnig. Der Umstieg gelingt, wenn er an eine ohnehin laufende Transformation gekoppelt wird. Als die Jira-Nutzung verpflichtend wurde, ließ sich die Einführung von X-Ray gleich mit durchziehen.
Bestandssoftware, die in den nächsten Jahren ausläuft, darf dabei bei Excel bleiben. Pflicht ist das neue Tool dort, wo es zählt. Aus diesem Pflichtanteil heraus lernen die ersten Anwender den Nutzen schätzen und kommen freiwillig: Testfälle strukturiert ablegen, den eigenen Stand erkennen, Tests durch verschiedene Menschen ausführen lassen. Diese Testmanagement-Funktionen machen vieles einfacher, und das spricht sich herum.
Defektmanagement: vier Kategorien sagen mehr als fünfundzwanzig
Nicht jeder Fehler braucht ein Ticket. Kleine Fehler, die sich auf der “Hey-Joe-Ebene” direkt mit dem bekannten IT-Kollegen lösen lassen, dürfen so gelöst werden. Sobald ein Fehler nicht sofort lösbar ist oder unklar ist, wer zuständig wäre, gehört er als Defect aufgeschrieben.
Der eigentliche Erkenntnisgewinn entsteht bei der Auswertung. Eine simple Einteilung in vier Kategorien reicht aus:
| Kategorie | Aussage |
|---|---|
| Ausbildung | Tester war nicht ausreichend geschult |
| Vorbereitung | Rechte oder Voraussetzungen fehlten |
| Funktionaler Test | hätte vorher leicht gefunden werden können |
| Integration | echter Integrationsfehler |
Diese vier Kategorien sind klar und einfach, und genau deshalb wirken sie. Ein Team erkannte in der Retrospektive selbst, dass etwa fehlende Rechte den Tester aufgehalten und verärgert hatten, und nahm sich vor, das nächste Mal die Vorbereitung besser zu machen. Einen Tester zu verärgern, der ohnehin keine Zeit hat, kostet Vertrauen, das schwer zu kitten ist.
Der Reiz, das mit KI feiner auszuwerten, ist groß, aber unangebracht, solange die Basis fehlt. Wer ungefähr auf dem Reifegrad von 2005 testet, sollte ein paar Zwischenschritte gehen, bevor er zu KI greift. Viele Anregungen von Konferenzen zielen außerdem auf Individualentwicklung und sind für einen konfigurativen SAP-Kontext schwer übertragbar.
Integrationstests über eine Prozessmodellierung steuern
Wer ist zuständig, wenn große Standardsysteme integriert werden? Diese Frage löst sich am besten über eine Prozessmodellierung. Wenn ein Programm die Prozesse neu denkt statt nur das System zu migrieren, lassen sich die Prozessteile sauber zusammenführen und Testläufe daran ableiten.
Vertraute Abläufe, die Fachleute immer schon so gemacht haben, müssen dafür erst in Prozesse gegossen werden. Das wirkt zunächst umständlich, schafft aber einen Faden, an dem man die Beteiligten zusammenbringt. Entlang des Prozesses lässt sich auch die Diskussion führen, ob nur der Happy Path oder welche Varianten geprüft werden.
Zusätzlich gibt es User-Story-unabhängige Prozesstests. Die End-to-End-Strecken, die schon laufen, werden immer wieder mitgetestet, weil der tatsächliche Impact einer Änderung nie ganz sicher ist.
Warum User Stories im Enterprise-Kontext anders aussehen
User Stories im Enterprise-Umfeld umfassen oft einen längeren Span als ein reiner Konfigurationsschalter. Die Denkweise lautet: Ich ändere etwas, damit eine bestimmte Wirkung eintritt, also teste ich diese Wirkung.
Das Gegenbeispiel: Als das dritte Geschlecht eingeführt wurde, war der Schalter schnell gesetzt. Ob man es danach auch beim Schreiben von Briefen korrekt verwenden konnte, wurde womöglich nicht geprüft. Genau auf diese Wirkungskette sind erfahrene Enterprise-Leute eher gepolt. Idealerweise wandert dieser Wirkungsblick schon ins Refining der User-Story und wird Teil der Akzeptanzkriterien.
Wie Testdatenmanagement bei SAP funktioniert
Im klassischen SAP-Umfeld zieht man eine produktive Kopie und hofft, dass keine kritischen Daten darin stecken. Ein neu aufgesetztes System hat dieses Problem nicht, weil es schlicht keine Daten gibt. Das schafft Awareness und zwingt zur Zusammenarbeit.
Der Test bringt sich an einer konkreten Stelle ein: an den Prozess-Bubbles markieren, an welcher Stelle welche Daten zum ersten Mal ins Spiel kommen. Business-Partner ab einer bestimmten Schnittstelle, Materialien ab einer anderen. Diese Transparenz hilft allen, rechtzeitig mit dem jeweiligen Provider zu sprechen, wenn Daten gebraucht werden.
Wichtig ist die Unterscheidung zwischen konfigurativen Basisdaten und Transaktionsdaten. Basisdaten werden im Rahmen des Programms mitentwickelt, Transaktionsdaten nicht. Bei intellectual property gilt zudem oft eine harte Regel: Kein externer Tester bekommt diese Daten zu sehen.
Testautomatisierung braucht zuerst Erfolgsgeschichten
Testautomatisierung im Enterprise-Umfeld läuft auf zwei Ebenen. Was wirklich entwickelt wird, automatisieren die Entwickler mit ihren eigenen Werkzeugen wie Cypress oder Unit-Tests. Schwieriger ist die Prozessebene, die über mehrere Tools hinweggeht.
Ein eingeführtes Werkzeug wie Tosca sollte hier weniger technische Personen befähigen, scheiterte aber an der Realität. Es bleibt ein Expertentool, in das man sich einarbeiten muss, und die Anwender haben keine freie Zeit dafür. Ohne Erfolgserlebnis wurde es nicht angenommen.
Der neue Ansatz dreht das um: erst ein zentrales Automationsteam aufbauen, das die Erfolgsgeschichten produziert. Wenn eine Basis steht und sichtbar wird, dass die Automation Arbeit abnimmt, lassen sich Leute in den Bereichen darauf einlassen und einarbeiten. Erfolg vor Breite.
Für übergreifende Prozesse, die mehrere Tools berühren, braucht es eine zentrale Orientierung. Die ersten drei Tests in einem Werkzeug, die nächsten in einem anderen zu schreiben und das über ein drittes Tool zu verbinden, ist kein erstrebenswerter Zustand.
Metriken, die in die falsche Richtung lenken, aber trotzdem nützen
Eine Test-Coverage, die einen Testfall pro Story zählt, sagt nichts über dessen Qualität aus. Ob der eine Testfall gut ist, bleibt offen. Als Aussage über Testabdeckung ist die Metrik schwach.
Trotzdem hat sie einen Wert. Die roten und blauen Balken auf den Charts sind einfach erklärbar, schnell sichtbar und managementtauglich. Damit lässt sich Aufmerksamkeit erzeugen und durchsetzen, dass die Leute mehr Zeit zum Testen bekommen.
Wer den Hebel kennt, nutzt ihn bewusst. Eine Metrik, die fachlich in die falsche Richtung zeigt, aber den Menschen mehr Testzeit verschafft, ist ihr Geld wert, solange daraus später bessere Testfälle entstehen.
Wo der nächste große Hebel liegt: exploratives Testen
Das größte ungenutzte Potenzial im Enterprise-Test sind die erfahrenen Anwender und ihr exploratives Testen. Sie haben jahrelange Erfahrung mit dem System und sind sehr empfänglich, wenn man ihnen zeigt, wie sie ihr intuitives Vorgehen schärfen.
Erfahrungsbasierte Techniken passen hier besonders gut, etwa Heuristiken in Form eines kompakten Cheatsheets. Die Anwender müssen sich nur die kurze Zeit nehmen, das zu lernen. Hier rennt man offene Türen ein.
Automation und exploratives Testen ergänzen sich, sprechen aber unterschiedliche Zielgruppen an. Solange die Automation noch dünn ist, trägt ein gutes exploratives Testen weit, gerade in einem Umfeld, in dem erfahrene Nutzer ohnehin nah am System sind und ein starkes Eigeninteresse haben, dass es funktioniert. Sie müssen schließlich später damit leben.
