Smartes Testen
Wer testet, ist feige? Mitnichten! Wer nicht testet, kennt den Business Process Change Analyzer (BPCA) als Teilfunktionalität des SolMan nicht – und auch nicht dessen unschlagbare Vorzüge im Rahmen der Optimierung des Testumfangs.
Hiervon profitieren Prozessverantwortliche, Testmanager, Key User/Tester, die SAP-Basis, sämtliche Entscheidungsträger sowie die Endanwender. Und somit final die Prozessstabilität bzw. der SAP-Betrieb.
Denn: Wer wirklich smart Testen möchte, der benötigt solch ein Werkzeug. Und ganz gewiss sämtliche o. g. Akteure mit solidem Prozess-Know-how – vor allem, um die Ergebnisse des BPCA einzuordnen, insbesondere für den durch den BPCA definierten Testumfang und damit die definierten Testfälle. Hier liegt das Herzstück des BPCA.
Doch der Reihe nach:
- Wer kann den BPCA nutzen?
- Wie gestaltet sich der Weg dahin?
- Welche BPCA-Anwendungsfälle gibt es?
- Wie sieht das Ergebnis aus?
- Und welchen Nutzen ziehe ich hieraus?
- Und wieso gerade jetzt ein Artikel zum Thema BPCA, wo es diesen doch schon seit einigen Jahren gibt?
Letztere Frage zuerst: Mit SolMan 7.2 steht eine neu organisierte Lösungsdokumentation zur Verfügung. Lösung meint hier: Einheit aller Systeme inklusive Prozessdokumentation, Testfälle, ausführbare Einheiten ([Z-]Transaktion, [Z-]Report). Die Lösungsdokumentation kann nach Reifegrad unterschieden werden (Produktion vs. Wartung vs. Entwicklung/Sandbox). Dies ermöglicht eine inhaltlich trennbare Versionierung der Dokumentation.
Welche BPCA-Anwendungsfälle gibt es? Wie sieht das Ergebnis aus? Und welchen Nutzen ziehe ich hieraus? Die zentrale Fragestellung hinter allen Anwendungsfällen lautet: Welche geschäftskritischen Prozesse sind durch eine durchgeführte Änderung betroffen? Sprich, welche Prozesse sind (nach)zu testen, um die Prozessstabilität bzw. den SAP-Betrieb sicherzustellen?
BPCA-relevante Änderungen können sein: SP/EhP-Upgrade, Aktivierung Business-Funktion, (Objekt in einem) Transportauftrag, ChaRM-Änderungsdokument inklusive Transportaufträge sowie Objektlisten. Allen BPCA-relevanten Änderungen gemeinsam ist: Sie müssen in einem Transportauftrag im Entwicklungssystem vorliegen.
Das BPCA-Ergebnis ist eine Auflistung aller durch eine Änderung betroffenen Prozesse/Prozessschritte, das heißt der (nach)zu testende Umfang. Liegen hierzu keine Testpläne vor, können diese per Knopfdruck generiert und in der Test Suite abgelegt werden.
Schneller geht nicht! Ist der initial durch den BPCA definierte Testumfang zu umfänglich bzw. in der verfügbaren Zeit durch die verfügbaren Ressourcen nicht abarbeitbar, stehen pragmatische Ansätze zur Testumfangsoptimierung zur Verfügung (zum Beispiel 75-prozentige Testabdeckung: 10 Testfälle vs. 90-prozentige Testabdeckung: 100 Testfälle).
Der Nutzen ist klar: eine erste Empfehlung zum (nach)zu testenden Umfang. Oft eine intellektuell nicht leistbare Aufgabe. Zudem ressourcentechnisch oft nicht abbildbar.
Ein Review des jeweiligen BPCA-Ergebnisses durch einen Prozessexperten ist meines Erachtens unerlässlich. Denn: Wer den Nutzen des BPCA bewusst missverstehen will, sollte sich erst gar nicht auf die Reise machen.
Und damit zu den letzten Fragen: Wer kann den BPCA nutzen? Wie gestaltet sich der Weg dahin?
In den Genuss des BPCA kommen aktuell SAP-Enterprise-Support-Kunden. Der Weg zur BPCA-Analyse gestaltet sich in groben Zügen wie folgt: Prozesse und Prozessschritte definieren und diese mit ausführbaren Einheiten hinterlegen, die BPCA-Konfiguration in dem solman_setup durchführen und sogenannte „Technical Bill of Materials“ (TBOM) je ausführbarer Einheit auf Basis UPL/SCMON-Daten im Produktivsystem generieren.
Dann die Änderung in einen Transportauftrag packen, die BPCA-Analyse über diesen Transportauftrag laufen lassen, Ergebnis analysieren/interpretieren und gegebenenfalls Testplan hieraus erstellen lassen – fertig! Damit ist der Weg in Richtung „smartes Testen“ geebnet.
