Eine erfolgreiche Teststrategie für SAP BW & HANA Anwender

Jede Software und jede Logik muss getestet werden, auch die von SAP BW und HANA Objekten und zwar vollständig. Besonders wenn Sie in einem agilen Modus arbeiten möchten, ist einen gleichbleibend hohe Qualität von entscheidender Bedeutung. Zu oft verwenden SAP BW / HANA Benutzer nur die grafische Benutzeroberfläche (GUI) als bevorzugtes Testmedium. Zum einen, weil es einfach(er) zu bedienen ist und zum anderen, weil es kaum alternative Ansätze zur automatisierung gab.
Leider sind GUI Tests immer End 2 End (E2E) Tests und führen alleinig angewandt nie zum Erfolg, sondern zu unzureichenden Laufzeiten und mangelnder Abdeckung.
In diesem Artikel erklären wir die Hintergründe warum dies so ist, welche zusätzlichen Testmethoden verwendet werden sollten und welche verbesserte Teststrategie sich daraus ergeben. Am Ende wird der Leser wissen, wie man effizient SAP BW Transformationen, BEx Queries, HANA Calcilation Views / Prozeduren testet, um Scrum oder DevOp fähig zu werden.

Die Grenzen von GUI basiertem E2E Testen

Eines ist klar - es gibt kein Schweizer Taschenmesser in der Softwaretechnologie und erst recht nicht für die Testautomatisierung, sprich ein Vorgehen, daß für alles das Beste ist. Genauso wenig können Sie mit GUI Tests, die immer den gesamten Software Stack End2 End testen, nicht erfolgreich sein. Dafür gibt es etliche Gründe, hier sollen die wichtigsten aufgelistet sein:

  • es ist eine kostenintensive Testdatenverwaltung erforderlich
  • die Testausführung ist zu langsam und zu teuer (nicht effizient), weil durch einen Testfall mehr getestet und abgedeckt wird als erforderlich
  • zu viele Systemabhängigkeiten, weshalb Testfälle schnell ungültig werden
  • es ist kein umfassendes Testdesign möglich (nicht effektiv)
  • eine Fehleruntersuchung bezieht den gesamten Stack ein und basiert auf Massendaten, was sehr kostspielig und zeitaufwendig ist
  • kann nur auf dem Test- / Qualitätssystem durchgeführt werden und benötigt dafür vorab Transporte

Der GUI Ansatz wird wohl häufig gerne verwendet, weil es eine tolles Feature gibt: "Screen-Recording". Dabei werden die Aktionen der Tester oder Benutzer aufgenommen und einfach als Testfall wieder "abgespielt". Alternativ dazu können Logs ausgelesen werden. Die Testfallerstellung wird beschleunigt und die Verwendung ist recht intuitiv. Aber irgendwann wird man dennoch den Punkt erreichen, an dem die GUI Tests zu teuer, zu langsam und ineffizient werden. Trotz immenser Anstrengungen laufen die Tests nicht über Nacht oder am Wochenende durch und Sie können die Qualität und die Liefertermine nicht mehr garantieren. Aus diesem Grund sollten GUI Tests Teil des Integrationstestens sein und den folgenden Zwecken dienen:

  • das Zusammenspiel der Schnittstellen von Objekten / Modulen zu testen
  • Prozessabläufe zu validieren (z. B. Prozessketten)
  • Laufzeiten validieren
Für Prüfungen der Anforderungen auf kleinster Granularität (siehe Entwicklertests), reicht diese Testmethode bei weitem nicht aus (weshalb gute Entwickler auch einen anderen nutzen, aber dazu mehr im Folgendem). Entwickler wissen, daß bei jeder Änderung, einmal vor und nach der Änderung, getestet werden muss. Dadurch wird sichergestellt, daß vor der Änderung alles funktionierte und durch die Änderung keine bestehende Anforderung fehlerhaft wurde. Wie also sollte es mit UI Tests möglich sein, nur ein Objekt dediziert zu testen, ohne Abhängigkeit zu anderen parallelen Testern und dies auch noch schnell auf dem Entwicklungssystem? Eben, es geht nicht. Also macht man es in der Praxis, besonders bei späteren Änderungen, nicht mehr.
Am Ende erhält man das so „anziehende“ Ice-Cream Anti-Pattern, in dem die Aufwände falsch herum verteilt sind:

Test anti-pattern Eiswaffel
Das Ice Cream Anti-Pattern das dann zu Tage tritt wenn man die Aufwände nicht nach unten schieben tut oder kann

Nahezu alle stehen vor diesem Problem

Auf der SAP Tech-Ed wurden wir meist gefragt was man in solch einem Fall machen kann, wenn man genau diese Grenzen der Nutzbarkeit von UI Tests erreicht hat. Unser Antwort darauf: mehr Automatisierte Komponententests einsetzen und weniger UI basierte Integrationstests. Genau diese Kunden waren an dem Punkt zu bemerken, das Sie mit dem falschen Tool versucht hatten das große Ganze zu erledigen.

Qualitätssicherung erfordert automatisierte Komponenten Tests

Die Lösung zu obigem Problem lautet Komponententests (aka Unit Tests). Beim Komponententesten wird ein Objekt isoliert und kann somit unabhängig von der Systemumgebung oder anderen abhängigen Objekten getestet werden. Das ist perse nichts Neues, jedes Industrieunternehmen arbeitet nach diesem Schema. Ein Auto wird nicht das erste mal auf der Straße getestet und ein Laptop nicht das erste mal im zusammengebauten Zustand. Vielmehr geht es darum, dem finalen Big-Bang Integrationstest, eine unzählige Reihe von Komponententests voraus zu setzen, in der jedes Element einzeln isoliert und unabhängig von anderen validiert wird. Erst wenn alle Komponenten erfolgreich alle Komponententests absolviert haben, erfolgt der eigentliche Integrationstest als Zusammenspiels aller (Teil-) Komponenten.

Komponenten vs. Integrationstests
Komponententests testen einzelne Objekte bevor der eigentliche Big Bang test deren Zusammenspiel integrativ und oft dann E2E testet

Beim Software Komponententesten werden Teile der Software separiert vom Rest getestet. Man fokussiert sich komplett auf die Validierung der Funktionalität einer Klasse, SAP BW Transformation, Query, HANA Calculation View, Procedure. Das ist für SAP Anwender nicht einfach, doch die Vorteile sind immens:

  • es wird kein „Testdaten Management“ benötigt
  • Tests werden bereits auf dem Entwicklungssystem durchgeführt, da AUTs unabhängig von den Daten und anderen Objekten des Systems sind (was sie zu Regressionstests macht), was zu sehr stabilen Testfällen und sehr schnellen Tests führt (es ist kein Transport zum Qualitätssystem mehr erforderlich)
  • Ergebnisse sind konstant und unabhängig vom Systemzustand-/variablen > Regressionstests
  • mittels Test Design lässt sich die Anzahl der Testfälle auf das benötigte Minimum reduzieren (effizient)
  • Jeder kann parallel zu anderen testen
Komponententests sind perse Regressionstests und voll automatisiert. Doch wenn Komponententests so viel bringen, warum verwenden viele SAP BW oder HANA Anwender diese kaum?
Dafür gibt es einige Gründe, der relevanteste aber liegt wohl in einer fehlenden Unterstützung für das SAP BW / HANA. Es gibt zwar AUTs (ABAP Unit Tests), diese lassen sich für die SAP BW / HANA Objekte aber nicht nutzen. Selbst wenn, erfordern Sie Entwicklerwissen zur Erstellung und Ausführung.
Daher haben wir es uns zur Aufgabe gemacht, Komponententests für SAP BW Anwender verfügbar zu machen, ganz ohne Entwicklerwissen, sodaß selbst der Fachbereich mitwirken kann. Dadurch entstehen viele weitere neue Vorteile, wie das Wegfallen von Schattentests und ein hohes Vertrauen in die Qualitätssicherung. Fingerpointing wird es so nicht mehr geben. Das wichtigste aber ist wohl, das somit eine ganz andere Teststrategie möglich ist.

Die optimale Teststrategie für SAP BW / HANA

Die optimale Teststrategie basiert unserer Meinung nach auf der Testpyramide (erstmals wohl vorgestellt von Mike Cohen), die besagt, daß man die Tools und Aufwände gemäß Ihren Kosten/Nutzen (Abdeckungsgrad) einsetzen sollte. Von den Methoden zur Funktionalen Validierung, sind das grob: AUTs, Integrationstests und manuelle Tests. Der Großteil der Funktionalität, mit 70-80 %, sollten über AUTs getestet werden, der Rest durch Integrationstests, UATs, manuelle Tests. Was nur schwer zu automatisieren ist, verbleibt als manueller Test.

Die optimale Teststrategie für SAP Applikationen
Die optimale Teststrategie für SAP Applikationen

Durch die Verlagerung der Aufwände, wird das initiale Problem, das Tests im SAP BW Umfeld nicht mehr zeitlich durchlaufen und den Kostenrahmen sprengen, aufgelöst. Es kann eine vollautomatisierte Abdeckung aller Testfälle erreicht werden, was die Grundlage für Dev-Ops und Scrum ist.
Ein Scrum Zyklus ohne eine hohe Testautomatisierung für ein SAP BW Team wird am Ende nur noch im Testen enden, oder nicht mehr, bzw. nur begrenzt testen, die wahrscheinlich häufigste aller Lösungen.
Dies hat auch positive Auswirkungen auf das Arbeiten in der SAP Landschaft. Der Hauptteil der Tests erfolgt im Entwicklungssystem, ohne die Notwendigkeit von Transporten. Das beschleunigt die Entwicklung zusätzlich. Fehler aus der Produktion können über AUTs einfach im Entwicklungssystem nachgestellt und gefixt werden, Sie sind so auch automatisch und für immer getestet.

Die Teststrategie in der SAP Landschaft
Die Teststrategie in der SAP Landschaft

Durch die hohe Granularität des Testens, erlauben Komponententests die Anforderungen vom Fachbereich direkt zu verknüpfen, bspw. aus JIRA oder HP-QC. Das spannende daran ist, das aus einer Anforderung ein AUT wird und die Logik dadurch perfekt dokumentiert wird, eben eine automatisierte Dokumentation. Stellen Sie sich vor, externe Berater oder Mitarbeiter verlassen das Projekt und deren Entwicklungen sind mittels automatischer Komponententests vollständig abgesichert und dokumentiert. Das wird den Unterschied ausmachen, ob man bei späteren Änderungen schwitzt oder in Sekunden nur einen Knopf zu drücken braucht um zu validieren, daß alle Anforderungen erfüllt sind.

Zusammenfassung

Exzessives End 2 End Testen führt unausweichlich zum Anti-Muster der Eiswaffel. Testausführungen dauern zu lange, sind zu kostenintensiv und die Agilität und Qualität der Entwicklungen ist nicht mehr gewährleistet. Eine vollständige und optimierte Testabdeckung kann auf diesem Weg nicht erreicht werden. Gemäß der Test Pyramide sollten Testaufwände primär auf untere Ebenen verlagert werden. Durch einen Fokus auf vollautomatische Komponententests (aka Unit Tests) können die genannten Probleme von E2E Tests aufgeweicht und eine optimale Testabdeckung erreicht werden. Mit unserer Lösung xGile können Sie AUTs ohne zu Programmieren über eine einheitliche Benutzeroberfläche für SAP BW-Transformationen, Abfragen, HANA-Berechnungsansichten und -Prozeduren erstellen.

Eine effiziente und vollständige Testabdeckung in SAP BW ist möglich!