Automatisiertes Testen von Berechtigungen in betrieblichen Anwendungssystemen

Größe: px
Ab Seite anzeigen:

Download "Automatisiertes Testen von Berechtigungen in betrieblichen Anwendungssystemen"

Transkript

1 FACHBEREICH INFORMATIK LEHRGEBIET PROGRAMMIERSYSTEME Abschlussarbeit im Studiengang Informatik, Abschluss Master of Computer Science Automatisiertes Testen von Berechtigungen in betrieblichen Anwendungssystemen vorgelegt von Khalid Ebanhesaten Matrikelnummer Prüfer: Prof. Dr. Friedrich Steimann Betreuer: Dr. Daniela Keller

2 Inhaltsverzeichnis i Inhaltsverzeichnis Inhaltsverzeichnis... i Abbildungsverzeichnis...iv Tabellenverzeichnis...vi Abkürzungsverzeichnis...vii Eidesstattliche Erklärung... viii Kurzfassung Einleitung Problembeschreibung Lösungsidee Gliederung Warum testen wir Software? Was ist Qualität? Grundlagen des Softwaretestens und des Testprozesses Verifikation und Validation Testfall und Teststufen Regressionstest und risikobasiertes Testen als Teststrategie Testplanung Testspezifikation Testdurchführung Testprotokollierung und Testauswertung Testen im Softwareentwicklungsprozess Wasserfallmodell V-Modell nach Boehm Extreme Programming Software-Test und IT-Governance IT-Governance und der Testprozess Die Notwendigkeit von Tests trotz kürzeren Produktzyklen Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren Was ist Testautomation?...22

3 Inhaltsverzeichnis ii 3.2 Erwartungen an die Testautomation Vorteile der Testautomation Zwei Fehlannahmen der Testautomation Testautomation und was noch zu beachten ist Testwerkzeuge Plattformunterstützung Unterstützung der zu automatisierenden GUI-Elementen Testausführung Testskripterstellung HP Quicktest Professional (QTP) HP Quality Center als Testmanagementtool - Skripterstellung unter QTP Requirements Modul Testplan Modul Testlab (Testlabor) Fehlermanagement (Defectmanagement) Technischer Aufbau von QTP als Add-In vom HPQC Testskripterstellung mit QTP im HPQC Datengetriebene- und Schlüsselwortgetriebene Testskriptarten ObjectSpy von QTP Bewertung von QTP SAP Grundlagen - Vorstellung des Testgegenstands Was ist SAP? Berechtigungsprüfungen in SAP Zusammenhang zwischen SAP Mandant und Buchungskreise Zuordnung von Berechtigungen Das SAP Modul FICO und die direkten abhängigen SAP-Module sowie deren Notwendigkeit in einem Geschäftsprozess SAP FICO als Herzstück des Unternehmens Notwendigkeit für Berechtigungsprüfungen und deren Automatisierung Testen von Berechtigungen: Ist-Zustand Problembeschreibung Warum sich Automatisierung anbietet...55

4 Inhaltsverzeichnis iii Anforderung an einem automatisierten Berechtigungstest SAP-Testdaten und die Notwendigkeit ihrer Transformation Technische Umsetzung Allgemeine Testfallspezifikation für die Berechtigungsprüfung Testsystemlandschaft für die Automation Vorgehensweise bei der Programmierung des Transformationsskriptes Vorgehensweise bei der Programmierung der Testskripten Programmierung des Funktionsbausteins Anmeldemaske Programmierung der Funktionsbausteine Transaktionen laden Ausgabeabgleich Testreport (Testauswertung) Starten eines Testlaufs Erstellung und Programmierung von wartbaren Testskripts Wirtschaftlichkeitsanalyse Kosten für Lizenz & Support- Wartung Break-Even-Analyse Was bringt das Automatisieren der Berechtigungstests? Fazit und Ausblick...89 Anhang... viii Glossar...ix Literaturverzeichnis...x

5 Abbildungsverzeichnis iv Abbildungsverzeichnis Abbildung 2.1 Fehlerkritikalität Comicfigur aus der Zeitschrift die ZEIT... 8 Abbildung 2.2 Blackbox Tests...10 Abbildung 2.3 Whitebox-Test...11 Abbildung 2.4 aus [7], [8], [9] angepasst durch den Autor dieser Masterarbeit...11 Abbildung 2.5 (Dreisystemlandschaft)...14 Abbildung 2.6 Wasserfallmodell nach Royce...15 Abbildung 2.7 V-Modell nach Boehm [5] (angepasst durch den Autor der Masterarbeit)...16 Abbildung 2.8 IT-Governance Prozessmap aus [40] (angepasst durch Autor dieser Masterarbeit)...18 Abbildung 2.9 Release Prozess aus [40] (angepasst durch den Autor dieser Masterarbeit)...19 Abbildung 2.10 Teststufen nach IT-Governance...19 Abbildung 2.11 IT-Governance Prozessablauf...20 Abbildung 3.1 Return on Investment (ROI) Testautomation [35]...27 Abbildung 3.2 HP Quality Center Aufbau...32 Abbildung 3.3 Requirements Modul...34 Abbildung 3.4 Modul Testplan...35 Abbildung 3.5 Testlab und Schnittstelle zu Testplan...36 Abbildung 3.6 Erfassen eines Fehlers (Abweichung)...37 Abbildung 3.7 HPQC und QTP Verbindungsaufbau...39 Abbildung 3.8 Anlegen eines automatisierten Testfalls...40 Abbildung 3.9 Entwicklungsumgebung QTP aus HPQC starten...41 Abbildung 3.10 Anmeldeprozedur und ihre Abhängigkeiten...42 Abbildung 3.11 Anmelderoutine (Ablauf)...43 Abbildung 3.12 Objekt Spion ( ObjectSpy ) im QTP...46 Abbildung 4.1 Zusammenhang SAP- Mandant und Buchungskreis...51 Abbildung 4.2 Module SAP im FICO Umfeld...52 Abbildung 4.3 Skizze aller beteiligten Komponenten...58 Abbildung 4.4 SAP-Rohdatei nach Export in Excel...59 Abbildung 4.5 Transformationsprozess...60 Abbildung 4.6 Ablauf der automatisierten Berechtigungsprüfung...61 Abbildung 4.7 SAP Systemlandschaft inkl. Testsystem...64

6 Abbildungsverzeichnis v Abbildung 4.8 Testautomationsframework...65 Abbildung 4.9 Ablagestruktur Transformationsskript...66 Abbildung 4.10 Einbindung von Bibliotheken in die Entwicklungsumgebung...66 Abbildung 4.11 Ausschnitt aus der fertig transformierten Datei...67 Abbildung 4.12 Programmausschnitt (nicht vollständig)...68 Abbildung 4.13 Berechtigungsprüfungen Testabfolge...69 Abbildung 4.14 Anmeldung SAP System...71 Abbildung 4.15 Transaktionen laden und automatisierte Eingabe...75 Abbildung 4.16 Testablauf für eine Transaktion...77 Abbildung 4.17 Aufruf der "SU53" im Fehlerfall...78 Abbildung 4.18 Abfangen von Fehler...79 Abbildung 4.19 Testreport...80 Abbildung 4.20 Starte Testprogramm...81 Abbildung 4.21 Lebenszyklus für ein Testautomationsskript, das Programme testen soll...82 Abbildung 5.1 Gewinnschwelle...87 Abbildung 5.2 Fehler in der Produktion...88

7 Tabellenverzeichnis vi Tabellenverzeichnis Tabelle 1 Testdauer - Transaktionen...55 Tabelle 2 Generische Testfallbeschreibung für eine Berechtigungsprüfung...63 Tabelle 3 Kostenaufstellung für Toolbereitstellung...84 Tabelle 4 Kostenaufstellung manuell und automatisiert...84 Tabelle 5 Return on Investment...85 Tabelle 6 Initialaufwand...86

8 Abkürzungsverzeichnis vii Abkürzungsverzeichnis AUT BEA BEP FS FICO GUI HR HPQC ITGI QTP SAP SQA Testlab TS UAT Application Under Test Break Even Analyse Break Even Point Funktionale Spezifikation Finance & Controlling Graphical User Interface Human Resources Hewlett Packard Quality Center IT-Governance Institute Quicktest Professional Systeme- Anwendungen- Produkte Software Quality Assurance Testlabor Technische Spezifikation User Acceptance Test (Kundenabnahmetest)

9 Eidesstattliche Erklärung viii Eidesstattliche Erklärung Ich versichere, dass ich die vorliegende Arbeit selbständig und ohne unerlaubte Hilfe Dritter angefertigt habe. Alle Stellen, die inhaltlich oder wörtlich aus Veröffentlichungen stammen, sind kenntlich gemacht. Diese Arbeit lag in gleicher oder ähnlicher Weise noch keiner Prüfungsbehörde vor und wurde bisher noch nicht veröffentlicht. Grevenbroich, den (Khalid Ebanhesaten)

10 Kurzfassung 1 Kurzfassung Der Softwaretest auf traditioneller Weise ist langwierig, komplex, kostenintensiv. Um hochqualitative Applikationen zu erhalten und dabei sowohl Zeit und auch Kosten zu reduzieren, ist eine Automatisierung der Testprozesse erforderlich. Aber nicht nur Geschäftsprozesse einer Anwendung müssen getestet werden, sondern auch der berechtigte oder unberechtigte Zugriff auf Daten. Es muss gewährleistet werden, dass nur die Anwender auf Daten zugreifen dürfen, die eine explizite Erlaubnis dafür haben. Berechtigungen dienen dazu, solche Zugriffe zu regeln und zu verwalten. Somit kann angegeben werden, auf welche Daten ein bestimmter Anwender zugreifen darf und welche Art Zugriff möglich sein soll. Berechtigungen müssen schon alleine wegen gesetzlicher Vorgaben umgesetzt werden, und gehören zum Konzept eines Softwaresystems. Im SAP-System wird diese Aufgabe von sogenannten Berechtigungsobjekten erfüllt. Das Testen von Berechtigungen in SAP-Systemen ist eine Herausforderung - betrachtet man die Anzahl der Benutzer und die verschiedenen Rollen der Benutzer, die in SAP-Systemen vorhanden sind. Diese Masterarbeit befasst sich mit der Automatisierung von Berechtigungstestfällen in SAP-Systemen am Beispiel des SAP-Systems Finanzen und Controlling. Sie bietet eine Einführung in das Thema Testen und Testautomatisierung, basierend darauf wird ein Lösung vorgestellt, wie Berechtigungstests in SAP-Systemen automatisiert durchgeführt werden können.

11 Einleitung 2 1 Einleitung Die Komplexität und die Größe moderner Software-Systeme steigen mit der zunehmenden Zahl an Funktionen, die von Unternehmen und Anwendern verlangt werden. Daher setzen Unternehmen immer mehr komplexer werdende Software, häufiger in unternehmenskritischen und sicherheitskritischen Bereichen ein. Es gibt keine fehlerfreie Software, wie uns die Praxis immer wieder zeigt. Beinahe täglich berichten Fachzeitschriften und Webportale über Fehlverhalten und Sicherheitslücken großer Softwaresysteme. Die Konsequenzen sind oft weitreichend und können erhebliche Kosten verursachen. Ein Beispiel für die möglichen Folgen eines relativ kleinen Fehlers in einem sicherheitskritischen System ist der missglückte Jungfernflug der europäischen Trägerrakete Ariane 5 am 4. Juni Bei dieser Rakete wurde ein Teil der Software komplett vom Vorgängermodell Ariane 4 übernommen. Ein Test der übernommenen Software wurde unter anderem aus Kostengründen nicht durchgeführt. Da die Ariane 5 eine andere Flugbahn hatte als ihr Vorgängermodell, berechnete eine Funktion andere Werte als erwartet. Bei der Konvertierung eines dieser Werte von einer 64 Bit Gleitkommazahl in eine 16 Bit Festkommazahl kam es zum Speicherüberlauf, was einen Ausnahmefehler verursachte. Dieser Überlauf löste eine Folge von Kettenreaktionen aus, worauf die Rakete zerbrach und die Selbstsprengung ausgelöst wurde [1]. Ein Programmierer der US Air Force wollte in seinem Programm, das für eine Rakete bestimmt war, Platz sparen, das stellte er so an: Wann immer die Rakete den Äquator überquerte, sollte sie einfach ihrem bisherigen Flugkoordinaten folgen, allerdings mit umgekehrten Vorzeichen. Dieses Vorgehen führte zwar dazu, dass die Rakete beim Überfliegen des Äquators um die eigene Achse rollte. Das störte allerdings niemanden. Als das Programm jedoch unverändert in den Autopiloten des Jägers F-18 übernommen wurde, flog der Jet beim Überfliegen des Äquators plötzlich mit dem Cockpit nach unten weiter. Diese Beispiele verdeutlichen, welche Auswirkungen es hat, wenn Software in sicherheitskritischen Systemen fehlerhaft ist. Im schlimmsten Falle kann es Menschenleben kosten, wenn Software bspw. bei Flugzeugen fehlerhaft funktioniert und nicht ausreichend getestet worden ist. Durch das reine Testen kann lediglich die Präsenz von Fehlern aufgezeigt werden, nicht die Fehlerfreiheit eines Programms. Das bedeutet aber gleichzeitig, dass durch mehr effektives und kontinuierliches Testen die Wahrscheinlichkeit von Fehlern in einem Softwaresystem geringer wird. Daher stellt sich die Frage, ob man durch geschicktes Einsetzen von Testwerkzeugen das Risiko von Fehlern in Softwaresystemen verringern kann. Diese werden allerdings immer noch von Menschen bedient und können demnach nur so effizient eingesetzt werden, wie ihr Benutzer es zulässt. Einen Weg, auch in schwierigen Projektsituationen einen hohen Testabdeckungsgrad zu erreichen, ist die Einführung und Etablierung eines Testautomationsframework.

12 Einleitung Problembeschreibung Die METRO SYSTEMS GmbH ist eine Tochtergesellschaft der Metro Group und übernimmt alle IT Aufgaben im Konzern. Die METRO SYSTEMS entwickelte auf Basis von SAP 1 und auch in Java vielfältige Business Solutions, die konzernweit die komplette IT Systemlandschaft des Konzerns abbilden. Der aus Sicht der Revision immanenten Gefahr einer unsachgemäßen, ggf. sogar missbräuchlichen Nutzung entsprechender Daten/Information kann nur durch ein adäquat ausgestaltetes Berechtigungskonzept begegnet werden. Das SAP FICO System ist die Unternehmensschaltzentrale des Konzerns, und Fehlbuchungen oder Missbrauch aufgrund von falschen Berechtigungen haben nicht nur finanzielle Folgen, sondern können auch dem Image des Konzerns schaden, was zur Vertrauensverlust führen kann. Unternehmen, die sich vor Wirtschaftskriminalität schützen wollen, kommen um das Thema Funktionstrennung nicht herum. Vor allem in rechnungslegungsnahen Bereichen kann eine fehlende Trennung von Berechtigungen folgenschwere Auswirkungen haben. Die Optimierung des Berechtigungssystems und das Testen eines Berechtigungssystems ist daher ein wesentlicher Faktor, um bspw. kriminelle Handlungen zu verhindern. Gerade in SAP ist es jedoch schwierig, Transparenz in die bestehende Rechtevergabe zu bringen. Das SAP - Berechtigungskonzept ist sehr komplex: Es besteht aus über Transaktionen 2 und beinahe Berechtigungsobjekten, die in einem Zusammenspiel von Rollen, Sammelrollen, Profilen (Benutzern) und Sammelprofilen kombiniert werden können. Erschwerend kommt hinzu, dass für die Vergabe von Berechtigungen nicht immer ausreichende Richtlinien existieren, diese unter Umständen sogar auf Zuruf" erfolgt. Darüber hinaus entstehen im Zeitablauf bspw. durch Mitarbeiterwechsel oder Änderungen in den Verantwortungsbereichen stetig wieder neue, kritische Berechtigungskombinationen. Damit in jeder Testphase die Berechtigungsprüfungen nachweislich durch vorgegebene Kombinationen getestet werden können, muss dieser Prozess automatisiert werden. Der Nachweis und das revisionssichere Hinterlegen der Testergebnisse muss gewährleistet werden, damit bspw. Wirtschaftsprüfer jeder Zeit Zugriff auf die Testergebnisse haben und das Unternehmen den gesetzlichen Verpflichtungen nachkommt. Die SAP bietet kein generelles Masterkonzept, um Berechtigungen automatisiert zu testen, da die Berechtigungen unternehmensspezifisch sind und von vielen anderen Faktoren abhängen wie bspw. der Mitarbeiterorganisation. Deshalb muss sich jedes Unternehmen Gedanken machen, wie es die Berechtigungstests der jeweiligen SAP Lösungen in einer angemessenen Zeit und mit einer hohen Testabdeckung durchführt. 1 (SAP steht für Software Anwendungen Produkte) 2 Quelle.

13 Einleitung 4 Die Anzahl von Berechtigungsfehlern in SAP Produktivsystemen war die Motivation sich mit dem Thema Testautomatisierung in Bezug auf Berechtigungstests zu beschäftigen. Neben dem Problem, dass berechtigte Systemanwender gewisse Programme und Transaktionen im SAP System nicht ausführen können, die sie für ihre tägliche Arbeit benötigen, gibt es weitere Probleme. In erster Linie sind es die anfallenden Kosten für die Behebung solcher Fehler in Produktivsystemen bspw. nach einem erfolgreich durchgeführten Releaseupgrade. Fehler in Produktivsystemen kosten ein Vielfaches der Fehler, die man bspw. auf Testsystemen findet [5]. Ein weiteres Problem in SAP-Systemen sind die diversen SAP-Rollen, die Systemanwendern zugeordnet werden können. Diese SAP Rollen berechtigen einen Systemanwender, Programme und Transaktionen auszuführen. Eine Kombination zwischen Systemanwender und den Rollen, die er in einem SAP-System annehmen darf, machen ein manuelles Testen solcher Kombinationen nahezu unmöglich. Um in einem kurzen Testzeitraum alle Systemanwender und die ihnen zugeordneten Rollen, Programme und Transaktionen zu testen, bietet sich als Lösung an, alle Berechtigungstests automatisiert durchzuführen. 1.2 Lösungsidee Hersteller von Softwaresystemen für betriebliche Anwendungen sind einem enormen Wettbewerbsdruck ausgesetzt und müssen den hohen Anforderungen am Markt genügen, um konkurrenzfähig zu sein. Der Wettbewerbsdruck wird durch den Kunden erzeugt, indem in immer kürzer werdenden Zyklen Releases erwartet werden, bei gleichzeitiger Qualitätsverbesserung. Ein vollständiger manueller Test aller Berechtigungen ist mit der großen Anzahl dafür notwendiger Testfälle nicht realisierbar oder nur mit einem unvertretbaren hohen Aufwand möglich. Das Ziel dieser Arbeit ist es, genau dieses Berechtigungskonzept durch eine Testautomationslösung für SAP Anwendungen automatisiert zu testen. Mit dieser Lösung sollen die bisdato nur manuell in Stichproben durchgeführten Berechtigungsprüfungen im Buchhaltungssystem SAP FICO 3 abgelöst werden. Die Nachteile der manuellen Testlösung liegen auf der Hand: die immer wiederkehrenden Testphasen, getrieben durch immer kürzer werdende Releasezyklen und Testphasen, erlauben keinen vollständigen Test. Ziel ist es eine Testabdeckung von 100% zu erreichen, somit werden nicht nur Fehler auf Produktivsystemen vermieden, sondern es werden gleichzeitig gesetzliche Vorgaben erfüllt. Dabei soll eine generische Lösung angestrebt werden, sprich, die Lösung soll transparent auch für andere SAP Anwendungen anwendbar sein, unabhängig, in welchem SAP Modulen diese eingesetzt werden. Der Autor dieser Masterarbeit illustriert demonstrativ anhand eines Beispiels aus der Handelsbranche, wie eine Testautomationslösung für SAP Berechtigungsprüfungen aussehen kann. Die Lösung soll in einem ersten Schritt die in einem SAP-System Regelwerk gepflegten Systemanwender und die zugeordneten Rollen und Berechtigungen auslesen können. Es wird eine Exceldatei generiert, die mit Testautomationswerkzeugen kombiniert werden kann. Die Exceldatei 3 Finanzen und Controlling

14 Einleitung 5 enthält das komplette Berechtigungskonzept eines SAP-Systems. Allerdings ist die so generierte Exceldatei sehr umfangreich und beinhaltet auch Informationen, die für einen automatisierten Testdurchlauf irrelevant sind. Daher muss die Komplexität auf nur die Informationen reduziert werden, die für einen Test relevant sind. Dieses geschieht durch eine Transformation der Datei. Das Ergebnis dieser Transformation ist eine weitere Exceldatei, die jeden Systemanwender aufführt und seine erlaubten Transaktions- und Programmaufrufe. Sie enthält also alle SAP-Transaktionen und Programme, die ein Systemanwender in seiner Rolle ausführen darf. Die Transformation ist eine grundlegende Voraussetzung für die Automatisierung der Berechtigungstests. Die dort generierte Datei beinhaltet nicht nur die Informationen über die Systemanwender und Rollen, sondern diese dienen gleichzeitig als Testdaten. In einem weiteren Schritt muss jetzt ein Testskript mit Hilfe eines Testwerkzeugs entwickelt werden, der folgendes leisten muss: Anmelden am SAP-System mit einer Systemanwenderrolle. Auslesen der Datei, die aus der Transformation entstanden ist die die Systemanwender und deren Systemanwenderrollen beinhalten. Ausführen der einzelnen Transaktions- und Programmaufrufe für den jeweiligen Systemanwender. Auswerten des Testablaufs in einem Testprotokoll. Die Herausforderung hierbei ist, ein Testskript zu entwickeln, welches generisch für verschiedene SAP- Systeme anwendbar ist. Ein positiver Nebeneffekt dieser Lösung ist, dass die Datei die aus der Transformation entstanden ist, beliebig manuell erweitert werden kann, um gezielt Fehler in den Testdaten zu platzieren, um auch gleichzeitig überprüfen zu können, ob Testskripte auch korrekt testen. 1.3 Gliederung Nach der Einleitung bietet Kapitel 2 im ersten Teil dem Leser einen wissenschaftlichen Einstieg in das Thema Softwaretesten. Darauf basierend werden die Begriffe Verifikation und Validation in Bezug auf statische- und dynamische Tests abgegrenzt. Weiter wird das risikobasierte Testen als Teststrategie des Regressionstests erläutert. Im zweiten Teil des Kapitels 2 erfolgt eine kurze Erläuterung zum Thema Testen im Softwareentwicklungsprozess, insbesondere im Wasserfall- und V-Modell, daneben wird das agile Extreme Programming tangiert. Den Abschluss dieses Kapitels bietet das Thema IT- Governance in Bezug auf den Testprozess in der Softwareentwicklung. Es wird erläutert, warum ein IT-Governance Tool die Qualitätssicherung unterstützen kann.

15 Einleitung 6 In Kapitel 3 erfolgt eine etwas detaillierte Betrachtung des Themas Testautomation. Dort werden die Grundlagen der Testautomation vorgestellt sowie die Erwartungen, die an eine Testautomation gestellt werden. Neben den Erwartungen und Vorteilen werden auch die Grenzen und Fehlannahmen von Testautomatisierung beleuchtet und darauf hingewiesen, wie diese umschifft werden können. Dabei werden die Anforderungen an Testwerkzeuge formuliert und das Testwerkzeug Quicktest Professional vorgestellt. Den letzten Teil des Kapitels 3 ist dem Testmanagementtool von Hewlett Packard Quality Center gewidmet. Dieses bildet zusammen mit Quicktest Professional den Rahmen für die Realisierung der Testautomation. Kapitel 4 fokussiert sich auf den Hauptteil dieser Masterarbeit und stellt zunächst das Testgegenstand vor. Was ist SAP? Aus welchen Modulen besteht es, und welche sind für diese Masterarbeit von Bedeutung? Wie werden Berechtigungen zugeordnet, und was sind in diesem Zusammenhang Buchungskreise? Dann werden die Anforderungen an eine Testautomatisierung für Berechtigungstests aufgeführt, sprich was die Testautomationslösung während des automatisierten Testdurchlaufs leisten muss. Die technische Umsetzung bildet den zweiten Schwerpunkt dieses Kapitels. Es erläutert die am Test beteiligten Komponenten und zeigt kleine Programmausschnitte der Realisierung. Es wird erläutert, wie ein Transformationsskript entwickelt wird und welche Bibliotheken dafür entwickelt worden sind. Die Bibliotheken enthalten neben den Testablauflogiken auch die für den Test notwendigen Informationen wie das Abfangen und Verarbeiten von SAP-Systemmeldungen. Basierend darauf wird ein generisches Testskript entwickelt, dass über die Bibliotheken und die Testdaten gesteuert wird. Abschließend wird die automatisierte Testauswertung gezeigt. Kapitel 5 konzentriert sich auf die Kosten der umgesetzten Testautomationslösung und welche Einsparungen und Testabdeckungsgrad erreicht werden können. Für dieses Projekt wurde von der Projektleitung ein Budget in Höhe von Euro als Grenze gesetzt, was nicht überschritten werden darf. Kapitel 6 gibt eine Zusammenfassung der Masterarbeit wieder und einen Ausblick.

16 Warum testen wir Software? 7 2 Warum testen wir Software? Im folgenden Text geht es zunächst um Qualität und dessen Begriffsdefinition. Bevor dann die Grundlagen des Softwaretestens und der Testprozess im Softwareentwicklungsprozess beleuchtet wird. Der letzte Abschnitt erläutert kurz den Zusammenhang zwischen Softwaretesten und IT- Governance. Bei jedem Softwareprogramm ist zu entscheiden, wie intensiv und wie umfangreich es zu testen ist. Diese Entscheidung muss in Abhängigkeit vom erwarteten Risiko bei fehlerhaftem Verhalten des Programms getroffen werden. Um zu einem zufrieden stellenden Ergebnis zu kommen, müssen die Tests strukturiert und systematisch durchgeführt werden. Nur so ist es mit angemessenem Aufwand möglich, viele Fehlerwirkungen nachzuweisen und unnötige Tests, die zu keinen neuen Erkenntnissen führen, zu vermeiden. 2.1 Was ist Qualität? Software-Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Software-Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht 4. Die Qualität eines Produktes ergibt sich somit aus der Summe aller seiner Eigenschaften bezogen auf die gestellten Anforderungen. Im Buch von J. McCall, P.K. Richards und G. Walters Factors in Software Quality wurden schon in den siebziger Jahren die Eigenschaften von Softwarequalität beschrieben, was heute auch in der ISO Norm für Software-Engineering wieder zu finden ist. Die Norm beschreibt ein Modell, das die Eigenschaften in sechs Kategorien einordnet vgl. dazu Fußnote 5. Funktionalität Zuverlässigkeit Benutzerfreundlichkeit Effizienz Wartbarkeit Portierbarkeit Diese sechs Kriterien sind teilweise nicht messbar, bspw. kann die Benutzerfreundlichkeit von verschiedenen Nutzergruppen unterschiedlich beurteilt werden. Zumindest gibt es dadurch die Möglichkeit diese Eigenschaften durch Test eingeschränkt zu bestimmen. Die Motivation und das Ziel jeder Softwareentwicklung muss es sein, ein möglichst fehlerfreies Softwareprodukt zu erstellen und dadurch die Qualität zu verbessern. Es gibt verschiedene Auffassungen vom Begriff Qualität, dass spiegelt sich auch in den verschiedenen Literaturen zu diesem Thema wieder vgl. dazu [5], [7], [9]. 4 Quelle: International Organization for Standardization,

17 Warum testen wir Software? 8 Ziele der Softwareentwicklung werden hauptsächlich aufgrund von wirtschaftlichen Interessen definiert. So geht es oft darum, die Erstellung eines Produktes zu beschleunigen, bei gleichzeitiger Kostenreduktion sowie eine Qualitätssteigerung eines Produktes. Die Beschleunigung der Softwareentwicklung wird durch die Wiederverwendung von Software erreicht, die Beschleunigung der Sicherstellung der Qualität kann analog zur Softwareentwicklung durch Wiederverwendung von Tests erreicht werden und durch Testautomation ergänzt werden. Durch diese immer größere Steigerung der Wiederverwendung von Funktionen, Klassen, Komponenten und Architektur wird die Softwareentwicklung vereinfacht. Dem Ansehen eines Unternehmens wird durch eine fehlerhafte Softwareauslieferung schnell geschadet und dies kann zu einem mehr oder weniger großen wirtschaftlichen Schaden führen. Abbildung 2.1 Fehlerkritikalität Comicfigur aus der Zeitschrift die ZEIT Qualitätssteigerung durch Testen Der Begriff Testen lässt sich auf verschiedenen Arten definieren: 1. Testen bedeutet, eine gegebene Software zu einem gegebenen Zeitpunkt zu nehmen und überzeugend zu zeigen, dass sie den gegebenen Anforderungen entspricht [3]. 2. Testen ist die Ausführung eines Programms mit dem Ziel, seine Funktion zu bestätigen. Testen ist die Ausführung eines Programms mit dem Ziel, seine Zuverlässigkeit zu messen [4]. 3. Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. Aus dieser Definition ist zu folgern, dass ein Test dann erfolgreich war, wenn er einen Fehler gefunden hat [5]. 4. Unter Softwaretesten versteht man die Verifikation und Validation einer Softwarekomponente oder eines Softwaresystems [9]. Ziel dieses Vorgangs ist es, die Qualität bzw. die Korrektheit einer Software zu überprüfen. Der Begriff Korrektheit

18 Warum testen wir Software? 9 bezieht sich hierbei auf das Verhalten der Software bzgl. des in ihrer Spezifikation festgeschriebenen Verhaltens. 5. Nach [6] ist der Test ein überprüfbarer und jederzeit wiederholbarer Nachweis der Korrektheit eines Softwarebausteins relativ zu vorher festgelegten Anforderungen, und definiert das Testen so: Testen ist der Vergleich spezifizierter Eigenschaften mit realisierten Eigenschaften. Es ist eine objektive Methode zur Verifikation einer erbrachten Leistung. Es gibt unterschiedliche Ansätze, wie Fehler gefunden oder die Funktionalitäten des Programms nachgewiesen werden kann. Aber auch negative Tests sind notwendig, dadurch können gleichzeitig auch Testfälle auf Fehler getestet werden. Ein negativer Test kann bspw. sein zu prüfen, ob man in einem als Integer definiertem Feld auch Buchstaben zulässig sind. Ebenso können im Entwicklungsprozess unterschiedliche Testtechniken angewendet werden. 2.2 Grundlagen des Softwaretestens und des Testprozesses Dieser Abschnitt teilt sich in zwei Schwerpunkte auf, der erste Teil erläutert die Grundbegriffe des Softwaretestens wie bspw. Softwareverifikation und Softwarevalidation. wobei sich der zweite Teil auf den Softwaretestprozess fokussiert Verifikation und Validation Thaller [7] sieht in der Verifikation die Überprüfung einer Software am Ende einer Entwicklungsphase gegen Anforderungen, einen Standard oder die Ergebnisse der vorhergehenden Phase. D.h., die Verifikation hinterfragt, ob das System mit der Beschreibung bzw. mit der Spezifikation übereinstimmt oder ob das System so funktioniert, wie es in der Beschreibung behauptet wird. Bei Validation handelt es sich um die Prüfung der Frage, ob ein Softwareprodukt seinen Anforderungen gerecht wird. Es gibt einen grundsätzlichen Unterschied: Die Verifizierung weist nach, dass die erzeugten Komponenten der Spezifikation aus der Anforderungsentwicklung genügen. Das bedeutet, dass die Tests von unten nach oben (Bottom-Up) durchgeführt werden. Demgegenüber liefert die Validierung eine Bestätigung dafür, dass das Produkt den Merkmalen genügt, die der Endanwender gefordert hat. Dies impliziert einen von oben nach unten laufenden Systemtest. Grob kann gesagt werden, dass bei Verifikation überprüft wird, ob das Produkt richtig funktioniert, bei Validation prüfen wir, ob wir das richtige Produkt erstellt haben [7]. Kurz: Validierung: Erstellen wir das richtige Produkt? Verifikation: Erstellen wir das Produkt richtig? Während die Verifikation den Output einer Entwicklungsphase auf die Korrektheit mit der vorherigen Phase untersucht, wird die Validation benutzt, um das Gesamtsystem mit den Kundenanforderungen

19 Warum testen wir Software? 10 zu vergleichen. Die zentrale Tätigkeit der Validation ist das Testen. Das Gesamtsystem wird bei Ende des Prozess getestet, ob es den Kundenanforderungen entspricht oder nicht. Verifikation ist in erster Linie auf Einzelheiten (Review eines Grobkonzepts oder Durchsicht des Pflichtenheftes) ausgerichtet, während bei Validation das Produkt in seiner Umgebung getestet wird. Validation wird auch dynamisches testen genannt im Unterschied zur Verifikation wo statisch getestet wird. Bei dynamischem Test wird die Software zum Testen ausgeführt, und beim statischen Testen nicht. Das ist auch der grundlegendste Unterschied zwischen Verifikation und Validation. Insgesamt lässt sich das Testen zusammenfassen als: Testen von Software dient der Sicherstellung bzw. Steigerung der Qualität der Software Testfall und Teststufen Als Softwaretest wird hierbei die systematische Ausführung eines Programms bezeichnet. Zentrales Element der Tests sind die Testfälle, und Testfälle beschreiben wie auf Eingaben das System zu reagieren hat, und welche Ausgaben es erwartet. Ein Testfall besteht aus Eingabedaten und erwarteten Ausgabedaten. Die sich beim dynamischen Ablauf ergebenden Daten werden gegen die erwarteten Ausgabedaten geprüft [2]. Ein Testfall prüft die Software, ob die spezifizierten Anforderungen umgesetzt sind. Dabei beeinflusst die Wahl und die Ausformulierung der Testfälle die Qualität einer Software, denn die Bestimmung von Testfällen erfordert nicht nur Disziplin, sondern auch Wissen über die zu testende Anwendung und Kreativität. Dabei bieten einem Tester die gängigen Testverfahren Orientierung, um Testziele zu formulieren. Es existieren bspw. Verfahren, um ein Programm gegen eine Spezifikation zu testen, solche Tests nennen sich Blackbox-Tests, und andere Tests bspw. konzentrieren sich auf die innere Struktur eines Programms, also auf Quellcode- Ebene. Solche Tests werden Whitebox-Tests (Strukturtests) [9] genannt. Abbildung 2.2 Blackbox Tests

20 Warum testen wir Software? 11 Der Strukturtest prüft ein Programm mit konkreten Werten. Hierbei handelt es sich um eine Analyse der inneren Struktur eines Systems meist einer Systemkomponente. Testdaten werden vom Tester aus der Programmlogik hergeleitet, d.h. Testfälle werden direkt aus dem Quellcode abgeleitet. Abbildung 2.3 Whitebox-Test Sowohl der Blackbox-Test als auch der Whitebox-Test kommen in unterschiedlichen Teststufen zum Einsatz. Abbildung 2.4 aus [7], [8], [9] angepasst durch den Autor dieser Masterarbeit Der Modul- und Funktionstest stellt die erste unterste Stufe des computergestützten Testens bei der Softwareentwicklung dar. Zunächst werden hierbei alle elementaren Bausteine als Fundament eines Programmsystems getestet und dann erst ihre Integration. Modul- und Funktionstesten findet sich oft unter dem Begriff des Komponententests wieder. Der Integrationstest testet komponentenübergreifend. Für den Begriff des Integrationstests wird auch Funktionales Testen genutzt. Funktionales Testen geschieht ohne Wissen der inneren Strukturen und ähnelt somit der Anwendung des Produkts. D.h. in dieser Teststufe werden alle angebundenen Komponenten zusammengeführt und getestet. Die Teststufe des Systemtests ist nur aufgrund der Vollständigkeit

21 Warum testen wir Software? 12 hier aufgeführt und im Rahmen dieser Masterarbeit nicht von Relevanz. Ein Systemtest fokussiert sich auf das Testen der Benutzeroberflächen, Datenbanken und Systemschnittstellen. Der Abnahmetest orientiert sich an der Anforderung und der Spezifikation und wird durch den Kunden durchgeführt. Abnahmetests werden auf Grundlage der Spezifikation erstellt und dienen nicht vorrangig der Suche nach Fehlern aus der Programmierung (Verifikation der Software), sondern dienen der Feststellung, ob die Software den Anforderungen, Bedürfnissen und Wünschen des Kunden entspricht (Validation der Software). Der Abnahmetest stellt einen Meilenstein im Softwarelebenszyklus dar. Zuvor befindet sich das Produkt in der Entwicklungsphase, wobei die Verantwortung für die Entwicklung beim Auftragnehmer liegt. Mit erfolgreichem Abschluss der Abnahmetest wechselt die Verantwortung zum Auftraggeber, das Softwareprodukt wird ausgeliefert und befindet sich von diesem Zeitpunkt an in der Pflege- und Wartungsphase [7]. Eine Teststufe die in der Grafik nicht aufgeführt wurde, ist der Regressionstest. Dieser Test fokussiert sich darauf, dass Änderungen an der Software sich nicht auf andere Funktionen der Software auswirken Regressionstest und risikobasiertes Testen als Teststrategie Sowohl durch Wartungsarbeiten als auch bei Weiterentwicklungen werden Teile vorhandener Software geändert oder um neue Softwarebausteine ergänzt. In beiden Fällen muss die geänderte Software erneut getestet werden, diese Tests heißen Regressionstests. Da diese Tests nach jeder Änderung an einer Software ausgeführt werden müssen, wäre hier eine Automatisierung der Testfälle eine sinnvolle Investition. Die Automatisierung von Testfällen in betriebswirtschaftlichen Informationssystemen ist auch heute noch nicht die Regel, sondern eher die Ausnahme [30]. Wegen den Faktoren Zeit, Kosten und Wettbewerbsdruck entstand daher das sogenannte risikobasierte Testen: risikobasiert aus dem Grund, weil aus einem großen Pool an Testfällen entschieden werden muss, welche auszuführen sind. Alle möglichen Testfälle einer Anwendung auszuführen wäre nur mit einem unvertretbar hohen Aufwand möglich. Risikobasiertes Testen ist vor allem bei Großsystemen ein wichtiger Ansatz. Da es unmöglich ist, in einem umfangreichen Softwareprodukt alle möglichen Programmteile zu testen, sollte eine Risikogewichtung vorgenommen werden, die eine grobe Unterteilung gibt, wo die Fehlerhäufigkeit am größten sind, und welche Fehler massiven Schaden bei Kunden anrichten und somit eventuell zu Schadenersatzforderungen führen können. Ziel des risikobasierten Testens ist, höheres Vertrauen in das getestete Produkt zu schaffen, die Fehlerkosten des Produkts im operativen Einsatz zu verringern und die Testressourcen effizienter zu nutzen [26]. Dabei kann der Umfang eines Tests gemeinsam von Testern und Kunden festgelegt werden. Diese Tests werden dann mit einer Priorisierung versehen und ausgeführt. Eine Priorisierung hat den Vorteil, dass die wichtigsten Testfälle als erstes zur Ausführung kommen und schwerwiegende Fehlerwirkungen frühzeitig erkannt und behoben werden können. Im zweiten Teil dieses Abschnitts erfolgt jetzt eine Fokussierung auf den Testprozess, der in kleinere Arbeitsschritte gegliedert werden muss:

22 Warum testen wir Software? 13 Testplanung Testspezifikation Testdurchführung Testprotokollierung und die Testauswertung Diese kleineren Arbeitsschritte bilden einen fundamentalen Testprozess diese werden jetzt vorgestellt Testplanung Mit der Planung des Testprozesses wird zum Beginn eines Softwareentwicklungsprozesses, eines Releases oder System-Upgrades begonnen. Für den Testprozess sind die benötigten Ressourcen einzuplanen und die entsprechenden Festlegungen in einem Testkonzept festzuhalten. Heutzutage existieren viele Tools, die das Projektmanagement und Testmanagement dabei unterstützen, solche Planungen bis auf Testfallebene durchzuführen und auszuwerten. Damit können der Testprozess, die Testinfrastruktur sowie das zu testende System verwaltet werden. Die Hauptaufgabe der Planung ist die Bestimmung der Teststrategie. Ziel der Teststrategie ist die optimale Verteilung der Tests auf die kritischen Stellen des Softwaresystems, um eine Testfallexplosion zu vermeiden. In der Praxis werden bspw. Experten Sessions durchgeführt, an denen Entwickler, Tester und der Fachbereich, der in der Regel auch die Anforderung stellt, teilnehmen. Neben dem Wissenstransfer, welches in den Sessions ausgetauscht wird, werden auch die Testfälle für den Test bestimmt und festgelegt Testspezifikation Die im Testplan festgelegte Teststrategie bestimmt, welche Testmethoden zum Einsatz kommen sollen. In der Testspezifikation werden dann unter Anwendung dieser Testmethoden die entsprechenden Testfälle spezifiziert. Neben den üblichen Abnahmetestfällen sollte die Testfallspezifikation auch Integrationstestfälle und Modultestfälle enthalten. Die Spezifikation erfolgt in zwei Schritten, zuerst sind generische Testfälle zu definieren, anschließend können diese dann durch Testdaten konkretisiert werden Testdurchführung Nach Übergabe der zu testenden Programmteile durch die Entwicklungsabteilung an die Testabteilung kann mit der Testdurchführung begonnen werden. Die Übergabe erfolgt meistens formal durch eine Abnahme der IT-Qualitätssicherung. Als Basis für die Abnahme gelten die Modultests die durch die Entwickler durchgeführt werden müssen. In einer Dreisystemlandschaft (siehe Abbildung 2.5) bestehend aus Entwicklungssystem, Testsystem und Produktivsystem erfolgen auf einem Entwicklungssystem die Implementierung sowie der anschließende Entwicklertest. Auf dem Testsystem erfolgt ein Test der über den Modultest hinausgeht. Bevor die Qualitätssicherung mit dem Testen der Anwendung beginnen kann, sollte immer sichergestellt werden, dass auf dem Testsystem

23 Warum testen wir Software? 14 alle für den Test benötigten Programme und Testdaten vorhanden sind, sowie alle für den Test benötigten Systeme angebunden sind. Abbildung 2.5 (Dreisystemlandschaft) Als grundsätzliche Teststrategie empfiehlt sich, die Testdurchführung mit der Überprüfung der Hauptfunktionen des Testobjekts zu beginnen. Sollten sich hier bereits Fehlerwirkungen oder Abweichungen von den Sollergebnissen zeigen, ist ein tiefes Einsteigen in das Testen wenig sinnvoll, da vorab die fehlerhaften Hauptfunktionen korrigiert werden müssen Testprotokollierung und Testauswertung Die Durchführung der Tests ist vollständig zu dokumentieren und zu protokollieren. Zum einen muss anhand dieses Protokolls die Testdurchführung auch für nicht direkt beteiligte Personen, z.b. für den Kunden, nachvollziehbar sein. Gleichzeitig dienen Auswertungen von Tests als Dokumentationen für z.b. Wirtschaftsprüfer in SAP-Finanzsystemen, in diesem Fall müssen alle Testfälle revisionssicher, nicht offen zugänglich und nicht manipulierbar sein. Das Testprotokoll muss Auskunft darüber geben, welche Komponenten, von wem, wann, in welcher Intensität und mit welchem Testergebnis getestet wurden. Nach [12] muss zu jeder Testdurchführung eine ganze Reihe Dokumente und Informationen zusammengestellt werden, die es ermöglichen den Test zu einem späteren Zeitpunkt mit den gleichen Daten und Randbedingungen zu wiederholen. Die Dokumente beinhalten Testrahmen, Testprotokolle, Testabdeckungsprotokolle, Eingabedaten, usw. Testprotokolle sind in erster Linie Testablaufprotokolle, sogenannte Logs, die die Reihenfolge der getesteten Komponenten dokumentieren. Testabdeckungsprotokolle geben Informationen darüber, welche Zweige, Methoden, Operationsaufrufe und Objekte wie oft ausgeführt werden [8]. Kurz: der Testprotokoll beinhaltet in Summe die Testergebnisse auf einem Blick, öffnet man ein Testprotokoll so kann auf den Testablaufprotokoll zugegriffen werden, der jeden Testschritt dokumentiert sowie die zum Testzeitpunkt gemeldeten Systemmeldungen beinhaltet. Testablaufprotokolle sind vor allem bei Fehlern wichtig, um die Fehler besser eingrenzen zu können.

24 Warum testen wir Software? 15 Tritt bei der Testdurchführung eine Abweichung zwischen dem tatsächlichen und dem erwarteten Ergebnis auf, ist bei der Auswertung der Testprotokolle zu entscheiden, ob tatsächlich eine Fehlerwirkung vorliegt, oder ob möglicherweise die Testspezifikation, die Testinfrastruktur oder der Testfall bzw. der Testlauf Fehler aufweisen. 2.3 Testen im Softwareentwicklungsprozess In diesem Abschnitt werden das Wasserfall-, V-Modell und aus der agilen Softwareentwicklung das Extreme Programming erläutert Wasserfallmodell Das Wasserfallmodell bspw. erfolgt das Testen am Ende eines Entwicklungsprozesses. Das Wasserfallmodell wurde von Royce entwickelt und später vor allem von Boehm propagiert. Erst wenn eine Entwicklungsphase abgeschlossen ist, wird mit der nächstfolgenden begonnen. Es gibt nur zwischen angrenzenden Stufen Rückkopplungsschleifen, die eine gegebenenfalls notwendige Überarbeitung in der vorherigen Stufe ermöglichen. Der entscheidende Nachteil ist, dass das Testen als einmalige Aktion am Ende eines Prozesses kurz vor Inbetriebnahme angesehen wird. Abbildung 2.6 Wasserfallmodell nach Royce 5 Das hat zu Folge, dass Fehler zu spät gefunden werden, und dadurch die Kosten für Fehlerbehebung um ein vielfaches teurer sind [9]. 5 Das Wasserfallmodell ist ein sequenzielles Vorgehensmodell, das die Entwicklung anhand aufeinanderfolgender Phasen organisiert. Es wurde 1970 von Royce vorgeschlagen und wurde von Boehm als Wasserfallmodell bezeichnet.

25 Warum testen wir Software? V-Modell nach Boehm Das V-Modell ist auf der Basis der Grundidee entwickelt worden, dass Entwicklungsarbeiten und Testarbeiten zueinander korrespondierende, gleichberechtigte Tätigkeiten sind. Bildlich dargestellt wird dies durch die zwei Äste eines V s, siehe Abbildung 2.7. Abbildung 2.7 V-Modell nach Boehm [5] (angepasst durch den Autor der Masterarbeit) Der linke Ast steht für die immer detaillierter werdenden Entwicklungsschritte, in deren Verlauf das vom Kunden gewünschte System schrittweise entworfen und schließlich programmiert wird. Der rechte Ast steht für Integrations- und Testarbeiten, in deren Verlauf Programmbausteine sukzessive zu größeren Teilsystemen zusammengesetzt (integriert) und jeweils auf die richtige Funktion geprüft werden [9] Extreme Programming Im agilen Umfeld, insbesondere Extreme Programming, spielen Tests eine zentrale Rolle was sich im Test-First-Ansatz widerspiegelt. Zunächst einmal wird ein Testfall entwickelt, erst dann die passende Komponente. Jetzt kann abwechselnd das Programm kompiliert und automatisiert getestet werden bis der Testfall erfolgreich ist. Das hat mehrere Vorteile: Tests dokumentieren Code Jedes Programmstück ist getestet Code ist testbar Entwickler beschäftigen sich beim schreiben eines Testfalls sehr intensiv um die Anforderung die es gilt zu entwickeln. Der positive Nebeneffekt ist, dass Programme so entwickelt werden, dass diese von vornherein testbar sind. Im Extreme Programming stellen Funktionstests vollständig die Anforderungsspezifikation. Die Funktionstests müssen vorher von einer Fachabteilung ausformuliert und entwickelt werden. Generell sollten Funktionstest mit Prioritäten versehen werden. Um zu einem

26 Warum testen wir Software? 17 zufriedenstellenden Ergebnis zu kommen, müssen die Tests strukturiert und systematisch durchgeführt werden. Beim Strukturieren von Entwicklungs- und Testphasen bieten sogenannte IT Governance Tools, die zumeist in Unternehmen mit größeren Organisationen zum Einsatz kommen Unterstützung. Dort müssen die Verantwortlichkeiten zwischen IT-Anforderer, Entwickler, Tester und Projektmanager enger abgegrenzt werden. 2.4 Software-Test und IT-Governance Warum die Themen Softwaretesten und IT-Governance so eng miteinander verzahnt sind, soll dieses Kapitel verdeutlichen. Dabei soll das Zusammenspiel zwischen Anforderungsermittlung, Entwicklung und Test anhand von standardisierten Prozessen verdeutlicht werden. IT Governance Tools dienen dazu, die Zusammenarbeit von verschiedenen Unternehmensorganisationen zu koordinieren und zu verwalten. Sie bieten gleichzeitig Auswertungsfunktionen und unterstützen die Einhaltung des Vieraugen-Prinzips. Im Rahmen dieser Masterarbeit erfolgt die Erläuterung zu IT-Governance ausschließlich aus der Sicht der IT-Qualitätssicherung. Es wird besonders die Rolle der Tester beleuchtet, eine ausführliche Erläuterung bietet [21]. Ein vollständiger IT-Standardprozess inkl. aller am Prozess beteiligten Rollen befindet sich im Anhang. IT-Governance ist eine von Hewlett Packard (HP) entwickelte Software, mit der sich Prozesse der Softwareentwicklung standardisieren lassen. Es lehnt sich an das V-Modell von Boehm an und weltweit gibt es heute Beratungshäuser wie PriceWaterhouse Coopers, die sich immer mehr dem Thema IT Governance widmen. Sie legen fest, was unter diesem Begriff zu verstehen ist und welche Hilfsmittel für eine erfolgreiche Einführung und Sicherstellung der IT Governance angewendet werden können. Das IT-Governance Institute (ITGI) definiert IT-Governance wie folgt [44]: IT-Governance liegt in der Verantwortung des Vorstands und des Managements und ist ein wesentlicher Bestandteil der Unternehmensführung. IT-Governance besteht aus Führung, Organisationsstrukturen und Prozessen, die sicherstellen, dass die IT die Unternehmensstrategie und -ziele unterstützt. Die Definition aus [44] trifft genau die Kernaufgabe solcher Tools. Es ist ein Instrument mit dem auch das Management steuern, planen und kontrollieren kann. Die IT-Governance wird maßgeblich gesteuert von den externen Anforderungen an die IT-Prozesse und -Systeme sowie die internen Zielsetzungen des IT-Managements. Während in den letzten Jahren weniger Regelungen zur Entwicklung oder für den Betrieb der Informatiklösungen vorhanden waren und die Systemlandschaften über alle Komponenten entsprechend relativ frei gestaltet wurden, sind heute immer mehr Standards im Sinne von Standard-Prozessen und -Methoden, aber auch technischen Protokollen oder Best Practices vorhanden. Hierzu gehören etwa Standards im Bereich

27 Warum testen wir Software? 18 des Projektmanagements oder des IT Service Managements (z.b. ITIL 6 ). Es gibt verschiedene Frameworks, die dass IT-Governance unterstützen, wobei ITIL 7 in Ansätzen genutzt wird IT-Governance und der Testprozess Das IT Governance Tool basiert auf einem Workflow 8 mit Rollen und Berechtigungen. Die Einführung eines IT-Governance Tools bringt einem Unternehmen folgende Vorteile: Exakte Beschreibung der IT-Services und damit Ausrichtung auf die Kunden Eindeutig definierte Verantwortlichkeiten und Ansprechpersonen Detailliert definierte Prozesse mit Performancemessungen, Qualitäts- und Kostenkontrolle Basis für Zertifizierung Für viele Unternehmen bspw. in den USA ist es essentiell, dass sie zertifiziert sind, weil dieses eine Voraussetzung ist, um an Ausschreibungen teilzunehmen. Die Computergestützte Einhaltung des Vieraugen-Prinzip Abbildung 2.8 IT-Governance Prozessmap aus [40] (angepasst durch Autor dieser Masterarbeit) 6 Information Technology Infrastructure Library 7 ITIL steht für Information Technology Infrastructure Library, ein Best Practice Konzept für die Definition und den Betrieb von IT-Prozessen, und beinhaltet eine umfassende und öffentlich verfügbare fachliche Dokumentation zur Planung, Erbringung und Unterstützung von IT-Serviceleistungen. 8 ein Arbeitsfluss (englisch: Workflow) ist eine inhaltlich abgeschlossene, zeitlich und sachlogisch zusammenhängende Folge von Funktionen, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig sind und deren Funktionsübergänge von einem Informationssystem gesteuert werden [18].

28 Warum testen wir Software? 19 Der Releaseprozess ist der am häufigsten genutzte Prozess im IT-Governance [46], ca. 80% der IT- Entwicklung werden über Releases abgedeckt. Eine Releasestrategie wird meistens vom IT- Management festgelegt und hängt jeweils von Softwareprodukt ab. Folgende Abbildung zeigt vereinfacht, wie IT-Governance das Zusammenspiel zwischen Entwicklung, Projektmanagement und Qualitätssicherung regelt. Abbildung 2.9 Release Prozess aus [40] (angepasst durch den Autor dieser Masterarbeit) Die Quality-Gates bilden eine Art Tor, das nur betreten werden darf, wenn gewisse Qualitätssicherungsmaßnahme erfolgt sind. Die Quality Gates 1 und 2 bestehen aus reinem Review von Dokumenten wie bspw. die funktionale und technische Spezifikation (folgend nur noch mit FS für Funktionale Spezifikation und TS für Technische Spezifikation abgekürzt). Dabei kommt es darauf an, dass ein Tester aus der funktionalen Spezifikation Testfälle ableitet. Auch die Dokumente auf Konsistenz und Widerspruchsfreiheit zu prüfen gehört in dieser Phase der Prüfung dazu. Dieser Vorgang wird statisches Testen genannt. Neben dem statischen Test existiert noch ein dynamischer Test. Abbildung 2.10 Teststufen nach IT-Governance Die FS wird anhand einer Checkliste geprüft, die Checkliste beinhaltet Qualitätsmerkmale, die an ein FS Dokument gestellt werden (siehe Anhang Checkliste zu Prüfung von FS). Wird das Dokument

29 Warum testen wir Software? 20 erfolgreich durch einen Tester auf das Quality Gate 1 geprüft, erfolgt die Prüfung auf Quality Gate 2. Die Prüfung der TS entspricht der Prüfung des Quality Gate 2. Die TS beschreibt die technische Umsetzung und muss ein Konzept der Realisierung beinhalten. Mit Quality Gate 3 erfolgt das dynamische Testen. Innerhalb des Quality Gates 3 wird geprüft, ob die Implementierungen der Softwarekomponente (die entwickelt werden soll) abgeschlossen sind. Der Fokus liegt hier auf der entwickelten Komponente. Die Entwicklung muss nachweisen, dass ein Komponententest erfolgt ist. Abbildung 2.11 IT-Governance Prozessablauf Quality Gate 4 beinhaltet das Testen der Anforderungen applikationsübergreifend. Es findet in diesem Quality Gate der Integrationstest statt. Die Tester sind hier in der Verantwortung, den Test erfolgreich auszuführen um dem Kunden die entwickelten Komponenten zur Kundenabnahme zu übergeben. Quality Gate 5 beschäftigt sich mit dem Kundentest (User Acceptance Test = UAT). Neben dem UAT findet gleichzeitig auch ein risikobasierter Regressionstest statt. Das spezielle an beiden Quality Gates (4,5) ist, dass hier fachliche Tests im Vordergrund stehen, und hier geschäftsprozessorientiert getestet wird. Gängige Testmanagement Tools wie das HP Quality Center, bieten eine Schnittstelle zum IT Governance, so kann jeder Test im Quality Center einer Anforderung im IT Governance zugeordnet werden. Das Quality Gate 3 ist das wichtigste Quality Gate im IT-Governance Prozess, und dient gleichzeitig als Abnahme der Entwicklung durch eine IT Qualitätssicherungsorganisation.

30 Warum testen wir Software? Die Notwendigkeit von Tests trotz kürzeren Produktzyklen Dass die Qualität eines Produktes durch Softwaretests sichergestellt wird, hat sich inzwischen durchgesetzt. Genauso ist bekannt, dass Tests wegen der aufzunehmenden Mühe und Zeit ein unbeliebter Arbeitsschritt ist. Es bleibt aber auch unerreichbar, dass ein Testwerkzeug per Knopfdruck die Korrektheit eines Programms überprüft. Das Ergebnis und die Qualität der Testfälle sind weiterhin vom Tester abhängig, und müssen äußerster Sorgfalt durchgeführt beschrieben und ausgeführt werden. Die Arbeit des Testers kann mit Hilfe der Testautomatisierung unterstützt werden. Die Notwendigkeit von Tests ist unter Softwareentwicklern und Projektmanagern im Allgemeinen akzeptiert, da Fehler ein einkalkulierter Faktor bei Softwareentwicklungsprojekten sind, und Testen die bisher bevorzugte Methode ist, um Fehler zu finden und zu beheben. Dennoch ist die Frage berechtigt, warum Fehler überhaupt entstehen. Häufig entstehen Fehler schon bei der Formulierung der umzusetzenden Anforderung. Deshalb existieren heute viele Requirements Tools, mit denen es möglich ist, eine Anforderung zusätzlich mit UML Diagrammen zu erweitern. Mit kürzeren Produktzyklen am Markt und steigender Komplexität der Softwaresysteme ist der Testbedarf kontinuierlich angewachsen. Neue gesetzliche Anforderungen [47] verlangen zwingend umfassende Tests vor jeder Inbetriebnahme bestehender und neuer Software. Durch IT Governance existiert ein Instrument um den Entwicklungsprozess viel früher und enger zu kontrollieren. Mit Quality Gates wird ein Mechanismus installiert, der Qualitätssicherung schon in einer sehr frühren Entwicklungsphase einfordert. Die kürzeren Produktzyklen fördern aber auch den Zeitdruck auf Entwickler und Tester gleichzeitig. Um den Zeitdruck vor allem in der Testphase zu entgegen, gehen viele Unternehmen den Weg der Testautomation. Testautomatisierung ist ein Wunschtraum eines jeden Programmierers, der sich bereits mit Entwicklung, Durchführung und Auswertung von Tests beschäftigen musste. Durch die Testautomatisierung soll in erster Linie nicht die Qualität der Software, sondern die Effizienz der Testdurchführung erhöht werden. Das Automatisieren des Testens von Software kann den Aufwand, der für adäquates Testen erforderlich ist, erheblich reduzieren.

31 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 22 3 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren Dieses Kapitel soll im ersten Teil einen Überblick über das Thema Testautomation geben. Im zweiten Teil wird das Testautomationswerkzeug vorgestellt, mit dem im Rahmen dieser Masterarbeit die technische Lösung umgesetzt werden soll. Das Testen einer Software zählt mit zu den aufwendigsten Tätigkeiten in der Softwareentwicklung. Die Kosten dafür werden nach Thaller [7] auf 30% bis 50% der gesamten Projektkosten geschätzt. Die Praxis und die Erfahrungen vor allem in großen Softwareprojekten bestätigen diese Schätzung. Die Schätzung basiert auf der Annahme, dass in jedem Softwareprojekt es Testphasen wie Modultest, Integrationstest und Abnahmetest (User Acceptance Test) gibt. Zusätzlich kommen in meist allen Fällen, Regressionstests hinzu. Eine Testautomation muss die immer wiederkehrenden Regressionstests unterstützen. Das Automatisieren des Testens von Software muss den Aufwand, der für adäquates Testen erforderlich ist, erheblich reduzieren, und dabei gleichzeitig den Testabdeckungsgrad signifikant erhöhen. Die Praxis zeigt, dass ein Testautomationsframework für viele Unternehmen eine enorme Investition darstellt, die zunächst Kosten erzeugt [29]. Diese können sich aber über den Lebenszyklus einer Software amortisieren. Die Betonung liegt auf können, denn die Praxis zeigt auch, dass viele Testautomationsframeworks schon von vornherein zum Scheitern verurteilt sind. Es gibt viele Mythen [41] über die Wirksamkeit der Testautomatisierung, die insbesondere bei den aktuell verwendeten Testwerkzeugen oft Fehlannahmen sind. Der erste Teil dieses Kapitels gibt einen Einblick in die Welt der Testautomation, zeigt die Vorteile, allerdings auch die Gefahren, die mit Testautomation verbunden sind. 3.1 Was ist Testautomation? Es gibt unter Experten unterschiedliche Ansichten und Erwartungshaltungen, was Testautomatisierung bedeutet und was für Auswirkungen sie hat. Einige Experten wie Menzel in [25] reduzieren deren Nutzen auf die Vereinfachung von Regressionstests. Dies ist eine zu starke Einschränkung der Möglichkeiten der Testautomatisierung, denn sie betrachtet lediglich die Testdurchführung und Auswertung als Gegenstand der Automation. Bei der automatisierten Testmethode werden Tests nach einem vorgegebenen Testplan über systemgesteuerte Regeln ausgeführt [26]. Eine Definition des Begriffs Testautomation bietet [48]: Testautomatisierung ist die Verwendung eines Testwerkzeuges (oder Testtools) mit dem Ziel das Testen zu unterstützen. Dabei ist ein Testwerkzeug ein Hilfsmittel, das eine oder mehrere Testaktivitäten unterstützt. Zerlegt man die Gesamtaufgabe des Testens in seine Teilaufgaben, so ergeben sich viele Möglichkeiten zur Automatisierung und Vereinfachung dieser Teilaufgaben durch Testwerkzeugunterstützung: Testmanagement (Ressourcenplanung, Teamauswahl, Testwerkzeugauswahl)

32 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 23 Testplanerstellung (Festlegung eines Zeitplans, von Teststrategien und Testkriterien) Testdesign (Erstellung von Testszenarien und Testfällen) Testdurchführung (klassische Testautomation) Testauswertung Besonders lohnenswert ist eine Automatisierung bei sich wiederholenden Aufgaben, zu denen besonders die Testdurchführung im Regressionstest und die anschließende Auswertung zählen. Unter Auswertung soll im Kontext von Testautomation folgendes verstanden werden: Der Vergleich zwischen Soll- und Ist-Werten in einem Testschritt, sprich der Vergleich zwischen dem tatsächlichen und dem erwarteten Ergebnis. Aber auch die Testfallerstellung und die Testdatengenerierung aus Anforderungen ist ein sich wiederholender Prozess. Weil vor allem bei der Testfallerstellung sorgfältig gearbeitet werden muss, sollte hier über einen Automatismus nachgedacht werden diese kann dazu dienen, eine Basis für das Automatisieren von Testfälle zu bilden. Werkzeuge, die es ermöglichen, auf Ebene von Anforderungen Testfälle abzuleiten, bspw. aus einem Testmodell, existieren mittlerweile ausreichend in der Domäne der eingebetteten Systeme. Testautomatisierung führt nicht dazu, dass automatisch mehr Fehler entdeckt werden [26], da die Testfälle weiterhin von Testern manuell erstellt werden. Die Testfälle der Testautomatisierung sind also lediglich so gut, wie von den Testern entwickelt. Allerdings ist mit Testautomatisierung die Chance und die Wahrscheinlichkeit, Fehler zu entdecken, höher als bei der Verwendung manueller Tests, weil mit Hilfe der Testautomation mehr Testfälle in einem kurzem Testzeitraum ausgeführt werden können. Somit können mehrere Funktionen einer Software getestet werden können, im Gegensatz zum manuellen Testen, wo evtl. nur eine kleine Auswahl an Funktionen aus Zeitgründen getestet werden können. 3.2 Erwartungen an die Testautomation Die Testautomatisierung wurde bereits Ende der 90er Jahren als Heil bringende Lösung immer wieder groß angekündigt und mit vielen Vorschusslorbeeren bedacht. Sie sollte zur Abdeckung des stets zunehmenden Testaufwands genutzt werden. Und glaubt man den Werbebroschüren vieler Hersteller diverser Testautomationswerkzeuge, reicht es aus, einen Testfall aufzuzeichnen, um ihn später auf gleiche Weise abzuspielen. Allerdings reicht ein Blick in die Praxis um festzustellen, dass dieses nicht ausreichend ist. Viele Testdaten, die während eines Test erzeugt werden, können bspw. nur einmal verwendet werden, oder Programmteile reagieren zu verschiedenen Zeiten unterschiedlich und von den Business Experten 9 im Unternehmen werden die Prozesse in Teilbereichen geändert, so dass die entwickelten Testskripte immer wieder angepasst werden müssten. Heute zeigen sich viele 9 Business Experten sind Mitarbeiter einer Fachabteilung die bestens über ihre Geschäftsprozesse Bescheid wissen

33 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 24 Unternehmen, die selbst Versuche zur Implementierung automatisierter Tests unternommen haben, ernüchtert [29], [30]. Die hohen Erwartungen werden vielfach nicht erfüllt. Der Aufwand für die Wartung und Pflege der automatisierten Tests wird zu Beginn meist signifikant unterschätzt. Trotz dieser Risiken haben viele Unternehmen sehr viel Geld in die Hand genommen, um genau diesem Problematiken aus dem Weg zu gehen und um neue Strategien in der Testautomation zu entwickeln, die den Wartungsaufwand auf ein Minimum reduzieren. Eine Strategie, um Geschäftsprozesse zu automatisieren, hat der Autor dieser Arbeit in [29] ausführlich beschrieben. Folgende Aufstellung gibt einen groben Überblick, mit welchen Erwartungen heute Auftraggeber, aber auch zum Teil Beratungsfirmen an das Thema Testautomation herangehen. Verringerte Durchlaufzeiten: Viele Rechner erledigen gleichzeitig und in maximaler Geschwindigkeit die Testarbeit im 24-Stunden-Betrieb. Erhöhte Testabdeckung und verbesserte Qualität: Die höhere Testleistung pro Zeiteinheit erlaubt, auch in kurzen Intervallen große Testfallbestände auszuführen. Die umfassenden und detaillierten Fehlerreporte führen mittel- und langfristig zu verbesserter Softwarequalität. Signifikante Kostenreduktion im Test: Die bisher manuell erledigte Testarbeit wird von Maschinen übernommen. Es ergibt sich eine deutliche Reduktion der Kosten. Vollinhaltliche Nachvollziehbarkeit der Tests: Automatisierte Tests müssen genau definiert werden und zeichnen sich durch stets gleiche Qualität in der Durchführung und Dokumentation der Tests aus. Dadurch werden formale Anforderungen an den Softwaretest erfüllt. Einfache Erstellung automatisierter Testfälle: mit Hilfe von Capture-Replay Werkzeugen können Testwerkzeuge die Tastendrücke, die während des Testens ausgeführt werden aufzeichnen. Analog dazu werden die passenden Bildschirmausgaben zu den Eingaben abgespeichert. Bei einem Replay vergleicht das Testwerkzeug dann die Eingaben mit dem im Tool abgespeicherten Ausgaben. Die Praxis zeigt allerdings: Kaum Kostenreduktion: Der Initialaufwand ist enorm, um einen Testfall so zu beschreiben, dass dieser sich zu Automatisierung eignet. Dieser Testfall muss dann einen hochqualifizierten Tester mit Programmiererfahrung zur Entwicklung übergeben werden. Weiterhin müssen die erstellten Testautomatisierungsskripte ständig gewartet und angepasst werden. Durch den zunächst gestiegenen Arbeitsaufwand zur Erstellung der Tests ist ein höherer Personalaufwand deshalb wahrscheinlich (siehe Abschnitt 3.2.2).

34 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 25 Entstehung komplexer Testframeworks: Um die Testskripte lauffähig halten zu können, sind Erweiterungen der Testsystemlandschaft vonnöten. Grund dafür ist, dass für die Entwicklung solcher Testskripte eine eigene Testumgebung benötigt wird, vor allem, wenn auf einem Testsystem nicht nur Entwickler und Tester arbeiten, sondern auch der Kunde direkt angebunden ist. Wie die Anwendung selbst verlangen auch die Testfälle Wartung und Pflege, was leider oft unterschätzt wird. Cem Kaner [30] weist bereits 1998 darauf hin, dass Testautomatisierung über Capture-Replay nicht funktioniert und präsentiert Überlegungen zum Aufbau geeigneter Frameworks, um das Wartungsproblem zu entschärfen. Mark Fewster [31] und viele andere wie [32], [33] unterstützen und präzisierten in den darauf folgenden Jahren die Ideen von Cem Kaner. Alle weisen darauf hin, dass die Testautomation nicht unter dem Begriff Softwaretest einzuordnen ist, sondern es sich um ein eigenständiges Softwareentwicklungsprojekt handelt, (siehe Abschnitt 3.2.2). Es besteht kein Zweifel daran, dass eine Testautomation einen Mehrwert bietet, wenn die oben kritisch angeführten Faktoren berücksichtigt werden. Auch spielt ein Fachbereich eine zentrale Rolle, Prozessänderungen an einem Softwaresystem müssen frühzeitig den Testexperten angekündigt werden, damit diese die entwickelten Testskripte frühzeitig anpassen können Vorteile der Testautomation Die Notwendigkeit von Testautomation lässt sich an einem einfachen Beispiel veranschaulichen, das in der Praxis oft vorkommt. Testobjekt ist eine Applikation mit einem Login. Dabei soll getestet werden, ob ein erfolgreiches Login möglich ist und der Tester auf die Website kommt. Die Testbeschreibung lässt sich so formulieren: Schritt 1. URL für die Login Page eingeben Schritt 2. Prüfen, ob man sich auch auf der richtigen Login Page befindet. Schritt 3. Username Fritz eingeben Schritt 4. Passwort eingeben Schritt 5. Button Login klicken Schritt 6. Prüfen, ob man sich auch auf der richtigen After Login Page befindet. Überlegen wir uns folgende Situation: Was geschieht, wenn ich direkt auf die Page springe, ohne Login? Wir müssen prüfen, dass keine Page angezeigt wird ohne korrektes Login und wir müssen prüfen, dass nach einem korrekten Login die richtige Page angezeigt wird Bei einem falschen Login müssen wir auf der Login Page bleiben.

35 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 26 Nun stellt man sich vor, ein Tester muss diese Fälle alle immer und immer wieder von Hand ausführen! Er wird schnell gelangweilt und unaufmerksam werden. Nicht zu vergessen, dass er noch für jeden Test die Session zurücksetzen muss. Das bedeutet eine Menge Arbeit und enormen Zeitaufwand. Wird er wirklich alle Fälle immer wieder testen? Manuelles Testen verleitet dazu, sich in falscher Sicherheit zu wiegen, weil es mühselig und aufwändig ist. Es erzeugt beim Tester den Eindruck, viel geleistet zu haben, daraus schlussfolgert ein Tester, dass er viel und erfolgreich getestet hat. Ein zentraler Vorteil der Testautomatisierung ist die Möglichkeit, selbst bei kleinsten Änderungen an der Software vollständige Testläufe mit minimalem Aufwand durchzuführen. Diese Tests können auch ohne Überwachung ausgeführt werden, bspw. über Nacht. Weiterhin sind die Testdurchläufe jederzeit reproduzierbar und können exakt mit denselben Eingaben in genau derselben Reihenfolge nochmals ausgeführt werden. Dadurch kann insgesamt besseres Testen mit weniger Aufwand erreicht werden, bei gleichzeitiger Steigerung des Testabdeckungsgrads. Ein gut ausgearbeiteter Testfall, der in der Lage ist, einen Fehler zu finden, findet diesen meist im ersten Durchlauf. Diesen noch einmal erneut auszuführen ist eigentlich sinnlos, da es relativ unwahrscheinlich ist, dass dieser dann noch weitere Fehler findet. Aber der Nutzen, den Testfall trotzdem zu automatisieren, liegt darin, dass er anschließend nach jeder Änderung am Programm oder an der Umgebung erneut ausgeführt werden kann. Der eigentliche Wert ist die Bestätigung dafür, dass sich die Software nach kleinen Anpassungen noch immer so verhält wie gewünscht. Regressionstests können beliebig oft auf einem System ausgeführt werden, bspw. auch bei kleineren Anpassungen, Änderungen an Programmen sichern diese Tests ab, dass durch die Veränderungen das System weiterhin auch noch funktioniert, wie es funktionieren soll. Tatsächlich liegt der Fokus der Testautomation auf Regressionstests und bringt hier den größten Nutzen in großen Softwaresystemen. Solche Tests führen zur Entlastung von routinemäßigen Testaktivitäten und führen gleichzeitig zu höherer Zufriedenheit und Produktivität bei den Testern. Die automatisierte Testfallerstellung ist Gegenstand des modellbasierten Testens und nicht Thema in dieser Masterarbeit. Allerdings können mit der Testautomation automatisierte Testdaten für den Regressionstest generiert werden. Abschließend ist noch zu erwähnen, dass die Testautomation zu einem gesteigerten Vertrauen führt. Zu wissen, dass eine große Anzahl automatisierter Tests erfolgreich durchgeführt wurde, erhöht das Vertrauen, dass keine unangenehmen Überraschungen auftreten, wenn die Software freigegeben wird Zwei Fehlannahmen der Testautomation Die sofortige Kostenreduktion durch effektivere Tests bei der Automatisierung ist eine Fehlannahme. Im Gegenteil, die Erstellung allgemeiner Tests, die sich für die Automatisierung eignen, ist sogar kostenintensiver. Geht man von Testfällen auf GUI-Ebene aus, so rechnet man mit einem 3-10mal so

36 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 27 hohem Aufwand zur Erstellung der Tests, sind spezielle GUI-Elemente involviert, so kann dieser Faktor sogar um ein Vielfaches steigen, vgl. dazu auch [9] und [10]. Die Rentabilität der Testautomatisierung ist bei heutigen Testmethoden abhängig von ihrer Flexibilität, Wartbarkeit und der Lebensdauer des zu testenden Produkts. So entstehen bei der Erstellung der Tests zunächst deutlich höhere Kosten, doch in der Weiterentwicklung des Produkts rentiert sich der zunächst höhere Aufwand durch die Wiederverwendung und die effektivere Durchführung der bereits erstellten Testfälle. Folgende Abbildung macht diesen Kostenverlauf im Vergleich zu manuellen Tests auf Basis des Lebenszyklus einer Software deutlich. Die Abbildung ist auf Basis von Testwerkzeugen der HP Produktpalette entstanden. Abbildung 3.1 Return on Investment (ROI) Testautomation [35] Aus der Abbildung 3.1 lässt sich leicht ablesen, dass die Testautomation sich erst bei mehreren Durchläufen rentiert. Dabei verteilen sich die Kosten auf folgende Faktoren: Kosten der Integration von Testautomation in ein Projekt Testfallbeschreibung- und durchführung sowie Programmierung der Skripte Kosten zur Wartung der Testfälle Die Kosten entstanden aus einer Untersuchung von acht Produkten die mit HP Quicktest Professional eine Testautomation realisiert haben. Diese acht Produkte teilen sich auf in 20 Testautomationsprojekte. Daher können diese Zahlen vor allem bei der Automatisierung von Geschäftsprozessen in betrieblichen Informationssystemen als Referenz genommen werden. Der erste Kostenfaktor stellt hierbei eine Investition in die Zukunft dar, denn er ist deutlich höher als bei manuellen Tests (ca.50%). Der Kostenfaktor, Testfallbeschreibung- und durchführung sowie das Programmieren der Skripte ist der Teil, der ca. 30% des Automationsprojekts ausmacht, für die Wartung der Testskripte schätzt man ca %. Diese Schätzungen beruhen auf Erfahrungswerten

37 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 28 aus diversen großen Testautomationsprojekten 10. Es ist ein entscheidender Faktor, der in vielen Testautomationsprojekten 11 branchenübergreifend vernachlässigt und unterschätzt wird. Eine weitere Fehlannahme ist, dass ein Testautomationsprojekt in der Testphase eines Softwareprojektes durchgeführt werden muss. Der Grund hierfür ist, dass Tests, die manuell durchzuführen sind meistens nach folgendem Schema ablaufen: Von einer Anforderungsspezifikation werden Testfälle aus den funktionalen Funktionseinheiten abgeleitet. Dann werden diese Tests in einem Testmanagement Tool in Form eines Testfalls beschrieben. Anschließend werden sie dann manuell ausgeführt Dieser Testfall wird jetzt, nachdem er mindestens einmal ausgeführt wurde, zum Regressionstestfall. Nachdem der Test jetzt als Regressionstest markiert worden ist, kann dieser nach Abstimmung mit Entwicklung und Fachbereich ausgewählt und automatisiert werden. In der Testphase eines Softwareprojekts stehen Tester unter einem enormen Zeitdruck, in so einer Phase können keine Tests programmiert und ausgeführt werden, sondern die zuvor schon entwickelten Tests könnten hier jetzt nur noch als Unterstützung der Tests ausgeführt werden. Deswegen sollten Testautomationsprojekte als eigenständige Softwareentwicklungsprojekte angesehen werden, die durch einem Projektleiter geplant, budgetiert und durchgeführt werden. Softwareprojekt darum, weil auch die entwickelten Programme, einem Lebenszyklus unterworfen sind, diese müssen gewartet und ggf. auch angepasst werden. Und wenn neue Anforderungen an das zu testende System gestellt werden, so müssten auch die Testskripte erweitert werden usw. Ansonsten würden diese schon nach wenigen Releases nicht mehr funktionieren Testautomation und was noch zu beachten ist Es gibt aber auch eine Reihe von Problemen in Verbindung mit Testautomation. Es beginnt bei der Auswahl des richtigen Tools. Eine Analyse der zu automatisierenden Applikation kann diesem Problem entgegentreten. In einer solchen Analyse wird geschaut, zu welcher Applikation Testfälle zu automatisieren sind. Anhand der Applikation kann dann eine Toolauswahl erfolgen. Mit manchen Tools lassen sich bspw. Webapplikationen sehr einfach automatisieren, Quicktest Professional hat hier massive Probleme bei der Erkennung von Weboberflächen. Mit einer Analyse bekommt man diese Informationen im Vorfeld und kann auf eine Alternativlösung ausweichen [49]. Eine gesunde Mischung 10 Automationsprojekt im SAP Umfeld Personalabrechung, Automationsprojekt Materialwirtschaft, alle diese Projekte hatten eine Laufzeit von mehr als 6 Monate. 11 [29] Christian Stenhorst und der Autor dieser Masterarbeit illustrieren in diesem Fachartikel die Gefahren und die Risiken von großen Testautomationsprojekten

38 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 29 zu finden, sprich ein Tool womit Webapplikationen genauso automatisiert werden können wie SAP mit ganz individueller GUI Elemente, gestaltet sich schwierig [49]. Ein weiteres nicht zu unterschätzendes Problem ist die schlechte Testkultur in vielen IT-Unternehmen. Es ist grundsätzlich sinnvoller, zunächst eine gute Testkultur zu etablieren. Wenn in einem Unternehmen manuelle Tests nur sporadisch durchgeführt werden und es keine festgelegte Teststrategie und etablierte Testverfahren gibt, dann macht es wenig Sinn, eine Automatisierung einzuführen. Die Verwendung von Testwerkzeugen erfordert einen strukturierten Testprozess, den bspw. das IT Governance einer Organisation bietet. Unternehmen, welche diese Kriterien nicht erfüllen, riskieren, evtl. ihre Marktsituation zu verschlechtern, indem sie teuer Werkzeuge einkaufen und dann nicht einsetzen. Die Erwartungshaltung, dass mit neuen Methoden und neuen Werkzeugen die Lösung aller Probleme einfach zu erreichen ist, ist meistens ein Irrglaube. Einen zentralen Fehler allerdings begehen fast alle Unternehmen, die Testautomation einsetzen: Wenn etwas an der zu testenden Software geändert wird, ist es meist notwendig, einen oder mehrere, vielleicht sogar alle Testfälle anzupassen, damit diese wieder erfolgreich durchgeführt werden können. Wenn es aufwendiger ist, die automatisierten Tests zu aktualisieren, als den Test einmalig manuell durchzuführen, so führt das in vielen Fällen dazu, dass wieder zur manuellen Durchführung zurückgekehrt wird und die automatisierte Testsuite nicht weiter gepflegt wird. Auch die Testautomatisierungswerkzeuge selbst sind nicht frei von Fehlern, diese sind meist keine Eigenentwicklungen, sondern zugekaufte Produkte. Diese können wie jedes andere Softwareprodukt nicht ausreichend getestet und fehlerhaft sein. Umso frustrierender ist es, herauszufinden, dass das Problem kein Problem der zu testenden Software ist, sondern ein Fehler in der Software, die zum Testen verwendet wird. Als letztes seien die allgemeinen organisatorischen Probleme erwähnt, die es natürlich immer gibt. Es bedarf hierbei der Unterstützung durch die Softwareentwicklungsabteilung. Ebenso wie eine sinnvolle Testkultur generell muss auch die Testautomatisierung im Unternehmen bzw. der Abteilung vernünftig eingebunden werden. 3.3 Testwerkzeuge Ein Testwerkzeug ist ein automatisiertes Hilfsmittel, das bei einer oder mehreren Testaktivitäten, beispielsweise Planung und Verwaltung, Spezifikation, Aufbau von Ausgangsdateien, Testdurchführung und Beurteilung, Unterstützung leistet [26]. Der Prozess der Selektion selbst ist eine sehr zeitaufwendige Arbeit. Kriterien für die Werkzeugauswahl müssen sorgfältig auf die Testanforderungen abgestimmt werden. Jedes Werkzeug muss gegen diese Kriterien getestet werden. In diesem Abschnitt werden allgemeine Merkmale der

39 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 30 Tools vorgestellt. Für das in dieser Arbeit zu behandelnde Automatisierungsproblem können die folgenden allgemeinen Anforderungen an das Testwerkzeug gestellt werden: Plattformunterstützung Die Durchführung von Oberflächentests wird allgemein durch Tools, die der Automatisierung von GUI Elementen zuzuordnen sind, durchgeführt. Viele GUI-Testtools sind für bestimmte Plattformen ausgerichtet. Sollen bspw. Oberflächen von Windows-Anwendungen getestet werden, so muss das Tool unter Windows lauffähig sein, da dadurch doppelter Aufwand für die Einarbeitung in das Tool und für die Testerstellung vermieden wird. Wenn Software für mehrere Plattformen verfügbar sein soll, dann ist es vorteilhaft ein Testtool auszuwählen, dass auf all diesen Plattformen ausgeführt werden kann Unterstützung der zu automatisierenden GUI-Elementen Neben der geeigneten Plattform ist der Einsatz des Testtools auch abhängig von der Schnittstellen- Technologie, mit der die Oberfläche der zu testenden Anwendung dargestellt wird. Das ist wichtig, da das Testautomationstool genau über die Benutzeroberfläche Elemente einer Software identifizieren muss. SAP bietet speziell für QTP einige Schnittstellenelement die das Identifizieren von Elementen vereinfachen, bspw. bei der Erkennung von Microsofts Windows Forms, SAP Elemente Java/Swing, und Java/SWT wobei SAP heute auch eine Repertoire an Daten liefert, damit die Testautomaten ihre Elemente anhand von Schlüsselwörtern eindeutig identifizieren können. Die grafischen Oberflächen von Webseiten werden über HTML-Quelltext beschrieben und mit Hilfe eines Browsers dargestellt. Jede dieser Schnittstellen hat eigene grafische Bedienelemente und Mechanismen zur Behandlung von Ereignissen, die vom jeweiligen Testtool unterstützt werden müssen. Dazu gehören einfache ereignisse (Low-Level-Events), wie Mausklicks oder Tastatureingaben, die von jeder GUI-Technologie unterstützt werden müssen Testausführung Bei der Testausführung wird die GUI-Oberfläche durch Auslösen der grafischen Elemente im GUI gesteuert. Diese Steuerung kann auf zwei Wegen erfolgen: Positionsorientierung und Objektorientierung. Bei der positionsorientierten Testausführung simuliert das Testtool Tastatureingaben, Mausbewegungen und Mausklicks so, als würde ein Benutzer die Oberfläche bedienen. Zur Positionierung der Maus werden im Test (x, y)-koordinaten verwendet, die wie die Klicks und Tastatureingaben an das SAP gesendet werden. Dort werden die Ereignisse dann an die zu testende Anwendung oder den Browser weitergeleitet und das grafische Element ermittelt, das auf der Mauskoordinate liegt. Ausgehend von diesem Element werden dann die dahinterliegenden Funktionen ausgeführt. Ein großer Nachteil dieses Modus ist, dass er nicht sehr robust gegenüber Veränderungen auf der Benutzeroberfläche ist. Bei der objektorientierten Ausführung wird von der Position des Mauszeigers auf unterster Ebene abstrahiert. Stattdessen werden Oberflächenelemente mittels eines Plug-Ins ( ObjectSpy ) identifiziert

40 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 31 und Referenzen werden nach der Identifizierung auf die Objekte gelegt. Dadurch werden die automatisierten Testabläufe gegenüber Änderungen am Layout robuster, da die Größe und die Position der Elemente innerhalb eines Fensters nicht wichtig sind. Die Oberfläche die getestet werden soll, muss immer überprüft werden, ob sie die zu testende Oberfläche aktiv ist, nur dann wird der Testfall auf diese Oberfläche ausgeführt. Alles das wird getestet, was im GUI identifiziert werden kann. Die Objekte erhalten eine eindeutige Nummerierung und können wiederverwendet werden. Das entwickelten der Testskripte erfolgt durch Programmierung. Allerdings können Capture&Replay Mechanismen von Testautomationstool genutzt werden, um Elemente zu identifizieren um diese dann mit Hilfe der Programmierung zu spezifizieren Testskripterstellung Mit der Programmierung ist die manuelle Überführung von Testfallbeschreibungen in Testskripte gemeint. Die Ausführung der Testskripte erfolgt im Rahmen eines Testmanagementtools was wiederum einem Framework unterstellt ist. Die manuelle Programmierung der Testskripte ist mit sehr viel Aufwand verbunden. Die Kontrolle sowie die Struktur können bspw. durch Capture & Replay Vorgeleistet werden. Allerdings stellt sich die Frage, wie die zu testenden Oberflächenelemente mit der Skriptsprache angesprochen werden können, so dass neben der Programmierung auch Verweise auf die Elemente erstellt werden müssen. Testtools bieten auch hierfür eine technische Lösung. Der Capture-Replay-Ansatz ist die häufig genutzte Methodik, um Testskripte zu entwickeln. Dabei werden die Benutzerinteraktionen bei einer Testdurchführung mit dem laufenden System in Form von Mausklicks, Mausbewegungen und Tastatureingaben objekt- oder positionsorientiert im Hintergrund aufgenommen und das Testskript um diese Aktionen ergänzt (Capture). Während der Aufzeichnung können Soll-Ist-Vergleiche in Form von Prüfpunkten (Checkpoints) in das Skript eingefügt werden, um das Programmverhalten sowie layoutrelevante Eigenschaften der Oberflächenelemente zu überprüfen [10]. Das fertige Skript kann dann in Form von automatisierten Testdurchführungen beliebig oft abgespielt werden (Replay). In der Praxis kommt meistens eine Mischung aus beiden Ansätzen zum Einsatz. Die Grundstruktur kann mit Capture & Replay erstellt werden, die Logik des Testfalls muss aber explizit ausprogrammiert werden. Neben den Ansätzen Programmierung und Capture-Replay, bei denen eine Person maßgeblich an der Erstellung der Testskripte beteiligt ist, gibt es weitere Methoden, bei denen neben der automatisierten Testdurchführung auch Testskripte automatisch generiert werden, so dass zufällige lauffähige Skripte in kurzer Zeit und ohne viel Aufwand erzeugt werden können HP Quicktest Professional (QTP) Für das Testen von SAP GUI Backendsystemen ist eine Objekterkennung zwingend notwendig. Hierbei reicht es nicht aus, über eine Bilderkennung wie beim Produkt der IBM Rational SQA [51] zu verfügen, sondern dass Objekt muss über Variablen und mittels Methoden ansprechbar und manipulierbar sein. Das ist eines der größten Stärken vom QTP. QTP ist ein Tool zur Automatisierung von GUI-Tests unter Windows. Die internen Repräsentationen von Windows-Steuerelementen können erkannt und

41 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 32 verwendet werden. Durch Plug-Ins ist es unter anderem auf SAP- und Javaanwendungen erweiterbar. Das Aufzeichnen der Testabläufe kann im ersten Schritt mittels Capture-Replay realisiert werden, um dann mittels Programmierung von Funktionsbausteinen und Parametrisierung wiederverwendbare SAP Komponenten zu entwickeln. QTP ist eine Softwarelösung von HP und deswegen bietet HP Quality Center eine Schnittstelle um QTP zu integrieren. Entscheidender Vorteil von QTP ist tatsächlich die Objekterkennung von SAP Elementen. Speziell für diese Masterarbeit und die Fokussierung auf SAP Testing ist das ein Vorteil, die Testskripte mit QTP zu entwickeln. Ein weiterer Vorteil ist die Integration in das Quality Center, die problemlos erfolgt. QTP kann beim Start bereits eine Verbindung mit dem Quality Center aufbauen und ist somit auch direkt aus Quality Center startbar. SAP bietet auch einen Testautomaten an, ECATT 12, dieser lässt sich auch mit QTP leicht kombinieren. ECATT wird im Rahmen dieser Masterarbeit vernachlässigt. Testfälle können somit einfach über das HP Quality Center abgelegt, verwaltet und ausgeführt werden. QTP transferiert alle Testergebnisse ins HP Quality Center zurück. Einen weiteren Vorteil bietet der ObjectSpy an, mit dem alle SAP Objekte eindeutig identifizieren werden können. Es können damit auch die Eigenschaften und die Hierarchiestruktur eines ausgewählten Objekts ausgelesen oder auch manipuliert werden, beide Eigenschaften sind für eine stabile Testautomation enorm wichtig. Somit kann mit QTP sowohl programmiert werden, als auch ein Capture & Replay Ansatz dafür Sorge tragen die Struktur eines Testskripts anzulegen. 3.4 HP Quality Center als Testmanagementtool - Skripterstellung unter QTP Das HP Quality Center (HPQC) ist ein zentrales Qualitätsmanagement-Tool, mit dem die Aktivitäten im Testprozess abgebildet und alle für den Test relevanten Daten verwaltet werden können. Alle diese Informationen werden in verschiedenen Modulen des HPQC erfasst. HP Quality Center Testmanagement Tool Requirements Testplan Quicktest Professional Defectmanagement Testlab Datenbank/ Quicktest Professional Repository Abbildung 3.2 HP Quality Center Aufbau 12 extended Computer Aided Test Tool - ist die SAP-eigene Entwicklung eines Werkzeugs zur Testautomatisierung

42 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 33 Die Informationen werden in den Modulen Requirements (Anforderungserfassung), Testplan (Testplanung), Testlab (steht für Testlabor, und ermöglicht erst die Testausführung) und im Defectmanagement (Fehlermanagement) erfasst. Im Testplan werden Testfälle definiert und spezifiziert, im Testlab werden aus den im Testplan definierten Testfällen eine Testsuite erstellt und gegebenenfalls ausgeführt. Im Defectmanagement werden im Falle eines Fehlers während der Testausführung der Fehler dokumentiert. All diese Informationen sind miteinander verknüpft, so dass der Status eines Testprojektes jederzeit ersichtlich ist. Diese Übersicht wird durch die Möglichkeit, diverse Analysen zu erstellen, noch verbessert. Es können Berichte und Graphen erstellt werden, die über den aktuellen Status oder Verlauf eines Testprojektes visuell und auch statistisch Auskunft geben. Sie enthalten unter anderem Informationen über alle aktuell erfassten Anforderungen, den Verlauf eines Tests, die Testfallabdeckung, und die Anzahl der Fehler und diese wiederum klassifiziert nach Fehlerklassen. Alleine das Fehlermanagement beherbergt einen sehr komplexen Fehlerabarbeitungsfluss (Defectworkflow), auf dem im Rahmen dieser Masterarbeit nicht eingegangen wird, allerdings befindet sich im Anhang dieser Masterarbeit ein Beispiel für einen Defectworkflow. Das HPQC ist eine Webapplikation und somit wird nur ein Browser benötigt, um weltweit auf ein Testprojekt zugreifen zu können. Die Zugriffsrechte werden über ein Administrationsmodul verwaltet, und es können verschiedene Benutzerkonten und auch Benutzerrollen angelegt werden. Neben diesen vier Modulen gibt es noch zwei weitere, Releasemanagement- und das Business Components-Modul. Mit dem Release Modul werden Testfälle konkret einem Release zugeordnet, und beim Business Components- Modul können Testfälle generisch angelegt und dann je nach Testsituation verschieden parametrisiert werden. Diese beiden Module werden nur der Vollständigkeit halber erwähnt, und auf sie wird nicht mehr eingegangen. Die Entwicklungsumgebung zur Erstellung von automatisierten Testskripten bietet das QTP. Folgender Abschnitt zeigt kurz, wie ein Testfall angelegt und ausgeführt werden kann, bevor die Testskripterstellung vorgestellt wird Requirements Modul Das Requirements Modul dient zur Verwaltung der Anforderungen, die bspw. Bestandteil eines Releases sind. Anforderungen können sich in verschiedene funktionale und nicht funktionale Anforderungen gliedern. Diese werden als Übersicht in einer Hierarchiestruktur (Baumstruktur) ausgewiesen und organisiert.

43 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 34 Abbildung 3.3 Requirements Modul Dieses Modul ist an das im Kapitel 2.4 vorgestellte IT-Governance Tool angebunden. Durch die Anbindung können alle Anforderungen, die im IT Governance Tool dokumentiert und gepflegt werden, automatisch ins HPQC geladen werden. Hier können jetzt jeder funktionalen Spezifikation jeweils immer eine Testsuite zugeordnet werden. Eine Testsuite besteht wiederum aus einem oder mehreren Testfällen. Somit kann sichergestellt werden, dass jede Anforderung durch eine Testsuite abgedeckt ist, es besteht dadurch jetzt auch die Möglichkeit bspw. eine Auswertung über bestehende Anforderungen durchzuführen, und analog dazu, welche Testsuite diese abdecken sollen, somit hat man eine gewisse Übersicht über Testabdeckungsgrad Testplan Modul Die einzelnen Testfälle werden im Modul Testplan aufgebaut und organisiert. Hier werden alle relevanten Informationen zu einem Testfall beschrieben wie technische Voraussetzungen bis zu den für diesen Testfall benötigten Testdaten. Ein Testfall wird konkret in einzelnen Schritten erläutert (Design Steps = Testschritte). Jeder Testschritt wird beschrieben, so wie mit erwarteten Ergebnissen (Testorakel) versehen.

44 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 35 Abbildung 3.4 Modul Testplan Das Testplan-Modul dient ausschließlich dazu Testfälle anzulegen und diese in eine geordnete Ordnerstruktur zu bringen, d.h. Testfälle werden auch direkt im Testplan organisiert. Um die einmal erstellten Testfälle in einer bestimmten Reihenfolge auszuführen, wird jetzt das Testlab-Modul benötigt Testlab (Testlabor) Mit Hilfe dieses Moduls schafft das HPQC eine Trennung zwischen Testfallplanung-, Testfallerstellung und der eigentlichen Testausführung. Im Testplan konnte man sehen, wie Testfälle zu verschiedenen Releases und Produkten und Subprodukten erstellt und organisiert werden können. Der nächste Schritt ist jetzt, diese Testfälle nicht nur in einer festgelegten Reihenfolge auszuführen, sondern auch die verschiedenen Testfälle zusammen in einer Testsuite zusammenzufassen und auszuführen. Das ermöglicht im HPQC das Modul Testlab.

45 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 36 Abbildung 3.5 Testlab und Schnittstelle zu Testplan Den Testsuites (im HPQC Jargon Testsets genannt) kommt dabei eine besondere Bedeutung zu. Die Testsuiten sind sogenannte Sammelbehälter für Testfälle, die in einer bestimmten Reihenfolge ausgeführt werden müssen. In der Praxis werden die Testsuiten dazu benutzt Testfälle zusammen zufassen, die zu einem Geschäftsprozess gehören, gleichzeitig wird damit der Kontext für den Testfalls festgelegt. Im Testlabor werden keine Testdaten angelegt, diese werden schon im Testplan angelegt, d.h. die Testfälle müssen schon im Testplan parametrisiert werden. Wichtiger Vorteil des Testlabs ist, dass wenn während der Ausführung eines Testfalls festgestellt wird, dass ein Testprozess sich verändert hat, dieser dort direkt angepasst werden kann. Änderungen werden dann automatisch direkt überall gemacht wo der Testfall benutzt wird. Dadurch verringert sich der Wartungsaufwand der Testfälle enorm. Allerdings sollten einmal zusammengefasste Testsuites niemals überschrieben werden, denn: Die Revisionssicherheit muss für jedes Release garantiert werden, es muss immer nachgewiesen werden können, dass bestimmte Testfälle ausgeführt worden sind. Die Anforderungen können sich von Release zu Release ändern, und dadurch die Testfälle auch, dennoch muss man immer in der Lage sein, zu jedem Releasestand eine passende Testsuite zum Releasestandbereitzuhalten.

46 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren Fehlermanagement (Defectmanagement) Abweichungen werden im Modul Fehlermanagement (Defectmanagement) erfasst, es ist das letzte Modul, was hier betrachtet wird, allerdings auch das komplexeste von allen anderen Modulen. Folgende Abbildung zeigt, wie aus einem Testfall ein Fehler bei Feststellung einer Abweichung erfasst werden kann. Informationen die ausgeführt werden müssen Abbildung 3.6 Erfassen eines Fehlers (Abweichung) Das Modul rundet das Testmanagementtool ab, indem es eine Unterstützung bietet, Fehler zu bearbeiten und zuständigen Entwicklern zuzuordnen. Jedem der einen Zugang zum HPQC hat, wird vom Administrator eine Rolle zugeordnet, so dass bspw. ein Entwickler die Entwicklerrolle bekommt, und einen Fehler, der im HPQC erfasst worden ist, öffnen und bearbeiten kann. Er darf ihn nach

47 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 38 erfolgreicher Abarbeitung den Status behoben (Fixed) zuteilen, so dass bspw. jetzt ein Tester mit der Testerrolle den Fehler noch einmal retesten kann, und ggf. den Fehler schließen (auf Closed im Defectworkflow) setzen kann. Das kann nur derjenige, der den Fehler auch eingestellt hat. Ein Standard-Defectworkflow befindet sich im Anhang dieser Masterarbeit und wird an dieser Stelle nicht mehr vertieft. Fazit zu HPQC Das HPQC mit all seinen Modulen bietet unterschiedliche Arten von Tests. Es können sowohl Modultests (Entwicklertest) bis Kundentests (User Acceptance Test) damit entwickelt werden. Es ist ein Werkzeug was die Erstellung, Ausführung und Auswertung aller erfassten Testfälle ermöglicht. Es bietet die Möglichkeit, den Planungsvorgang von Tests aktiv zu unterstützen. In einem ersten Schritt wird eine allgemeine Strategie für die Testplanung erfasst, die im Verlauf der Zeit in immer feinere Schritte aufgeteilt wird. Dadurch erhält man am Ende der Planung eine detaillierte Testanleitung mit den erwarteten Ergebnissen, die Basis der späteren konkreten Testausführung ist. Zur Dokumentation der durchgeführten Tests müssen Testspezifikationen erstellt werden, die sowohl die durchzuführenden Aktionen als auch die erwarteten Ergebnisse beinhalten. Da das HPQC die Möglichkeit zur Erstellung von Auswertungen anbietet, kann diese Dokumentation nach Erfassung durch den Benutzer direkt aus dem Werkzeug heraus generiert werden. Eine Gliederung aller geplanten Tests nach verschiedenen Gesichtspunkten kann dafür sorgen, dass der Testprozess leichter zu überschauen und damit auch zu verwalten ist. Es ist nicht nur eine Einteilung nach Subprodukten und Teststufen möglich, sondern man kann sich im HPQC auch weitere auswertungsrelevante Faktoren anzeigen lassen, dazu bedient man sich des Test Subject Tree. In den Ästen dieses Test Subject Tree stehen einzelne konkrete Testfälle, somit kann jetzt hier eine Auswertung auf Kriterien wie z.b. welche Testfälle beziehen sich auf Bildschirmmasken und welche Testverfahren werden dabei eingesetzt, durchgeführt werden Technischer Aufbau von QTP als Add-In vom HPQC Wie schon in erläutert, ist QTP ein Testtool zur automatisierten Durchführung von Funktionsund Regressionstests. Die Skripte basieren auf der Sprache Visual Basic-Skript 13. Konzipiert wurde es für Windows und webbasierte Anwendungen. Mit einem sogenannten Add-In 14 können damit auch SAP Anwendungen getestet werden. QTP Add-ins sind Programmbibliotheken, welche die Automatisierung von spezifischen Umgebungen wie WEB, JAVA, SAP, usw. ermöglichen. Im Rahmen 13 Visual Basic ist eine zwar auf Basic beruhende, objektorientierte Programmiersprache von Microsoft, die aber inzwischen in keiner Weise mehr mit Basic vergleichbar ist. Sie bietet mächtige Werkzeuge, um mit hoher Geschwindigkeit professionelle Windowsprogramme zu erstellen. Das aktuelle Visual Basic heißt nicht Visual Basic 7.0, sondern Visual Basic.NET (VB.NET) 14 Mit Add_In bezeichnet man meist eine Sammlung von zusätzlichen Funktionen oder Optionen, die in ein Programm integriert werden. Die Programme werden dadurch in ihrem Leistungsumfang verstärkt und erhalten zusätzliche Eigenschaften

48 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 39 dieser Masterarbeit sind nur die SAP und WEB Programmbibliotheken interessant. Bevor aber gezeigt wird, wie solche Addins integriert werden können, gibt folgende Grafik einen Überblick, wie QTP zunächst in HPQC eingebettet ist. Abbildung 3.7 HPQC und QTP Verbindungsaufbau Die Verbindung zum HPQC muss einmalig erfolgen, dazu werden nur der Server benötigt, auf dem die HPQC Applikation läuft, und die Benutzerdaten, um sich auch im HPQC anzumelden. Nachdem diese beiden Daten eingepflegt worden sind, ist die Verbindung zwischen beiden Produkten hergestellt. Somit kann QTP auf Ordnerstrukturen von HPQC zugreifen und auch Testergebnisse direkt ins HPQC zurück schreiben lassen. Mit Hilfe des Addin-Managers von QTP ist es jetzt auch möglich, die beiden für diese Masterarbeit relevanten Addins (Web, SAP) zu integrieren. Weitere zentrale Elemente sind die Funktionsbibliotheken und die Testdaten, wobei die Funktionsbibliotheken wie die Addins direkt eingebunden werden. Wie das genau geschieht, sollte an dieser Stelle nicht weiterverfolgt werden, eine ausführliche Beschreibung, die gleichzeitig als Tutorial benutzt werden kann, bietet [39]. Wie ein Testskript aus dem HPQC erstellt werden kann, zeigt der nächste Abschnitt Testskripterstellung mit QTP im HPQC Das Entwickeln eines Testskriptes ist nach der Einbindung von QTP recht einfach. Beim Anlegen eines Testfalls im HPQC wird anstatt eines manuellen Testfall einfach ein automatisierter Testfall bei der Anlage ausgewählt, und somit hat man schon einmal ein Skript erstellt, im ersten Schritt noch ohne Programmlogik. Zu Demonstrationszwecken wird ein kleines Beispiel gezeigt, wie ein Testskript aussehen kann, was bspw. das Anmelden an einem SAP System durchführt. Was wird dazu benötigt?

49 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 40 Erstens werden administrative Informationen benötigt wie das SAP-System, der Mandant 15 und der dazugehörige Client mit Benutzername und Passwort. Alle diese Informationen sind sogenannte Testdaten. Man sieht schon auf den ersten Blick, dass bspw. so eine Anmeldetest bei jedem Testfall erfolgen muss, daher bietet sich an, direkt eine generische Funktion zu programmieren und diese bspw. Anmelde_Prozedur zu nennen, die die Programmierlogik der Anmeldung beinhaltet, da diese ja immer gleich ist. Dadurch wird Coderedundanz vermieden, und eine bessere Strukturierung und Wartbarkeit der Testskripte erreicht. Folgende Grafik zeigt, wie ein automatisierter Testfall im HPQC angelegt wird. Abbildung 3.8 Anlegen eines automatisierten Testfalls Dabei unterscheidet sich ein automatisierter Testfall von einem manuellen auf dem ersten Blick kaum. Im HPQC wird der Reiter Testskript aktiviert, und das ist das einzige Zeichen dafür, dass es sich hierbei nicht um einen manuellen Testfall handelt, sondern um ein Testskript. Die nächste Grafik zeigt jetzt die Entwicklungsumgebung von QTP, mehr Informationen und eine Einführung bietet [39]. Für das Beispiel, das hier gezeigt werden soll, ist nur das kleine Programmstück aus Abbildung 3.9 wichtig, dieses zeigt die Funktion für die Anmeldeprozedur. Die ausprogrammierte Funktion ist in eine 15 Der Mandant ist definiert als für sich handelsrechtlich, organisatorisch und datentechnisch abgeschlossene Einheit innerhalb eines SAP-Systems. Das bedeutet, dass alle betriebswirtschaftlichen Daten gegenüber anderen Mandanten geschützt sind. Jeder Mandant verfügt über seine eigenen Kundendaten, die er als sein exklusives Eigentum betrachten kann.

50 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 41 Bibliothek ausgelagert und kann jetzt von anderen Testskripten benutzt werden. Wie die Anmeldefunktion im Detail aussieht, wird im nächsten Schritt dann erläutert. Abbildung 3.9 Entwicklungsumgebung QTP aus HPQC starten In Zeile 4 wird die Funktion (sap_login_de) aufgerufen, und diese erledigt das Anmelden am SAP System. Nach erfolgreichem Abarbeiten der Funktion soll in Zeile 7 die Anwendung wieder geschlossen werden. Was passiert jetzt konkret in Zeile 4? Was bedeutet ( Test ) und was wird da übergeben? Und wie sind die Testdaten organisiert? Wie man sieht, werden in Zeile 4 und auch in Zeile 7 Funktionen, d.h. eine Programmlogik die in einer Funktionsbibliothek hinterlegt ist, aufgerufen. Wenn Zeile 4 jetzt näher untersucht wird, ergibt sich folgender Programmablauf:

51 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 42 Abbildung 3.10 Anmeldeprozedur und ihre Abhängigkeiten Zeile 10 zeigt den Funktionskopf, und dort wird eine Variable (psalias) übergeben, diese beinhaltet einen Testuser, der für den Test sich am System anmelden möchte. Dieser Testuser wird der Funktion als String übergeben siehe Zeile 4. In Zeile 19 wird eine Funktion aufgerufen die dazu dient, eine Exceldatei zur Laufzeit einzulesen und zu verarbeiten. In Zeile 19 wird die ( RegTestUser.xls ) eingelesen, die die Systemanwender sowie deren Benutzerdaten und Passwort beinhalten. Diese Funktion durchsucht jetzt die geladene Exceldatei nach dem übergebenen Testuser in Zeile 10 ( Test ) und sobald ein Eintrag gefunden worden ist, führt Zeile 28 dann die konkrete Anmeldung inklusive Fehlerbehandlung durch (Beispiel, was hier konkret passiert weiter unten). Wird der übergebene Testuser nicht gefunden, so springt das Programm sofort in Zeile 38 und beendet den Test mit der Meldung dass der Testuser nicht vorhanden ist. Zeile behandelt einen Anmeldeversuche mit bspw. falschen Passwort / oder auch Benutzernamen. Diese Fehlerbehandlung vereinfacht die Fehlersuche nach einem Testlauf enorm, denn in der Praxis wird nicht mit einem Testuser getestet, sondern immer mit mehreren Systemanwendern und mit deren verschiedenen

52 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 43 Rollen. Wie oben schon angemerkt folgt an dieser Stelle jetzt eine etwas detaillierte Vorstellung der Funktion aus Zeile 29 (SAPGuiUtil.AutoLogon), die dafür sorgt, dass die Anwendung, die getestet werden soll, aufgerufen wird. Abbildung 3.11 Anmelderoutine (Ablauf) Die Abbildung gibt einen guten Überblick darüber, was genau während des Testlaufs passiert. Das Testskript wird gestartet, im ersten Schritt werden Testuser und Testdaten geladen und ins zu testende System eingepflegt. Im Fehlerfall (was hier in diesem kleinen Beispiel nicht betrachtet wird) gibt es eine explizite Fehlerbehandlung sowie eine Ausgabe in einem Fehlerauswertungsbogen, der auch den Testuser aufführt, der auf ein Fehler gelaufen ist. Mit Hilfe des Testskripts kann jetzt eine Anmeldung auf verschiedenen SAP Systemen sowie auch verschiedenen Clients durchgeführt werden. Durch die Trennung von Testdaten und Testimplementierung (Testskript) können die Testdaten das Testskript steuern, das sogenannte datengetriebene Testen. Ingesamt unterscheidet Uwe Vigenschow in [10] fünf Testskriptarten, von denen nur die für diese Masterarbeit relevanten erläutert werden: Datengetriebene Skripte (Data-Driven-Skripting) Schlüsselwortgetriebene Skripte (Keyword-Driven-Skripting)

53 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren Datengetriebene- und Schlüsselwortgetriebene Testskriptarten Häufig stellen sich Fehler einer Anwendung, die sich im Test befindet (AUT 16 ), erst bei bestimmten eingegebenen Daten heraus. Deswegen besteht die Motivation, möglichst viele Eingaben zu testen. Lineare, strukturierte und modularisierte Testskriptarten bieten Techniken, diese Eingaben nur auf die jeweiligen Stellen im Skript zu verteilen, und jede Modifikation an den Eingabedaten erfordert das Auffinden der jeweiligen Stelle im Skript, und eine Veränderung des Skriptes an dieser Stelle. Bei Verwendung von datengetriebene Testskriptes müssen die Daten nicht mehr im Skript selbst erscheinen, sondern sie stehen in einer gesondert abgelegten Tabelle bspw. in einer Datenbank. Abbildung 3.10 und 3.11 illustrierten schon das Beispiel mit einer Anmeldung, hier sind die Testdaten in einer Exceldatei abgelegt und können dort modifiziert werden, ohne die Ablauflogik des Testskriptes zu beeinflussen. Vorteil hierbei ist: Testeingaben können mit minimalem Aufwand angereichert werden, wodurch die Anwendung wesentlich umfangreicher getestet wird. Damit auch die Ergebnisse sinnvoll verglichen werden können, wird eine solche Tabelle neben den Testeingaben auch entsprechende Vergleichswerte beinhalten. Die Trennung der Testdaten und der Instruktionen zum Testen mittels der datengetriebenen Testskripttechnik ermöglicht den flexiblen Umgang mit verschiedenen Testdaten, und darüber hinaus können auch Tester, die über wenig oder keine Programmierfähigkeiten verfügen, Tests anpassen und erweitern. Dagegen muss die Verarbeitung der Informationen aus den Tabellen in die Skripte integriert werden, wodurch sich der initiale Aufwand der Erstellung erhöht. Es muss im Einzelfall abgewogen werden, ob es sich lohnt bestimmte Daten über eine Tabelle einzulesen, oder ob es nicht sinnvoller ist, die Daten direkt in ein Skript zu integrieren. Je einfacher es ist, Daten aus einer Tabelle zu lesen, desto geringer wird die Hemmschwelle beim Implementieren sein. Die Einfachheit hängt wiederum von der verwendeten Skriptsprache ab. Die datengetriebene Testskripttechnik ist heute die in der Praxis am meisten eingesetzte Methode um Testskripte zu entwickeln. Die Idee der schlüsselwortgetriebenen Testtechnik liegt eigentlich nahe, wenn man sich die Idee hinter der datengetrieben Testskripttechnik vor Augen führt. Die einzelnen Module eines modularen Skriptes werden für einen Test mittels eines Hauptskriptes zusammengeführt. Haben die einzelnen Module sinnvolle Namen bekommen und existieren außer den Modulaufrufen keine weiteren Anweisungen oder Ausdrücke im Hauptskript, so liest sich das Hauptskript wahrscheinlich recht ähnlich einer natursprachlichen Beschreibung des Testfalls in Tabellenform. Bringt man hierzu die Idee der datengetriebenen Skripten ein, so ergibt sich, dass diese Modulaufrufe nicht mehr in einem Hauptskript stehen, sondern in einer Tabelle. Dann muss für einen neuen Testfall nur noch eine Tabelle in einer Form angelegt werden, die auch von Personen ohne Programmierkenntnisse bewältigbar ist. Auf der anderen Seite müssen natürlich entsprechende Module schon existieren bzw. es wird immer wieder notwendig sein, auch neue Module anzulegen, da die Vorhandenen nicht 16 Abkürzung steht für Anwendung unter Test

54 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 45 ausreichen. Ein Modul wurde im Rahmen dieser Masterarbeit schon vorgestellt, die Anmeldeprozedur aus ist nichts anderes als ein Modul, was die Anmeldung am SAP System durchführt und durch Testdaten gesteuert wird. Der Algorithmus in der Programmlogik ist immer gleich. Versucht man das Modul Anmelderoutine durch ein weiteres Modul zu erweitern, leitet sich schon hier das Einsatzgebiet der schlüsselwortgetriebenen Skripttechnik ab. Im Gegensatz zu den datengetrieben Skripten können mit der schlüsselgetriebenen Skripttechnik Testskripte auch ohne Programmierkenntnisse erstellt werden, z.b. werden in SAP alle Oberflächenelemente mit einem eindeutigen Schlüsselwort versehen. Dadurch hängt die Anzahl der Testskripte nicht von der Anzahl der Testfälle ab, sondern diese wächst mit der Funktionalität der Software. Für Software, deren Einsatz schon von vorneherein ein absehbares Ende in nicht zu ferner Zukunft hat, lohnt sich der Aufwand, um einzelne Module anzufertigen, sicherlich nicht. Ebenso für kleinere Softwareprojekte, bei denen der Umfang der Software und vor allem die Zahl der Testfälle überschaubar bleiben, ist ein mittels schlüsselwortgetriebener Skripttechnik implementierter Testfall nicht empfehlenswert. Für langlebige Softwaresysteme können hingegen schlüsselwortgetriebene Skripttechniken im Laufe der Weiterentwicklung enorme Vorteile schaffen. Die Bedeutung des Aufwandes der initialen Modulentwicklung wird immer mehr zurücktreten und die Hauptaufgaben beim Erstellen neuer Tests werden sich von der aufwändigen Modulerstellung hin zu der leichten und schnellen Erstellung von Testtabellen verschieben. Jede der vorgestellten Techniken hat ihre Berechtigung. Das bedeutet, dass auch immer wieder entschieden werden muss, welche der Techniken zum Einsatz kommen soll. Viele am Markt erhältliche Werkzeuge erleichtern die Entscheidung, indem die genutzten Skriptsprachen es erlauben, jede der Techniken einzusetzen bzw. im Laufe der Testentwicklung umzustellen. Um solche Umstellungen zu ermöglichen, muss aber darauf geachtet werden, den Einsatz einer anderen Technik nicht durch die Art der Skriptimplementierung zu verhindern. Es wird nicht immer von Anfang an notwendig ein, sich für alle Eventualitäten zu wappnen, es geht lediglich darum die Notwendigkeit eines Umstieg frühzeitig zu erkennen. Das QTP bietet bspw. den Objekt Spion ( ObjectSpy ), um beide Testtechniken zu unterstützen. Was der Objekt Spion genau macht, erläutert kurz der folgende Abschnitt ObjectSpy von QTP Mithilfe des Objekt Spions können die Eigenschaften eines Objekts in einer offenen Anwendung angezeigt werden. Die ObjectSpy zeigt die komplette Hierarchiestruktur des ausgewählten Objekts und seiner Eigenschaften und Werte. Der Objekt Spion lässt sich ganz einfach aus der Entwicklungsumgebung starten und ist ein mächtiges Werkzeug, welches erlaubt, für jedes identifizierte Objekt alle Methoden und Parameter anzugeben, die auf diesem Objekt ausgeführt werden dürfen. Weiter bietet es eine sehr komfortable Form technische Details zu den Objekten auszulesen und Werte abzugreifen. Der Objekt Spion rundet das starke Profil von QTP ab.

55 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 46 Abbildung 3.12 Objekt Spion ( ObjectSpy ) im QTP Bewertung von QTP Mit QTP lassen sich recht schnell sowohl datengetriebene als auch schlüsselwortgetriebene Testskripte erzeugen. Die Erkennung von Objekten unter Windows erfolgt zuverlässig, und mit Hilfe von Capture- Replay kann ein erster Baustein in der Testautomation ganz einfach gelegt werden, der die Basis für ein Testskript schaffen kann. Voraussetzung für den Einsatz von QTP ist, dass die zu testende Anwendung eine Windows-, SAP-, Oracle-, Java- oder Webanwendung ist. Allerdings zeigt QTP im speziellen bei Webanwendungen einige Schwächen, die zu schweren Fehlern führen. Tests auch mit dem Produkt von IBM Rational SQA Robot haben gezeigt, dass auch Rational SQA Robot hier Schwächen hat. Als Beispiel wird eine ComboBox gewählt. Wenn jetzt versucht wird mit einem Testwerkzeug dieses Element zu identifizieren und darauf mittels Acessoren zuzugreifen, funktioniert dieses nur mit dem ersten Element in der Auswahlliste, alle darunter befindlichen Einträge können nicht als Elemente dieser Liste identifiziert werden. Das ist eine große Schwachstelle und kann nur durch einem großen Aufwand programmiertechnisch gelöst werden. Die Integration von QTP in HPQC erfolgt problemlos. QTP kann beim Start bereits eine Verbindung mit dem QC aufbauen und somit seine Daten gleich in den entsprechenden QC-Projekten ablegen. Die Testfälle erscheinen dann im Test Plan und können anschließend im Testlab zu komplexeren Testabläufen modelliert werden. Auch die Ausführung der Tests ist direkt über das HPQC ist möglich.

56 Warum Testautomation notwendig ist um nachhaltig Softwarequalität zu garantieren 47 Die bisherigen Kapitel gaben bisher einen Überblick über die Grundlagen des Testens und der Testautomation. Dabei wurde versucht, zwei Sichten darzustellen, einmal die theoretische Sicht, die sich damit beschäftigt, wie die Fachliteratur die Eingliederung von Testen und Testautomation einordnet, und die praktische Sicht, die das Ganze aus der Praxis zeigt. Die Diskrepanz zwischen Theorie und Praxis ist in den letzten Jahren allerdings stetig gesunken, das zeigen viele Beispiele. An dieser Stelle zu erwähnen ist die Metro, die einen definierten Prozess etabliert hat, wie Software zu entwickeln und zu testen ist. Vodafone hat einen ähnlichen Entwicklungs- und Testprozess. Die Daimler AG setzt voll auf Automation ihrer administrativen SAP Systeme wie Personalwirtschaft und derer Finanzmodule. Die EDEKA Gruppe hat einen enormen Aufwand betrieben, ihre SAP Testfälle zu automatisieren, durch die Beauftragung von Beratungsunternehmen werden aktuell Strategien und die ersten Pilotprojekte realisiert. Die eingangs in Kapitel 3 getroffene Aussage, dass Testautomationsprojekte als eigene Softwareprojekte anzusehen sein sollten, zeigt auch die Praxis und auch die Pilotierungen anderer Unternehmen 17. Das nächste Kapitel beschäftigt sich mit dem Testgegenstand, für den diese Masterarbeit eine Lösung bieten soll. 17 Ebay, Vortrag Michael Palotas IQNITE Konferenz April 2011 in Düsseldorf, Titel: Ein Blick hinter den Kulissen

57 SAP Grundlagen - Vorstellung des Testgegenstands 48 4 SAP Grundlagen - Vorstellung des Testgegenstands Im ersten Teil dieses Kapitels, was gleichzeitig den Schwerpunkt dieser Masterarbeit behandelt, erfolgt ein kurzer Überblick über SAP und für die Masterarbeit relevanten SAP Module. Basierend auf dieser Einführung erfolgen die Vorstellung des Testgegenstands sowie die technische Realisierung einer automatisierten Berechtigungsprüfung in SAP. Dabei werden auch die am Test beteiligten Komponenten beleuchtet und warum diese für eine funktionierende Testautomation benötigt werden. 4.1 Was ist SAP? Die SAP AG wurde im Jahr 1972 im deutschen Weinheim gegründet. Innerhalb kürzester Zeit ist es dem Unternehmen gelungen, zu einem Konzern von Weltbedeutung zu wachsen: Heute beschäftigt das Unternehmen etwa Mitarbeiter und erzielt einen jährlichen Umsatz im zweistelligen Milliardenbereich. SAP ist ein ziemlich komplexes System, welches in vielen Kapitalgesellschaften, Gesellschaften oder Einrichtungen zur Unterstützung von betriebswirtschaftlichen Tätigkeiten herangezogen wird. Die Software soll Unternehmen die Verwaltungsarbeit erleichtern. In der Anwendung selbst werden die Funktionen in Programm-Module, wie Finanzen-Controlling und Materialwirtschaft oder Vertrieb, unterteilt. SAP nutzt die ABAP Object Programmiersprache und funktioniert mit den meisten Computern der unterschiedlichen Hersteller. Die Daten von mehreren Rechnern lassen sich über diese Software verbinden. SAP gibt es nicht an der Ladentheke, es muss individuell für das Unternehmen angepasst werden Berechtigungsprüfungen in SAP Berechtigungen in einem SAP System steuern die Zugriffsmöglichkeiten seiner Benutzer. Die Sicherheit der Geschäftsdaten hängt daher direkt von den eingestellten Berechtigungen ab. Aus diesem Grund muss die Vergabe von Berechtigungen sorgfältig geplant und durchgeführt werden, um die gewünschte Sicherheit zu erreichen. Die Funktionen eines SAP Systems (bspw. Programme oder Reports, generell Applikationen im SAP System) werden über Transaktionen 19 aufgerufen, die dabei unterschiedliche Operationen oder Aktivitäten (bspw. Schreiben, Lesen, Löschen) auf Daten ausführen können. Die über Transaktionen gestarteten Applikationen prüfen beim Aufruf, ob der aufrufende Benutzer über die notwendigen Berechtigungen verfügt, die angeforderte Operation auf den durch die Applikation angesprochenen Daten auszuführen. Während des Testens werden verschiedene Transaktionen (Programme) 18 Quelle: SAP AG unter 19 Für jede Anwendung im SAP-System gibt es einen Transaktionscode. Das ist eine Kombination aus Zahlen und Buchstaben. Wenn ein Transaktionscode in der Befehlszeile eingegeben wird, startet die entsprechende Anwendung. SAP verfügt über etwas mehr als Transaktionen (quelle:

58 SAP Grundlagen - Vorstellung des Testgegenstands 49 aufgerufen, diese Programme werden in SAP dynamische Programme genannt, oder abgekürzt Dynpros. Dynpros bilden Instanzen, welche durch den Aufruf von Dialogmodulen die Ausführung von ABAP-Programmen steuern. Der Prüfmechanismus baut auf so genannten Berechtigungsobjekten auf, die Autorisierungsfelder besitzen. Eine konkrete Berechtigung kann als Ausprägung eines Berechtigungsobjektes mit ausgefüllten Autorisierungsfeldern verstanden werden. Beim Start einer Transaktion prüft das SAP-System zunächst, ob der Benutzer die Berechtigung zum Start der Transaktion besitzt. Nach dem Start kann die Transaktion auch weitere Berechtigungsprüfungen durchführen. Geprüft wird, ob der zugreifende Benutzer eine Berechtigung besitzt, die vom benötigten Berechtigungsobjekt abgeleitet ist. Ist dies der Fall, werden die Autorisierungsfelder der Berechtigung daraufhin geprüft, ob sie die benötigten Werte oder Wertekombinationen enthalten. Eine Transaktion kann dabei auf mehrere Berechtigungen prüfen. Welche dies sind, wird im Programm-Code festgelegt. Beim Start einer Transaktion wird vom SAP-System immer auf das Berechtigungsobjekt S_TCODE geprüft. Beim Start von Applikationen wird auf das Berechtigungsobjekt S_PROGRAM geprüft. Die eigentliche Prüfung erfolgt also immer durch den Kern des SAP Systems, auch wenn diese durch den Programm-Code der Transaktion angestoßen wird. Aus Applikationssicht sind insbesondere diejenigen Autorisierungsfelder von Berechtigungsobjekten wichtig, die als so genannte Organisationsebenen ausgeprägt werden müssen. Sie berechtigen dann eine Rolle, eine bestimmte Transaktion, beispielsweise für den angegebenen Buchungskreis (oftmals eine zusammenhängende Geschäftseinheit eines Unternehmens, z. B. Gesellschaften, Vertriebslinien) durchzuführen. Ein Buchungskreis stellt hierbei die kleinste bilanzierende Einheit im externen Rechnungswesen dar. Für jeden Buchungskreis wird eine eigene Bilanz und eine Gewinn- und Verlustrechnung nach den jeweiligen handelsrechtlichen Bestimmungen erstellt Zusammenhang zwischen SAP Mandant und Buchungskreise Der Mandant ist die höchste Hierarchieebene im SAP-System. Festlegungen, die auf dieser Ebene getroffen, oder Daten, die auf dieser Ebene eingegeben werden, gelten für alle Buchungskreise und darüber hinaus auch für alle anderen Organisationsstrukturen. So wird beispielsweise die Anschrift bspw. eines Debitors auf der Mandantenebene abgelegt, so dass alle anderen Organisationseinheiten auf diese zentralen Daten zugreifen können (die Buchhaltung für eine Mahnung, der Vertrieb für eine Auftragsbestätigung usw.). Daten müssen somit nicht mehrfach erfasst werden. Die zentrale Pflege dieser Angaben gewährleistet jederzeit einen konsistenten Datenstand. Jeder Mandant ist in einer SAP-Installation eine für sich abgeschlossene Einheit mit getrennten Stammsätzen. In allen Datensätzen wird ein Mandantenschlüssel mitgeführt, der die Trennung der Datensätze nach Mandanten gewährleistet. Bereits bei der Anmeldung am System muss der Benutzer einen Mandantenschlüssel angeben. Damit legt er fest, in welchem Mandanten er arbeiten möchte. In der Praxis arbeitet ein Unternehmen i.d.r. mindestens mit einem Entwicklungs-, einem

59 SAP Grundlagen - Vorstellung des Testgegenstands 50 Qualitätssicherungs- und einem Produktivmandanten. Es können auch weitere Schulungsmandanten existieren. Alle Eingaben werden getrennt nach Mandanten gespeichert. Die Verarbeitung und Auswertung der Daten geschieht ebenfalls getrennt nach Mandanten. Es ist beispielsweise nicht möglich, Debitorenkonten unterschiedlicher Mandanten in einem Mahnlauf auszuwerten. Auch die Zugangsberechtigung wird getrennt nach Mandanten vergeben. Für jeden Benutzer muss in dem Mandanten, in dem er arbeiten möchte, ein Benutzerstammsatz angelegt werden. Der Buchungskreis ist eine organisatorische Einheit des Rechnungswesens, der das Unternehmen aus Sicht der Finanzbuchhaltung gliedert. Es handelt sich dabei um die kleinste organisatorische Einheit, für die eine vollständige in sich abgeschlossene Buchhaltung abgebildet werden kann. Dies beinhaltet sowohl die Erfassung aller buchungspflichtigen Ereignisse als auch die Erstellung aller Nachweise für einen gesetzlichen Einzelabschluss, wie bspw. oben schon erwähnt die Bilanz sowie Gewinn- und Verlustrechnung. Ein Buchungskreis wird nach steuerrechtlichen, handelsrechtlichen oder sonstigen finanzbuchhalterischen Gesichtspunkten gebildet. In der Praxis entspricht der Buchungskreis in der Regel einem rechtlich selbstständigen Unternehmen. Für jeden Mandanten lassen sich mehrere Buchungskreise einrichten, um so die Buchhaltung mehrerer selbständiger Firmen gleichzeitig führen zu können. Mindestens ein Buchungskreis muss eingerichtet sein, wenn das System eingesetzt wird Zuordnung von Berechtigungen Berechtigungen werden Benutzern dadurch zugeordnet, dass ihnen so genannte Rollen zugeordnet werden. Rollen geben an, welche Transaktionen durch den Benutzer ausgeführt werden sollen, dem eine Rolle zugeordnet wurde. Da jede Transaktion auf bestimmte, durch den Programm-Code festgelegte Berechtigungsobjekte prüft, kann für jede Rolle ein Berechtigungsprofil (d. h. Menge von Berechtigungen) abgeleitet werden, in dem alle Berechtigungsobjekte enthalten sind, die zur Ausführung der Transaktionen generell benötigt werden. Der Prozess, das Berechtigungsprofil für eine Rolle und die darin enthaltenen Transaktionen zu erstellen, wird über den Profilgenerator (SAP Transaktion PFCG) automatisiert. Über Prüfkennzeichen für Transaktionen kann gesteuert werden, für welche Berechtigungsobjekte, auf die eine Transaktion prüft, der SAP-System tatsächlich eine Prüfung ausführt. Über die Prüfkennzeichen können folglich Berechtigungsobjekte beim Aufruf einer Transaktion von der Prüfung ausgeschlossen werden. In diesem Fall wird durch den Profilgenerator auch keine Berechtigung im generierten Berechtigungsprofil erzeugt. Die Prüfkennzeichen werden über die Transaktion SU24 gepflegt, hier werden auch für die einzelnen Autorisierungsfelder der Berechtigungsobjekte die Werte gepflegt, die durch den Profilgenerator in die generierten Berechtigungen der Profile eingetragen werden. Es handelt sich dabei um Vorschlagswerte. Die Profile, die durch den Profilgenerator erzeugt werden, müssen unter Umständen noch manuell nachbearbeitet werden. Durch die Vergabe von Berechtigungen wird definiert, welche betriebswirtschaftlichen Objekte von den Mitarbeitern des Unternehmens bearbeitet werden dürfen und welche Rollen dabei zugelassen sind.

60 SAP Grundlagen - Vorstellung des Testgegenstands 51 Das SAP Modul SAP FICO (SAP Finanz und Controlling) vereinheitlicht in einem Unternehmen die Geschäftsprozesse in den Bereichen Finanz- und Rechnungswesen sowie im Controlling. SAP-System Unternehmen Mandant Firma Buchungskreis Werk Werk Lager 4.2 Das SAP Modul FICO und die direkten abhängigen SAP- Module sowie deren Notwendigkeit in einem Geschäftsprozess Tochtergesellschaften Vertriebsgesellschaften Verkaufsorganisation Abbildung 4.1 Zusammenhang SAP- Mandant und Buchungskreis Für die Instandhaltungsprozesse ist das SAP Modul Materialwirtschaft zuständig, dieses übernimmt alle administrativen Aufgaben der Instandhaltung vom Gebäude-, Vertrags-, bis zu Reparatur-, und Energiemanagement. Ein administrativer Prozess ist beispielsweise die Bestellung von neuen Leuchtmitteln für den Eigengebrauch im Unternehmen. Ein weiteres Beispiel kann das Bestellen von Büromaterial für die Verwaltung eines Unternehmens sein. Das Modul Investitionsmanagement dient der Planung und Abwicklung von Investitionen im finanzwirtschaftlichen Sinn. Mit dem Modul Bestellungen im SAP Materialwirtschaft können bspw. Verbrauchs- und Investivgüter über eine katalogbasierte Plattform im Intranet bestellt werden. Dieser Katalog ist mit einer Schnittstelle zu Lieferanten versehen.

61 SAP Grundlagen - Vorstellung des Testgegenstands 52 SAP-Systeme und die Abhängigkeiten zum SAP-FICO System Externe Bestellungen ohne SAP Investitions- Management SAP Finanz & Rechnungs- Wesen SAP Bestellungen mit SAP Materialwirtschaft SAP Personalwirtschaft SAP Abbildung 4.2 Module SAP im FICO Umfeld Auch Dienstleistungen wie das Einkaufen von externen Ressourcen können mit dem SAP Modul Bestellungen durchgeführt werden. Unter externen Ressourcen werden Entwickler und Berater verstanden. Sowohl die Rechnung als auch die Bezahlung erfolgen durch das angebundene Finanzmodul. Auch hier muss das Berechtigungskonzept dafür sorgen, dass der Besteller nicht gleichzeitig Genehmiger und Zahlungsanweiser sein darf. Die Schnittstelle zu Personalwirtschaft kommt aus dem SAP Modul Human Resources. Hier werden die Abrechnungsdaten von Mitarbeiter nach Kostenstellen zusammengefasst und an das SAP FICO übergeleitet. Das Modul Investitionsmanagement kann genutzt werden um bspw. IT-Hardware anzuschaffen. Für die jeweilige Hardware wird automatisch eine Abschreibungsregel im System hinterlegt und eine Buchungsnummer, die an das SAP-FICO-System automatisch zur Weiterverarbeitung weitergeleitet wird. In Konzernen sind Anforderungen an die Berichterstattung von Finanzdaten erheblich gestiegen. Zum einen müssen wesentlich mehr Informationen in Form von Hochrechnungen, Abschlüssen, etc. geliefert werden und zum anderen muss dies in wesentlich kürzerer Zeit geschehen. Darüber hinaus verlangen die internationalen Rechnungslegungsvorschriften, gleiche Geschäftsvorfälle vertriebslinienübergreifend auf gleiche Art und Weise zu bilanzieren und zu bewerten. Das Modul SAP FICO und die in Abhängigkeit stehenden Module müssen diese Anforderungen abdecken. Die Metro AG ist die Holdinggesellschaft und unter ihr sind alle Gesellschaften und Vertriebslinien der Metro Group geordnet. Mit einem Vereinheitlichen von SAP Prozessen werden Gesellschaften des Konzerns angetrieben standardisiert zu arbeiten. Dadurch wird die Transparenz und Nachvollziehbarkeit von buchhalterischen Aktivitäten zwischen den Gesellschaften erhöht.

62 SAP Grundlagen - Vorstellung des Testgegenstands SAP FICO als Herzstück des Unternehmens Das Rechnungswesen bildet das "Herzstück" der gesamten SAP-Modul-Landschaft. Bspw. senden sämtliche Logistiksysteme ihre Bewegungsdaten in Form von Materialbelegen, Ausgangsrechnungen, Eingangsrechnungen und Leistungen online in das Finanzwesen und Controlling. Mit der Hauptbuchhaltung, Debitoren- und Kreditorenbuchhaltung können sämtliche Anforderungen des internen und externen Rechnungswesens abgedeckt werden. Die generellen Funktionalitäten des Controllings sind mit den Funktionen der Finanzbuchhaltung vernetzt, wobei die Finanzbuchhaltung alle kostenrechnungsrelevanten Daten sofort an das Controlling übermittelt. Die Standardfunktionen werden mit der klassischen Kostenstellen- und Kostenartenrechnung abgebildet. Hat ein Benutzer Zugriff auf das SAP FICO System, so hat dieser Zugriff auf das zentrale Element eines Unternehmens, dieses System beinhaltet nicht nur Lieferantendaten, Lieferkonditionen, Preislisten, sondern es können damit auch Überweisungen und Buchungen vorgenommen werden. Um Missbrauch vorzubeugen und um Daten so zu schützen, dass diese nicht von unberechtigten Personen eingesehen werden dürfen, oder versehentlich gelöscht werden, existieren Zugriffschutzmechanismen (vgl. Abschnitt 4.3.1). Gleichzeitig dienen Berechtigungen der Transparenz und Sicherstellung von Verantwortlichkeiten und Rollen. Handelsrechtlich sollen hierdurch Verstöße gegen das elektronische Radierverbot ( 239, Abs.3 HGB) verhindert werden, die Nachvollziehbarkeit im Sinne der 238 ff. HGB gewährleistet und Verstöße gegen die Grundsätze ordentlicher Buchführung (GoB) vermieden werden - um sicherzustellen, dass keine unautorisierten, unvollständigen, unrichtigen und zeitlich oder sachlich falsch zugeordneten Daten in das System gelangen Notwendigkeit für Berechtigungsprüfungen und deren Automatisierung Die Prüfung des Berechtigungskonzeptes ist eine zentrale und immer wiederkehrende Aufgabe. Benutzerstammsätze und Berechtigungskomponenten sind mandantenabhängig. Für jeden Mandanten im SAP System sind also eigene Benutzerstammsätze und Berechtigungskomponenten zu pflegen. Sie enthalten Werte (bspw. einen konkreten Buchungskreis) zu Feldern, die in einem zugehörigen Berechtigungsobjekt festgelegt sind. Den Benutzern selbst sind Berechtigungsprofile - Schlüsseln vergleichbar - und/oder Sammelberechtigungsprofile - einem Schlüsselbund vergleichbar - an die Hand gegeben, d.h. in ihren Benutzerstammsatz eingetragen. Die Prüfung, ob ein Berechtigungsprofil eines konkreten Benutzers zu einer Berechtigung passt, wird zur Laufzeit im Dialog vorgenommen. Nahezu alle Transaktionen sind in der SAP-eigenen Programmiersprache ABAP geschrieben, die mit einem mächtigen Sprachumfang umfassende Manipulationsmechanismen innerhalb von SAP bietet. Die Orientierung an einer Sprache hat innerhalb des Berechtigungskonzeptes jedoch auch einen Nachteil. Die Ressourcen werden nicht als solche gegen unberechtigte Zugriffe abgeschirmt, vielmehr muss die Berechtigungssteuerung innerhalb der Programme mit ABAP-Funktionsaufrufen bzw. -

63 SAP Grundlagen - Vorstellung des Testgegenstands 54 Sprachmitteln erfolgen. Um dieser Notwendigkeit Rechnung zu tragen, wird über das ABAP-Statement 'AUTHORITYCHECK' - entweder direkt im Hauptcoding oder über einen Funktionsbausteinaufruf - die Prüfung auf der jeweiligen SAP-Ressource durchgeführt. Dieses Statement erhält als Übergabewerte das zu prüfende Berechtigungsobjekt, die jeweiligen Steuerungsfelder des Berechtigungsobjektes und die notwendigen Feldinhalte als Zugangsvoraussetzung zu der SAP-Funktionalität. Ist der Abgleich zwischen notwendigem Zugangwert und Vergleichwert des Mitarbeiters aus seiner Zuweisung erfolgreich, wird der Wert 0 als Returncode zurückgegeben, ansonsten erfolgt über einen anderen Returncode eine Ablehnung. Innerhalb des Zugriffs auf einzelne Ressourcen erfolgt meist der Abgleich auf mehrere Berechtigungsobjekte, die in Gänze zutreffen müssen, um Zugriff auf die Funktionalität zu erhalten. So darf also sowohl bei der Programmierung als auch bei der Prüfung weder das Berechtigungsobjekt noch die jeweils gültige Einzelausprägung der zugehörigen Felder übergangen werden Testen von Berechtigungen: Ist-Zustand Es werden Tests in Rahmen von Releasen im SAP FICO durchgeführt. Diese basieren auf Change Requests (Änderungsanforderungen) und Neuentwicklungen, die mit dem Lebenszyklus eines Softwaresystems notwendig werden. Viele dieser Änderungen sind entweder kleine Korrekturen am Geschäftsprozess, oder Fehlerbehebungen aus dem täglichen Betrieb. Nach jedem Release muss sichergestellt werden, dass alle Funktionalitäten, die von Änderungen nicht betroffen waren, noch so funktionieren, wie vorher (Regressionstest) und die neuen Funktionalitäten in einem integrativen Test fachlich und technisch den Anforderungen entsprechen. Der Test teilt sich insgesamt in drei Teile auf: Testvorbereitung, Testausführung und Testnachbereitung. Unter Testvorbereitung versteht man das Schaffen von Voraussetzungen, damit ein Test ausgeführt werden kann. Dies kann zum Beispiel das Anlegen von Testdaten sein, oder die Schaffung einer für den Test notwendigen Systeminfrastruktur. Zur Testvorbereitung gehören auch die Berechtigungsprüfungen. Diese bilden die Basis für die darauffolgenden geschäftsprozessbezogenen Tests. Testausführung bedeutet, einen Testfall auf ein Testsystem anzuwenden, sprich die im Testfall aufgeführten Testschritte am System auszuführen. Testnachbereitung bezeichnet alle Schritte, die nach dem eigentlichen Test erforderlich sein können. Eventuell liegen die Testergebnisse an verschiedenen Stellen im System und müssen in das dafür vorgesehene Verzeichnis gelegt werden. Manche Protokolle, die keine Fehlermeldungen enthalten, können gelöscht werden, oder bestimmte Datensätze, die nur für den Test benötigt wurden, müssen wieder aus der Datenbank entfernt werden. Es gibt eine Menge an Vor- und Nachbereitungsaufgaben. Diese Aufgaben sind zeitintensiv und müssen evtl. nach jedem Testfall ausgeführt werden. Da es sich hierbei häufig um gleiche oder ähnliche Aufgaben handelt, bietet sich auch hier eine Automatisierung dieser Testvor- und Testnachbereitungsphasen an. Beispielsweise bietet es sich an, die Vor- und Nachbereitung in entsprechenden Funktionen zu kapseln und an den entscheidenden Stellen in das Automatisierungsskript zu integrieren. Es sollte noch beachtet werden, dass bei der Nachbereitung andere Aufgaben anfallen können, wenn der Test nicht erfolgreich abgeschlossen wurde. In diesem

64 SAP Grundlagen - Vorstellung des Testgegenstands 55 Fall ist es durchaus sinnvoll, keine Bereinigung vorzunehmen, damit am Ende alle Daten zur Analyse des Fehlers vorliegen. 4.3 Problembeschreibung Warum sich Automatisierung anbietet Dieser Kapitelabschnitt soll eine Problembeschreibung liefern, die die Notwendigkeit einer Testautomation bei Berechtigungstests rechtfertigt. Des Weiteren soll die Transformation als Voraussetzung für das Entwickeln von Testprogrammen vorgestellt und erläutert werden. Im Durchschnitt werden sechs Release pro Jahr entwickelt. Zu dem Releasen kommen zusätzlich kleine Änderungen und Fehlerbehebungen, die jeweils zeitnah erfolgen müssen und sich nicht in den Releasezyklus einordnen lassen. Insgesamt gibt es ca. 300 Systemanwender für das SAP-FICO- System. Alle Systemanwender sind an das Berechtigungs- und Rollenkonzept gebunden. Es gibt durchschnittlich drei Rollen pro Systemanwender, sprich insgesamt 900 verschiedene Systemanwenderrollen. Jede Systemanwenderrolle darf ca. 50 Transaktionen ausführen. Multipliziert man die Zahl der Systemanwenderrollen (900) mit der Anzahl der Transaktionen (50), die eine Systemanwenderrolle ausführen darf, so erhält man Transaktionen, die über 900 Systemanwenderrollen verteilt angewendet werden dürfen. Jede dieser Kombinationen zwischen Systemanwenderrolle und einer Transaktion entspricht einem Testfall. In Summe sind das Testfälle pro Transaktion ein Testfall - die durchzuführen sind, um einen vollständigen Berechtigungstest zu gewährleisten. Diese Anzahl an Testfällen müssen in jeder Testphase mindestens einmal vollständig ausgeführt werden, um sicherzustellen, dass alle Berechtigungsrollen auf den Produktivsystemen funktionieren. Diese Anzahl an Tests deckt acht Buchungskreise, die auf einem SAP Mandant abgebildet sind, ab. Manuelle Tests bringen bei so einer Anzahl von Testfällen keine hohe Testabdeckung, oder wenn dann nur mit einem unvertretbar hohen Aufwand. Während der Tests können natürlich auch Abweichungen vom Soll und Ist festgestellt werden. Praxisbeispiel Für das Testen mit einer Systemanwenderrolle und 150 Transaktionen wurden in einer Untersuchung folgende Zeiten erfasst: Systemanwender Transaktionen Testfälle Dauer Stunden Tabelle 1 Testdauer - Transaktionen Das bedeutet, dass ein Systemanwender für 150 Transaktionen ca. 2 Stunden benötigt. Multipliziert mit der tatsächlich durchzuführenden Anzahl an Testfällen entspricht das einer Zahl von ca. 600

65 SAP Grundlagen - Vorstellung des Testgegenstands 56 Arbeitsstunden. Berechtigungstests kommen in der Testvorbereitungsphase zum Einsatz und sichern ab, dass alle auf dem System zugelassenen Systemanwender ihre Tests - wofür sie die Transaktionsund Programmaufrufe benötigen - auch ausführen können. Mit den Berechtigungstests sind noch keine Geschäftsprozesse in dieser Berechung enthalten. Diese müssten jetzt noch hinzuaddiert werden. Der Aufwand diese Tests manuell auszuführen, steht somit in keinem Verhältnis. Aufgabe Durch das Testen der Berechtigungen alleine wird keine Qualität gesichert. Die Berechtigungstests erhöhen allerdings bei erfolgreicher Ausführung den Grad der Testabdeckung und die Zufriedenheit der Anwender. Dadurch soll erreicht werden, dass nach erfolgreicher Produktivsetzung neuer Release oder Funktionalitäten keine Fehler in den Produktivsystemen auftauchen, die auf Berechtigungen zurückzuführen sind. Lösung Eine Lösung, die hier Abhilfe schaffen soll, ist das Entwickeln von Programmen, die wiederum andere Programme testen sollen. Die Programme sollen so aufgebaut werden, dass sie auf verschiedenen SAP-Buchungskreise arbeiten können. Es soll nicht für jeden SAP Buchungskreis ein spezielles Programm entwickelt werden, sondern es muss eine generische Lösung entworfen und entwickelt werden, die in der Lage sein muss, alle SAP-Berechtigungstests durchzuführen - das bedeutet nicht nur SAP-FICO, was Gegenstand dieser Masterarbeit ist, sondern auch beliebige andere SAP-Systeme. Was wird benötigt? Ein Testwerkzeug wie Quick Test Professional, was gleichzeitig eine Entwicklungsumgebung und eine Ausführungseinheit beinhaltet, soll jetzt den Rahmen bieten, um Programme zu entwickeln die das Testen von Berechtigungen automatisiert durchführen. Für das Entwickeln einer Testautomation werden Testdaten benötigt, diese werden vom jeweiligen Fachbereich geliefert. Der Fachbereich muss ein vollständiges Berechtigungskonzept zur Verfügung stellen, welches alle Benutzer und die passenden Rollen beinhaltet, sowie die erlaubten Transaktionen. Der Inhalt des Berechtigungskonzepts entspricht den Testdaten Anforderung an einem automatisierten Berechtigungstest 1. Es sollte kein manuelles Eingreifen nötig sein, d.h. das Berechtigungskonzept wird aus SAP generiert und in einer Ablagestruktur (Filesystem im HPQC) abgelegt. 2. Es muss sichergestellt werden, dass alle Systemanwender geladen werden und dass alle möglichen Berechtigungsprüfungen des im SAP FICO implementierten Regelwerks getestet werden.

66 SAP Grundlagen - Vorstellung des Testgegenstands Alle Transaktionen (Programme, Reports, usw.), die jeweils für das Unternehmen angepasst worden sind, müssen während der Berechtigungsprüfung aufrufbar und ausführbar sein Ein Fehler muss genau wie ein erfolgreicher Test reproduzierbar (SU53 21 ) bleiben und in einer Fehlerdatenbank dokumentiert sein. Dadurch ist sichergestellt, dass Tests revisionssicher sind und das Unternehmen dadurch auch die gesetzlichen Vorgaben eingehalten hat. 5. Wichtig ist, dass jeder einzelner Test dokumentiert wird, sprich zu jedem Buchungskreis muss ausgewiesen werden, welcher Systemanwender mit welcher Rolle den Test ausgeführt hat, und was das Ergebnis des Tests ist. 6. Es muss auch möglich sein, einzelne Buchungskreise für einen Test zu selektieren und diese zu testen. Testprojekte sind oftmals auf ein speziell für das entsprechende Release angepasste Testsystem abgestimmt. Aus verschiedenen Gründen ist dieses Vorgehen für die Entwicklung langfristig wieder verwertbarer Testfälle nicht akzeptabel. So ist es unvermeidbar, dass sich ein zu testendes System mit der Zeit ändert. Im Regelfall hat jede Änderung Auswirkungen auf Testfälle. Das führt zu aufwendigen Anpassungen, die wiederum fehlerbehaftet sein können, die den Testablauf ungewollt modifizieren und schlimmstenfalls zu anderen Testresultaten führen. Daher ist es unabdingbar, bevor ein Testautomationsprojekt aufgesetzt wird, eine stabile Testumgebung zu schaffen. Generische Testfälle zeichnen sich dabei dahingehend aus, dass diese nach einem Baukastenprinzip entwickelt werden können. Wichtig ist außerdem, dass im Unternehmen Verantwortliche für Informationen und Prozesse ernannt werden (Prozessowner 22, Datenowner 23 ), beispielsweise ist der Leiter der Finanzabteilung für den Finanz- und Controllingbereich verantwortlich. Die Verantwortlichen aller Bereiche sind unbedingt in die Planung der benötigten Rollen, Berechtigungen und Prozesse einzubeziehen, da nur sie die dazu notwendigen Kenntnisse auf fachlicher Ebene besitzen. 20 Lässt sich die Transaktion FB01 auf Applikationsserver X und Mandant Y mit dem Benutzer Tester01 und Passwort tester001 aufrufen? Wenn ja, dann prüfe weiter, ob ein Kreditor angelegt werden kann und schreibe das in den Testauswertungsbericht. Wenn nein, dann führe die Transaktion SU53 aus und mach eine Abbildung vom dort aufgeführten Fehlerdiagnoseprogramm und speichere diese im Filesystem im HPQC ab. Anschließend schreibe das Ergebnis im Testauswertungsbericht. 21 Die Transaktion SU53 ist eine sehr wichtige Transaktion für Fehlerdiagnose und Fehlerrückverfolgung, die soll hier zur Anwendung kommen, damit ein Fachbereich auf einen Blick sehen kann, woran der Test gescheitert ist, und gleichzeitig können Fehler dadurch leicht reproduziert werden 22 Geben den Prozess vor, nach dem eine Organisation im Unternehmen arbeitet 23 Die sind verantwortlich für alle Stamm- und Bewegungsdaten bspw. in einem SAP System

67 SAP Grundlagen - Vorstellung des Testgegenstands SAP-Testdaten und die Notwendigkeit ihrer Transformation Die am Test beteiligten Komponenten werden im Anhang dieser Masterarbeit aufgeführt, im Glossar erfolgt eine kleine Erläuterung. Abbildung 4.3 Skizze aller beteiligten Komponenten Als Quellsystem für Testdaten dienen das SAP System, wo sich die jeweils ans Unternehmen angepassten Berechtigungen im Regelwerk befinden. Der Vorteil, den SAP hier bietet, ist, dass das komplette Regelwerk mit einer speziellen Transaktion nach Excel exportiert werden kann. Nachteil ist hierbei die aus SAP generierte Struktur der Datei, die für die Testautomation nicht direkt verwendet werden kann, sondern sich vorher Transformation unterziehen muss. Abbildung 4.4 bietet einen kleinen Ausschnitt aus der aus SAP exportierten Rohdatei ohne Transformation. Die Zeilen zeigen die Rollen und die Arbeitsplätze sowie die zugeordneten Programme und Transaktionen, die der Systemanwender mit seiner Rolle ausführen darf. Die Datei beinhaltet noch weitere Informationen: Welche Rollen werden benötigt? Welche Rolle darf welche Programme und Funktionsbausteine im SAP System ausführen?

68 SAP Grundlagen - Vorstellung des Testgegenstands 59 Mit welcher Rolle darf ein Systemanwender bestimmte Auswertungen und Buchungen im System vornehmen? Mit welcher Rolle darf ein Systemanwender bspw. auf sensible Daten wie Lieferantendaten, Lieferkonditionen, Kontonummern zugreifen? Nutzen Applikationen neben dem SAP Standardberechtigungssystem noch weitere Berechtigungen? Wenn ja, müssen diese entsprechend im Konzept berücksichtigt werden. Welche Prozesse sind für die Berechtigungsverwaltung vonnöten, bspw. Beantragung, Genehmigung, Anlegen, Verändern, Löschen von Berechtigungen? Sind Funktionstrennungsaspekte im Berechtigungskonzept ausreichend beachtet? Hier spielen insbesondere auch rechtliche Anforderungen eine Rolle. Mit Hilfe der Transformation sollen die Testdaten, Benutzer, sowie die erlaubten Programme und Transaktionen separiert und in eine strukturierte Form transferiert werden. Es erfolgt tatsächlich eine Teilung des aus SAP generiertem Berechtigungskonzeptes. Abbildung 4.4 SAP-Rohdatei nach Export in Excel So erhält jeder Benutzer seine im Produktivsystem genutzten Transaktionen und Programme in tabellarischer Form aufgeschlüsselt. Beim Testen wird davon ausgegangen, dass in allen Systemen sich zwar die Benutzer unterscheiden, aber dass Passwort nicht, sondern dieses ist für alle Benutzer

69 SAP Grundlagen - Vorstellung des Testgegenstands 60 identisch. Abbildung 4.5 Transformationsprozess Abbildung 4.5 zeigt, wie der Transformationsprozess die Berechtigungsdatei in Systemanwender und Transaktionen teilt und separiert. Auch ist es hier ein Vorteil, ein einheitliches Passwort für alle Systemanwenderrollen zu vergeben, denn es kann problematisch werden, ca. 900 verschiedene Benutzernamen und Passwörter zu verwalten. Erklärung für die Notwendigkeit eines einheitlichen Passworts: Systemanwenderrollen simulieren echte Benutzer auf den Produktivsystemen. Diese Rollen müssen eins zu eins auf den Testsystemen angelegt werden, damit Tester die manuellen Testfälle mit diesen speziellen Systemanwenderrollen ausführen können. Nur so wird sichergestellt, dass ein produktivnahes Testen möglich ist. Da jede Systemanwenderrolle korrespondierend ein Passwort besitzt, existieren analog zu den Anzahl der Systemanwenderrollen ca. 900 verschiedene Passwörter. Das ist auf Produktivsystemen absolut notwendig, allerdings auf Testsystemen nicht. Hier reicht es, wenn ein einheitliches Kennwort automatisiert für alle Systemanwenderrollen vergeben wird. Gründe: Im Test sind meistens nur eine Handvoll Benutzer im Einsatz, die das Testen durchführen. D.h. das bspw. fünf Benutzer 900 Systemanwenderrollen testen müssen. Damit aber auf Testsystemen nicht zu jeder Systemanwenderrolle ein neues Passwort angelegt werden muss, wird einheitlich für alle Systemanwenderrollen ein Initialkennwort (bspw. initial1234) festgelegt. Mit diesem Kennwort können sich die am Test beteiligten Benutzer einheitlich mit verschiedenen Systemanwenderrollen anmelden und Tests durchführen. Beispiel: Systemanwenderrolle: Arbeitsplatz_Gesellschaft_X_Rolle_buchen_mittel_Europa Benutzername: Buchen_Khalid_pnr_1234_ME (pnr=personalnummer, ME=Mitteleuropa) Kennwort: initial12345

70 SAP Grundlagen - Vorstellung des Testgegenstands 61 Eine Ablagestruktur im HPQC soll dafür sorgen, dass das Ergebnis der Transformation automatisiert auf einem Server im HPQC gesichert wird. Im Abschnitt zeigt Abbildung 4.11 das Ergebnis der Transformation. Die Ablagestruktur wird über einen Pfad identifiziert, dieser Pfad wird in der Implementierungsphase einem Testskript als fester Parameter übergeben, und so wird die Datei zur Verarbeitung eingelesen. 4.4 Technische Umsetzung Der zweite Teil dieses Kapitels beschäftigt sich mit der technischen Umsetzung dieser Masterarbeit. Es zeigt die Umsetzung der Transformation und wie darauf basierend die Testprogramme (Testskripte) entwickelt werden und auf SAP angewendet werden können. Einen Überblick, wie die technische Umsetzung der Berechtigungsprüfung aussieht, bietet folgende Grafik: Abbildung 4.6 Ablauf der automatisierten Berechtigungsprüfung Dieser Abschnitt stellt die einzelnen durchzuführenden Schritte vor und zeigt, wie dieses mit programmierten Testskripts gelöst werden. Die einzelnen entwickelten Testskripte werden dann in

71 SAP Grundlagen - Vorstellung des Testgegenstands 62 einer Testsuite zusammengefasst. Diese Testsuite kann nur mit Hilfe der Testentwicklungsumgebung Quick Test Professional ausgeführt werden, die dort enthaltenen fertigen Testskripte können als Programme angesehen werden, die wiederum Programme (SAP Berechtigungen) testen Allgemeine Testfallspezifikation für die Berechtigungsprüfung Eine Anforderung an die Testautomation ist es, generische Testskripte zu entwickeln, sprich es muss möglich sein, einen generischen Testfall zu entwerfen, zu spezifizieren und zu programmieren, der in der Lage sein muss, alle möglichen Tests abzudecken. Ein Test kann als eine Art Gerüst betrachtet werden, der eine gewisse Ablauflogik bereitstellt, deren Ausführung jeweils die Testdaten beeinflussen. Tatsächlich werden jetzt die Testfälle mit Hilfe von Parametern in vielfältiger Art und Weise anwendungsspezifisch mit Daten bestückt. Bei den Parametern kann man verschiedene Attribute unterscheiden: Parameter zur Anpassung des Testsystems (bspw. Initial Setup nach Systemneuaufbau) Parameter zur Beschreibung der Testumgebung Parameter der Testdurchführung (Testdaten) Generisch muss der Testfall sein und zusätzlich muss dieser so modular aufgebaut sein, dass ohne viel Aufwand eine Erweiterung und Anpassung der Testfälle möglich ist. Ein Testfall für eine Berechtigungsprüfung kann so beschrieben werden: Steps Testschritte Voraussetzungen Description- Beschreibung der Testschritte Testuser vorhanden? Testsystem mit Initial Setup verfügbar? Expected Result Erwartetes Verhalten, Systemantwort Testuser angelegt Testsystem mit Stammdaten bestückt Alle für den Test benötigten Schnittstellen angebunden? Freigaben durch Datenowner und Prozessowner? Alle Schnittstellen angebunden Datenschutzerklärung, da Testsysteme mit Produktivdaten ausgestattet werden Step 1 Testdaten in benötigter Qualität vorhanden? Login ins SAP-FICO System Eingabe Benutzername Eingabe Kennwort Eingabe SAP System und Client Eingabe Sprache Quick Check der Testdaten OK System im SAP Anmeldemodus vorhanden Login erfolgreich

72 SAP Grundlagen - Vorstellung des Testgegenstands 63 Step 2 Testuser für Rolle bspw. Accounts Payables für Buchungskreis XXX (im Skript später generisch) auswählen. Buchungskreis im System vorhanden Step 3 Aufrufen des Programms: Rollenkonzept (im Skript später generisch) Export der Datei auf Ablagestruktur im HP Quality Center Aufruf erfolgreich Export auf HPQC Ablagestruktur erfolgreich Step 4 SAP Logout Logout erfolgreich Step 5 Login im SAP-FICO mit zu testender Systemanwenderrolle aus dem generierten und exportierten Rollenkonzept. Login mit Testuser XXX (im Skript später generisch) erfolgreich, d.h. User ist angelegt und Initialpasswort funktioniert Step 6 Step 7 Auslesen der Datei mit allen erlaubten Transaktionsaufrufen und Programmen Beginne die Transaktionen einzeln und nacheinander auszuführen Ok Transaktion erfolgreich ausgeführt Step 8 Dokumentiere jeden Testerfolg und Testmißerfolg Ok Step 9 Step 10 Step 11 Step 11 Bei Misserfolg, starte Programm mit Transaktion SU53 (Notfallprogramm zur Fehlerdiagnose), generiere eine Fehlerauswertung aus SAP mit einer exakten Fehlerbeschreibung Mach ein Bild vom Notfallprogramm und lade dies in (JPG-Format) in die Ablagestruktur des HPQC Eröffne einen Fehler im HPQC und leite ihn an den Fachbereich weiter Bei Erfolg generiere eine Auswertung mit allen Testschritten und gebe jede getestete Transaktion und Programm aus Ok Ok Ok Ok Step 12 SAP Logout Ok Tabelle 2 Generische Testfallbeschreibung für eine Berechtigungsprüfung So ein Testfall kann als Basis für das Programmieren eines passenden Testskripts dienen. Die Testfälle beinhalten keine Informationen über Testdaten, diese sind separat abgespeichert, sondern sie enthalten, wie schon beschrieben, nur eine Ablauflogik (Testablauflogik). Die Herausforderung für einen Testautomatisierer ist, diesen Testfall generisch zu programmieren Testsystemlandschaft für die Automation Berechtigungstests haben eine sehr besondere Ausgangsbedingung, es müssen zwei Programme, das Transformationsskript, das den Testdateninput liefern, und das Testskript, das die Berechtigungen

73 SAP Grundlagen - Vorstellung des Testgegenstands 64 anschließend testen soll, entwickelt werden. Um beide Programme zu entwickeln, muss neben einem Testautomationstool auch eine Testumgebung mit folgenden Komponenten (Abbildung 4.7) aufgebaut werden. Abbildung 4.7 SAP Systemlandschaft inkl. Testsystem Entwicklungen werden in SAP generell auf einem Entwicklungssystem durchgeführt und zu Testzwecken auf ein Testsystem transportiert, so dass auf dem Entwicklungssystem im Prinzip nur entwickelt und das Testen auf andere System verlagert ist. Diese besitzen meist auch Schnittstellen zu angebunden Systemen. SAP verfügt über ein Transportmanagementsystem (TMS), was Objekte, die auf einem Entwicklungssystem bspw. entwickelt worden sind, auf ein Testsystem transportieren kann. Das ist auch der einzige Weg, SAP-Objekte von einem System ins andere System zu übertragen. Das Test-, Entwicklungs-, sowie das Produktivsystem dürfen auf der technischen Ebene keine Unterschiede haben Vorgehensweise bei der Programmierung des Transformationsskriptes Die Vorgehensweise des Tests ist es, im ersten Schritt das Transformationsskript zu entwickeln. Dazu wird noch kein zu testendes Systems benötigt, allerdings das Testautomationswerkzeug zusammen mit HPQC.

74 SAP Grundlagen - Vorstellung des Testgegenstands 65 Abbildung 4.8 Testautomationsframework Neben dem Testfall und dem Testskript spielen die Testdaten und die Funktionsbibliotheken eine zentrale Rolle. Die Funktionsbibliotheken beinhalten die Programmlogik eines Test, das Testskript selbst beinhaltet eine Reihe von Prozeduraufrufen der in der Funktionsbibliothek für den Test entwickelten Routinen und Funktionen. Die Transformation wandelt jetzt eine Datei in eine andere Datei um, ohne das zu testende System zu tangieren. Im Folgenden wird der Aufbau des Codes des Transformationsprogramms skizziert, dabei soll die Aufgabe des Transformationsprozesses beleuchtet werden. Das vollständige Programm ist Bestandteil des Anhangs dieser Masterarbeit. Folgende Komponenten sind notwendig um das Transformationsskript zu entwickeln: Berechtigungskonzept (als Datei) Transformationsskript, was die Berechtigungsdatei verarbeitet und in die Ablagestruktur von HPQC transferiert Das Programm soll auch im HPQC als Testskript angelegt werden, so dass Testdaten, Testskript und Funktionsbibliotheken zusammen sich unter einer einheitlichen Struktur (siehe Abbildung 4.9) befinden.

75 SAP Grundlagen - Vorstellung des Testgegenstands 66 Abbildung 4.9 Ablagestruktur Transformationsskript Folgendes Programmstück zeigt, wie zunächst die Authorisierungsdatei eingelesen wird. Diese Programmstücke zeigen nur einen kleinen Ausschnitt des vollständigen Programms, das vollständige Programm befindet sich in der sap_lib.vbs - Datei (siehe Anhang). Abbildung 4.10 Einbindung von Bibliotheken in die Entwicklungsumgebung

76 SAP Grundlagen - Vorstellung des Testgegenstands 67 Die Bibliotheken beinhalten die ausprogrammierten Programmbausteine, die für einen Berechtigungstest benötigt werden. In Zeile 5 wird das Rollenkonzept aus der Ablagestruktur eingelesen und das Ergebnis der Verarbeitung der Funktion aus Zeile 11 wird in Zeile 6 in die Transaktionsliste geschrieben. In Zeile 8 und 9 werden die Variablen (Parameter) bestückt, die in der Funktion in Zeile 11 übergeben werden. Die Funktion ist in der Bibliothek implementiert und sorgt im ersten Schritt für eine Verbindung zum HPQC, dabei wird gleichzeitig geprüft, ob alle für den Test notwendigen Komponenten vorhanden sind. Die Funktion aus Zeile 53, die genauso wie die Funktion aus Zeile 11 in der Funktionsbibliothek ausprogrammiert ist, sorgt dafür, dass aus dem eingelesenen Dokument authorization_concept FI CO.xls die Systemanwender sowie die verschiedenen Rollen und Transaktionen separiert werden. Folgendes einfaches Beispiel soll demonstrieren, wie das Skript arbeitet. Abbildung 4.11 Ausschnitt aus der fertig transformierten Datei Das Ergebnis der Transformation steht rechts in der Grafik. Den Spaltenkopf dieser Tabelle bildet der Systemanwender (Benutzername). Darunter befinden sich zu dieser Systemanwenderrolle alle Transaktionen und Programme, die diese ausführen darf. Das Transformationsskript erzeugt in einem echten Testlauf ca. 900 verschiedene Systemanwenderrollen und insgesamt werden Transaktionen in die Tabellen/Spalten gefüllt.

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

T2 Fundamentaler Testprozess

T2 Fundamentaler Testprozess T2 Fundamentaler Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Overview der Software- Entwicklung 2 1 Wasserfall-Modell Analyse

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Testplanung und Teststeuerung 2007 Dr. Klaudia Dussa-Zieger P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung

Mehr

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung

Systemen - Testprozess. Testprozess. Testprozess: Aktivitäten. Testplanung und Teststeuerung. Lehrplan 2003 Testplanung P r a k t I s c h e Testprozess - Inhalt Testprozess Testen von Software-Systemen Systemen - Testprozess Lehrplan 2003 Testplanung Testausführung ierung Testendebewertung Testberichterstattung Lehrplan

Mehr

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15

Mehr

TECHNISCHE UNIVERSITÄT ILMENAU. Technische Universität Ilmenau. Fakultät für Informatik und Automatisierung

TECHNISCHE UNIVERSITÄT ILMENAU. Technische Universität Ilmenau. Fakultät für Informatik und Automatisierung Cfu TECHNISCHE UNIVERSITÄT ILMENAU Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Theoretische und Technische Informatik Fachgebiet Softwarearchitekturen und Produktlinien

Mehr

Prozess-Modelle für die Softwareentwicklung

Prozess-Modelle für die Softwareentwicklung Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

Praxisgerechte Validierung von Sicherheitsapplikationen

Praxisgerechte Validierung von Sicherheitsapplikationen Praxisgerechte Validierung von Sicherheitsapplikationen Dr. Michael Huelke, FB Unfallverhütung Produktsicherheit, BGIA Institut für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung, Sankt Augustin

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

Mehr

Testmanagement bei SAP-Projekten

Testmanagement bei SAP-Projekten Testmanagement bei SAP-Projekten Erfolgreich Planen Steuern Reporten bei der Einführung von SAP-Banking von Alberto Vivenzio, Domenico Vivenzio 1. Auflage Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Managed Testing Service

Managed Testing Service Managed Testing Service Skalierbare Testleistungen Von der Testtoolbereitstellung bis zum Testing vor Inbetriebnahme Qualitätssicherung von IT Services durch Testing muss verlässlich, transparent und kostenoptimiert

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Automatisiertes Testen von Prüfplätzen

Automatisiertes Testen von Prüfplätzen EXCO. The Quality Company Solutions for Industry and R&D Automatisiertes Testen von Prüfplätzen Am Beispiel einer Prüfplatz-Software stellen wir einen toolgestützten Prozess zur Erstellung der erforderlichen

Mehr

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

Mehr

INHALT. testoffice der Fehlerfänger für Ihre Software-Qualitätssicherung

INHALT. testoffice der Fehlerfänger für Ihre Software-Qualitätssicherung storybook SPIRIT-TESTING steht für eine standardisierte, optimierte Teststrategie und ein nachhaltiges Wirtschaften mit den benötigten Ressourcen. Über unsere Toolbox testoffice erzielen wir kontinuierlich

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

Effizienzsteigerung von Softwaretests durch Automatisierung

Effizienzsteigerung von Softwaretests durch Automatisierung Bachelorarbeit am Institut für Informatik der Freien Universität Berlin, Arbeitsgruppe Programmiersprachen Effizienzsteigerung von Softwaretests durch Automatisierung David Emanuel Diestel 04.02.2016 Übersicht

Mehr

MHP Test Management Qualität ist kein Zufall Ihre Lösung zur Abdeckung des ganzheitlichen Testprozesses!

MHP Test Management Qualität ist kein Zufall Ihre Lösung zur Abdeckung des ganzheitlichen Testprozesses! MHP Test Management Qualität ist kein Zufall Ihre Lösung zur Abdeckung des ganzheitlichen Testprozesses! Business Solutions 2015 Mieschke Hofmann und Partner Gesellschaft für Management- und IT-Beratung

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit.

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit. BEKA: Frankfurt, 25. Oktober 2012 T-Systems Angebot Umsetzung des globalen Telematikprojekts für den ÖPNV im Großherzogtum Luxemburg.

Mehr

Testen von Data-Warehouse- und Business-Intelligence-Systemen

Testen von Data-Warehouse- und Business-Intelligence-Systemen Edition TDWI Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte von Herbert Stauffer, Beat Honegger, Hanspeter Gisin 1. Auflage Testen von Data-Warehouse- und

Mehr

Modellbasierte Teststrategie in der Fahrzeugerprobung am Beispiel der car2go

Modellbasierte Teststrategie in der Fahrzeugerprobung am Beispiel der car2go Daimler Mobility Services 09.10.2013 Modellbasierte Teststrategie in der Fahrzeugerprobung am Beispiel der car2go Aachener Kolloquium Fahrzeug- und Motorentechnik 2013 Slavko Bevanda (Daimler Mobility

Mehr

Testen. SEPR Referat: Testen - Oliver Herbst

Testen. SEPR Referat: Testen - Oliver Herbst Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt

Mehr

Testkonzept. Tipp-Star

Testkonzept. Tipp-Star Tipp-Star Version: V1.0-27.09.2015 Ablageort: Tipp-Star/01_Projektmanagement/03_Test Status: Fertig gestellt (In Bearbeitung / fertig gestellt / geprüft / freigegeben) Anzahl Seiten: 9 Autoren: tse Sergeyeva

Mehr

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung

Testen II. (Management, Tools) Daniela Rose. Software Engineering Projekt WS07/08 Fachgebiet Softwaretechnik und Systemgestaltung Testen II (Management, Tools) Daniela Rose Fachgebiet Softwaretechnik und Systemgestaltung 12.12.2007 Gliederung 1. Motivation 2. Der grundlegende Testprozess 3. Testen im Softwareentwicklungsprozess 4.

Mehr

Einführung in die Softwareentwicklung

Einführung in die Softwareentwicklung Einführung in die Softwareentwicklung Thorsten Lemburg Universität Hamburg Seminar: Softwareentwicklung in der Wissenschaft 1 / 53 Einführung in die Softwareentwicklung - Thorsten Lemburg Gliederung 1.

Mehr

Was versteht man unter einem Softwareentwicklungsmodell?

Was versteht man unter einem Softwareentwicklungsmodell? Softwareentwicklung Was versteht man unter einem Softwareentwicklungsmodell? Ein Softwareentwicklungsmodell ist ein für die Softwareentwicklung angepasstes Vorgehensmodell bei der professionellen ( ingenieursmäßigen

Mehr

Testanalyse und Testautomation bei der ImmobilienScout24

Testanalyse und Testautomation bei der ImmobilienScout24 www.immobilienscout24.de Testanalyse und Testautomation bei der ImmobilienScout24 Stuttgart 02.10.2009 Katrin Jähn / Eric Hentschel Inhalt Ausgangssituation Motivation Projekt Ganzheitliche Teststrategie

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

Software - Testung ETIS SS05

Software - Testung ETIS SS05 Software - Testung ETIS SS05 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

Mehr

Test modellbasiert entwickelter Steuergeräte

Test modellbasiert entwickelter Steuergeräte Seite 1 von 31 26. Treffen der GI-Arbeitsgruppe Test, Analyse und Verifikation von Software Stuttgart, den 06.12.2007 Systematischer Test modellbasiert entwickelter Steuergeräte Dipl.-Ing. Matthias Wiese

Mehr

Unit Tests. Programmiermethodik. Eva Zangerle Universität Innsbruck

Unit Tests. Programmiermethodik. Eva Zangerle Universität Innsbruck Unit Tests Programmiermethodik Eva Zangerle Universität Innsbruck Überblick Einführung Java Ein erster Überblick Objektorientierung Vererbung und Polymorphismus Ausnahmebehandlung Pakete und Javadoc Spezielle

Mehr

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1.

Agile Testing. Der agile Weg zur Qualität. von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner. 1. Agile Testing Der agile Weg zur Qualität von Siegfried Tanczos, Martin Klonk, Richard Seidl, Helmut Pichler, Manfred Baumgartner 1. Auflage Hanser München 2013 Verlag C.H. Beck im Internet: www.beck.de

Mehr

CICERO.Test Datenbasierende Testautomatisierung für höchste Qualitätsansprüche

CICERO.Test Datenbasierende Testautomatisierung für höchste Qualitätsansprüche CICERO.Test Datenbasierende Testautomatisierung für höchste Qualitätsansprüche Ihre Software -Anwendung ist Ziel von Reklamationen? Die Qualität Ihrer Anwendung - eine Frage des Glaubens? Oder eine Frage

Mehr

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Sperrvermerk Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Bachelorarbeit Zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

ASIA Industrieautomation GmbH

ASIA Industrieautomation GmbH Der Aufwand zur Entwicklung, Realisierung und dem Austesten von sicherheitsgerichteter Anwendersoftware erfordert jahrelange Erfahrung und wird deshalb zumeist unterschätzt. Damit die geforderten e der

Mehr

Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung

Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung Fachliche Testautomatisierung, verbindet Test-Outsourcing mit Test-Virtualisierung Der Stammesverbund Inhaltsverzeichnis Software-Qualitätssicherung Fachliche Testautomatisierung Test-Outsourcing Test-Virtualisierung

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Testautomatisierung. Märchen, Möglichkeiten und praktischer Nutzen. Richard Seidl 21. Januar 2013 TU Dresden. Medizin- und Informationstechnik AG

Testautomatisierung. Märchen, Möglichkeiten und praktischer Nutzen. Richard Seidl 21. Januar 2013 TU Dresden. Medizin- und Informationstechnik AG Medizin- und Informationstechnik AG Testautomatisierung Märchen, Möglichkeiten und praktischer Nutzen Richard Seidl 21. Januar 2013 TU Dresden Kardiologische Funktionsdiagnostik Vitalfunktions-Monitoring

Mehr

Software Engineering II (IB) Testen von Software / Modultests

Software Engineering II (IB) Testen von Software / Modultests Testen von Software / Modultests Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Programm-Tests Tests sollen zeigen, dass ein Programm das tut was es tun soll sowie

Mehr

arvato Heterogene Systemlandschaft

arvato Heterogene Systemlandschaft Verteiltes Testen heterogener Systemlandschaften Dr. Thomas von der Maßen Andreas Wübbeke Februar 2010 1 Inhalt 1 arvato services und das IT-Management im Bertelsmann-Konzern 2 3 Heterogene Systemlandschaft

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Abbildungsverzeichnis

Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1-1: Wirtschaftlichkeit (Kosten vs. Testintensität)... 2 Abbildung 1-2: Kostenexplosion der Fehlerbeseitigung im Entwicklungsverlauf... 3 Abbildung 2-1: Wasserfallmodell...

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt

Inhalt. 1 Einführungsveranstaltung. 2 Qualität kompakt Inhalt 1 Einführungsveranstaltung 1.1 Ziel der Veranstaltung Warum Qualität? Inhalt der Veranstaltung 1.2 Formaler Ablauf der Veranstaltung 1.3 Übungs- und Gruppeneinteilung 1.4 Bewertungskriterien mittels

Mehr

Kooperatives Testen Basis auch zur Testautomatisierung während der Softwareentwicklung. Dipl. Inform. Hans-Josef Eisenbach

Kooperatives Testen Basis auch zur Testautomatisierung während der Softwareentwicklung. Dipl. Inform. Hans-Josef Eisenbach Kooperatives Testen Basis auch zur Testautomatisierung während der Softwareentwicklung Dipl. Inform. Hans-Josef Eisenbach Der rote Faden Motivation zum Testen während der Softwareentwicklung Das Testkonzept

Mehr

Übungen Softwaretechnik I

Übungen Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 2: Vorgehensmodelle IAS-Vorgehensmodell Motivation Probleme Die

Mehr

Was ist SAM? Warum brauche ich SAM? Schritte zur Einführung Mögliche Potentiale Fragen

Was ist SAM? Warum brauche ich SAM? Schritte zur Einführung Mögliche Potentiale Fragen Software Asset Management (SAM) Vorgehensweise zur Einführung Bernhard Schweitzer Manager Professional Services Agenda Was ist SAM? Warum brauche ich SAM? Schritte zur Einführung Mögliche Potentiale Fragen

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann. Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE)

Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann. Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE) Synergieeffekte der formalen QS von Geschäftsprozessen Referent: A. Peter Zimmermann Unser Testprozess hat den LEVEL 4 nach ISO / IEC 15504 (SPICE) superdata auf einen Blick Produkte FIT Testverfahren

Mehr

Softwarequalitätssicherung

Softwarequalitätssicherung Softwarequalitätssicherung Dipl. Inf. Andrea Meyer Medieninformatik (Bachelor), Wahlpflichtmodul: Softwareprojekt II, Dipl. Inf. Andrea Meyer Warum Softwarequalitätssicherung? 2 Fatale Softwarefehler Ariane

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Testen heute und in der Zukunft Ergebnisse der ersten unabhängigen Marktstudie für 6 Länder

Testen heute und in der Zukunft Ergebnisse der ersten unabhängigen Marktstudie für 6 Länder Testen heute und in der Zukunft Ergebnisse der ersten unabhängigen Marktstudie für 6 Länder Rudolf van Megen, CEO SQS Software Quality Systems AG Hamburg, 15. November 2007 SQS Software Quality Systems

Mehr

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Uwe Hehn TAV Februar 2005 Hochschule Bremen Uwe.Hehn@methodpark.de Abnahmetest: Warum brauchen wir denn so etwas? Projektabnahme

Mehr

-Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Seite 1 DI Christian Eggbauer mobilkom austria

-Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Seite 1 DI Christian Eggbauer mobilkom austria Diese Diese Kommentarfelder Kommentarfelder können können Sie Sie über über das das Menü Menü Ansicht Ansicht -Kommentare ein-und ausschalten. -Kommentare ein-und ausschalten. Dies Dies ist ist die die

Mehr

Testmanagement. Dirk Tesche

Testmanagement. Dirk Tesche Testmanagement Dirk Tesche Agenda Einführung in die Thematik Testarten Testprozess Agile Methoden und Techniken Testautomatisierung Eingrenzung und Motivation Abbildung entnommen aus: www.campero.de Ziele

Mehr

SNP TEST MANAGEMENT. SNP The Transformation Company. SNP Test Pack. Test Manager SNP. Test Pack SNP. Pack SolMan Setup & Review.

SNP TEST MANAGEMENT. SNP The Transformation Company. SNP Test Pack. Test Manager SNP. Test Pack SNP. Pack SolMan Setup & Review. Test Manager L Defect Management Pack SolMan Setup & Review M S TEST MANAGEMENT The Transformation Company TEST PACK S TEST PACK M Einstieg und Grundlage zur Durchführung modulbasierter Tests von Migrationsobjekten

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG

Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG Agiles Testen - Ein Erfahrungsbericht Thomas Schissler / artiso AG Michael Lierheimer/ infoteam software AG Herausforderungen bei agilem Testen Klassische Projektstruktur Projektleiter Entwickler QS-Abteilung

Mehr

ISTQB Certified Tester Foundation Level Exam Übungsprüfung

ISTQB Certified Tester Foundation Level Exam Übungsprüfung BEMERKUG: Bitte nur eine Antwort auf jede Frage 1. Die statische Analyse kann höchstwahrscheinlich ICHT finden: (A) Die Verwendung einer Variablen bevor diese definiert wurde. (B) Unerreichbaren ( toten

Mehr

Praxiswissen Softwaretest - Testmanagement

Praxiswissen Softwaretest - Testmanagement Praxiswissen Softwaretest - Testmanagement Aus- und Weiterbildung zum Certified Tester Advanced Level nach ISTQB-Standard dpunkt.verlag 1 Einleitung 1 1.1 Basiswissen - komprimiert 4 1.2 Praxiswissen Testmanagement

Mehr

TESTPLAN

TESTPLAN <Projektname> Firma TESTPLAN ID Version Ersteller: ------------------- Vorgesetzter des Erstellers:

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Qualitätssicherungskonzept Web Annotation mit Fragment Ids Gruppe: swp12-9 Inhaltsverzeichnis 1. Dokumentationskonzept...2 1.1. Quelltexte...2 1.2. Änderungsdokumentation...4 1.3. Modellierungsdokumentation...4

Mehr

Mit Fehlerkennzahlen Software-Entwicklungsprozesse verbessern - Erfahrungen bei der IDG -

Mit Fehlerkennzahlen Software-Entwicklungsprozesse verbessern - Erfahrungen bei der IDG - Mit Fehlerkennzahlen Software-Entwicklungsprozesse verbessern - - Rainer Paasche (IDG) Oral Avcı (SQS) Universität zu Köln Lehrstuhl für Wirtschaftsinformatik, Prof. Dr. W. Mellis SQS Software Quality

Mehr

Qualitätsmanagement. Grundlagen

Qualitätsmanagement. Grundlagen Grundlagen Historie: Mit industriellen Massenproduktion erforderlich geworden (Automobilindustrie, Anfang des letzten Jahrhunderts); Qualitätsmanagement zunächst nur in der Fertigung Mitte des letzten

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

Mehr

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011 Programmieren I Martin Schultheiß Hochschule Darmstadt Wintersemester 2010/2011 1 2 Übersicht Testen ist eine der wichtigsten, aber auch eine der Zeitaufwändigsten Arbeitsschritte der Softwareentwicklung.

Mehr

EoL-Testautomation 2.0. Technische Beschreibung. DI Hans-Peter Haberlandner. Blumatix GmbH

EoL-Testautomation 2.0. Technische Beschreibung. DI Hans-Peter Haberlandner. Blumatix GmbH EoL-Testautomation 2.0 Technische Beschreibung DI Hans-Peter Haberlandner Blumatix GmbH EoL-Testautomation 2.0 Technische Beschreibung Die Herausforderung Die Software spielt im Bereich der Testautomation

Mehr

Testen im Software- Entwicklungsprozess

Testen im Software- Entwicklungsprozess Technologie-Event 2006 Testen im Software- Entwicklungsprozess W.Lukas, INGTES AG Was nicht getestet wurde, funktioniert nicht. -- R.Güdel (ca. 1998) Seite 2 Was sollen wir tun? Anomalien & Defekte von

Mehr

Stuttgarter Test-Tage 2011 Der Fluch des grünen Balkens in sehr großen Projekten

Stuttgarter Test-Tage 2011 Der Fluch des grünen Balkens in sehr großen Projekten main {GRUPPE} Seite 1 Jürgen Nicolai Geschäftsführender Gesellschafter Liebknechtstrasse 33 70178 Stuttgart Tel : 0711 2270225 Fax : 0711 2270497 Mail : j.nicolai@main-gruppe.de Web: www.health4j.de Stuttgarter

Mehr

2 Vorgehensmodelle in der Softwareentwicklung

2 Vorgehensmodelle in der Softwareentwicklung 2 Vorgehensmodelle in der Softwareentwicklung 2.1 Vorbemerkungen Aufgrund der Komplexität von Software-Produkten ist es nahezu unmöglich, allein durch Tests die Korrektheit bzw. die Fehlerfreiheit festzustellen.

Mehr

IT-Governance. Standards und ihr optimaler Einsatz bei der. Implementierung von IT-Governance

IT-Governance. Standards und ihr optimaler Einsatz bei der. Implementierung von IT-Governance IT-Governance Standards und ihr optimaler Einsatz bei der Implementierung von IT-Governance Stand Mai 2009 Disclaimer Die Inhalte der folgenden Seiten wurden von Severn mit größter Sorgfalt angefertigt.

Mehr

AUFBAU EINER TESTORGANISATION

AUFBAU EINER TESTORGANISATION AUFBAU EINER TESTORGANISATION ODER DIE GEISTER, DIE ICH RIEF... Software-Tester Forum Mittwoch, 16. November 2005 SWX Swiss Exchange, Convention Point Zürich Robin Heizmann, CS IT Quality Management 14.11.2005

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr