Die Entwicklung mit automatisierten Komponententests (auch als automatisierte Unit Tests - AUTs bekannt) ermöglicht ein beschleunigtes Projektvorgehen. Das liegt massgeblich an den folgenden drei Eigenschaften von Komponententests:
- es wird für die Testausführung kein Transport in das Testsystem benötigt
- auf der Granularität von Komponenten können Test Design Verfahren angewandt werden, die eine vollständige Testabdeckung ermöglichen
- es wird mit minimalsten Simulationsdaten und nicht mit Massendaten des Systems gearbeitet
Wie sieht nun ein Projektablauf im Detail aus?
Anforderungsaufnahme und Testfallerstellung
Jegliche Entwicklung muss den gestellten Anforderungen genügen. Diese kommen im SAP BW Umfeld in der Regel vom Fachbereich. Dabei muss einer Anforderung mindestens ein automatisierter Testfall gegenüberstehen. Bereits während oder nach der Anforderungsaufnahme können zusammen mit dem Fachbereich die zugehörigen Testfälle definiert werden. Die Anforderung enthällt bereits alle Informationen für den Testfall - bei welcher Ausgangssituation wird welches Verhalten erwartet, oder abstrakt ausgedrückt, welches X an Eingangswerten erzeugt welches Y an Ausgangswerten am Testobjekt.
In Zusammenarbeit mit dem Fachbereich reicht eine simple Visualisierung (bspw. als Powerpoint oder Excel) in der festgehalten wird, wie die Felder der Ausgangssituation belegt sind (das X) und welches Resultat in diesem Fall erwartet wird (das Y), der Erwartungswert.
“Die Testfalldefinition zusammen mit dem Fachbereich deckt sofort Anforderungslücken oder Unklarheiten auf.”
xGile Testen
Für jedes X muss ein eindeutiges Y hinterlegt werden können. Falls nicht, so kann man die Anforderung und Funktionalität auch nicht testen und auch nicht abnehmen. Daher muss der Fachbereich in die Lage versetzt werden das erwartete Verhalten definieren und beurteilen zu können, denn nur er kann die geforderten Anforderungen final abnehmen.
“Der Fachbereich muss Erwartungswerte und Testfälle definieren können, sonst könnte er die Entwicklungen nicht abnehmen.”
xGile Testen
Der Erfahrung nach stellt dieses Vorgehen kein Problem für den Fachbereich dar und die Testfalldefinition schreitet zügig voran. Am Ende erhällt man eine 100% Abdeckung alle Anforderungen, die bereits auf dem Entwicklungssystem ausgeführt werden können.
“Anforderungen sind Testfälle.”
xGile Testen
Daher kann man mit Komponententest ganz klar sagen, daß Anforderungen gleich Testfälle sind. Testfälle wiederum sind eindeutig mit Ihrem Testobjekt (SUT - System Under Test) verknüpft. Die automatischen Testfälle und somit "ausführbaren" Anforderungen beschreiben direkt das Testobjekt (BEx Query, BW Transformation, HANA Objekt, etc.). So entsteht eine "ausführbare" Dokumentation und zwar die Beste und immer Aktuellste die Sie je für ein SAP Objekt erhalten werden.
“Komponententests sind wie eine ausführbare Dokumentation.”
xGile Testen
Bei späteren Code-Änderungen sichern die Komponententests nicht nur die Anpassung vollständig ab, sondern beschreiben das SAP Objekt und die enthaltene Logik voll umfänglich. Übergaben zwischen Entwicklern oder ein Wechsel im Fachbereich sind dadurch ebenso abgesichert. Für diese Form der Dokumentation wird kein technisches Verständnis benötigt.
Vollständige Testabdeckung
Um die minimal notwendige Anzahl von Testfällen zu definieren und nicht redundante Testfälle zu erzeugen, bieten sich Ansätze aus dem Test Design, wie Entscheidungstabellen, Äquivalenzklassen oder Rändertests an. Neben Effizienz kann so auch die Vollständigkeit der Testabdeckung garantiert werden. Diese Verfahren werden bei zu grosser Varianz der Eingangswerte zu komplex und nicht mehr anwendbar. Dadurch wird klar, daß nur auf dem Detaillevel vom Komponententests, mit Ihre kleinen Fokus auf ein SAP Objekt, diese Ansätze zur Entscheidung einer vollständigen und optimalen Testabdeckung einsetzbar sind.
“Nur auf Ebene der Komponententests lässt sich eine optimale und vollständige Testabdeckung erreichen.”
xGile Testen
Mit dem beschriebenen Vorgehen können bereits alle Testfälle auf dem Entwicklungssystem erstellt, durchgeführt und eine 100% Testabdeckung erreicht werden. Dafür wird kein Transport in das Q-System benötigt, denn alle Testfälle enthalten die erforderlichen Testdaten. Im Entwicklungsystem finden in der Regel 70 - 80% der Testaufwände statt.
Optimierungszyklus
Nach der Validierung der Komponentenkorrektheit im Entwicklungsystem, findet der erste Transport in das Q-System, zum Test auf Realdaten statt. Hier können Ausreißer und die Laufzeit analysiert werden. Bei unerwartetem Verhalten, welches im BW nun auch einmal Daten getrieben ist, wird dieser Fehler im Entwicklungsystem als Komponententest nachgestellt, behoben und die Korrektheit aller Anforderungen an die Komponente nochmals vollständig validiert (defakto kann auch eine Überarbeitung des Test Designs stattfinden).
Nur so wird sichergestellt, das einmal gefundene Fehler nicht erneut auftreten und keine bestehenden Anforderungen durch die Anpassung korumpiert werden. Ein perfektes Sicherheitsnetz aus automatischen Komponententests. Im folgenden Video sehen Sie das exemplarische Testvorgehen für einen SAP HANA Calculation View:
En detail, sieht eine Anpassung wie folgt aus. Zuerst werden alle bestehenden Tests für eine Komponente ausgeführt. Alle sollten erfolgreich durchlaufen. So wird der Zustand vor der Änderung festgehalten. Dann kann die Anpassung erfolgen und im Anschluss die erneute Ausführung aller Tests. Sind alle erfolgreich durchgelaufen, kann man sicher sein, daß durch die Änderung keine neuen Defekte produziert wurden. Jetzt kann wieder der Transport in das Q-System stattfinden und mit dem Integrationstesten fortgefahren werden. Dieses Vorgehen wird auch bei Problemen im P-System angewandt. Es ist ersichtlich, daß von Iteration zu Iteration die Güte der Entwicklungen zunimmt und ein Qualitätsgrad erreicht wird, der so nur mit Komponententests möglich ist.
Zusammenfassung
Es ist offensichtlich, daß Anforderungen vom Fachbereich abgenommen werden müssen. Dafür tut dieser das Verhalten beschreiben in der Form, wenn diese Konstellation der Daten vorliegt (Berechnungswerte), dann ist das mein Erwartungswert gemäss Berechnungsanforderung. Diese aus X (Eingangswerte) folgt Y (Erwartungswerte) bestehenden Auflistungen sind bereits die Komponententestfälle. Daher können alle vollautomatischen Komponententests in xGile über ein simples grafisches Web UI, ohne technisches Wissen, erstellt werden.
Bereits im Entwicklungsystem kann so eine 100%ige Testabdeckung für ein SAP Objekt erreicht werden. Der Integrationstest End 2 End findet im Q-System statt. Dort oder im P-System gefundene Anomalien, werden als Testfälle im E-System nachgestellt. Nach der Erweiterung / Fehlerbehebung und erfolgreichem Passieren aller automatischen Tests, findet der Korrekturtransport in das Q-/ P-System statt. Über diesen Ansatz wird sichergestellt, daß keine neuen Fehler aufkommen können und die Qualität der Berechnungen konstant bleibt und sogar steigt. Nebenher erhällt man eine vollständige automatische Testabdeckung, was die Grundlage für Scrum oder DevOps ist.
