Praktikum bei der Bibliotheca RFID Library Systems AG

Transkript

1 Praktikum bei der Bibliotheca RFID Library Systems AG Als Test Ingenieurin Praktikumsbericht Juli 2008 Unter der Aufsicht von: Prof. Dr. Jacques Pasquier-Rocha und Dr. Patrik Fuhrer Software Engineering Gruppe Software Engineering Gruppe Departement für Informatik Universität Freiburg (Schweiz)

2 Zusammenfassung Während drei Monaten habe ich mich als Praktikantin bei der Bibliotheca RFID Library Systems AG intensiv mit der Entwicklung eines Test Frameworks für die Durchführung von automatischen Tests an der BiblioSelfCheck Software beschäftigt. Dieses Softwareprodukt läuft auf Selbstverbuchungsstationen von Bibliotheken und bietet den Benutzern die Möglichkeit Bücher und andere Media selbstständig auszuleihen, zu verwalten und zurückzubringen. Mit dem von mir entwickelten Testframework können Testsequenzen, sprich Geschäftsprozesse, definiert werden und automatisch über die normale Benutzeroberfläche der BiblioSelfCheck Anwendung abgespielt und ausgewertet werden. Das Testframework steuert die Selbstverbuchungsstation quasi fern, speichert die durchgeführten Prozesse und untersucht diese auf Fehler. Das Testframework lag von Beginn bis zum Abschluss des Projektes in meiner Verantwortung. Ich arbeitete selbständig, konnte all mein Wissen und meine Ideen einbringen und in regelmässigen Abständen besprach ich mein Vorgehen mit Softwareentwickler und dem Chief Technology Officer (CTO). Neben diesem Hauptprojekt war ich tätig als allgemeine Testerin, Dokumentationsverfasserin und Trainerin an Produkteschulungen. Das Praktikum hat mir Zugang gewährt in den Arbeitsalltag eines Softwaretesters. Bald stellte ich grosse Unterschiede zwischen dem Arbeitsalltag und dem Universitätsleben fest. Egal an was gerade gearbeitet wird, das hektische Alltagsgeschäft drängt sich immer wieder in den Vordergrund. Ich habe viele positive Erfahrungen gemacht und auf fachlicher sowie menschlicher Ebene dazugelernt. Neben der guten Zusammenarbeit im Team bleibt mir allerdings hauptsächlich der Mangel an Ressourcen in Erinnerung. Während meines ganzen Praktikums fehlte es an Arbeitskräften und materiellen Ressourcen, aber auch das scheint für die Branche und den aktuellen Arbeitsmarkt typisch zu sein. Stichwörter: Praktikum, Software Testing, Test Automation Framework, AutoIt v3 I

3 Inhaltsverzeichnis Zusammenfassung... I Inhaltsverzeichnis... II Abbildungsverzeichnis... III Abkürzungen... III 1 Einleitung Aufbau Bibliotheca RFID Library Systems AG Aufgaben Resultate Software Testing Testverfahren Testprozess und phasen Testautomation AutoIt Test Framework Überblick Projektphasen Verbesserungsmöglichkeit Gelernte Lektionen Andere Tätigkeiten Testen Dokumentation Interne Schulungen Erworbene Kompetenzen und Kenntnisse Fachliche Fähigkeiten Allgemeine Fähigkeiten Wissenschaftliche Fähigkeiten Fazit AutoIt Test Framework RFID Bibliotheca Library Systems AG Literaturverzeichnis Webresourcen II

4 Abbildungsverzeichnis Abb. 1.1 AutoIt Test Framework [Dober 2008, S.2]... 3 Abb. 3.1 Softwareentwicklungsprozess in Form einer Spirale nach Boehm (1988) Abb. 5.1 AutoIt Engine - GUI mode Abkürzungen bez. Bibliotheca BSC d.h. DLL GUI RFID z.b. beziehungsweise Bibliotheca RFID Library Systems AG BiblioSelfCheck das heisst Dynamic Link Library Graphical User Interface Radio-frequency identification zum Beispiel III

5 1 Einleitung Im Rahmen meines Masterstudiums in Wirtschaftsinformatik an der Universität Freiburg, absolvierte ich vom 1.April bis am 30.Juni 2008 ein Wahlpraktikum als Test Ingenieurin bei der Bibliotheca RFID Library Systems AG. Dieser Praktikumsbericht bietet einen Überblick über meine Tätigkeiten und Erfahrungen während dieser interessanten und lehrreichen Zeit. Dies ist keine exakte Dokumentation der Praktikumsresultate. Das AutoIt Test Framework, das Hauptresultat des Praktikums, wird in [Dober, 2008] detailiert beschrieben. 1.1 Aufbau Dieser Praktikumsbericht ist wie folgt aufgebaut. Die Einleitung gibt einen groben Überblick über die Firma, die Aufgaben und die Resultate. Kapitel 2 Software Testing bietet hauptsächlich Hintergrundinformation zum Thema Software Testing, welches das Hauptthema meines Praktikums war. In den Kapitel 3 AutoIt Test Framework und 4 Andere Tätigkeiten werden meine Tätigkeiten bei der Bibliotheca RFID Library Systems AG beschrieben. Anschliessend fasst Kapitel 5 die erworbenen Kompetenzen und Kenntnisse zusammen. Ein Fazit des Praktikums wird im letzen Kapitel gezogen. 1.2 Bibliotheca RFID Library Systems AG Während zwei Jahren ging ich neben dem Studium einer Teilzeitarbeit als Test Ingenieurin und technische Redakteurin bei der Bibliotheca RFID Library Systems AG (nachfolgend Bibliotheca genannt) in Cham nach. Anschliessend an die letzten Vorlesungen und Prüfungen an der Universität erhöhte ich mein Arbeitspensum und absolvierte mein Wahlpraktikum bei dieser Firma. Bibliotheca RFID Library Systems ist Spezialist in Entwicklung, Herstellung und Marketing von Soft- und Hardware zur Automatisierung, Inventarisierung und Mediensicherung in Bibliotheken. Mit über 300 installierten Projekten ist das Schweizer Unternehmen europäischer Marktführer; weltweit positioniert sich das Unternehmen auf Platz zwei. [Biblio08] Weiterführende Informationen zur Firma sind auf der Firmenwebseite [Biblio08] zu finden. 1.3 Aufgaben Während meinem Praktikum war ich hauptsächlich als Test Ingenieurin und Softwareentwicklerin tätig. Innerhalb des Test Teams war ich verantwortlich für die Erstellung eines Test Frameworks für die Durchführung automatischer Tests an der BiblioSelfCheck Software. Die BiblioSelf- Check Applikation ist eines von mehreren Softwareprodukten von Bibliotheca, sie läuft auf Selbstverbuchungsstationen von Bibliotheken und bietet den Bibliothekskunden die Möglichkeit Bücher und andere Medien selbständig auszuleihen, zu verwalten und zurückzugeben. Mein Praktikum beinhaltete die komplette Abwicklung des Projektes Test Framework für Biblio- SelfCheck. Von der Design- und Analysephase bis hin zur Produktschulung und Einführung gehörte alles zu meinem Aufgaben. Die Grobspezifikation des Frameworks wurde aufgrund von 1

6 mir schon durchgeführter Automationsprojekte bei Bibliotheca erstellt. Auch die verwendeten Entwicklungswerkzeuge waren von früheren Projekten gegeben. Da ich mit dem Umfeld vertraut war, bekam ich sehr viel Entscheidungs- und Gestaltungsfreiheit. Mit meinem Vorgesetzten bei Bibliotheca, der gleichzeitig auch der Auftraggeber war, traf ich mich regelmässig um Status und weiteres Vorgehen zu besprechen. Auf diese Weise herhielt ich regelmässig mündliche Anweisungen zu Änderungen und Ergänzungen am Test Framework. Die durchgeführten Aufgaben an dem AutoIt Test Framework sind in der folgenden Auflistung in chronologischer Abfolge zusammengefasst und in Kapitel 3 AutoIt Test Framework ausführlich beschrieben: Die Analyse der bestehenden Testfälle der BiblioSelfCheck Software und die Entscheidung welche Testfälle vollständig automatisiert werden können. Erstellung der Spezifikation für das AutoIt Test Framework anhand der Testfälle, die zu automatisieren sind. Definition der Schnittstellen zwischen allen beteiligten Komponenten. AutoIt Test Framework entwickeln. Test Input (Test Sequenzen, Konfigurationen, Medien und Benutzer) erstellen für die Testfälle, welche in der Analyse als vollständig automatisierbar bewertet wurden. AutoIt Test Framework testen und allfällige Korrekturen vornehmen. Alle notwendigen Dokumentationen zur Benutzung und Weiterentwicklung des Frameworks erstellen. Das Bibliotheca Test Team für das AutoIt Test Framework schulen und das Framework einführen. Zusätzlich zur Hauptauftrag hatte ich immer wieder kleine Aufgaben zu erledigen, die aus dem Alltagsgeschäft heraus entstanden. Beschrieben sind diese im Kapitel 4 Andere Tätigkeiten. 1.4 Resultate Das AutoIt Test Framework für die BiblioSelfCheck Software und die Dokumentation dazu ist das Hauptresultat, das aus dem Praktikum hervorgeht. Eine Übersicht des Test Frameworks bietet Abb Alle blau eingefärbten Komponenten gehören zum Test Framework. Die grünen Komponenten stellen die Bibliotheca Anwendungen dar, welche mit dem Framework getestet werden. Eine detaillierte Übersicht und genaue Beschreibungen der einzelnen Komponenten ist in der Framework Beschreibung [Dober, 2008] zu finden. Diese Dokumentation ist als wesentliches Resultat des Praktikums diesem Bericht im Anhang angefügt. [Dober, 2008] beinhaltet zudem Informationen zur Entwicklung, Weiterentwicklung und Benutzung des Frameworks. 2

7 Abb. 1.1 AutoIt Test Framework [Dober 2008, S.2] 3

8 2 Software Testing Die Basis zur Erstellung des Test Frameworks für automatische Tests sind Kenntnisse im Bereich Software Testing. Aus diesem Grund fasst dieses Kapitel alle für das Praktikum relevanten Punkte zum Thema Software Testing zusammen. In anderen Worten diese Kapitel beschreibt das nötige Hintergrundwissen zum Projekt AutoIt Testing Framework. Besonders fokussiert wird das Thema Testautomation. Was ist Software Testing überhaupt? Eine gute Übersicht zum Thema bietet die Webseite [Answers08]. Der Vielfältigkeit des Begriffes kann dieser kurze Praktikumsbericht nicht gerecht werden. Es wird allerdings versucht die für das Praktikum nötigen Grundlagen zu beschreiben. Zusammengefasst in ein paar Punkten heisst Software Testing: Fehler finden, d.h. Fehler systematisch und nachvollziehbar aufzudecken. Mit Validationen und Verifikationen die Korrektheit der Anwendung nachweisen. Überprüfen ob die spezifizierten Anforderungen und die implementierte Funktionalität übereinstimmen. Die Qualität einer Anwendung sicherstellen und erhöhen. Testen von qualitativen Eigenschaften wie Robustheit, Probabilität, und Benutzerfreundlichkeit. In der effektiven Durchführung der oben aufgelisteten Punkte des Software Testing liegen einige Herausforderungen, die unbedingt zu beachten sind und welche auch für das Testen der Biblio- SelfCheck Software zutreffen. Verschiedene Umgebungen (Software- und Hardwareumgebung). Unterschiedliche Konfigurationen (z.b. konfigurierbarer Funktionsumfang, Ablaufvarianten der Anwendung). Nicht funktionale Anforderungen, die in der Testumgebung nicht der Realität entsprechen können (z.b. die Anzahl der Benutzer einer Anwendung). Mehrsprachigkeit einer Anwendung; die Sprachvarianten und deren Darstellung im GUI. Schnell wird ersichtlich, dass man sich beim Software Testing einschränken und den Fokus auf das Machbare setzen muss. In jeden Software Testing Projekt stellt sich die Frage welche Möglichkeiten mit den vorhanden Ressourcen (Testpersonen, Zeit, Testmaterial und Testumgebung) abgedeckt werden können. Des Weiteren ist zu beachten, dass das Testen einer Anwendung in einer Testumgebung nie hundertprozentig der Realität entsprechen wird. Eine Software wird von Testern und den richtigen Benutzer verschieden bedient. Im Falle der hier zu testenden BiblioSelfCheck Anwendung ist der Tester immer ein Experte, der die Software gut kennt. Der reale Benutzer hingegen ist ein Laie, der die Anwendung ab und zu benutzt. Um die Anforderungen des Software Testing trotz den hohen Herausforderungen so optimal wie möglich erfüllen zu können braucht es in jedem Fall ein Testkonzept. Zu einem Testkonzept ge- 4

9 hören die Festlegung des Testumfang, der Vorgehensweise, der Ressourcen und eine Zeitplanung. In der Praxis gibt es viele Vorgehensweisen, d.h. Testverfahren zur Durchführung von Tests. In der Literatur z.b. [Rätzmann 2004] sowie im Internet z.b. [Answers08] werden diese Testverfahren ausführlich beschrieben. Der folgende Abschnitt gibt lediglich eine kurze Einführung in die für das Praktikum relevanten Testverfahren. 2.1 Testverfahren In diesem Abschnitt werden bei Bibliotheca angewandten Testverfahren in Bezug auf die Biblio- SelfCheck Software zusammengefasst. Bis anhin wurde sehr viel Ad-hoc-Testing betrieben. Aufgrund der Ressourcenknappheit und fehlenden Testkonzepten wurde versucht das Testing auf das Wichtigste zu beschränken. Jeder Entwickler testet die Anwendung ad-hoc, wenn er gerade daran am Arbeiten war. Vieles blieb so nicht getestet und nicht dokumentiert. Mit der kürzlichen Einführung eines kleinen Testteams kamen strukturiert manuelle und automatische Testverfahren dazu. Zu den automatisierten Testverfahren gehört der Langzeit-Test (Systemtest). Dieser testet ob die Anwendung über mehrere Wochen stabil läuft. Der Langzeit-Test analysiert sowohl den Speicherverbrauch als auch Online-/Offline-Aktivitäten der Anwendung. Die Programmlogik wird allerdings nicht getestet. Mit Hilfe dieses automatischen Langzeit-Tests konnte die BiblioSelf- Check Software stark verbessert werden. Viele Speicherlecks, Deadlocks und Leistungsprobleme konnten aufgedeckt und reproduziert werden. Das Hauptziel dieser automatisierten Systemtests ist das Testen der nichtfunktionalen Anforderungen wie z.b. Sicherheit, Robustheit, Geschwindigkeit und Zuverlässigkeit. Zusätzlich können externe Schnittstellen zu Hardwarekomponenten und anderer Softwarekomponenten auf ihre Konnektivität getestet werden. Zu den manuellen Testverfahren der Tests der BiblioSelfCheck Software gehören: Regressionstests, d.h. selektives wiederholtes Testen von Systemkomponenten zum Nachweis, dass die Modifikationen keine Auswirkungen auf die schon existierenden Funktionalitäten haben. Zu Regressionstests sagt (Rätzmann, S.51): Da Regressionstest nach jeder Programmänderung oder spätestens vor der Freigabe der nächsten Version wiederholt werden sollen, ist hier der Drang zum Automatisieren dieser Tests besonders stark. Smoketests, dies ist ein Minimalsatz an Regressionstests, die sich auf grundlegende Funktionen beschränken. Smoketests sind Positivtests, d.h. sie sollen nachweisen, dass eine bestimmte Funktionalität vorhanden ist und keine Fehler aufweist. Wenn die Smoketests fehlschlagen, wird eine Software nicht für weitere Tests freigegeben. Innerhalb von kurzer Zeit kann festgestellt werden, ob das Programm unter Gut-Wetter Bedingungen seinen Dienst tut. Mehr zu Smoke Tests in [Rätzmann 2004, S. 52]. Die Smoketests gelten bei Bibliotheca als minimale Abnahmetests, die testen ob das Verhalten den Anforderungen entspricht. 5

10 Integrationstests, die verifizieren das Zusammenspiel einzelner Softwarekomponenten. Im Falle der BiblioSelfCheck Anwendung beziehen sich diese Tests hauptsächlich auf die Integration von verschiedenen Hardwarekomponenten, dessen Treibersoftware und der BiblioSelfCheck Software. Quittungsdrucker, Benutzerkartenleser, Barcodeleser und Touchbildschirm sind Beispiele solcher Komponenten. Konfigurationstests. Die BiblioSelfCheck Software bietet hunderte von Konfigurationsparameter, die in tausenden von Kombinationen funktionieren müssen. Historisch bedingt, gibt es keine Standardkonfiguration der BiblioSelfCheck Anwendung. Jeder Kunde hat eine andere, kundenspezifische Konfigurationseinstellung. Bevor ein Software Update einem Kunden ausgeliefert wird, führt die Bibliotheca kundenspezifische Konfigurationstests durch. Auch diese Tests haben sollten automatisiert werden. Der grosse Zeitverlust beim Umstellen der Konfiguration könnte so vermieden werden. Bis auf die Integrationstests, besitzen die heutigen manuellen Tests von Bibliotheca grosses Potential für die Automation. Bevor allerdings im Detail auf die Testautomation eingegangen wird, beschreibt der nächste Abschnitt den bei Bibliotheca üblichen Testprozess und dessen Testphasen. 2.2 Testprozess und phasen Ob automatisiert oder manuell getestet wird, es gibt Testprozesse und Konzepte, die sich in der Praxis etabliert haben. Bei der Bibliotheca RFID Library Systems AG hält man sich für alle Tests an den einen Testprozess, welcher iterativ folgende Testphase durchläuft. Grundsätzlich fliesst das Testen von Software ein in den Softwareentwicklungsprozess und beginnt meistens nachdem die Entwickler an einem Program Änderungen oder Erweiterungen vorgenommen haben. 1. Planung Der erste wichtige Schritt in jedem Testprozess ist die Planung. Ad-hoc Testing oder anderes unkoordiniertes Testen führt nicht zu einer nachvollziehbaren Verbesserung der Softwarequalität und sollte deshalb vermieden werden. In der Planung werden Testfälle identifiziert, Testverfahren festgelegt und Ressourcen verplant. Im Idealfall liefert die Softwarespezifikation beziehungsweise der Anforderungskatalog die Grundlage für die Identifikation der Testfälle. 2. Testfälle definieren Sind die Testfälle identifiziert, so müssen sie genau definiert werden. Im Falle der Biblio- SelfCheck Applikation werden die Testfälle in einer Excel-Liste erfasst, welche laufend erweitert wird. Jeder Änderungsauftrag und Fehler erzeugt neue Testfälle. Zur Definition eines Testfalls gehören die folgenden Angaben: Name, Titel des Testfalls, Priorität, Voraussetzungen, Konfigurationen, Testbeschreibung, d.h. Ablaufschema des Testfalles, 6

11 Erwartetes Resultat, Angabe ob es ich um einen automatisierten oder manuellen Test handelt und Falls vorhanden Link zum Änderungsauftrag bez. Fehlerbericht des Testfalls 3. Testumgebung schaffen Die allgemein gültige Testumgebung ist definiert in den Systemanforderungen, welche zu Projektbeginn erstellt wurde und den Testern zur Verfügung steht. Durch den vielseitigen Einsatz der BiblioSelfCheck Applikation entstehen Systemvarianten und von Testfällen abhängige Konfigurationen. Deshalb müssen für jeden Test beziehungsweise jede Testgruppe die entsprechenden Konfigurationsdateien geschaffen und mit der Testfalldefinition abgelegt werden. 4. Testfälle durchführen Jetzt folgt das eigentliche Testen. Mit der Art des Tests (z.b. Konfigurationstests, Regressionstests oder Dauertests) wird bestimmt welche Testfälle auszuführen sind. Zur Ausführung gehören auch die Erstellung des Testprotokolls und die Dokumentation der Testresultate. 5. Resultate auswerten Nach der Durchführung der Tests, werden die Resultate ausgewertet. Nicht alle unerwarteten Ergebnisse sind auf Softwaremängel zurückzuführen und müssen deshalb gut analysiert und dokumentiert werden. Zur Auswertung gehört auch eine statistische Analyse. 6. Probleme melden und dokumentieren Entdeckte Mängel müssen am Ende der Tests über den Prozess der Fehler- und Änderungserfassung dokumentiert werden. So fliessen die Resultate der Tests in den Software-Entwicklungsprozess ein. 2.3 Testautomation Meine Hauptaufgabe während dem Praktikum war es ein Test Framework für Regressions- und Konfigurationstests der BiblioSelfCheck Software zu erstellen. Dieser Abschnitt dokumentiert das Hintergrundwissen der Testautomation. Software nach jeder Programmänderung zu prüfen ist Arbeit, die sich ständig wiederholt und sich deshalb zur Automation eignet. Dank Drittsoftware und besonderes geeigneten Programmier- bez. Skriptsprachen kann eine Automation fast bei jeder Software vorgenommen werden. Eine Testautomation soll in erster Linie einen Mehrwert gegenüber dem manuellen Software Testing generieren. Wenn von Testautomation die Rede ist, da wird deshalb als erstes daran gedacht, dass durch die Automation Zeit und Ressourcen gespart werden sowie, dass das Testen effektiver und effizienter wird. [Wieder, Giri 2007, S.338] kommen zum Schluss, dass sich aus der Automation von Workflow-basierten Tests viele Vorteile ergeben. Die Arbeitsleistung kann signifikant gesteigert werden. Ihre Experimente haben eine Verbesserung der Ausführzeit und der Kosten um mehr als 70% ergeben. Die Ausführung der Tests alleine deckt allerdings noch nicht die gesamten Aktivitäten, die bei der Testautomation beachtet werden sollten. 7

12 [Rätzmann, S. 273] besagt, dass für das einmalige Automatisieren eines Tests mit dem 10-fachen Aufwand der manuellen Testdurchführung gerechnet werden muss. Der Aufwand für die Wartung der automatisierten Testfälle liegt nach [Rätzmann, S. 273] pro Hauptversion der Software im Schnitt bei 30% des manuellen Testaufwands. Eine Testautomation wird damit erst nach einer gewissen Anzahl der Wiederverwendung zu einem Gewinn. Damit dies geschieht sollten nach [Rätzmann, S.47f] die folgenden Punkte beachtet werden: Testautomation muss erlernt werden und das Erstellen von automatischen Tests bedeutet zunächst einmal erhöhten Zeitaufwand. Das zu erlernende darf nicht unterschätzt werden. Testwerkzeuge sind kein Ersatz für Tester. Auch automatisch kann nicht alles getestet werden und es bedarf immer noch gute Teststrategien, um einem möglichst grossen Teil der Software zu testen. Automatische Tests müssen gepflegt werden, dazu dienen klare Verantwortlichkeiten und eine Versionsverwaltung für die Testdaten und Testsequenzen. Unbedingt auf eine dynamische Architektur der Automationssoftware und der Testfälle achten. Tests die einmal erstellt sind, sollten gültig bleiben und nicht nach jeder Version wieder verändert und angepasst werden müssen. Testautomatisierung kostet Zeit und Geld. Für den Fall der BiblioSelfCheck Software von Bibliotheca kann diese Liste mit dem folgenden Punkt ergänzt werden: Engere Zusammenarbeit von Tester und Softwareentwickler. Das Test Framework muss das zu testende Software Produkt ansteuern können und dazu braucht es klar definierte Schnittstellen. Zu tief sollte die Zusammenarbeit der Entwickler und Tester allerdings nicht sein, da sonst die Qualität und Objektivität der Tests darunter leiden könnte. Grosse Vorteile in der Testautomation sehe ich in der Tatsache, dass die Software für die Automation und die Testfalldefinitionen zwar von einem Experten erstellt werden müssen, diese dann aber von Testern mit relative wenig Wissen, benutzt werden kann. Einmal gestartet laufen die Tests 24/7 im Hintergrund. Erst bei der Auswertung der Resultate braucht es wieder die Anwesenheit eines Testers. 8

13 3 AutoIt Test Framework Die Bibliotheca RFID Library Systems AG vertreibt mehrere eigene Softwareprodukte und hat selbst limitierte Ressourcen für das Testen der Software. Dazu kommt, dass die einzelnen Softwareprodukte in sehr unterschiedlichen Konfigurationen bei Bibliotheca Kunden installiert sind. Alleine die BiblioSelfCheck Software besitzt mehrere hundert Konfigurationsparameter, welche theoretisch alle getestet werden müssten. Das Testen der Softwareprodukte ist komplex und aufwändig. Zur Bewältigung dieser Herausforderung entschied sich Bibliotheca einen Teil des Software Testing zu automatisieren. Vorerst begrenzt sich die Automation auf das Software Testing der BiblioSelfCheck Software. Die Automation hat zum Ziel die wichtigsten Testfälle zu definieren und diese anschliessend effizient auszuführen. Die Durchführung bestehender Testfälle kann beliebig wiederholt werden, einmal erstellte automatische Testfälle können immer wieder benutzt werden. Die Automatisierung geht so weit, dass sie von einem Tester manuell gestartet werden muss, danach über Stunden läuft und die Resultate in Logdateien festhält. Bestehende, manuell ausgeführte Testfälle dienten als Basis der automatisierten Tests. Mit den manuellen Tests hat das Testteam schon Erfahrungen und dank denen konnten die zu automatisierenden Testfälle optimal ausgewählt werden. Und genau dies ist wichtig für eine erfolgreiche Test Automation. [Kamer, Bach et al. 2004, Chapter5] schreibt zum Thema Test Automatisierung: Entwerfe deine Testfälle bevor entschieden wird welche Testfälle automatisiert werden. Dies verhindert, dass man mit der Automation in die Falle tritt indem einfach zu automatisierende Tests implementiert werden, diese aber schwach sind im Auffinden von Fehlern. Im AutoIt Test Framework wurden im Rahmen des Praktikums zuerst die Smoketests der Biblio- SelfCheck Software automatisiert. Gleichzeitig ist das Framework so konzipiert, dass später alle Regressions-Tests und die Konfigurations-Tests einfach in die automatisierte Testumgebung übergeführt werden können. Die Smoketests sind sie wichtigsten Tests, die nach jeder kleinen Änderung der Software durchgeführt werden. Dies ist so, weil als erstes bei Tests der Best Case getestet werden sollte. Das heisst, zuerst ist zu beweisen, dass ein Programm unter Gut-Wetter Bedingungen funktioniert. Erst wenn dies der Fall ist, kann ein Schritt weiter gegangen werden und die Software kann weitergehend getestet werden. Für die Automation dieser Tests ist vorgegeben, dass die bestehenden Werkzeuge bei Bibliotheca benutzt werden müssen, welche schon für die Erstellung der existierenden automatisierten Systemtests halfen. Die Entwicklungsumgebung ist klar definiert und kann im Rahmen der Praktikumsarbeit nicht geändert werden. Aus diesem Grund wird an dieser Stelle nicht auf die Entwicklungsumgebung eingegangen. Mehr dazu in [Dober 2008, Kapitel 8]. 3.1 Überblick Die Aufgabenstellung zum AutoIt Test Framework ist in der Einleitung Abschnitt 1.3 Aufgaben von diesem Dokument gegeben. Alle Fakten zum AutoIt Test Framework sind in der separaten 9

14 Bibliotheca Dokumentation [Dober, 2008] beschrieben. In diesem Praktikumsbericht wird deshalb möglichst wenig wiederholt und einfach auf die AutoIt Test Framework Dokumentation verwiesen. Die Framework Dokumentation AutoIt Test Framework for BiblioSelfCheck ist wie folgt aufgebaut: Einleitung Komponenten (graphische Übersicht Abb. 1.1) o BiblioSelfCheck o Bibliothek-System-Software o Virtueller RFID-Leser o Medien- und Benutzerkartensammlung o AutoIt Test Engine o Test Input (Testfälle, Testsequenzen, Konfiguration, virtuelle Medien und Benutzerkarten) o Datenbank o IST- und SOLL-Logdateien o Testresultat Zusammenfassung Wie wird ein neuer Testfall erstellt Wie wir eine Testsequenz durchgeführt Die Definition von Testsequenzen Technische Referenz der AutoIt Test Engine Entwickeln mit AutoIt v3 Bekannte Probleme Zukünftige Arbeit und Verbesserungen 3.2 Projektphasen Bei der Entwicklung des AutoIt Test Framework und all seinen Komponenten ging ich nach dem klassischen Spiralmodell nach Boehm vor (Abb. 3.1). Begonnen habe ich mit der Festlegung der Ziele für die Framework-Basis. In einem ersten Durchlauf schuf ich die Grundfunktionalitäten des Frameworks. Zunehmend wurden die Ziele (zu automatisierende Testfälle) und die Entwicklung komplexer, die durchlaufenen Entwicklungsphasen blieben allerdings immer dieselben. 10

15 Abb. 3.1 Softwareentwicklungsprozess in Form einer Spirale nach Boehm (1988) Die Grundfunktionalitäten der BiblioSelfCheck Software, wie beispielsweise das einfaches Ausleihen und Zurückbringen von Medien, waren schon nach wenigen Entwicklungszyklen vorhanden. Später kam dann die Handhabung von Testfällen wie Medien verlängern, Ausleihe mit einem Benutzerpasswort und der Quittungsdruck dazu. 3.3 Verbesserungsmöglichkeit Aus technischer Sicht gibt es einen Bereich im AutoIt Test Framework, der aus meiner Sicht grosses Verbesserungspotential besitz. Die Verbesserungsmöglichkeit liegt in den die Testfalldefinitionen, welche in INI Konfigurationsdateien abgelegt sind. Anstelle von INI Dateien könnten die Testfälle auch in XML Dateien definiert werden. Das würde mehrere Vorteile mit sich bringen. XML Dateien kann ein Schema hinterlegt werden und damit können sie auf eine gültige Struktur hin überprüft werden. Die Testfalldefinitionen könnten so vor dem automatischen Testen besser validiert und verifiziert werden. 11

16 3.4 Gelernte Lektionen Neben all den positiven Effekten der Testautomation, gibt es auch viele kritische Punkte, die während der Entwicklung des AutoIt Test Framework auftauchten. Lessons learned (gelernte Lektionen) in Software Testing heisst das Buch [Kaner, Bach et al. 2002]. In Kapitel 5 dieses Buches beschreiben die Autoren 40 gelernte Lektionen im Bereich der Testautomation. Sehr viele dieser Lektionen kamen mir beim Lesen bekannt vor. Sie entsprechen Erfahrungen, die ich im Zusammenhang mit dem automatischen Testen auch gemacht habe. Lektionen, die mir besonders wichtig erscheinen, oder meine Arbeit besonders betreffen, sind in diesem Abschnitt beschrieben nach [Kaner, Bach et al. 2002] und von mir kommentiert Trennung von Testdaten und Testausführung [Kaner, Bach et al. 2002, Lessons 130] Testdaten und das Programm für die Testausführung zu trennen, war im Fall des AutoIt Test Frameworks von Beginn weg vorgesehen. Diese Separation verringert die Komplexität einzelner Komponenten und bietet auch noch andere Vorteile. Verschiedene Tools und verschiedene Personen können in die Erstellung von Testsequenzen und die Testprogrammierung integriert werden. Jede integrierte Person kann sich auf ihr Spezialgebiet fokussieren und selbständig arbeiten Vermeide die Gleichstellung von manuellen und automatischen Tests [Kaner, Bach et al. 2002, Lessons 108] Bei automatischen Tests kann nicht auf taktisches Wissen, das Bewusstsein und die Programmkenntnisse von einer Testperson zurückgegriffen werden. Eine reelle Testperson hingegen kann Fehlalarme und auffällige Nebenerscheinungen problemlos registrieren. Automatische Tests sollten die manuellen Tests deshalb nicht ersetzen, sondern ergänzen Testautomation ist ein Softwareentwicklungsprozess [Kaner, Bach et al. 2002, Lessons 118] Dass die Testautomation ein richtiger Softwareentwicklungsprozess ist, habe ich schon bald nach dem Projektstart festgestellt. Bei der Testautomation entsteht grundsätzlich eine neue Anwendung, die genauso spezifiziert, dokumentiert und durchdacht sein muss, wie jede andere Software. Zu Beginn war mir dies zu wenig bewusst Automatisierte Regressionstests finden wenig Fehler [Kaner, Bach et al. 2002, Lessons 110] Das AutoIt Test Framework erstellte ich in erster Linie genau für diese automatisierten Regressionstests. Und wenn ich die Auswertungen der bisher ausgeführten Tests betrachte, dann stimmt die Aussage von [Kaner, Bach et al. 2002, Lessons 110]. Während der Testentwicklung wurden mehr Fehler gefunden, wie bei dem eigentlichen Testen. 12

17 Da die Regressionstests vom AutoIt Test Framework allerdings auch das komplexe Konfigurationsmanagement der BiblioSelfCheck Anwendung vereinfacht, bin ich überzeugt, dass sich die Automatisierung in diesem Fall trotzdem lohnte Schlechte Automation wird nicht bemerkt [Kaner, Bach et al. 2002, Lessons 112] Der Programmierer der Testautomation muss genauso mitdenken wie ein Tester bei manuellen Tests. Die Testabdeckung ist vielleicht schlecht, unabhängig von der Menge der Tests, die gemacht werden. Eventuell löst die Automation Fehlalarme aus. Und neue Funktionalitäten in der Software bedeuten auch neue Features in der Testumgebung Test Tools sind fehlerhaft [Kaner, Bach et al. 2002, Lessons 114] Da das Test Framework auch eine Softwareanwendung ist, und jede Software Fehler hat, haben auch die Test Tools selber Fehler. Während der Entwicklung des Test Frameworks erstellte ich auch diesem Grund ein spezielles Set an Testsequenzen, die nur das Test Framework selbst testen. 13

18 4 Andere Tätigkeiten Neben meiner Hauptaufgabe, das AutoIt Test Framework zu erstellen, beteiligte ich mich während dem Praktikum auch an anderen Tätigkeiten innerhalb des Technik- und Operationsteam bei der RFID Bibliotheca Library Systems AG. Meine zusätzlich ausgeführten Aufgaben werden in diesem Kapitel kurz beschrieben und kommentiert. 4.1 Testen Ich beteiligte mich aktiv an der Entwicklung und Verbesserung des Prozesses für die manuellen Tests verschiedener Softwareprodukte von Bibliotheca. Neben der Prozessentwicklung, - überwachung und der Testauswertung beteiligte ich mich selbst aktiv am Testen der BiblioSelf- Check Software und anderen kleineren Anwendungen. Das manuelle Testen half mir sehr bei der Erstellung des Test Frameworks. Anforderungen und viele Ideen der Umsetzung entstanden aus meinen eigenen Testaktivitäten. Auch wenn das manuelle Testen für mich nicht immer sehr interessant erschein, so war es schlussendlich doch sehr hilfreich für das Verständnis der BiblioSelfCheck Software und die Erstellung der automatischen Tests. 4.2 Dokumentation Die Softwaredokumentation für den Kunden wird in der RFID Bibliotheca Library Systems AG vom Technikteam selbst geschrieben und verwaltet. Meine Aufgabe war es die Englischen Benutzerdokumentationen, Installations- und Konfigurationsdokumentationen verschiedener Produkte auf dem aktuellsten Stand zu halten. Bei einzelnen Produkten war ich zusätzlich für die Deutschen Übersetzungen zuständig. Auch in meiner Verantwortung war die Verwaltung, Aktualisierung und Ergänzung der Sprachressourcen mehrere Softwareprodukte. Die Benutzeroberfläche der BiblioSelfCheck Software beispielsweise ist standardmässig in 15 Sprachen erhältlich. Das bringt mit sich, dass bei den meisten Änderungen an der Benutzeroberfläche die entsprechenden Ressourcen in 15 Sprachen gepflegt werden müssen. Bibliotheca verwaltet die Sprachressourcen in Excel Dateien und exportiert diese mit einem selbstentwickelten Tool in INI und UNI Konfigurationsdateien. Die Bibliotheca Softwareprodukte greifen dann über diese Konfigurationsdateien auf die Sprachressourcen zu. 4.3 Interne Schulungen In die Zeit des Praktikums fiel bei Bibliotheca auch eine interne Partnerschulung. Im Rahmen dieser Schulung gab es für mich verschiede kleinere Aufgaben zu erledigen. Zu diesen gehörten die Organisation und Mitgestaltung des technischen Teils der Partnerschulungen. Die Vorbereitung, Gestaltung und Erstellung der Schulungsunterlagen sowie die Vorbereitung und Durchführung der Abschlussprüfung. Die Mitarbeiterschulung für neue Verkaufsmitarbeiter übernahm ich teilweise vollständig. 14

19 Durch die Schulungen bekam mir einen breiten Einblick in die RFID Bibliotheca Library Systems AG. Bei diesen Aufgaben waren komplett andere Fähigkeiten gefragt, wie beim allen anderen Tätigkeiten. Dies machte mein Praktikum einerseits vielseitig und spannend, andererseits war dies aber auch eine grosse Herausforderung. 15

20 5 Erworbene Kompetenzen und Kenntnisse Durch das vielseitige Praktikum konnte ich meine praktischen Erfahrungen stark erweitern und erwarb viele neue Kenntnisse in verschiedenen Bereichen. Die Bibliotheca gewährte mir viele Freiheiten und liess mich sehr selbständig arbeiten. Die Ziele und Prioritäten meiner Haupttätigkeit, der Entwicklung des Test Frameworks, durfte ich selbst definieren. Die Zusatztätigkeiten brachten Abwechslung und zusätzliche Disziplinen wie Präsentieren und Projektmanagement ins Praktikum. Mit der Entwicklung des AutoIt Test Frameworks erwarb ich hauptsächlich Kompetenzen im Bereich der Softwareentwicklung und des Software Testings. Mit der Skriptsprache AutoIt v3 [AutoIt08] lernte ich eine weitere mächtige Skriptsprache für die Windows Umgebung kennen und konnte meine Programmierfähigkeiten erweitern. In den folgenden Abschnitten ist zusammengefasst welche fachlichen, allgemeinen und wissenschaftlichen Kompetenzen und Kenntnisse aus dem Praktikum resultieren. 5.1 Fachliche Fähigkeiten Software Testing ist ein Fachgebiet, das in der Praxis und in der Ausbildung tendenziell vernachlässigt wird. Meistens werden die Schwerpunkte Architektur, Design und Implementierung so stark gewichtet, dass für das Software Testing schlussendlich nur noch begrenzt Ressourcen zur Verfügung stehen. In meinem Praktikum beschäftigte ich mich 80% der Zeit mit dem Thema Software Testing. Dadurch habe ich einen tiefen Einblick in die Thematik bekommen. Ich konnte mir so Wissen aufbauen, das bei vielen Softwareentwicklern zu kurz kommt. Ich habe gelernt wie Software Testing anzugehen ist, auch wenn die Ressourcen knapp und die Komplexität des zu testenden Produktes hoch sind. Mit meiner Hauptaufgabe, dem Erstellen des AutoIt Test Frameworks, beinhaltete mein Praktikum neben dem Testing noch ein zweites grosses Thema: die Automatisierung und Simulation von Benutzerprozessen in der Benutzeroberfläche einer Anwendung in der Windowsumgebung. Für diese Aufgabe war die Skriptsprache AutoIt v3 [AutoIt08] vorgegeben. Mit Skriptsprachen hatte ich bis zum Praktikum wenig Erfahrung. Meine Kenntnisse aus den Lehrveranstaltungen im Bereich Software Engineering halfen mir beim Einstieg in das Thema. Ich war erstaunt wie viele der Prinzipien aus der Objekt Orientierten Softwareentwicklung auch für die Entwicklung mit einer Skriptsprache angewandt werden konnten. Auch über den Funktionsumfang von AutoIt v3 war ich erstaunt. Zu Beginn der Entwicklung des AutoIt Test Framework hatte ich ein AutoIt Command Line Tool, konnte damit die Maus fernsteuern, an gewünschten Stellen klicken und so das Benutzerverhalten simulieren. Das Endprodukt des AutoIt Test Framework ist eine richtige Softwareanwendung mit Benutzeroberfläche, Zugriff auf das Dateisystem im Hintergrund, DLLs von anderen Programmen und eine Datenbank. Die Möglichkeiten der Skriptsprache sind genauso mächtig wie jede andere Programmiersprache. Fachlich habe ich nicht nur eine Skriptsprache kennengelernt, mit ihr vertiefte ich auch meine Kenntnisse über das Windows Betriebssystem und seine Funktionalitäten vertieft. 16

21 5.2 Allgemeine Fähigkeiten Das Praktikum bot mir die Gelegenheit meine Kenntnisse im Bereich Organisation, Kommunikation und Projektmanagement zu benutzen und zu verbessern. Meine Ideen und Vorstellungen wurden immer angehört und mit kritischen Fragen und Tipps ergänzt. Es war sehr interessant die verschiedenen Vorgehensweisen und Methoden der einzelnen Teammitglieder kennen zu lernen und dann diese in meinem eigenen Projekt anzuwenden. Im Alltagsgeschäft der Bibliotheca lernte ich den praktischen Unterschied von strategischen und operativen Aufgaben kennen. Das war sehr bereichernd, da dies in den Lehrveranstaltungen der Universität immer wieder ein Thema ist, ich mir in der Praxis allerdings nichts vorstellen konnte darunter. Die Aufgabe, die Komplexität einer Problematik für den Endbenutzer zu verringern, forderte mich das ganze Praktikum durch immer wieder. Ich konnte meine Fähigkeiten Komplexität zu erkennen und zu verringern weiter entwickeln. Ein Beispiel dafür ist die Erkenntnis, dass in der Softwareentwicklung die Benutzerfreundlichkeit und Benutzerführung in einem Softwareprodukt besonders wichtig sind. Das AutoIt Test Framework ist auch ein Softwareprodukt. Zu Beginn wurde es entwickelt als Command Line Tool, nach einigen Tests mit zukünftigen Benutzer des Test Frameworks programmierte ich eine einfach zu bedienende Benutzeroberfläche zum Framework (Abb. 5.1). Der Benutzer hat Schaltflächen zum Starten, Pausieren und Beenden der Tests, sieht sofort die Log-Einträge und den allgemeinen Status des Testverlaufs. Obwohl mit dem GUI keine neuen Funktionen in das Test Framework eingebaut wurden, fiel es den Benutzern gleich viel leichter Test auszuführen. Abb. 5.1 AutoIt Engine - GUI mode 17

22 5.3 Wissenschaftliche Fähigkeiten Meine wissenschaftlichen Fähigkeiten baute ich im sehr praxisorientierten Praktikum nicht aus, aber ich konnte meine bisher an der Universität gewonnenen Kenntnisse sehr gut einsetzen. Das theoretische Wissen in den Bereichen Projektplanung, Analyse, Modellierung, Dokumentation sowie das gelernte strukturierte Vorgehen war eine grosse Unterstützung bei der Umsetzung meiner Haupt- und Zusatzaufgaben im Praktikum. 18

23 6 Fazit Die Schlussfolgerung ist aufgeteilt in zwei Abschnitte, die noch einmal die Erkenntnisse aus den beiden wichtigsten Bereichen des Praktikums zusammenfassen. Einerseits sind das die Erfahrungen aus dem Projekt AutoIt Test Framework und andererseits die Eindrücke aus der Arbeitswelt bei Bibliotheca. 6.1 AutoIt Test Framework Die selbständige Konzeption, Implementierung und Nutzung des Test Framework gewährte mir einen vielseitigen Einblick in die Themen Software Testing, Software Automation und Projektmanagement im Informatikumfeld. Neben den Entwicklungsarbeiten steckt hinter dem AutoIt Test Framework viel Koordinations- und Kommunktionsaufwand. Alle betroffenen Teams, das heisst das Testing- und Softwareentwicklungsteam sowie Benutzer und Firmenpartner mussten bei der Festlegung der Anforderungen und bei der Umsetzung mit einbezogen werden. Während der täglichen Arbeit stellte ich immer wieder fest, dass diese administrativen Arbeiten mehr Zeit als geplant beanspruchten. Schon vor dem Praktikum war mir bekannt, dass die Definition der Anforderungen, Dokumentationen in der Softwareentwicklung häufig vernachlässigt werden. Aus diesem Grund rechnete hielt ich mir immer genügend Zeit frei um diese Aufgaben zuverlässig durchzuführen. Durch das Praktikum wurde mir zusätzlich bewusst, dass auch die Administration und das Testing von den Zeitaufwänden her häufig unterschätzt werden. Das AutoIt Test Framework betrachte ich als ein gelungenes Projekt, welches jetzt benutzt werden kann, das Testteam entlastet und sich einfach mit weiteren Testfalldefinitionen und Testsequenzen erweitern lässt. Besonders schwierig gestaltete sich die Literatursuche zum Thema Testing und Testautomation. Es erfreut mich allerdings, dass mein Praktikumsthema auch ein aktuelles Forschungsthema zu sein scheint. [Wieder, Giri 2007] beschreiben in A Workflow-Based Test Automation Framework for Web Based Systems ganz ähnliche Konzepte, wie die hinter meinem AutoIt Test Framework. Auch sie bieten ein Framework zur automatischen Durchführung von Testfällen. 6.2 RFID Bibliotheca Library Systems AG Die RFID Bibliotheca Library Systems AG ist in der Softwareentwicklungsbranche ein Kleinbetrieb. Alle Softwareprodukte werden für die eigenen Hardware-Produkte entwickelt. Fünf bis sieben Softwareentwickler und ein bis zwei Tester sind für den gesamten Software Lebenszyklus verantwortlich. Von der Zusammenstellung von Anforderungen für ein neues Produkt bis zur Wartung älterer Produkte gehört alles zum Job eines Entwicklers. Das Arbeitsumfeld war dem entsprechend sehr dynamisch und fordernd. Dies alles ermöglichte mir einen spannenden und breiten Einblick in die Softwareentwicklung bei Bibliotheca. Die Zeit des Praktikums war für mich intensiv und lehrreich auf fachlicher, aber auch auf menschlicher Ebene. 19

24 Literaturverzeichnis Abran, Moore et al Dober, 2008 Kaner, Bach et al Rätzmann 2004 Wieder, Giri 2007 Guide to the Software Engineering Body Of Knowledge: SWEBOK, Alain Abran, James W. Moore, IEEE ComputerSociety, 2004 AutoIt BSC Test Framework,, Bibliotheca RFID Library Systems AG, Cham, 2008 Lessons Learned in Software Testing: A Context-Driven Approach, Cem Kaner, James Bach and Bret Pettichord, 2002 Software-Testing & Internationalisierung, Manfred Rätzmann, 2. Auflage, Galileo Press GmbH, Bonn, 2004 A Workflow-Based Test Automation Framework for Web Based Systems, Wieder D. Yu, Giri Patil, Computer Engineering Department, San Jose State Universtiy, California, 2007 Webresourcen Answers08 AutoIt08 Biblio08 Answers.com, verfügbar via zugegriffen am AutoIt v3, verfügbar via zugegriffen am Bibliotheca RFID Library Systems AG, verfügbar via zugegriffen am