Wer testet, ist feige

Beim SAP-Releasewechsel ist es mehr als sinnvoll, die Unternehmensprozesse nochmals vollständig in einer Prozesskette zu testen und ein erfolgreiches Upgrade dadurch sicherzustellen.

Soll nun das „SAP-System“ getestet werden, so beginnt meist die Frage, was überhaupt getestet werden soll und wie es getestet werden soll. Viele Kunden sind es dann gewohnt, die betagten Testpläne des letzten Patches zu organisieren und gegebenenfalls noch zu überarbeiten.

Allerdings stellt sich meist hier schon die erste Frage: Welche Transaktionen sind auf den Testplänen noch nicht verzeichnet und müssen aufgenommen werden, welche Reports sind veraltet und werden gar nicht mehr verwendet und können demzufolge auch unberücksichtigt bleiben.

Allein diese Zusammenstellung und Inventarisierung ist keine einfache Aufgabe. Ich habe einen IT-Verantwortlichen erlebt, der vier Wochen vor Beginn der Testphase die Fachabteilungen angewiesen hat, alle genutzten Transaktionen in ein Excel Sheet fortlaufend einzutragen.

Das ist zwar ein guter Anfang, stellt aber eine Sisyphusarbeit dar. Insbesondere reicht dann meist auch der Betrachtungszeitraum nicht aus. Mit dem Blueprint Generator, den SAP inzwischen als Hinweis ausliefert, können die im Produktivsystem genutzten Transaktionen inventarisiert und in der Lösungsdokumentation abgelegt werden.

Das ist zwar noch kein Testplan, aber so wird immerhin sichergestellt, dass alle verwendeten Transaktionen auch tatsächlich in einer Struktur inventarisiert sind. Somit kann auf einfache Weise eine Ausgangsbasis für einen Testplan geschaffen werden, die vor allem auch vollständig ist.

Der hilfreiche Blueprint Generator kann im Übrigen auch Delta-Updates durchführen, also bestehende Strukturen um neu dazugekommene Transaktionen ergänzen. Dies ist meist dann der Fall, wenn es schon eine Dokumentation gibt, diese aber etwas in die Jahre gekommen ist.

So entsteht ein mächtiges Testwerkzeug

Auf Basis der generierten Dokumentationsstruktur lässt sich dann ein Testplan aufbauen. Zwar kann technisch aus dieser Struktur dann auch ein Testplan erstellt werden und abgearbeitet werden.

Dieser Plan beinhaltet aber dann lediglich die Transaktionen. Dies ist in der Regel noch nicht sonderlich hilfreich, da noch relevante Vorgaben fehlen, mit welchen Stammdaten, Belegarten und Positionstypen auch eine Transaktion wirklich zu testen ist.

Sinnvollerweise werden die generierten Strukturen um die Excel-Dokumente ergänzt, die die meisten Kunden ohnehin auf Fileshares liegen haben und damit ihre Testfälle zum Teil organisieren.

Diese Dokumente können auch in einem späteren Schritt überarbeitet und feingeschliffen werden, in der Regel ist es jedoch wichtig, erst mal eine Ausgangsbasis und einen Anfang zu schaffen.

Sind die Dokumente hinreichend vollständig hinterlegt, so können nun tatsächlich aussagekräftige Testpläne erstellt werden. Aus den Testplänen werden üblicherweise Testpakete gebildet und diese werden einzelnen Personen zugeordnet.

Sinnvoll ist es, Prozesse so zu testen, wie diese auch in der Realität ablaufen, und nicht nur funktionsorientierte Einzeltests durchzuführen. Unter dieser Voraussetzung müssen „Testsequenzen“ gebildet werden, die den natürlichen Ablauf einer Prozesskette abbilden.

So können über diese Sequenzen auch mehrere Fachabteilungen an einem Ablauf zusammenarbeiten. Die De-luxe-Variante in Verbindung mit Testsequenzen sieht vor, dass Tester auch per E-Mail zum Test ihres Prozesses oder ihrer Transaktion aufgefordert werden.

Auch ein Reminder- Modell mit Eskalationsfunktion lässt sich in dem Framework realisieren. In Summe entsteht dann ein mächtiges Testwerkzeug. Die Testfälle und Testpläne werden im Idealfall auch kontinuierlich weitergepflegt.

Welche Geschäftsprozesse sind relevant?

Da der Testumfang in der Regel mit dem steigenden Funktionsumfang einer IT-Umgebung kontinuierlich wächst, ist es bei Integrationstests umso wichtiger, zielgerichtet zu testen.

Der Business Process Change Analyzer von SAP kann die relevanten Geschäftsprozesse ermitteln, die im Rahmen eines Upgrades, einer Business Function oder sogar mit einem Transport verändert wurden. Auf dieser Basis lässt sich dann eine erhebliche Vereinfachung und Verschlankung der Testverfahren abbilden, da dann nur noch die wirklich relevanten Geschäftsprozesse einer Prüfung unterzogen werden müssen.

Im Zusammenspiel mit einer Geschäftsprozessdokumentation und einem Change Management kann die Testmanagement-Komponente des
Solution Managers eine sinnvolle Ergänzung für ein Application Lifecycle Management liefern. Auch wenn hier oft aller Anfang schwer ist, kann auf einfachem Wege eine pragmatische Lösung erarbeitet und etabliert werden.