Praktikum bei der Bibliotheca RFID Library Systems AG

Praktikum bei der Bibliotheca RFID Library Systems AG
Als Test Ingenieurin
Praktikumsbericht
Bettina Dober
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)
Praktikumsbericht
Bettina Dober
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
Praktikumsbericht
Bettina Dober
Inhaltsverzeichnis
Zusammenfassung ....................................................................................................................... I
Inhaltsverzeichnis........................................................................................................................ II
Abbildungsverzeichnis ................................................................................................................ III
Abkürzungen .............................................................................................................................. III
1 Einleitung ............................................................................................................................... 1
1.1
Aufbau ....................................................................................................................... 1
1.2
Bibliotheca RFID Library Systems AG........................................................................... 1
1.3
Aufgaben .................................................................................................................... 1
1.4
Resultate .................................................................................................................... 2
2 Software Testing .................................................................................................................... 4
2.1
Testverfahren ............................................................................................................. 5
2.2
Testprozess und –phasen ........................................................................................... 6
2.3
Testautomation .......................................................................................................... 7
3 AutoIt Test Framework........................................................................................................... 9
3.1
Überblick .................................................................................................................... 9
3.2
Projektphasen .......................................................................................................... 10
3.3
Verbesserungsmöglichkeit ........................................................................................ 11
3.4
Gelernte Lektionen ................................................................................................... 12
4 Andere Tätigkeiten ............................................................................................................... 14
4.1
Testen ...................................................................................................................... 14
4.2
Dokumentation ........................................................................................................ 14
4.3
Interne Schulungen .................................................................................................. 14
5 Erworbene Kompetenzen und Kenntnisse ............................................................................ 16
5.1
Fachliche Fähigkeiten ............................................................................................... 16
5.2
Allgemeine Fähigkeiten ............................................................................................ 17
5.3
Wissenschaftliche Fähigkeiten .................................................................................. 18
6 Fazit ..................................................................................................................................... 19
6.1
AutoIt Test Framework ............................................................................................. 19
6.2
RFID Bibliotheca Library Systems AG......................................................................... 19
Literaturverzeichnis................................................................................................................... 20
Webresourcen .......................................................................................................................... 20
II
Praktikumsbericht
Bettina Dober
Abbildungsverzeichnis
Abb. 1.1 AutoIt Test Framework [Dober 2008, S.2] ...................................................................... 3
Abb. 3.1 Softwareentwicklungsprozess in Form einer Spirale nach Boehm (1988) ..................... 11
Abb. 5.1 AutoIt Engine - GUI mode ............................................................................................ 17
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
Praktikumsbericht
Bettina Dober
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 BiblioSelfCheck 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 BiblioSelfCheck. 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
Praktikumsbericht
Bettina Dober
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. 1.1. 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
Praktikumsbericht
Bettina Dober
Abb. 1.1 AutoIt Test Framework [Dober 2008, S.2]
3
Praktikumsbericht
Bettina Dober
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 BiblioSelfCheck 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
Praktikumsbericht
Bettina Dober
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 BiblioSelfCheck 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 BiblioSelfCheck 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
Praktikumsbericht
•
Bettina Dober
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 BiblioSelfCheck 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
Praktikumsbericht
3.
4.
5.
6.
2.3
Bettina Dober
•
Erwartetes Resultat,
•
Angabe ob es ich um einen automatisierten oder manuellen Test handelt und
• Falls vorhanden Link zum Änderungsauftrag bez. Fehlerbericht des Testfalls
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.
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.
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.
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.
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
Praktikumsbericht
Bettina Dober
[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
Praktikumsbericht
Bettina Dober
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 BiblioSelfCheck 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
Praktikumsbericht
Bettina Dober
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:
3.2
•
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
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
Praktikumsbericht
Bettina Dober
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
Praktikumsbericht
3.4
Bettina Dober
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.
3.4.1
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.
3.4.2
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.
3.4.3
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.
3.4.4
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
Praktikumsbericht
Bettina Dober
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.
3.4.5
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.
3.4.6
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
Praktikumsbericht
Bettina Dober
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 BiblioSelfCheck 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
Praktikumsbericht
Bettina Dober
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
Praktikumsbericht
Bettina Dober
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
Praktikumsbericht
5.2
Bettina Dober
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
Praktikumsbericht
5.3
Bettina Dober
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
Praktikumsbericht
Bettina Dober
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
Praktikumsbericht
Bettina Dober
Literaturverzeichnis
Abran, Moore et al. 2004
Dober, 2008
Kaner, Bach et al. 2002
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, Bettina Dober, 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
http://www.answers.com/software%20testing, zugegriffen am
28.06.2008
AutoIt v3, verfügbar via
http://www.autoitscript.com/autoit3/index.shtml, zugegriffen am
30.06.2008
Bibliotheca RFID Library Systems AG, verfügbar via
http://www.bibliotheca-rfid.ch, zugegriffen am 28.06.2008
20