5 Stufen einer erfolgreichen Test-Strategie bei BI-Implementierungen

Die fünf wesentlichen Stufen einer erfolgreichen Teststrategie für SAP-BI-Implementierungen

Wie wichtig sind Tests in SAP BI überhaupt?

Es wird den ein oder anderen geben, der die drei goldenen Regeln für erfolgreiche SAP-BI-Projekte noch nicht kennt. Sie lauten:

„Testen, testen und dann noch einmal testen!

Und jetzt mal ganz im Ernst: Eine erfolgreiche Teststrategie für jede SAP-BI-Implementierung umfasst genau genommen sogar fünf ganz wesentliche Schritte. Diese lassen sich wie folgt zusammenfassen:

  1. Modultests
  2. Funktionstests
  3. Datenmigrations- und Integrationstests
  4. Performancetests
  5. User-Acceptance-Tests (UAT) & abschließende Freigabe

„Wenn Sie meinen, dass Tests zu teuer sind, sollten Sie sich darüber bewusst sein, was ein Auslassen dieser Tests kostet!“

Man hört diese Frage förmlich schon: „Was kosten mich denn diese ganzen Tests?!“

Es gibt immer wieder Kunden, die die Kosten für die erforderlichen Tests einer SAP-BI-Implementierung scheuen. Vielleicht verweisen sie darauf, dass die „Qualität“ eigentlich inbegriffen sein sollte – vorausgesetzt, das BI-Team hat bei der Entwicklung aller Berichtsobjekte gründlich gearbeitet.
Vielleicht wehren sie sich gegen eine Bereitstellung ihrer knappen Mittel für Testmaßnahmen und geben das Geld lieber für weitere Entwicklungen vor dem Go-live aus.
Und vielleicht stehen sie auch selbst unter Druck das „Maximum“ aus dem BI-Projektteam herauszuholen, solange es noch vor Ort ist – und all das sollte möglichst im festgelegten Projektumfang aus Zeit, Budget und Qualität liegen.

Und trotz all dieser Widerstände, die auf den ersten Blick für geringere Investitionen in Testläufe sprechen, zeichnet die Erfahrung aus SAP-BI-Projekten ein gegenteiliges Bild. Natürlich bedeutet die Entscheidung für gründlichere Tests auch erheblichen Mehraufwand, den es im Projektzeitplan frühzeitig zu berücksichtigen gilt – letztendlich können so aber in aller Regel auch die Gesamtkosten der Implementierung gesenkt werden.

Untersuchungen haben gezeigt, dass die tatsächlichen Kosten von Softwarefehlern abhängig vom Zeitpunkt ihrer Entdeckung exponentiell steigen können.

So gibt es zum Beispiel die 1-10-100-Regel:
Ein Fehler, der in der Entwicklungs- und anfänglichen Programmierungsphase noch 1 Euro kostet, kann während der Akzeptanztests schon 10 Euro und nach dem Go-live sage und schreibe 100 Euro kosten!

Unsere langjährige Erfahrung in BI-Projekten hat uns immer wieder gezeigt, dass Kosten gespart werden können, wenn Bugs bereits in den anfänglichen Testphasen entdeckt und behoben werden – je früher man also mit den Testläufen beginnt und je mehr Geld vorab in diese Tests investiert wird, desto mehr kann bei den Projektkosten sowohl kurz- als auch langfristig eingespart werden.

So mancher BI-Projektmanager schätzt das mögliche Einsparpotential auf das Zwei- bis Dreifache der Kosten! Und wenn sich die Projektverantwortlichen so noch nicht vom Wert zusätzlicher Tests überzeugen lassen, gilt es auch nicht zu vergessen, dass ebenso die Aufwände und der Druck direkt vor dem Go-live ganz erheblich reduziert werden können – ganz zu schweigen davon, dass so auch die Fachabteilungen beruhigt werden können –, wenn die anfängliche Konzentration auf die Tests allmählich Wirkung zeigt. Spätestens dann zeigt sich, dass sich diese Investition in die Qualität mehr als lohnen.

Testen oder Nichttesten, das ist hier (nicht) die Frage …

Da wir uns jetzt einig sind, dass Tests ein wesentlicher Bestandteil eines jeden SAP-BI-Projekts sind, stellen sich natürlich weitere Fragen:
Was genau muss wann, wie und wie oft getestet werden?

Grundsätzlich gilt: Je mehr man testet, desto geringer fallen die Gesamtentwicklungskosten aus.

Geht man beim Testen dann noch strukturiert vor, eröffnen sich weitere Vorteile. Hält man die Testergebnisse zum Beispiel fest und setzt sie in unmittelbaren Nutzen um, wird mit jeder Wiederholung von Testdurchläufen und Testphasen die Qualität des Endprodukts (eure BI-Berichte) gesteigert. Auf diese Weise stoßt ihr einen Prozess kontinuierlicher Verbesserung in eurem BI-Projekt an, der eurem SAP-BI-System auch lange nach Abschluss des ursprünglichen Implementierungsprojektes noch zugutekommt.

Was genau umfassen SAP-BI-Tests eigentlich – was gehört dazu?

Testläufe sind genau genommen regelmäßige „Qualitätsprüfungen“, also eine Gelegenheit, die Qualität einer Implementierung an festgelegten Punkten im Projektzeitplan und unter Berücksichtigung verschiedener Aspekte zu messen. Dabei sollte jeder Test durch Nachverfolgung und Dokumentation sowohl der SAP-BI-Testfälle als auch der Mängel in einem geeigneten Testtool unterstützt werden.
„HPQC” – HP ALM Quality Center ist ein häufig genutztes Testtool, aber natürlich gibt auch viele weitere Tools am Markt.

Wir bei Inspiricon wissen, dass jede Kundensituation einzigartig ist. Es gibt keine „Standardvorgehensweise“, die sich auf jedes beliebige Szenario anwenden lässt. Es gibt jedoch ein bewährtes Framework, das zur Strukturierung der Testaktivitäten eingesetzt werden kann. In unseren SAP-BI-Projekten konzentrieren wir unsere umfassenden Erfahrungen und unser Fachwissen aus vorausgegangenen Projekten, um auf die spezifischen Herausforderungen eingehen zu können. Darüber hinaus erarbeiten wir eine individualisierte Teststrategie und einen Testplan, um maximale Qualität für eure SAP-BI-Implementierung sicherzustellen und die Gesamtkosten möglichst gering zu halten.

Die folgenden Testaktivitäten haben nicht den Anspruch vollständig zu sein oder eine Standardvorgehensweise abzubilden. Sie dienen lediglich als Beispiel für einige der wichtigsten Qualitätsprüfungen, die im Rahmen unserer fünf wesentlichen Stufen von SAP-BI-Testläufen erfolgen können:

1. Modultests:

Gute Modultests liefern die Grundlage für alle weiteren Schritte. Diese ersten Tests umfassen eine gründliche Prüfung der Gestaltungsarbeit, gefolgt von einer schrittweisen Dokumentation der Daten auf ihrem Weg durch die verschiedenen Schichten eurer BI-Architektur, sowohl im persistenten als auch im nicht-persistenten Status.
Je größer die Zahl der erkannten und (einfacher) behobenen Bugs zu diesem Testzeitpunkt ausfällt, je größer sind die Einsparungen insgesamt!

  • Dokumentation und Freigabe der technischen Daten (dies kann zum Beispiel eine Beschreibung der Berichtsgestaltung und der Datenflüsse in Word, eine visuelle Übersicht in PowerPoint und eine Excel-Tabelle mit umfassenden Mappings des Datenmodells umfassen)
  • Treffen der Fachabteilung zur Freigabe der Berichtslayouts und -köpfe (schon bevor die Testdaten verfügbar sind)
  • Interne Tests durch den BI-Entwickler, einschließlich gründlicher Prüfung der Daten in jeder Stufe des Datenflusses und eines direkten Vergleiches der Quellsystemdaten, der SAP-BW-Daten und der Daten im endgültigen BI-Bericht

2. Funktionstests:

Um die Funktion effektiv testen zu können, muss im Team das notwendige Fachwissen nicht nur bezüglich der fachlichen Anforderungen und der Prozesse im ERP-Quellsystem vorliegen, sondern auch in Hinblick auf das Datenmodell, die Datenflüsse, die Berichtsgestaltung in SAP BI und die Möglichkeiten, diese beiden Welten zu „überbrücken“ bzw. zu vereinen.

  • Tests zur Sicherung der Qualität (QA), vor allem durch interne BI-Projektverantwortliche mit eingehenden Kenntnissen des vorherigen Berichtssystems und der zugrunde liegenden Geschäftsprozesse
  • Dokumentation der Testfälle in Testsoftware wie zum Beispiel HPQC
  • Pre-UAT-Tests (Pre-User Acceptance Testing) auf Fachseite, einschließlich Mängelbehebung und erneuter Tests, umfassender Dokumentation und Nachverfolgung im Testtool, z. B. HPQC
  • Interne Tests durch das BI-Team, koordiniert durch die Entwicklungsleiter und Dokumentation in einer zentralen Statusliste bzw. einem „Katalog“ aller BI-Berichte

3. Datenmigrations- und Integrationstests:

An diesem Punkt erfolgt die Überprüfung der Datenmigration und der reibungslosen Integration mit dem/den Quellsystem(en). Datenflüsse, einschließlich InfoPackages, DTPs, Transformationen und letztendlich der Prozessketten, die das vollständige tägliche Laden der Daten automatisieren, müssen koordiniert und auf Vollständigkeit, Richtigkeit, korrekte Fehlerbehandlung und Stabilität geprüft werden. Und selbstverständlich müssen alle BI-Objekte, die ins Produktivsystem transportiert werden, vor dem Go-live geprüft werden!

  • Prüfung der Datenmigrationen
  • Prüfung vollständige Datenübernahme gegenüber Delta-Datenübernahme
  • Optimierung und Test der täglichen und periodischen Prozessketten
  • Konfiguration und Test der Meta-Ketten
  • Aktivierung und Prüfung der automatisierten BW-“Housekeeping“-/Bereinigungsaufgaben
  • Prüfung der transportierten BI-Objekte im Produktivsystem vor dem Go-live

4. Performancetests:

An dieser Stelle erfolgt eine gründliche Prüfung der Performance der Systemarchitektur sowie des System-Sizings. Die Aktualisierungszeiten und akzeptablen Performancewerte werden anhand der Anforderungen auf fachlicher Seite festgelegt, üblicherweise werden dabei als Vergleichswert die Performance-Benchmarks der vorausgegangenen Berichtssysteme zu Grunde gelegt.

Automatisierte Performance-Tests durch Drittanbieter-Software wie LoadRunner. Dabei werden unter anderem die folgenden Aspekte berücksichtigt:

  • Lastspitzen durch gleichzeitige Benutzer
  • Anfängliche Ladezeiten für Berichtsstruktur und Eingabeaufforderungen
  • Aktualisierungszeiten für Berichte mit Daten
  • Maximale durch Berichtsabfragen zurückgegebene Datenmengen
  • Speichervolumen für gespeicherte Berichte und Zeitpläne

5. User-Acceptance-Tests (UAT) und abschließende Freigabe:

Hier wird es erst richtig interessant, denn hier haben die Endanwender als eigentliche „Empfänger“ unseres finalen Produkts endlich auch Gelegenheit, ihre Berichte zu testen! Sie können die Qualität der Berichtergebnisse durch Durchführung von Testfällen für Daten- und Plausibilitätsprüfungen prüfen. Darüber hinaus können sie mögliche Mängel und Erweiterungen im Testtool protokollieren und erfolgte Fehlerbehebungen erneut prüfen. Bei der endgültigen Freigabe eines Berichts auf der Fachseite haben immer die Endanwender das letzte Wort.

  • Datenprüfung im UAT auf Fachseite, einschließlich einer weiteren Runde an Fehlerbehebungen und erneuter Tests
  • Plausibilitätsprüfung im UAT auf Fachseite zum Abgleich der ursprünglichen Berichte mit den migrierten/replizierten SAP-BI-Berichten in Hinblick auf Zweck, verfügbare Spalten und ungefähre Ergebnisse. Dies kann trotz der zunehmenden Unterschiede zwischen den beiden Datenbestände nützlich sein: „laufende“ Live-Daten aus dem Quellsystem gegenüber dem „Snapshot“ der ursprünglich migrierten Daten und den gesammelten Daten aus den Akzeptanztests.
  • Weitere Tests nach Abschluss des UAT und Validierung durch größer angelegte Testgruppen mit umfangreicherem Datenmaterial, so zum Beispiel mit zusätzlichen migrierten Daten und weiteren gesammelten Testdaten.
  • Finale Freigabe auf Fachseite durch „bestandene“ Testfälle im Testtool, z. B. HPQC.

Es soll noch einmal betont werden, dass es sich hierbei lediglich um einige Beispiele empfohlener Schritte in einer umfassenden Teststrategie für BI-Implementierungen handelt und dass diese in keiner Weise eine Standardherangehensweise darstellen sollen. Jedes Implementierungsprojekt ist einzigartig und es sollte daher auch für jeden Kunden eine eigene Teststrategie und ein eigener Plan entwickelt werden, der den spezifischen Anforderungen und SAP-BI-Szenarien gerecht wird.

Qualität ist Trumpf!

Zusammengefasst ist eine umfassende Teststrategie unterstützt durch wirksame Strukturierung, Nachverfolgung und Dokumentation in einem geeigneten Testtool die beste Investition zur Sicherstellung eines reibungslosen Go-lives für Endanwender und eines zukunftssicheren BI-Systems mit nachhaltig hoher Qualität!

Je mehr Zeit und Geld ihr von Anfang an für Testzwecke investieren, desto weniger Probleme werden auch beim Go-live auftreten – und desto geringer werden auch die Gesamtkosten für das SAP-BI-Projekt ausfallen!

Ihr benötigt Unterstützung bei der Entwicklung einer eigenen Teststrategie für SAP BI? Dann ruft mich heute noch an oder schreibt mir eine E-Mail!

Autor dieses Beitrags
Andrea Taylor Senior Consultant SAP BI
Tel.: +49 (0) 7031 714 660 0
E-Mail: info@inspiricon.de