Evaluierung der Testautomatisierung mit SAP Solution Manager 7.1

2.4.1 Das kann die Testautomatisierung nicht leisten

Im Zusammenhang mit Testautomatisierung entstehen oft falsche Erwartungen, weil ungeschulte Personen eine falsche Vorstellung von automatisiertem Testen haben (vgl. [FeGr99], S. 10). Die Erwartungen liegen in vielen Fällen weit von der Realität entfernt, denn der Einsatz eines Testautomatisierungswerkzeugs bedeutet nicht, dass der Testaufwand automatisch verringert wird oder der Zeitplan sich verkürzt. Im Gegenteil nimmt der Aufwand zu Beginn eines Testprozesses zu und kann sich erst bei mehrmaliger Wiederholung auszahlen.

Laut [DuRP00] lassen hohe Ansprüche an Technologie und Automatisierung manche Menschen glauben, ein automatisiertes Testwerkzeug kann alle Aktivitäten von der Planung bis zur Ausführung der Tests ohne manuellen Einsatz erledigen. Andere glauben, ein einziges Testwerkzeug könne ohne Rücksicht auf Umgebungsparameter sämtliche Testanforderungen unterstützen.

Falsche Erwartungen im Hinblick auf Testautomatisierung müssen ausgeräumt werden, um ein besseres Verständnis für das automatisierte Testen und dessen Auswirkungen zu schaffen. In diesem Abschnitt wird ein Teil der falschen Vorstellungen aufgezeigt.

Die Alleskönner

Auch wenn die Vorstellung großartig ist, dass ein Testwerkzeug automatisch den Testplan entwickelt, die Testverfahren entwirft und erstellt und die Abläufe ausführt, entspricht dies nicht ganz der Realität. Testwerkzeuge können zwar einige Testaktivitäten automatisieren, trotzdem sollten sie als eine „Verbesserung des manuellen Testens“ [DuRP00] betrachtet werden, und nicht als Alleskönner, die den menschlichen Faktor komplett ersetzen können.

Verringerung des Testaufwands

Der Einsatz automatisierter Werkzeuge wird zwar oft in der Verringerung des Testaufwands begründet, jedoch tritt eine Einsparung nicht unmittelbar auf. Es ist sogar möglich, dass bei der Einführung automatisierter Tests ein höherer Aufwand für den Testprozess entsteht. Die Gründe für den höheren Aufwand können im Einsatz eines neuen Testwerkzeugs oder in der ausführlichen Analyse der Zielanwendung liegen. Sowohl die Einarbeitung in ein neues Werkzeug als auch die Untersuchung des Zielsystems, um zu ermitteln, welche Teile davon der Automatisierung zugänglich sind, stellen einen zusätzlichen Testaufwand dar (vgl. [DuRP00], S. 39). Eine Verringerung des Testaufwands wird gewöhnlich (bzw. wenn überhaupt) erst nach mehreren Testdurchläufen, in Form von Regressionstests, erreicht (vgl. [INET01]).

Verkürzung des Zeitplans

Eine weitere falsche Erwartung ist, dass Testautomatisierung den Testprozess beschleunigt und somit den Zeitplan verkürzt. Wie oben beschrieben, kann die Einführung eines automatisierten Testwerkzeugs den Testaufwand erhöhen. Dies hat zur Folge, dass die erwartete Verkürzung nicht unmittelbar zutrifft. Es besteht sogar die Möglichkeit, dass eine Verlängerung des Zeitplans erforderlich ist, da mit der Einführung der Testautomatisierung aktuelle Testprozesse erweitert oder sogar neue Prozesse entwickelt werden müssen (vgl. [DuRP00], S. 39).

Universelle Anwendbarkeit der Testautomatisierung

Wie bereits erwähnt, sollte der Begriff „Testautomatisierung“ als Verbesserung des manuellen Testens und nicht als die Lösung für das Testen gesehen werden. Schließlich ist es weder möglich noch ist es wirtschaftlich verträglich alle Tests in einem Projekt zu automatisieren. Allein die Betrachtung der unendlichen Anzahl von Abwandlungen und Kombinationen von System- und Benutzeraktivitäten, die in n-schichtigen Architekturen und Anwendungen mit grafischen Benutzeroberflächen möglich sind, zeigt, dass sehr viel Zeit benötigt wird, um jede Möglichkeit zu testen. Der Tester hat gar nicht die Zeit und die nötigen Ressourcen, um eine hundert-prozentige Testabdeckung einer Anwendung zu gewährleisten (vgl. [DuRP00], S. 41). Aufgrund der hohen Komplexität und der umfangreichen Funktionalität moderner Systeme würde das Testen zu einer endlosen Aufgabe wachsen (vgl. [INET05]). Infolgedessen sollte niemals eine hundertprozentige Testautomatisierung einer zu testenden Anwendung als das Ziel festgelegt werden. Denn „es ist unmöglich, einen 100%-Test mit allen möglichen einfachen Eingaben für ein System durchzuführen“ [DuRP00].

Hinzukommt der einschränkende Faktor „Kosten“, der die Automatisierung von einmal ausgeführter oder sehr spezifischer und komplexer Tests teurer als manuelles Testen macht (vgl. [INET05]). Aufgrund des hohen Zeitaufwands, der für die Erstellung von automatisierten Tests investiert werden muss, kann durch die einmalige Ausführung kein Mehrwert entstehen (vgl. [FeGr99], S. 5). Ähnliche Auswirkungen auf die Kosten haben spezielle und komplexe Testfälle. Die Testautomatisierung solcher Tests bringt meistens keine wirtschaftlichen Vorteile, da der automatisierte Test nur für diesen einen Fall angewandt wird und somit kein mehrfacher Einsatz möglich ist. Der Aufwand, der dafür betrieben werden muss, ist wiederum zu groß und erhöht die Kosten der Testerstellung. Daher sollte während der Testvorbereitung genau untersucht werden, für welche Testfälle sich die Investition in die Entwicklung eines automatisierten Testskripts lohnt (vgl. [FeGr99], S. 5). Dafür ist eine sorgfältige Analyse der zu testenden Systemanwendung notwendig.

Außerdem sollte beachtet werden, dass manche Tests physikalisch einfach nicht automatisiert werden können, wie zum Beispiel eine gedruckte Ausgabe. Sicherlich könnte der Prozessschritt, der einen Druckauftrag ausführt, geskriptet werden, jedoch kann die nachfolgende Prüfung, ob die Ausgabe auch wirklich erfolgt ist, nicht automatisiert werden. Die manuelle Prüfung durch den Anwender ist trotzdem notwendig.

Weiterhin sollte jedem bewusst sein, dass die Automatisierung von GUI-Tests einen großen Aufwand verursacht, wenn die Benutzeroberfläche der zu testenden Anwendung ständigen Änderungen unterworfen ist. Allein die Verschiebung eines Objekts in der Präsentationsschicht der Software kann einen automatisierten Test fehlschlagen lassen, wenn das Testwerkzeug nur die Position des Testobjekts speichert und dadurch das Objekt nicht mehr findet. Um die Funktionalität weiterhin testen zu können, ist somit eine Anpassung, evtl. sogar Neuerstellung, des Testskripts notwendig. Daher sollte die GUI-Testautomatisierung am Ende eines Projekts erfolgen, weil sich bis dahin oft noch Änderungen ergeben (vgl. [INET05]).

2.4.2 Vorteile der Testautomatisierung

Auch wenn die Testautomatisierung nicht alle Erwartungen erfüllen kann, so bringt sie bei korrekter Implementierung und einem festgelegten Testprozess (siehe Kapitel 2.3) einige Vorteile mit sich. Die bedeutendsten Vorteile automatisierter Tests werden nachfolgend aufgezeigt.

2.4.2.1 Verbesserung der Softwarequalität

Damit eine Software erwartungsgemäß und mit geringer Ausfallzeit laufen kann, werden mit der Testarbeit die Ziele der Auffindung und Reduzierung von Mängeln verfolgt. Ein weiteres Ziel sollte darin bestehen die Erwartungen der Benutzer zu erfüllen oder zu übertreffen. Um diese Ziele erreichen zu können, sollte der Testprozess innerhalb des Schrittes „Anforderungsdefinition“ in der Entwicklungsphase beginnen.

Testautomatisierung kann das Testen in alle Aktivitäten verbessern, z.B. bei der Entwicklung von Testverfahren während der Vorbereitung, der Testausführung, der Analyse der Test-ergebnisse und der Berichterstellung. Außerdem werden alle Teststufen, beginnend bei den Entwicklertests bis einschließlich Regressionstests, unterstützt. Testautomatisierung kann mit korrekt implementierten Testwerkzeugen und Methoden und einem wohldefinierten Testprozess zur Verbesserung der Qualität der Systemsoftware führen.

Detaillierte Definition der Anforderungen

Die Definition von Testfällen ist zwingend notwendig, um zuverlässige und kostengünstige Softwaretests erstellen zu können. Dabei sollten Anforderungen detailliert und eindeutig beschrieben werden, um den Testaufwand und Kosten zu verringern. Mit Werkzeugen wird das Erstellen testfähiger Anforderungen erleichtert. Testfertige Anforderungen unterstützen nicht nur die Vorbereitung eines effizienten Tests, sondern erhöhen zusätzlich die Nachvollzieh-barkeit des Testverfahrens. Dadurch wird eine größere Sicherheit in Bezug auf die Vollständigkeit des Tests geschaffen.

Verbesserte Performancetests

Die Zeiten als Leistungsdaten manuell mit der Stoppuhr gesammelt wurden, gehören seit der Einführung von Testwerkzeugen der Vergangenheit an. Die manuelle Ausführung war nicht nur arbeitsintensiv, sondern stark fehleranfällig und ermöglichte keine automatische Wieder-holung (vgl. [DuRP00], S. 45). Mit Werkzeugen für Performancetests werden Systemfunktionen automatisiert getestet und anschließend Zahlen und Kurven über Zeitwerte ausgegeben und die Engpässe dargestellt. Ein weiterer Vorteil des Einsatzes von Testwerkzeugen zur Performancemessung ist die Minimierung der eingesetzten Rechner und Personen zur Durchführung einer Vielzahl von Tests. Mit einem automatisierten Performancetest können nicht nur viele manuelle Tester ersetzt, sondern eine gleichbleibende Wiederholung der Tests ermöglicht werden. Zudem können anhand von Testdaten unterschiedliche Tests simuliert werden, um die Auswirkungen auf unterschiedliche Gegebenheiten zu testen. Das Ziel von Performancetests sollte im Nachweis der akzeptablen Reaktionszeiten unter realistischen Belastungen bestehen.

Mögliche Qualitätsmessung

Der Einsatz von Werkzeugen zur Testautomatisierung ermöglicht die Ausgabe von Metriken für die Qualität der Tests. Die Ergebnisse der automatisierten Tests lassen sich messen und analysieren und durch die Wiederholbarkeit von Tests mit bereits ausgeführten Tests vergleichen. Diese Möglichkeiten bilden einen Vorteil zum manuellen Testen, bei dem es vorkommen kann, dass die beim ersten Durchgang unternommenen Schritte nicht identisch mit denen sind, wie beim zweiten Durchgang. Infolgedessen wird eine Qualitätsmessung ungenau und der Vergleich somit schwierig.

2.4.2.2 Verbesserung der Testqualität

Ein weiterer Grund für die Verwendung von Testautomatisierung ist die Steigerung der Tiefe und Breite der Tests. Die Vorteile, welche sich dadurch ergeben, werden nachfolgend dargestellt.

Verbesserte Regressionstests

Laut Definition (siehe Kapitel 2.2) ist ein Regressionstest die Wiederholung eines Tests an einer modifizierten Software. Dabei wird das Ziel verfolgt, sicherzustellen, dass die bereitgestellte Funktionalität die Spezifikationen erfüllen und keine Fehler durch Änderungen in der Software entstehen. Ein Testautomatisierungswerkzeug ermöglicht einfachere Regressionstests durch die gleichbleibende Wiederholung eines Tests. Auf diese Weise kann gewährleistet werden, dass sich keine Fehler durch die Änderung der Software eingeschlichen haben. Ein ausführ-licher Regressionstest ist normalerweise langwierig und zäh und deshalb anfällig für mensch-liche Fehler (vgl. [DuRP00], S. 53). Aus diesem Grund sollte bei dieser Art von Tests die manuelle Prüfung durch den automatisierten Test ergänzt bzw. ersetzt werden. Der Test durchläuft automatisch jeden Schritt, der sonst manuell durchgeführt worden wäre, und verringert so den Testaufwand (vgl. [FeGr99], S. 9).

Testen der Softwarekonfigurationen

Ein weiteres Beispiel für die Vorteile, die sich durch die Wiederverwendung von automatisierten Tests ergeben, findet sich im verbesserten Testen der Softwarekonfigurationen (vgl. [DuRP00], S. 54). Durch Aktualisierungen und Implementierungen neuer Versionen können unerwartete Kompatibilitätsprobleme in der aktuellen Software entstehen. Die Ausführung automatisierter Testskripts nach Updates einer Software kann sicherstellen, dass aktuelle Anwendungen fehlerfrei funktionieren.

Ausführung einfacher Tests

Die Wiederholung von Tests mit immer gleichbleibenden Schritten führt zwangsweise zur Monotonie in der Ausführung der Arbeit. Diese wiederum hat negative Auswirkungen auf Tester, die aufgrund der monotonen Testschritte, die Testarbeit vernachlässigen könnten. Nach vielen erfolgreichen Tests besteht das Risiko, dass sie einige auslassen in der Hoffnung, dass die Software trotzdem richtig funktioniert. Auf diese Weise bleibt der ein oder andere Fehler unentdeckt (vgl. [DuRP00], S. 54). Die Verwendung der Automatisierung lohnt sich bei einfachen Tests, da ein Testskript die monotonen Schritte immer ausführt und anschließend die Ergebnisse prüft (vgl. [DuRP00], S. 55).

Durchführung von Tests, die mit manuellen Verfahren nicht möglich sind

Die immer größer werdende Komplexität von modernen Softwaresystemen stellt viele Tester vor große Herausforderungen. Die Prozesse und Testanforderungen sind teilweise so komplex, dass manuelles Testen nicht alle gewünschten Tests unterstützen kann. So lassen sich viele Arten der Testanalyse manuell nicht durchführen (vgl. [FeGr99], S. 9), weil zum Beispiel gegen die Logik der Anwendung geprüft werden soll. Dabei sollen die GUI- und API-Tests dasselbe Ergebnis liefern. Jedoch sind API-Tests manuell nicht durchführbar, weshalb eine Automatisierung unausweichlich wird.

Reproduktion von Fehlern

Wie bereits beschrieben sollen Softwaretests Fehler in der Anwendung aufdecken, damit Entwickler sie beseitigen können. Jedoch kommt es beim manuellen Testen des Öfteren vor, dass der Tester auf einen Fehler stößt, diesen aber nicht reproduzieren kann. Aus welchem Grund die Lokalisierung des Fehlers und die Ursachenfindung schwierig sind. Mit einem Testautomatisierungswerkzeug werden einzelne Schritte in einem Testskript aufgezeichnet und können anschließend mehrmals ausgeführt werden. Sollten bei der Ausführung eines Testskripts Fehler auftreten, so werden sie bei weiteren Ausführungen in Kombination mit gleichen Daten reproduzierbar auftreten.

Tests außerhalb der Arbeitszeit

Ein weiterer Vorteil der Testautomatisierung ist der variable Startzeitpunkt zur Ausführung von Testskripten. Der Tester kann um 8 Uhr morgens die auszuführenden Testskripte auswählen und den Ausführungszeitpunkt auf 10 Uhr abends legen. Am nächsten Morgen kann er die Ergebnisse im Testprotokoll durchsehen, analysieren und weitere Schritte einleiten.

[FeGr99] und [DuRP00] empfehlen die Startzeitpunkte zur Durchführung von Testskripten auf Tageszeiten zu legen, an denen wenig Auslastung am Gesamtsystem stattfindet. Diese Zeitpunkte können unter anderem der Beginn der Mittagspause oder kurz vor Feierabend sein. Dadurch können das System und die Arbeitszeit optimal genutzt werden.

2.4.2.3 Verringerung des Testaufwands und Minimierung des Zeitplans

Wie in Kapitel 2.4 erläutert wurde, führt die Testautomatisierung nicht unmittelbar zur Reduzierung des Testaufwands. Mit der Einführung eines Testautomatisierungswerkzeugs kann er aufgrund der Einrichtung und Einarbeitung sogar zunehmen. Auch die Entwicklung eines Testplans wird wegen der detaillierten Beschreibung des Testprozesses den Aufwand zunehmen lassen, durch die Wiederverwendbarkeit der Tests wird aber bereits nach wenigen Testdurchläufen ein Mehrwert sichtbar (vgl. [INET05]). „Die Verwendung eines automatisierten Testwerkzeugs kann sowohl den Testaufwand als auch den Testzeitplan reduzieren“ [DuRP00].

Die Aufwandsunterschiede zwischen dem manuellen und dem automatisierten Testen können in der Gesamtbetrachtung eines Testprozesses enorm sein. Laut [DuRP00] können mit Hilfe von Testwerkzeugen über 70% der Personenstunden, die das manuelle Testen benötigt, eingespart werden. Dabei sind die Einsparungen nicht in allen Testaktivitäten zu beobachten. Die stärkste Verringerung des Testaufwands wird in der Phase der Testausführung deutlich. Die Tätigkeiten, wie z.B. die Durchführung der Tests, die Analyse der Ergebnisse und das Erstellen von Testberichten, benötigen in der automatisierten Ausführung bis zu siebenmal weniger Arbeit. Die Unterschiede des manuellen und automatisierten Testens nach 1750 Testläufen und 700 Fehlern werden in der Tabelle 3.1 deutlich.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2 Manuelles und automatisiertes Testen im Vergleich^[1] (vgl. [DuRP00], S. 58)

Erstellung eines Testplans

Die Erstellung eines Testplans ist für den gesamten Testprozess von hoher Bedeutung. Alle wichtigen Aspekte des Testprozesses müssen durchdacht werden, bevor die eigentliche Erstellung der Testskripte beginnt. Die zu testende Anwendung muss vollständig auf die Kompatibilität mit dem Testwerkzeug untersucht werden, um zu ermitteln, welche Komponenten und Prozessschritte automatisiert werden können. Weiterhin sollte ein Plan mit allen möglichen Varianten der Testfälle und der dazu benötigten Testdaten skizziert werden. Außerdem müssen Standards definiert werden, damit Skripte direkt bei der Erstellung modular und wieder-verwendbar gestaltet werden. Diese und weitere Schritte^[2] sind notwendig, damit die Test-automatisierung erfolgreich und gewinnbringend eingesetzt werden kann. Die sorgfältige und detaillierte Planung hat zur Folge, dass der Testaufwand für das automatisierte Testen wesentlich höher ist als beim manuellen Testen.

Erstellung von Testverfahren

Die manuelle Erstellung und Wartung von Testverfahren ist ein mühsamer, teurer und zeitaufwändiger Vorgang (vgl. [DuRP00], S. 59). Änderungen einer Software können zur Anpassung vorhandener Testverfahren bzw. zur Erstellung neuer Testverfahren führen. Dazu müssen zunächst die zu ändernden Testverfahren identifiziert werden, bevor im nächsten Schritt die Anpassungen der Tests geschehen können. Moderne Werkzeuge können den Tester bei diesen Tätigkeiten unterstützen. Testverfahren können mit speziellen Programmen in wenigen Schritten generiert werden (vgl. [DuRP00], S. 98). Andere Programme, wie z.B. der Business Process Change Analyzer^[3] (BPCA), erkennen Änderungen an der Software und können Informationen über den benötigten Testaufwand zur Beseitigung der Konflikte geben. Der Testaufwand bei der Erstellung von Testverfahren kann durch die Verwendung von Werkzeugen deutlich verringert werden (siehe Tabelle 3.1).

Testausführung

Wie bereits erwähnt ist die manuelle Durchführung von Tests arbeitsintensiv und fehleranfällig. Mit der Verwendung von Testautomatisierungswerkzeugen werden bei dieser Tätigkeit die größten Einsparungen an Arbeits- und Zeitaufwand sichtbar (siehe Tabelle 3.1). Im Idealfall muss der Tester die Testskripte lediglich starten und das Testwerkzeug kann unbeaufsichtigt arbeiten. Es ist sogar möglich die Tests zu einer bestimmten Zeit beginnen zu lassen (siehe Kapitel „Verbesserung der Testqualität“), um Ressourcen schonend und sinnvoll auszunutzen. Außerdem ermöglicht die Wiederwendung der Tests die Ausführung der Skripte mit gleich-bleibender Testqualität.

Analyse der Testergebnisse

Testautomatisierungswerkzeuge besitzen im Allgemeinen die Funktionalität Protokolle für durchgeführte Tests zu erstellen. Dabei werden die Ergebnisse in Form von Ampelsignalen ausgegeben, bei denen grüne Ausgaben bestanden und rote das Gegenteil bedeuten. Manche Werkzeuge geben bei fehlgeschlagener Funktionalität eine Fehlerbeschreibung aus und erzeugen Screenshots von der Fehlerstelle. Anhand dieser Informationen werden die Fehleranalyse und der Vergleich mit Originaldaten erleichtert.

Berichterstellung

Testwerkzeuge können mit den Testergebnissen und zusätzlichen Eingaben der Tester Berichte für einen maßgeschneiderten Bedarf in kurzer Zeit erstellen und den Arbeits- und Zeitaufwand stark reduzieren.

2.4.3 Testwerkzeuge

Mit der Verwendung von Testwerkzeugen kann die Qualität der Software und des Testens verbessert und zudem eine erhebliche Verringerung des Arbeits- und Zeitaufwands im Testprozess bewirkt werden. Bevor jedoch willkürlich Werkzeuge, die den Arbeitsalltag vereinfachen sollen, in das Unternehmen eingeführt werden, aber keine Verwendung finden, sollte eine ausführliche Analyse des Bedarfs durchgeführt werden, anhand deren Ergebnissen die Auswahl von geeigneten Testwerkzeugen getroffen wird. Die Entscheidung, welche Arten von Werkzeugen nutzbringend eingesetzt werden können, gehört zu den grundlegenden Überlegungen von Projekten (vgl. [HeTr09], S. 65) und sollte während der Erstellung des Testplans getroffen werden.

Laut [SpLi08], [HeTr09] und [DuRP00] werden nahezu alle Verfahrensweisen und Methoden von entsprechenden Werkzeugen unterstützt oder automatisiert. Unterschiedliche Aktivitäten oder Phasen des Testprozesses erfordern jedoch verschiedene Werkzeugarten, um die gewünschten Tätigkeiten durchführen zu können. Nur in den seltensten Fällen wird das gesamte Sortiment an Testwerkzeugen in einem Projekt benötigt. Nachfolgend werden Werkzeuge, die unter anderem bei der Durchführung der Analyse (siehe Kapitel 5) verwendet wurden, für diese Anwendungsfälle gezeigt.

Testmanagement

Testmanagementwerkzeuge, wie die Test Workbench im SAP Solution Manager (siehe Kapitel 3), ermöglichen die Planung, Durchführung und Auswertung von Tests und bilden mit ihrem breitgefächerten Leistungsumfang ein Fundament für den Testprozess. Üblicherweise werden mit einem Testmanagementwerkzeug folgende Anwendungsbereiche unterstützt.

- Verwaltung von Testfällen: Werkzeuge für das Testmanagement sollten die geordnete Ablage von manuellen und automatisierten Testfällen erlauben und unabhängig von der Testdurchführung die zentrale Speicherung der Testfälle ermöglichen (vgl. [SONS01]). Außerdem sollten eine Sortierfunktion, nach Thema oder Ausführungsreihenfolge, und Dokumentvorlagen bereitgestellt werden.

- Testplanung und -durchführung: Die Testplanung kann durch die Verwendung von Werkzeugen insofern unterstützt werden, indem erstellte Testfälle für eine bestimmte Teststufe ausgewählt und einzelnen Testern zugewiesen werden. Die Tester können die ihnen zugewiesenen Testfälle abarbeiten und dabei deren Status erfassen und den Testverlauf entsprechend dokumentieren.

- Fehlermanagement: Die während der Testdurchführung entstandenen Fehlermeldungen sollten sofort und ohne Medienbrüche erfasst werden können. Testmanagementwerkzeuge stellen hierzu die Funktionalität eines Service Desks bereit, in dem das Abbilden eines individuellen Fehlerbehebungsprozesses ermöglicht werden sollte.

- Reporting: Die durch Tester erzeugten und im Fehlermanagement erfassten Daten können für ein effektives Reporting verwendet werden, um die Datenbasis für eine Analyse zu schaffen und eine kontinuierliche Verbesserung des Testprozesses zu ermöglichen.

Änderungsanalyse

Wie das Kapitel „Notwendigkeit von Tests“ dargestellt hat, können Änderungen eines Systems, seien es z.B. Änderungen im Customizing oder das Einspielen von Support Packages, die Funktionalität von Geschäftsprozessen beeinträchtigen. Mit einem Regressionstest kann sicher-gestellt werden, dass die Änderung keine negativen Auswirkungen auf die Kernprozesse hat. Die Auswahl der dazu notwendigen Testfälle kann durch Werkzeuge der Änderungsanalyse, wie z.B. dem bereits erwähnten Business Process Change Analyzer, unterstützt werden.

Testautomatisierung

Testautomatisierungswerkzeuge, auch Testroboter genannt, wie z.B. HP QuickTest Professional (siehe Kapitel 5), ermöglichen das automatische Abspielen von Testfällen und ersetzen auf diese Weise das manuelle Testen. Die Erstellung von solchen Tests erfolgt typischerweise nach dem Capture-and-replay-Verfahren, d.h. der Testroboter erfasst bei der Testdurchführung die Eingaben, Mausklicks und Angaben des Benutzers und speichert diese als ein Testskript (vgl. [Fran07], S. 213). Ein solches Skript kann bearbeitet werden, um z.B. durch Parametrisierung unterschiedliche Testdaten abspielen zu können. Die Funktionalität moderner Werkzeuge geht noch weiter und ermöglicht mit der Programmierung von Befehlen, meist in Form von Skriptsprachen, tiefergehende Prüfanweisungen oder eine tiefergehende Ablauflogik. Hersteller-spezifische Werkzeuge, wie z.B. eCATT von SAP, bieten hier weiteren Mehrwert, indem durch Befehle der direkte Zugriff auf die Datenbank erlaubt oder die Ausführung von Skripten auf dem Applikationsserver ermöglicht wird.

3 SAP Solution Manager

Werkzeuge können den Arbeitsalltag des Anwenders wesentlich erleichtern und mehr Qualität in die Bearbeitung von Aufgaben bringen. Die in Kapitel 2.4 beschriebenen Werkzeugarten bilden nur einen Bruchteil dessen, was moderne Werkzeuge leisten können. Mit dem SAP Solution Manager bringt SAP eine Lösung auf den Markt, die den kompletten Lebenszyklus einer Anwendung, von der Planung über den Betrieb bis zur kontinuierlichen Verbesserung, abdeckt.

In diesem Kapitel wird das Konzept des SAP Solution Managers und das Modell „Application Lifecycle Management“ (ALM) vorgestellt, nach dessen Prinzip die Prozesse im SAP Solution Manager abgebildet werden. Weiterhin werden die Abläufe des Testmanagementprozesses im SAP Solution Manager beschrieben und abschließend die drei Testoptionen kurz dargestellt.

3.1 Allgemeines Konzept

Der SAP Solution Manager ist die zentrale Lösung für den Application-Management-Lebenszyklus und den Betrieb von Softwarelösungen (vgl. [INET03]). Er unterstützt heterogene Systemumgebungen von der Implementierung über die Produktivsetzung und den Betrieb bis hin zur kontinuierlichen Verbesserung von Anwendungen. Mit der Kombination von Werk-zeugen und Inhalten kann die Zuverlässigkeit und Stabilität von Anwendungen erhöht und die Gesamtbetriebskosten verringert werden (vgl. [ScMe11], S. 29). Um dies zu ermöglichen, unterstützt der SAP Solution Manager den gesamten Lebenszyklus einer Anwendung, der nach dem Modell der IT Infrastructure Library (ITIL) dargestellt wird. Application Management ist ein umfassender Unterstützungsansatz in der Anwendungsumgebung, der in den folgenden Phasen den gesamten Lebenszyklus von IT-Lösungen abdeckt (siehe Abbildung 3.1):

- Anforderungen (Requirements): Sammlung der Anforderungen für neue Anwendungen
- Entwurf (Design): Umwandlung der Anforderungen in detaillierte Spezifikation
- Implementierung und Test (Build & Test): Anwendungskonfiguration und Erstellung eines Organisationsmodells gemäß den Spezifikationen
- Auslieferung (Deploy): Überführung des Betriebsmodells und der Änderungen in die bestehende produktive IT-Landschaft
- Betrieb (Operate): Bereitstellung der IT-Services, die für den fortlaufenden Betrieb erforderlich sind
- Optimierung (Optimize): Analyse der Erfüllung von Service-Levels und gegebenenfalls Start von Aktivitäten, um die Ergebnisse zu verbessern

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1 Application Lifecycle Management (vgl. [HeTr09], S. 137)

3.1.1 Änderungen in Projekten implementieren

Ein Projekt im SAP Solution Manager dient der Gruppierung und Organisation von Geschäftsaufgaben, technischen Aufgaben und Organisationsaufgaben, die bei der Implementierung von SAP-Software in einem Unternehmen entstehen. Innerhalb eines Einführungsprojekts werden Aufgaben nach einem Projektplan und einer Roadmap strukturiert durchgeführt. Die bereits in Kapitel 2.2 vorgestellte ASAP-Methode dient als Vorlage zur Durchführung von Projekten im SAP Solution Manager. Diese beginnt mit der Projektvorbereitung und schließt das Projekt in der Produktivstartphase ab.

Bezogen auf das Modell „Application-Lifecycle-Management“ deckt ein Projekt die drei Phasen Anforderungen, Entwurf und Implementierung und Test ab und legt somit einen wesentlichen Grundstein für die Auslieferungsphase. Hier werden alle während des Projekts gesammelten Informationen zu einer Lösung übernommen und in die bestehende produktive IT-Landschaft übertragen.

Laut [HeTr09] und [ScMe11] ergeben sich durch die Verwendung des SAP Solution Managers für Projekte folgende Vorteile:

- Projekte werden strukturiert und systematisch durchgeführt
- Der prozessorientierte Ansatz ist unabhängig von einzelnen Anwendungen und Komponenten, wodurch eine umfassendere Sicht auf die Prozessabläufe in heterogenen Systemlandschaften ermöglicht wird.
- Kein Informationsverlust zwischen den Projektphasen – Wiederwendung des Inhalts durch den gesamten Softwarelebenszyklus
- Der SAP Solution Manager stellt ein zentrales Repository für Lösungen dar - Dokumentation, Testfälle und Konfigurationsinformationen sind in einer Anwendung gebündelt

Aus Sicht des Lebenszyklus deckt ein Projekt im SAP Solution Manager die Phasen von der Anforderung bis hin zur Vorbereitung des Produktivstarts (Auslieferung) ab. Dabei können große Projekte, wie beispielsweise ein Upgrade, aber auch kleine Änderungen, die beim Durchlaufen eines Wartungszyklus umgesetzt werden, zum Umfang gehören.

3.1.2 Lösungen effizient betreiben

Nachdem ein Projekt erfolgreich in die Auslieferungsphase überführt wurde, entsteht während des Betriebs die Herausforderung, das gesammelte Wissen zu bewahren und aktuell zu halten. Beim Überführen eines Projekts in die produktive IT-Landschaft werden alle im Projekt gesammelten Informationen in eine Lösung übertragen. Somit enthält eine Lösung im SAP Solution Manager alle Informationen über Systeme, Softwarekomponenten und Geschäftsprozesse, die beim Betrieb und bei der Optimierung der Lösung benötigt werden. Auf diese Weise sind nach Abschluss eines Projekts alle Informationen trotzdem verfügbar.

Damit die Investitionen eines Projekts sich auszahlen, sollte sich die Betriebsdauer einer Lösung grundsätzlich über einen längeren Zeitraum als die Projektdauer erstrecken. „Ein erfolgreicher Betrieb steht und fällt daher mit der Integration der Lösung“ [ScMe11].

Folgende Vorteile des Lösungskonzepts ergeben sich laut [HeTr09] und [ScMe11]:

- Strukturen der Geschäftsprozesse werden direkt in die Lösung übertragen
- Vorgenommene Änderungen können mit Testfällen der jeweiligen Struktur geprüft werden
- Aus Projekten übernommene Informationen können in der Lösung für E-Learning wiederverwendet werden.
- Die Lösung verfügt über dieselbe Systemlandschaft wie das Projekt
- Grafiken können nach Microsoft Office oder HTML exportiert werden

Die Lösung im SAP Solution Manager deckt aus Sicht des Application-Management-Lebens­zyklus die Phasen von der Auslieferung über Betrieb bis hin zur Optimierung ab.

3.1.3 Prozesse im SAP Solution Manager

Für die effektive Implementierung von Änderungen im SAP Solution Manager sieht SAP die Erstellung von Projekten vor, die in den entsprechenden Phasen des Lebenszyklus zu Lösungen überführt werden. Um einen effizienten Betrieb der Lösungen zu ermöglichen, ist die fortlaufende Anpassung bzw. Verbesserung der Lösungen notwendig. Der SAP Solution Manager wird entlang von zwölf Prozessen organisiert, um die genannten Phasen des Application Managements abzudecken und Funktionen bereitzustellen, die den Anwender bei der Umsetzung der Aufgaben unterstützen. Nachfolgend wird ein kurzer Überblick der Prozesse nach [ScMe11] gegeben:

- Lösungsdokumentation: Die Lösungsdokumentation ist eines der wichtigsten Prozesse im SAP Solution Manager, denn sie bildet mit der Dokumentation der technischen Landschaft und der Geschäftsprozessdokumentation die Grundlage für alle anderen Funktionen des SAP Solution Managers. Hier werden die technischen Komponenten von SAP selbst als auch von anderen Anbietern beschrieben, aber auch Kerngeschäftsprozesse und die Schnittstellen des Kunden werden in der Dokumentation abgebildet. Sie umfasst außerdem die Dokumentation von benutzerdefiniertem Code und von Änderungen sowie Verweise auf unterstützende technische Objekte.

- Lösungsimplementierung: Dieser Prozess umfasst die Ermittlung, Anpassung und Implementierung von neuen und verbesserten Geschäfts- und Technikszenarien und nutzt den SAP Solution Manager, um innerhalb der Systemlandschaft Innovationen zu implementieren.

- Vorlagenmanagement: Das Vorlagenmanagement umfasst die Vorlagendefinition, -implementierung und -optimierung, damit Kunden ihre Geschäftsprozesse auch auf mehreren SAP-Installationen effizient verwalten können.

- Testmanagement: Dieser Prozess sieht die Definition von Anforderungen für Testfälle sowie den Testumfang vor. Darüber hinaus werden hier automatisierte und manuelle Tests entwickelt, Tester verwaltet und Berichte über den Testfortschritt und die Testergebnisse erstellt.

- Verwaltung der Änderungskontrolle: Verwaltung von Änderungen, mit denen die Lösung in betriebswirtschaftlicher oder technologischer Hinsicht verbessert werden soll. Funktionen unterstützen den Anwender dabei, Risiken optimal zu verwalten und eine technische und funktionale Stabilität sicherzustellen.

- Technischer Betrieb: Der Prozess „technischer Betrieb“ ermöglicht mit seinen Funktionen die Überwachung, Benachrichtigung, Analyse und Administration von SAP-Lösungen.

- Betrieb von Geschäftsprozessen: Hier werden die Aspekte für den reibungslosen und zuverlässigen Ablauf der Kerngeschäftsprozesse hinterlegt und damit eine Erfüllung der Geschäftsanforderungen sichergestellt.

- Application Incident Management: Alle Störungs- und Problemmeldungen aus unterschiedlichen Organisationsebenen werden hier zentral und gemeinsam verarbeitet. Der Prozess ist in alle Prozesse des SAP Solution Manager und in alle Lösungen der SAP Business Suite integriert und umfasst Folgeaktivitäten wie Wissensrecherche und Ursachenanalyse.

- Wartungsmanagement: Das Wartungsmanagement umfasst Pakete für die Softwarekorrektur von der Identifizierung und Bereitstellung bis hin zur Optimierung des Testumfangs.

- Upgrade-Management: Dieser Prozess ermöglicht eine bessere Handhabung der wesentlichen technischen Risiken und Herausforderungen bei einem Upgrade-Projekt, damit Upgrade-Projekte für die geschäftliche Seite möglichst gar nicht spürbar sind.

- Landscape Transformation Management: Geschäfts- und IT-Transformationen, wie beispielsweise bei Firmenfusionen, können mithilfe dieses Prozesses beschleunigt werden. Weiterhin können komplexe betriebswirtschaftliche Anforderungen über standardisierte Transformationslösungen geplant, strukturiert und durchgeführt werden.

- Custom Code Management: Mit Werkzeugen und Methoden können kundeneigene Entwicklungen analysiert werden, um entscheiden zu können, ob der Einsatz von Standardsoftware effektiver und kosteneffizierter ist, als kundeneigene Entwicklungen.

3.2 Der Prozess „Testmanagement“

Wie im vorhergehenden Abschnitt bereits erwähnt wurde, ist das Thema „Testen“ ein wichtiger Bestandteil des Application Lifecycle Managements und gehört daher zum Konzept des SAP Solution Managers. Mit dem Prozess „Testmanagement“ werden alle Testaktivitäten im SAP Solution Manager abgedeckt, beginnend mit der Planung der Testfälle bis zur abschließenden Durchführung der Tests. Wie groß der Testumfang einer Lösung ausfällt, ist allerdings von der Art der durchgeführten Änderungen abhängig (siehe Abbildung 3.2). Hier wird zwischen der Implementierung einer neuen SAP-Lösung und der Änderungen an vorhandenen SAP-Lösungen, wie beispielsweise das Einspielen eines Support-Packages, unterschieden.

Bei der Implementierung einer neuen SAP-Lösung oder der Modellierung weiterer Geschäfts-prozesse, ist die Ergänzung der Geschäftsprozesshierarchie in der Lösungsdokumentation zu empfehlen. Auf diese Weise können den Komponenten Tests direkt zugewiesen und der Testumfang besser bestimmt werden. Sollen hingegen Änderungen an technischen SAP-Objekten vorgenommen werden, ist die Änderungseinfluss-Analyse durchzuführen. Damit können Auswirkungen auf wichtige Geschäftsprozesse aufgedeckt und daraus ein geeigneter Testplan abgeleitet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2 Testmanagementprozess (vgl. [ScMe11], S. 232)

Die Testplanung besteht in erster Linie aus der Erstellung der notwendigen Testfälle, die den entsprechenden Geschäftsprozessen zugeordnet werden können. Erstellt werden entweder manuelle Tests, bei denen der Ablauf und erwartete Ergebnisse ausführlich beschrieben werden sollten, oder durch SAP- oder Partner-Testwerkzeuge automatisierte Tests, die den manuellen Testablauf ergänzen bzw. ersetzen. Ein umfassender Testplan wird nach einem konkreten Testzyklus aufgebaut. Hierfür ist zunächst die Bestimmung des Testumfangs notwendig, um für die Testdurchführung geeignete Testfälle ableiten zu können. Diese werden in einem Testplan zusammengefasst, der wiederrum in kleinere Testpakete untergliedert wird. Die Testpakete können dann den entsprechenden Testern direkt zugeordnet werden, um somit dem Testmanager die Koordination der Testaufgaben zu erleichtern.

Damit die erstellten Testfälle auf den geänderten Funktionen ausgeführt werden können, ist es zunächst notwendig, dass alle Softwareänderungen in das Testsystem transportiert werden. Darüber hinaus ist für die Bereitstellung geeigneter Testdaten im Testsystem zu sorgen, um alle zu testenden Geschäftsprozesse mit realistischen Varianten auszuführen.

Nachdem alle bei der Testplanung notwendigen Aufgaben umgesetzt wurden, kann die Ausführung der manuellen und automatischen Tests durch die Tester erfolgen. Um einen zuverlässigen Betrieb der geänderten Komponenten und Systeme gewährleisten zu können, werden neben den funktionalen Tests zusätzlich Performance- und Lasttests durchgeführt. Wenn während der Tests Fehler auftreten, können diese direkt über Problemmeldungen erfasst und von Entwicklern analysiert werden. Nach Beseitigung der Fehler werden die Korrekturen nachgetestet. Mit dem Reporting liefert der SAP Solution Manager einen Überblick über den jeweils aktuellen Stand der Aktivitäten, der offenen Problemmeldungen und der noch abzuarbeitenden Testpakete.

3.3 Optionen für Testwerkzeuge

Um den dargestellten Ablauf des Testmanagementprozesses zu ermöglichen, unterstützt der SAP Solution Manager den Anwender mit seinen Funktionen während des gesamten Prozesses. In der neuen Version bringt er drei differente Optionen für die Organisation und Durchführung verschiedener Testarten mit. Dabei stehen dem Anwender neben den SAP- auch Nicht-SAP-Testwerkzeuge zur Verfügung (Abbildung 3.2). Nachfolgend werden diese drei Testoptionen vorgestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3 Testoptionen (vgl. [ScMe11], S. 234)

Testoption 1

Die Test Workbench (TWB) ist im SAP Solution Manager die zentrale Anlaufstelle für die Organisation und Durchführung von Tests. Während im integrierten Business Blueprint die Definition und Dokumentation der Geschäftsprozesse erfolgt, kann der Business Process Change Analyser alle am Projekt vorgenommenen Änderungen identifizieren (vgl. [ScMe11], S. 237) und über die TWB-Integration einen Testplan erzeugen. Um die Möglichkeiten der Testautomatisierung zu erweitern, können mit dem Test Automation Framework neben dem eCATT zusätzliche Testwerkzeuge (z.B. HP QuickTest Professional) integriert werden. Die Verwaltung von Problemmeldungen im Service Desk und ein umfangreiches Reporting runden die Funktionen der Testoption 1 ab. Im Gegensatz zu den anderen Optionen kann nahezu der komplette Testprozess in der Option 1 abgebildet werden.

Testoption 2

Die Definition und Dokumentation der Geschäftsprozesse erfolgt über den Business Blueprint des SAP Solution Managers, während eine Schnittstelle für den Transport der Geschäftsprozesshierarchie und der Links auf die Prozessanforderungen an das Requirements-Modul von SAP Quality Center by HP sorgt. Wie bei der Testoption 1 kann der BPCA für die Ermittlung der von Softwareänderungen betroffenen Geschäftsprozesse verwendet werden. Der SAP Quality Center by HP unterstützt den Anwender bei der Verwaltung seiner Tests sowie bei der Planung und Ausführung der Testzyklen. Automatisierte Tests werde mit dem Modul HP QuickTest Professional aus dem SAP Quality Center by HP erstellt und ausgeführt. Zusätzlich kann mit der Anwendung SAP Test Acceleration and Optimization eine schnellere und einfachere Erstellung automatisierter Tests erreicht werden. Die Verwaltung von Problemen während der Testphase, das umfangreiche Berichtswesen und die Möglichkeit, Dashboards für das Management zu erstellen, runden das SAP Quality Center by HP ab. Alle Testergebnisse und Problemmeldungen können über die Schnittstelle an den SAP Solution Manager übermittelt werden, damit Support-Mitarbeiter an der Problemlösung arbeiten können. Außerdem kann der Projektleiter durch diese Integration Berichte im SAP Solution Manager aufrufen und die Testergebnisse im Zusammenhang mit dem Status der Implementierung darstellen.

Testoption 3

Mit dem SAP Solution Manager 7.1 wird eine neue zusätzliche Testoption angeboten, die SAP Solution Manager-Module mit IBM Rational-Modulen integriert. Wie auch bei den ersten beiden Testoptionen werden für die Erstellung der Geschäftsprozesse bzw. Identifikation der Änderungen sowohl der Business Blueprint als auch der BPCA eingesetzt. Für alle weiteren Aufgaben, wie Testorganisation, Aufbau der Tests sowie Verwaltung von Problemmeldungen, übernehmen die über eine neue Schnittstelle integrierten Module von IBM Rational. Die Testergebnisse können über die Schnittstelle an den SAP Solution Manager zurückgegeben werden.

4 Vorbereitungen der Analyse

4.1 Ziele der Untersuchung

Wie im Kontext des Kapitels 3.4 deutlich wird, stehen im neuen SAP Solution Manager unterschiedliche Testoptionen für die Organisation und Durchführung funktionaler Tests zur Verfügung. Durch die Vielzahl an SAP-eigener oder über Schnittstellen integrierbarer Nicht-SAP Werkzeuge ergeben sich viele Möglichkeiten im Testmanagement und der Testautomatisierung. Jedoch haben hohe Kosten der Testwerkzeuge, betriebliche Einsparmaßnahmen oder die große Anzahl benötigter Werkzeuge oft zur Folge, dass Unternehmen auf die Anschaffung von Testwerkzeugen verzichten und dementsprechend nicht alle Möglichkeiten des Testens ausnutzen. Mit der Testoption 1 wirkt SAP diesen Argumenten entgegen und erlaubt die komplette Abdeckung von Geschäftsprozessen im SAP Solution Manager (vgl. [ScMe11], S. 251).

Diese Arbeit soll die Machbarkeit der Testautomatisierung unter Testoption 1 untersuchen und unter Einbezug der neuen Funktionen und Erweiterungen die technischen Möglichkeiten der Testautomatisierung in heterogenen Systemen beschreiben. Hierzu ist eine ausführliche Untersuchung des neuen Test Automation Frameworks und der integrierten Testwerkzeuge notwendig. Das TAF erlaubt nicht nur den Einsatz SAP-eigener Testwerkzeuge, sondern ermöglicht eine nahezu nahtlose Integration der Partner- bzw. Drittanbieter-Werkzeuge (vgl. [ScMe11], S. 251 und 260). Hier gilt es die Integration des externen Testwerkzeugs HP QuickTest Professional sorgfältig zu analysieren und die gewonnenen Erkenntnisse darzulegen. Um den Funktionsumfang des TAFs und der daraus resultierenden Möglichkeiten zu zeigen, werden die Abläufe der Testerstellung und –ausführung und des anschließenden Reportings anhand eines beispielhaften Geschäftsprozesses gezeigt. Während der Beschreibung des Prozesses sollen mit Hilfe einer ereignisgesteuerten Prozesskette die Prozessschritte und die angewandten Systeme skizziert werden. Dabei steht nicht der Prozess, sondern die verwendete Technologie im Fokus der Untersuchung. Zusätzlich soll die Machbarkeit der Modulintegrationstests auf Fachebene und die Handhabbarkeit der Testwerkzeuge im Auge behalten werden.

4.2 Betrachtung der zu testenden Technologien

Das Customer-Relationship-Management (CRM), auch Kundenpflege genannt, ist zu einem wichtigen Bestandteil vieler Unternehmen geworden. Die große Konkurrenz und der hohe Preisdruck auf den Märkten zwingen viele Unternehmen zur Pflege und dem Weiterausbau der vorhandenen Kundenbeziehungen. Schließlich kann die kontinuierliche Kundenbindung an das eigene Unternehmen bis zu fünf Mal billiger sein, als die Gewinnung von Neukunden (vgl. [INET10]). Kundenseitig wird oftmals die Entscheidung über den Kauf eines Produkts nicht aufgrund des Preises getroffen, sondern über die mitgelieferten Leistungen. Der Service nimmt somit einen immer höher werdenden Stellenwert ein. Daher ist es umso wichtiger, dass alle Prozesse reibungslos funktionieren, um einen guten Service anbieten zu können.

4.2.1 Geschäftsprozess der Angebotserstellung

Der Geschäftsprozess der Angebotserstellung mit unterschiedlichen Anwendungen ist ein mögliches Anwendungsgebiet für die Prüfung der Modulintegration. Dieser erstreckt sich über die Teilprozesse der Anlagenerfassung, der Preiskalkulation bis zur endgültigen Erstellung des Angebotsdokuments (siehe Abbildung 4.1). Die integrierten Systeme unterstützen den Anwender bei jedem Prozessschritt und vervollständigen somit den Geschäftsprozess. Die grundlegenden Funktionen des Teilprozesses Anlagenerfassung lassen sich auf die Funktion der Neukundenerstellung reduzieren. Dabei werden neben den allgemeinen Daten, wie Adresse, Vertrieb und Kommunikation auch angebotsrelevante Daten im SAP CRM erfasst. Das SAP-System stellt im gesamten Geschäftsprozess die Basis für die Erfassung und Verwaltung von Kundendaten und muss somit die fehlerfreie Funktionsweise und die Anbindung weiterer Systeme gewährleisten. Die Preiskalkulation für Strom, Gas oder weitere Produkte wird anhand von Verbrauchsdaten in einem externen Kalkulationstool durchgeführt und mittels einer Schnittstelle an die SAP-Anwendung übertragen. Auf Grundlage der erfassten und kalkulierten Daten wird abschließend mit der externen VBA-Anwendung ein Angebotsdokument erstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1 EPK zum Prozess der Angebotserstellung

Der beschriebene Geschäftsprozess ist ein stark vereinfachtes Beispiel eines Prozesses zur Angebotserstellung für Energieprodukte. Der Ablauf folgt der oben genannten Beschreibung, die eine weitere Unterteilung der Prozessschritte vorsieht. Die zu betrachtenden Objekte hierbei sind die angewandten Systeme, die den Anwender bei jedem Prozessschritt unterstützen und den Geschäftsprozess vervollständigen. Dabei übernehmen sie die Aufgaben der Kundenverwaltung, der Preiskalkulation und der Erstellung des Angebotsdokuments.

Wie zuvor erwähnt ist dieser Geschäftsprozess für rein exemplarische Zwecke gedacht und mit realer Angebotserstellung, aufgrund des benötigten Funktionsumfangs und der vielen Variationen in den genannten Prozessschritten, nicht zu vergleichen. Die Beschreibung des Geschäftsprozesses ist soweit erfolgt, dass die Integration der heterogenen Systeme mit den unterschiedlichen Technologien, die für die erfolgreiche Untersuchung von Nöten sind, gezeigt werden kann. Daher wurde bewusst auf die detaillierte Beschreibung des Geschäftsprozesses verzichtet.

4.2.2 Darstellung der Systeme und deren Technologien

Die im Geschäftsprozess erwähnten Anwendungen SAP CRM, Kalkulationstool und DocGenerator unterscheiden sich nicht nur in der Funktionsweise, sondern basieren auf unterschiedlichen Technologien. Während sich das CRM-System aus den SAP-Technologien SAP GUI (SAP Graphical User Interface) und SAP BSP (Business Server Pages) zusammensetzt, ist das Kalkulationstool in der Programmiersprache Java und die Anwendung DocGenerator in Visual Basic for Applications implementiert.

Aufgrund der Tatsache, dass das SAP-eigene Testwerkzeug eCATT nur das automatisierte Testen der SAP GUI ermöglicht (vgl. [INET11]), wird für die Testautomatisierung des oben beschriebenen Geschäftsprozesses mit heterogenen Systemen und Technologien ein weiteres Testwerkzeug benötigt. Da das SAP CRM-System den größten Teil des Tests darstellt, werden die dahinterstehenden Technologien zusammengefasst erklärt.

SAP CRM - SAP GUI und SAP BSP

SAP GUI ist die grafische Benutzeroberfläche eines SAP-Systems und stellt somit in einer Drei-Schichten-Architektur die Programmkomponente der Präsentationsschicht dar (vgl. [INET12]). Alle Bildschirmdarstellungen und Benutzerinteraktionen werden über das SAP GUI abwickelt. In dem oben beschriebenen Beispiel stellt das SAP GUI den Rahmen für die Benutzeroberfläche des SAP CRM-Systems dar. Während im SAP GUI gewöhnliche Benutzerinteraktionen, wie Eingabe der Transaktion, Navigation usw., durchgeführt werden können, stellen SAP BSPs die für das Anlegen eines Neukunden notwendigen Bildschirmdarstellungen bereit.

Business Server Pages sind eine von SAP entwickelte Technologie zur dynamischen Erzeugung von HTML- und XML-Ausgaben eines Webservers. In ABAP geschriebener Code und spezielle BSP-Aktionen können in statischen Inhalt eingebettet werden, mit dem Vorteil, dass die Logik unabhängig vom Design implementiert wird (vgl. [INET13]). Die dynamische Erzeugung von Objekten bringt viele Vor- und Nachteile mit sich. Unter anderem wird eine Vielzahl an Gestaltungsmöglichkeiten der Bildschirmdarstellungen ermöglicht, diese verzögert allerdings die Ausgabe der Objekte. Welche Auswirkungen die verschiedenen Objekte auf das Testen haben, wird die Analyse in Kapitel 5 ergeben.

Beide Technologien stellen viele Objekte zur Verfügung, die auch im SAP CRM-System ihren Einsatz finden. Dazu gehören beispielsweise Eingabefeld, Drop-Down, Auto-Complete, Button, Kontextmenü, Checkbox, Table-Control usw. Diese müssen auf ihre Testbarkeit mit den Testwerkzeugen untersucht werden.

Weitere Technologien und Anwendungen

Weitere wichtige Technologien bzw. Anwendungen, die im oben beschriebenen Geschäftsprozess zum Teil bzw. nicht zum Einsatz kommen, jedoch zusätzlich untersucht werden müssen, sind:

- Java
- Visual Basic for Applications
- SAP CRM Web UI
- ABAP Web Dynpro
- Microsoft Office Anwendungen
- Microsoft Windows Elemente

[...]

^[1] Die hier dargestellten Werte sind einer geleisteten Forschungsarbeit der Firma imbus GmbH entnommen. Dabei führte das Unternehmen in Zusammenarbeit mit dem European Systems and Software Initiative (ESSI) der Europäischen Kommission ein Experiment zur Prozessverbesserung durch automatisiertes Testen grafischer Benutzerschnittstellen durch.

^[2] Eine detaillierte Beschreibung zur Erstellung eines Testplans ist im Kapitel 6 des Buches „Software automatisch testen“ gegeben.

^[3] In Kapitel 7 des Buches „SAP Solution Manager“ wird der Business Process Change Analyzer ausführlich beschrieben.