Insbesondere bei der Einführung unternehmensweiter Softwarelösungen ist das Thema Testautomation nicht mehr wegzudenken. Dabei stehen neben Kosten- und Effizienzsteigerungen vor allem der Aspekt der messbaren Qualitätsverbesserung im Vordergrund der Betrachtung.

Insbesondere bei der Einführung von Standardsoftwarelösungen, die das Kerngeschäft bzw. die Kernprozesse des Unternehmens abbilden sollen, kommt der Testautomation eine strategische Bedeutung zu.

Was versteht man unter Automation?
Im Allgemeinen versteht man unter Automation die Zusammenfassung wiederkehrender Funktionsabläufe. Im Softwareumfeld setzt man dazu entsprechende Tools ein, um automatisiert Testprozesse ablaufen zu lassen. Das Ergebnis, ob die Ausführung erfolgreich war oder nicht, steht dann in einem Durchführungsprotokoll. Im Grunde geht es um die Ausführung einer Software ohne dazu Menschen vor dem Bildschirm sitzen zu haben.

Welche Vorteile ergeben sich daraus?
Die Automation von Prozessen soll in einem Projekt eine gewisse Unabhängigkeit von Personal bringen. Hilfreich ist dies in den Testphasen eines Softwareprojektes. Nachdem die Software realisiert wurde muss sie auf Ihre Eignung hin überprüft werden. Es muss nachgewiesen werden, dass die Geschäftsprozesse mit Einsatz dieser neuen Software weiterhin funktionieren.

In Softwareprojekten sind immer drei Parameter kritisch: Zeit, Kosten, Ressourcen. Hinzu kommt, dass in Banking Projekten die Qualitätssicherung immens wichtig ist. Nichts ist fataler wenn man Kunden fehlerhafte oder falsche Daten aushändigt. Die Erfahrung sagt, dass man den gleichen Aufwand, den man für die Realisierung hat auch in die Qualitätssicherung investieren muss. Insbesondere hierbei kommt die Testautomation ins Spiel.

Es gibt am Markt diverse Anbieter von Testing Tools. Jedes von Ihnen hat seine Vor- und Nachteile. Es ist teilweise eine subjektive Entscheidung, welches Tool man für ein Projekt auswählt. In manchen Projekten wird einem diese Frage genommen, da der Kunde entsprechende Werkzeuge zur Verfügung stellt. In SAP Projekten hingegen ist es sehr einfach. Man nutzt die mitgelieferten SAP eigenen Werkzeuge eCATT und die Test Workbench vom Solution Manager.

Was ist eCATT?
Mit eCATT (extended Computer Aided Test Tool ) bietet SAP ein Tool an, welches integraler und damit kostenfreier Bestandteil der SAP Basiskomponente ist. Außer dem Aufzeichnen und Abspielen von Transaktionen, verfügt dieses Tool über verschiedene zusätzliche Funktionen zum Testen von Anwendungen und Programmteilen:

• Direkte Lese- und Schreiboperationen auf der Datenbank
• Aufrufen und Ausführen von Funktionsbausteinen und BAPI’s
• Ausführen von ABAP innerhalb der Scripte
• Testen von Transaktionen und Reports
• Testen von Anwendungen, die außerhalb der SAP GUI für Windows und SAP GUI für Java laufen (mittels Schnittstelle für Drittanbieter)

Darüber hinaus ist eCATT eingebettet in die „Test Workbench“. Die „Test Workbench“ ist eine komplette Programmsuite um Testpläne, Testfallkataloge und Testfälle, also das gesamte Testszenario zeitlich und hierarchisch gegliedert, an zentraler Stelle zu verwalten und den Testbeauftragten, wie auch den Entwicklern zur Verfügung zu stellen.

Über das Info-System der „Test Workbench“ hat man jederzeit die Möglichkeit, sich ad hoc zum Stand der Testaktivitäten und Testergebnisse zu informieren. Ergebnisse und Status müssen nicht mehr manuell in andere Dokumente übertragen werden.

Was heißt das konkret für ein SAP Banking Projekt?
Beziehen wir nun diese Informationen auf eine zu realisierende Demo Bank, die auf der SOA konformen Plattform SAP Banking Services 6.0 basiert und im Release 1 die komplette Funktionalität aus dem Passiv-Geschäft bietet!

Realisiert man ein Core Banking System wie die „Demo Bank“ auf der sogenannten grünen Wiese, was bedeutet, dass man kein Altsystem ablösen und dessen Daten ins neue SAP System migrieren muss, hat man zwei Themenstellungen zu klären. Auf der einen Seite stellt sich die Frage, welche Prozesse man sinnvoller Weise automatisiert. Auf der anderen Seite ist zu klären, wie man die „Demo Bank“ mit Testdaten füllen kann, um sinnvolles Vorführen ermöglichen zu können.

Welche Tests kann man sinnvoller Weise automatisieren?
Hingegen zu einem herkömmlichen Softwareentwicklungsprozess wird bei der Umsetzung einer SAP Lösung weniger programmiert. Die verschiedenen Module existieren bereits und werden über das Customizing auf die Kundenwünsche angepasst. Der größte Programmieraufwand fällt auf die Erstellung der Schnittstellen und die Umsetzung von Kundenwünschen die nicht im SAP Paket realisiert sind.

In aller Regel gibt es zwischen den Kundenanforderungen und dem SAP Deposits Management einen sehr hohen Abdeckungsgrad. Der Kunde wählt ein Core Banking System und wie der Name schon sagt sind die „Kernfunktionen“ einer Bank die Hauptanforderungen. Diese Hauptanforderungen werden durch unsere sogenannten Standardtestfälle abgebildet. Bis auf kleinere Anpassungen können diese Testfälle von Projekt zu Projekt übernommen werden.
Die Wiederverwendbarkeit der Standardtestfälle ist ein Aspekt für eine mögliche Automatisierung. Generell kann man sagen, je öfter ein Testfall ausgeführt wird umso rentabler ist eine Automatisierung.

Eine Automatisierung muss zunächst entwickelt werden. Dies geschieht in den meisten Fällen mit Hilfe einer Software. In unserem Fall eCATT. Der Prozess wird aufgezeichnet und als Testscript in einem Quellcode Editor angezeigt. Anschließend werden die zu testenden Eingabewerte parametrisiert und durch Platzhalter ersetzt. Mittels dieser Platzhalter können über eine TXT Datei verschiedene Eingabekombinationen eingebunden werden. Bei eCATT ist das Erzeugen von Testscripten und die dazugehörigen Testdaten getrennt. Das Bindeglied der beiden bildet die Testkonfiguration. Des Weiteren können verschiedene SAP Systeme eingebunden werden. Die Systeme werden im Module Systemdaten angelegt und in dem Module Testkonfiguration mit den Testdaten und Testscripten in Verbindung gebracht.

eCATT ist ein benutzerfreundliches Werkzeug und bietet die Möglichkeit über Listenfunktionen Anweisungen einzufügen. Dennoch sind Programmierkenntnisse hilfreich.

Es ist auch möglich ganze Sequenzen oder Geschäftsprozesse aufzuzeichnen und dann auf Knopfdruck wiederzugeben. Allerdings erschwert dies die Wartbarkeit der Scripte. Es ist zu empfehlen modularisiert vorzugehen. Jede Komponente sollte dabei in einem eigenen Script erfasst werden. Anschließend kann man Sequenzen bilden und über ein Masterscript die einzelnen Module aufrufen.

Um die Frage, wann automatisiert werden sollte zu beantworten, wurden im Zuge des isadem Projekts Daten zusammengetragen. Aufgrund dessen wurde ein Modell entwickelt welches die Zeitaufwendungen für einen manuellen und automatisierten Testfall gegenüberstellt.
Das Existieren der Standardtestfälle ist dabei eine wichtige Grundvoraussetzung. Darüber hinaus werden Durchschnittswerte für die Ausführung eines manuellen Testfalls auf 20 Minuten beziffert. Für das Protokollieren und Verarbeiten einer aufgetretenen Fehlermeldung 15 Minuten. Hingegen werden für die Automatisierung (Entwicklung) 180 Minuten, für die Ausführung 5 Minuten und für Behandlung von Fehlerwirkungen ebenfalls 5 Minuten angesetzt. Zu guter letzt werden noch 10 Minuten als Zeitpuffer für das Anpassen von den automatisierten Testfällen für andere Projekte vorgemerkt.

Oder:

Tabelle 1: Anzahl der Projekte

Der Ergebnisbereich der Tabelle entspricht der Anzahl der Projekte in denen der automatisierte Testfall verwendet werden soll, damit es dem Zeitaufwand des manuellen gerecht wird. Diese Tabelle ist gestützt auf Durchschnittswerte und Annahmen die auf Erfahrungen aus früheren Projekten zurückgehen. Des Weiteren wurde hier stark vereinfacht nur ein Testfall verwendet. Bei sechsmaligem Verwenden eines Testfalls pro Projekt und jeweils einer auftretenden Fehlerwirkung reichen zwei Projekte aus, um einen zeitlichen Vorteil zu erlangen.

Auf den ersten Blick könnte man annehmen, dass diese Tabelle ein Argument gegen eine Automatisierung ist. Allerdings ist bei der Ausführung eines manuellen Testfalls Personeneinsatz notwendig. Dabei stellt sich die Frage wie lange kann ein Tester konzentriert einen Testfall nach dem anderen abarbeiten ohne das die Qualität nachlässt. Bei der Automatisierung hingegen können die entwickelten Scripte nach einem Arbeitstag angestellt und die Ergebnisse am Anfang des nächsten Arbeitstags eingesehen werden. Diese Überlegungen sind schwer in Zahlen zu fassen und wurden aus diesem Grund auch nicht in die Rechnung einbezogen. Sie verdeutlicht wie schnell sich der Zeitvorsprung der manuellen Testfälle bei mehrfacher Ausführung auflöst.

Automatisierung kostet. Einerseits Zeit für die Entwicklung andererseits Ressourcen für die Anschaffung und Einführung der Software. Diese negativen Aspekte sind mit den oben genannten Vorteilen abzuwiegen bevor man sich für eine Automatisierung entscheidet.

Wie komme ich an Testdaten?
Das Testen von SAP Deposits Management basiert auf den Geschäftspartnern. Bei der isadem Bank kann ein Geschäftspartner eine Person, Gruppe oder Organisation sein, wobei ein Geschäftspartner u.a. folgende Parameter auszeichnen: Name, Vorname, Straße, Postleitzahl, Wohnort, Land, Bundesland. Jeder Geschäftspartner kann wiederum verschiedene Rollen annehmen:
Rollen:

• Geschäftspartner allgemein
• Kontoinhaber
• Karteninhaber
• Korrespondenz Empfänger

Je nach Rollenvergabe können dann für diesen Geschäftspartner Aktionen durchgeführt werden: Konto anlegen, Karte anlegen etc.

Sinnvolle Geschäftspartnerdaten werden mittels eines VBA/Microsoft Excel basierenden Tools aus Kombinationsmöglichkeiten generiert und über ein generiertes eCATT Testscript eingespielt. Für den Fall das die Testfälle manuell durchgeführt werden kann diese Datenbasis ebenfalls die Grundlage bilden. Bei automatisierten Tests werden die entwickelten Scripte nach diesem Prozess ausgeführt.

Die Simulation des Bankengeschäfts
Die Simulation des Bankengeschäfts ist für das isadem Projekt eine Kernaufgabe. Es sollen Geschäftsprozesse simuliert werden unter annähernd realen Bedingungen. Dies dient zur Veranschaulichung der Abläufe von SAP Deposits Management. Ziel ist es über einen Zeitraum Überweisungen, Einzahlungen, Auszahlungen zu simulieren. Der Kunde bekommt dann die Möglichkeit über einen grafisch dargestellten Geldautomaten Geld abzuheben oder Kontoauszüge zu drucken. Die Simulation ist ebenfalls mittels eCATT realisiert. Der folgende Ablauf liegt dabei zu Grunde:

1. Master Script

Das Funktionsmodule „SAP intern Speichern“ speichert die Geschäftspartner-, Konto- und Kartendaten in eine SAP interne Datenbanktabelle.

2. Master Script

Bevor das Script ausgeführt wird muss die Anzahl der zu simulierenden Geschäftstage festgelegt werden. Des Weiteren muss die Anzahl der Überweisungen, Einzahlungen und Auszahlungen pro Geschäftstag angegeben werden. Das Funktionsmodul „Daten auswählen“ wählt zufällig Daten aus der internen Datenbanktabelle (1.Master Script) aus und fügt sie in die jeweilige Eingabemaske ein. Mit dem Anstoß der Tagesendverarbeitung endet der Geschäftstag und ein neuer beginnt. Je nach Anzahl der Geschäftstage kann die Ausführung über einen langen Zeitraum andauern.

Der Akzeptanz- oder Abnahmetest zielt darauf ab, dass der Kunde sein angefordertes Produkt selbst testet. Dies soll natürlich nicht in der Produktivumgebung geschehen. Die oben verwendete Simulation kann dazu dienen ein produktives System darzustellen.

Automatisierung mit eCATT (Beispiel)
Der Automatisierungsprozess startet mit dem Aufzeichnen der zu automatisierenden Transaktion. Durch Das Starten der Aufnahme öffnet sich ein neues SAP Fenster. In diesem wird die Aufzeichnung durchlaufen. Anschließend kehrt man in das eCATT Fenster zurück und beendet die Aufzeichnung.

Je nach Einstellung der Aufnahme und Granularität wird nur eine Zeile im Code Editor (Command Editor) beschrieben. Die einzelnen Schritte sind dann im Struktur Editor (Structure Editor) in einem Baum dargestellt. In diesem Baum wird auch die Parametrisierung durchgeführt.

Zur Parametrisierung wählt man die betroffene Eingabemaske. Die während der Aufzeichnung getätigten Eingaben ändert man in Platzhalter (Parameter). In diesem Beispiel werden Vor-, Nachname und Titel parametrisiert. Die Parameternamen sind I_TITLE, I_FIRST_NAME und I_LAST_NAME. Das “I” steht für Importparameter. Wenn das aufgezeichnete Script ausgeführt wird können über diese Parameter beliebige Eingaben getätigt werden.

Die Parameterliste enthält alle Parameter die angelegt wurden. In der Spalte „Value“ erscheint der Eingabewert der während der Aufnahme getätigt wurde. Dieser kann hier geändert werden.

Der Parametername bildet die Schnittstelle zu den Testdaten. Die Testdaten können nur den Parametern zugeordnet werden, wenn die Namen sich gleichen.

Die Testdaten können manuell in eine Tabelle eingegeben oder über eine externe TXT Datei eingebunden werden. Diese TXT Datei bedarf allerdings bestimmter Konventionen damit sie von eCATT verarbeitet werden kann.

Testdaten und Testscript werden jetzt mittels Testkonfiguration zusammengeführt.

Bei Ausführung wird nun ein System angesprochen und dieses dann mit dem Testscript durchlaufen. Je nach Einstellung und angegebenen Testdaten wird das Script bei jedem Durchgang mit anderen Daten abgespielt.

Jeder Durchgang wird im Protokoll als extra Knoten dargestellt. Schlägt eine Aktion fehl wird diese mit rot gekennzeichnet.

Zusammenfassung
Wie man sehen kann, ist die Automatisierung von Tests aufwendig. Man benötigt Zeit und Ressourcen. Beim Demo Bank Projekt haben wir uns auf die Automatisierung der Tests konzentriert, die über die SAP GUI ausgeführt werden. Dies reduziert den Kostenaufwand für Testtools zu 100%, da es sich hier um SAP eigene Tools handelt, die kostenfrei mitgeliefert werden. Hat man darüber hinaus noch andere Frontends (z.B. eine Kassen- oder Schalteranwendung), über die Tests automatisiert werden sollen, ist über den Einsatz von weiteren Tools nachzudenken. Es gibt am Markt ausreichend gute und bedienerfreundliche Pakete, für die man aber auch die Lizenzkosten in die Aufwandsbetrachtung einbinden muss.

Da wir aufgrund unserer langjährigen SAP Banking Erfahrung uns ein Paket von Standardtestfällen aufgebaut haben, die mit geringem Aufwand in jedem SAP Banking Projekt nutzbar sind, haben wir diese Testfälle automatisiert.

Es aber wichtig zu bemerken, dass – selbst wenn man standardisierte Testfälle hat und Tools, für die keine Investitionen erforderlich sind – ist die Automation sehr aufwendig. Daher macht eine solche Automatisierung nur dann Sinn, wenn man die Testfälle mehrmals nutzen kann, wie zB. als Quality Gate bei neuen Releases. In solchen Fällen nutzt man die automatisierten Testfälle vielfach und der Aufwand amortisiert bereits nach 5 – 7 Iterationen.

Literaturempfehlung
Für weitere Informationen zum Thema empfehle ich Ihnen mein im Juli 2009 erscheinendes Buch Testautomation mit SAP: SAP Software erfolgreich einführen und als Ergänzung das Praxisbuch eCATT.

Autor
Alberto Vivenzio, freiberuflicher Unternehmensberater, ist seit über 15 Jahren erfolgreich im Bereich Software Test für Core-Banking Applikationen tätig. In dieser Zeit war er weltweit bei zahlreichen Banken verantwortlich für die Erstellung und Umsetzung von Testkonzeptionen, insbesondere im SAP Core-Banking Umfeld.
Zuletzt konnte er seine Expertise im Thema – Banking Next Generation – bei der Neugründung einer Bank im arabischen Raum eindrucksvoll unter Beweis stellen.
Kontakt: [email protected] oder +49-(0)171-7540692

Weitere Empfehlungen: