Kaum eine Projektphase wird so oft gekürzt wie die Testphase – und kaum eine rächt sich so verlässlich. SAP-Testmanagement ist keine Qualitätssicherung am Projektende, sondern die Disziplin, die entscheidet, ob Sie am Go-Live-Tag wissen, was funktioniert. Wer erst sechs Wochen vor dem Stichtag mit dem Aufbau von Testfällen beginnt, testet nicht die eigenen Geschäftsprozesse, sondern klickt die Oberfläche durch. Dieser Beitrag beschreibt, wie strukturiertes Testen aufgebaut wird, welche Teststufen wirklich nötig sind und woran Testmanagement im Mittelstand typischerweise scheitert.

Warum SAP-Testmanagement mehr ist als Fehlersuche

Der offensichtliche Zweck des Testens ist das Finden von Fehlern. Der wichtigere ist ein anderer: Testen erzeugt die Informationsgrundlage für die Go-Live-Entscheidung. Ohne dokumentierte Testergebnisse ist diese Entscheidung eine Einschätzung – in der Regel die Einschätzung derjenigen, die das System gebaut haben und deren Zielfunktion die Fertigstellung ist.

Mit strukturiertem Testmanagement beantworten Sie dagegen prüfbare Fragen: Welcher Anteil der als kritisch eingestuften Geschäftsprozesse ist vollständig durchlaufen? Welche Fehler sind offen, mit welcher Auswirkung auf welchen Prozess? Welche Prozesse sind gar nicht getestet? Erst diese Antworten machen aus einem Termin eine Entscheidung.

Der zweite Nebeneffekt wird häufig unterschätzt: Testen ist die wirksamste Form der Anwenderschulung. Wer als Key User seinen eigenen Prozess im neuen System einmal vollständig durchlaufen hat, ist am Go-Live-Tag arbeitsfähig. Wer nur eine Schulungspräsentation gesehen hat, ist es nicht.

Die Teststufen im SAP-Projekt

Komponenten- und Funktionstest

Prüft einzelne Bausteine isoliert: eine Konfiguration, eine Eigenentwicklung, ein Formular. Liegt in der Verantwortung derjenigen, die den Baustein erstellt haben. Findet technische Fehler, sagt aber nichts über die Prozessfähigkeit aus.

Integrationstest

Die zentrale Stufe. Hier laufen Geschäftsprozesse über Modul- und Systemgrenzen hinweg: vom Kundenauftrag über Disposition, Fertigung und Lieferung bis zur Faktura und deren Verbuchung. Genau an diesen Übergängen entstehen die Fehler, die im isolierten Test unsichtbar bleiben – insbesondere an Schnittstellen zu Vorsystemen, Lagerverwaltung, EDI oder Versanddienstleistern.

Regressionstest

Stellt sicher, dass bereits funktionierende Prozesse durch neue Änderungen oder Korrekturen nicht wieder brechen. In der späten Projektphase, in der täglich Transporte eingespielt werden, ist dies die Stufe mit dem höchsten Wiederholungsaufwand – und damit der natürliche Kandidat für Automatisierung.

Anwenderakzeptanztest

Der Fachbereich prüft anhand eigener realistischer Vorgänge, ob er mit dem System arbeiten kann. Nicht die IT gibt hier frei, sondern derjenige, der später damit arbeitet. Dieser Test ist nicht verhandelbar: Eine technische Abnahme ohne fachliche Freigabe ist der klassische Weg in einen Go-Live, der im Echtbetrieb korrigiert wird.

Woran SAP-Testmanagement in der Praxis scheitert

  • Das Testfenster ist der Projektpuffer. Verzögerungen in der Realisierung werden am Ende aufgeholt – zulasten des Tests. Aus acht Wochen werden drei.
  • Testfälle entstehen aus dem System, nicht aus den Anforderungen. Getestet wird dann, was gebaut wurde, nicht was gefordert war. Lücken bleiben unsichtbar.
  • Keine Testdaten. Ohne realistische Stamm- und Bewegungsdaten laufen nur Musterfälle. Die Sonderfälle, die im Betrieb dreißig Prozent des Aufkommens ausmachen, werden nie geprüft.
  • Key User ohne Freistellung. Testen wird zusätzlich zum Tagesgeschäft erwartet und entsprechend unvollständig erledigt.
  • Fehler ohne Bewertung. Eine ungewichtete Fehlerliste macht nicht entscheidungsfähig. Ohne Kritikalität und Prozessbezug lässt sich nicht beurteilen, ob ein Go-Live vertretbar ist.
  • Kein Nachweis. Wird nicht dokumentiert, was mit welchem Ergebnis getestet wurde, ist der Test für die Abnahme wertlos.

Testfälle aus Anforderungen ableiten

Der entscheidende methodische Punkt: Testfälle gehören an die Anforderungen gekoppelt, nicht an das fertige System. Jede verbindliche Anforderung braucht mindestens einen Testfall, der ihre Erfüllung nachweist. Diese Zuordnung – in der Praxis als Nachverfolgbarkeit oder Traceability bezeichnet – leistet zwei Dinge auf einmal. Sie zeigt Abdeckungslücken, also Anforderungen ohne Test. Und sie zeigt bei einem Fehler unmittelbar, welche fachliche Zusage betroffen ist.

Praktisch bedeutet das: Der Aufbau der Testfälle beginnt mit der Anforderungsspezifikation, nicht nach der Realisierung. Wo die Grundlage dafür entsteht, beschreiben wir unter Phase 0 – Anforderungsmanagement; die operative Umsetzung im laufenden Projekt finden Sie unter Testmanagement im SAP-Projekt.

Ein zweiter Hebel liegt in der Priorisierung. Vollständige Abdeckung aller denkbaren Fälle ist in einem Mittelstandsprojekt weder finanzierbar noch nötig. Wichtig ist eine bewusste Auswahl: Welche Prozesse stehen still, wenn sie nicht funktionieren? Welche Fehler wären nach dem Go-Live nur mit hohem Aufwand korrigierbar – etwa falsche Bestandsbuchungen oder fehlerhafte Fakturen? Diese Prozesse werden vollständig getestet, andere risikobasiert reduziert.

Testdaten: der unterschätzte Engpass

Ein sauber geplanter Integrationstest scheitert regelmäßig daran, dass die Daten fehlen. Testen braucht Material: Kundenstämme mit den tatsächlich genutzten Konditionen, Materialien mit realen Stücklisten, offene Posten, laufende Aufträge. Anonymisierte Produktivdaten sind dafür meist die beste Grundlage – ihre Bereitstellung ist aber ein eigenes Arbeitspaket mit Vorlaufzeit, keine Nebentätigkeit.

Ebenso wichtig ist die Wiederherstellbarkeit. Ein Testsystem, dessen Datenbestand nach zwei Wochen Testbetrieb inkonsistent ist, blockiert alle weiteren Durchläufe. Definierte Ausgangszustände und die Möglichkeit, dorthin zurückzusetzen, gehören in die Testplanung.

Abnahmekriterien und Go-Live-Entscheidung

Abnahmekriterien werden vor dem Test festgelegt, nicht während der Abnahme verhandelt. Belastbar sind Kriterien, die sich prüfen lassen: Alle als kritisch eingestuften Prozesse sind vollständig und fehlerfrei durchlaufen. Es existiert kein offener Fehler der höchsten Kritikalitätsstufe. Für Fehler mittlerer Stufe liegt eine dokumentierte Übergangslösung vor. Der Fachbereich hat den Akzeptanztest je Prozessbereich schriftlich freigegeben.

Der Wert solcher Kriterien zeigt sich genau dann, wenn der Termindruck am größten ist. Sie verhindern, dass am Stichtag darüber diskutiert wird, ob ein bekannter Fehler „noch tragbar“ ist – diese Frage wurde vorher beantwortet. Die laufende Verfolgung dieser Kennzahlen ist typischerweise Teil der Projekt- und Programmsteuerung.

Wann Testautomatisierung sinnvoll ist

Automatisierung lohnt sich dort, wo dieselben Abläufe vielfach wiederholt werden – also im Regressionstest und im späteren Releasebetrieb. Für den einmaligen Ersttest eines Prozesses ist der Aufwand für Erstellung und Pflege eines Skripts meist höher als der manuelle Durchlauf.

Ein weiterer Punkt wird oft übersehen: Automatisierte Tests sind Software und müssen gepflegt werden. Ändert sich der Prozess, ändert sich das Skript. Ohne diese Pflege entstehen Tests, die zwar grün melden, aber nicht mehr das Richtige prüfen. Wann sich der Einstieg rechnet, haben wir unter Testmanagement und Testautomatisierung zusammengefasst.

Wer das Testmanagement verantwortet

Testmanagement braucht eine benannte Rolle mit Zeitbudget. Wird die Aufgabe implizit beim Implementierungspartner belassen, entsteht ein Interessenkonflikt: Derjenige, der die Lösung gebaut hat, definiert dann auch, was als ausreichend geprüft gilt. Das ist nicht unseriös, aber methodisch ungünstig.

Bewährt hat sich eine Testmanagement-Rolle auf Kundenseite, die Testumfang, Priorisierung und Abnahmekriterien verantwortet und die Ergebnisse gegenüber dem Lenkungskreis berichtet. Die fachliche Durchführung leisten die Key User der Bereiche, die technische Fehlerbehebung der Partner. Diese Dreiteilung ist deutlich belastbarer als eine gemeinsame Verantwortung, in der am Ende niemand die Freigabe verweigert.

Der Aufwand dafür ist überschaubar, wenn er früh eingeplant wird – und erheblich, wenn er nachträglich unter Termindruck organisiert werden muss.

Ihr Go-Live rückt näher und Sie sind unsicher, ob der geplante Testumfang ausreicht? Unser kostenloser SAP-Krisencheck gibt Ihnen eine strukturierte Ersteinschätzung Ihrer Testreife – oder sprechen Sie uns direkt an über das Kontaktformular.