Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Projektübergreifendes Testmanagement am Beispiel des Produkts Quality Center in einem Finanzunternehmen Bachelorarbeit im Studiengang Informatik von Sinan Botros Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Dr. Matthias Becker Hannover, 18. August 2006
Erklärung Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbstständig und ohne fremde Hilfe verfasst habe und keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel verwendet habe. Hannover, 18.08.2006 Sinan Botros 2
Danksagung Ich bedanke mich bei Herrn Dipl.-Math. Thomas Flohr für die hervorragende Betreuung meiner Bachelorarbeit. 3
Inhaltsverzeichnis 1 Einführung... 6 1.1 Motivation... 6 1.2 Zielsetzung... 6 1.3 Vorgehensweise... 7 1.4 Struktur der Arbeit... 7 2 Systematisches Testen von Software... 8 2.1 Begriff und Ziel des Testens... 8 2.2 Arten von Tests... 8 2.3 Probleme und Fehler beim Testen... 9 2.4 Tätigkeiten beim Testen... 10 2.5 Dokumentation beim Testen... 12 3 Testen im Unternehmen... 13 3.1 Vorstellung des TestDirectors... 13 3.1.1 TestDirector-Struktur... 13 3.1.2 Analyse und Reports... 18 3.2 Rollenkonzept... 18 3.3 Ist-Zustand der Projekte im TestDirector... 19 3.4 Probleme beim Reporting... 20 4 Standardisierungskonzept... 21 4.1 Zweck der Standardisierung... 21 4.2 Ordnerstruktur und ordnende Attribute... 21 4.2.1 Test Plan... 22 4.2.2 Test Lab... 24 4.2.3 Defects... 28 4.3 Reporting... 31 4.4 Listenadministration... 32 4.5 Rechtekonzept... 33 5 Zielorientiertes Messen von Software... 34 5.1 Motivation... 34 5.2 Ziele des Software-Messens... 34 5.3 Software-Metriken... 35 5.4 Indikatoren... 36 5.5 Goal-Question-Metric-Ansatz... 38 5.5.1 Messplanung... 39 5.5.2 Messinstrumentierung... 43 5.5.3 Datenerfassung... 43 5.5.4 Datenanalyse... 43 6 Ableitung von Metriken nach der GQM-Methode... 44 6.1 Metriken für Tester... 45 6.2 Metriken für Entwickler... 46 6.3 Metriken für QS-Manager... 47 6.4 Metriken für Projektleiter... 49 6.5 Metriken für projektübergreifendes Reporting... 51 4
7 Projektübergreifendes Reporting... 53 7.1 Motivation zum Einsatz eines Reporting-Systems... 53 7.1.1 Verbesserung der Kommunikation... 53 7.1.2 Verbesserung der Dokumentation... 53 7.2 Voraussetzungen für den Einsatz eines Reporting-Systems... 54 7.3 Umsetzung eines Reporting-Systems... 54 7.4 Vorstellung des Quality Center Dashboards... 55 7.5 Beispielhafte Implementierung der Indikatoren... 58 Literaturverzeichnis... 62 Abbildungsverzeichnis... 63 Tabellenverzeichnis... 65 Anhang A... 66 5
1 Einführung 1.1 Motivation Das Unternehmen ist mit mehreren Tausend Mitarbeitern und Präsenzen in verschiedenen Bundesländern eins der größten Informationstechnologie-Dienstleister in der Finanz-Branche in Deutschland. Die zentralen Funktionen der Abteilung, in der diese Arbeit geschrieben wurde, sind die Sicherstellung der eingesetzten DV-Systeme im Gesamtzusammenhang aller Systeme unter Einhaltung der Ordnungsmäßigkeit und Prüfung der Datenverarbeitung und die Bereitstellung von Testsystemen und Testwerkzeugen. Darüber hinaus werden die Entwickler und Tester durch umfassenden Support und Schulungen bzgl. der Testsysteme und Tools unterstützt. Zur Dokumentation und Durchführung von Tests wird im Finanzdienstleister das Tool TestDirector der Firma Mercury 1 von über 90 Projekten verwendet (siehe Kapitel 3 Testen im Unternehmen). Der Finanzdienstleister legt großen Wert darauf, seinen Kunden ausreichend qualitativ gesicherte Anwendungssysteme zur Verfügung zu stellen. Eine der wichtigsten Maßnahmen, die zur Qualitätssicherung beiträgt, ist Testen. Deshalb müssen im Projektverlauf eine sehr große Anzahl von Tests durchgeführt und dokumentiert werden. Zur Unterstützung des Testprozesses wird der TestDirector im Finanzdienstleister als verbindliches Testfallverwaltungstool verwendet. Deshalb enthält der TestDirector eine sehr große Menge von Informationen über den Teststatus der Projekte. Die Ablagestruktur der Testfälle in den Projekten ist jedoch unterschiedlich, Attribute und Auswahllisten sind nur teilweise standardisiert. Auswertungen über den Teststatus können deshalb nur innerhalb eines Projektes mit genauer Kenntnis der projektspezifischen Ablagestruktur erstellt werden, sind jedoch von außen, z.b. durch die Integration und Abnahme, nicht nachvollziehbar. Diese Tatsache wurde durch eine interne Befragung bestätigt. Außerdem wird der Anspruch an TestDirector-Projekte immer größer, Anforderungsmanagement und Releasetest benötigen eine projektübergreifende standardisierte Sicht auf den Status der getesteten Anwendungen. Die projektübergreifende Sicht ist mit dem Quality Center Dashboard 2 realisierbar. Dies ist nur dann umsetzbar, wenn die Projekte eine einheitliche Struktur sowie einheitliche Attribute und Attributwerte aufweisen. Aus diesem Grund wurde die Entscheidung getroffen, ein Nutzungskonzept zur Standardisierung der TestDirector-Projekte zu erstellen. Dieses Konzept wird im Laufe dieser Arbeit vorgestellt (siehe Kapitel 4 Standardisierungskonzept) und stellt die Grundlage für die Erreichung des Ziels dieser Arbeit. 1.2 Zielsetzung Ziel dieser Arbeit ist, es zu ermöglichen, den Teststatus der TestDirector-Projekte anhand quantitativ bestimmbare Maßeinheiten, sog. Key Performance Indicators (KPIs), graphisch als Portlets im Quality Center Dashboard darzustellen. 1 Mercury ist einer der weltweit führenden Anbieter im Bereich Business Technology Optimization (BTO). Es wird Unterstützung in Form von Dienstleistungen und Software angeboten zur Optimierung der Qualität, Performance und Verfügbarkeit von Applikationen sowie beim Management von IT Kosten und Risiken. Weitere Infos im Internet unter www.mercury.com. 2 Beim Dashboard handelt es sich um ein Tool der Firma Mercury zur Visualisierung der Daten in Form von Diagrammen oder Tabellen. Es bietet die Möglichkeit, eigene Metriken für die Software-Güte zu konfigurieren und diese durch den gesamten Qualitätssicherungsprozess hinweg zu erfassen und zu verwalten. 6
Der erste Schritt ist die Erstellung eines Konzepts zur Standardisierung der Testdokumentation der TestDirector-Projekte. Anschließend wird nach der Goal-Question- Metric-Methode vorgegangen, um Indikatoren und Metriken zur Überprüfung des Teststatus der Projekte abzuleiten. Diese Metriken richten sich an die verschiedenen Nutzergruppen entsprechend des Rollenkonzepts im Finanzdienstleister (Tester, Entwickler, QS-Manager, Projektleiter). Schließlich sollen die Indikatoren, die sich insbesondere für projektübergreifendes Reporting eignen, hervorgehoben und einige exemplarisch im Dashboard implementiert werden. Diese Indikatoren präsentieren eine Gesamtübersicht über den Teststatus der Projekte. Durch Bereitstellung dieser Gesamtübersicht über alle Projekte wird es zukünftig den Verantwortlichen möglich sein, auf einen Blick die Mängel sofort zu erkennen und dementsprechend zu handeln. Auf Basis dieser Übersicht können dann Messungen durchgeführt werden, um quantitative Aussagen zu bestimmten Systemqualitäten zu erhalten und den Fortschritt der Projekte zu kontrollieren. 1.3 Vorgehensweise Mit der Analyse des Ist-Zustandes der TestDirector-Projekte werden die benötigten Attribute verifiziert und für besseres Reporting geeignete Ablagestruktur der Testfälle mit den Projektmanagern diskutiert und abgestimmt. Anhand der daraus resultierenden Ergebnisse wird das Standardisierungskonzept erstellt. Anschließend wird nach der Goal-Question-Metric-Methode (GQM) vorgegangen, um Metriken und Indikatoren für den Status der TestDirector-Projekte abzuleiten. Zum Abschluss wird das Reportingtool Dashboard vorgestellt und dort exemplarisch einige Indikatoren implementiert. 1.4 Struktur der Arbeit In dem ersten Kapitel wurden Ziele der Arbeit und der Finanzdienstleister vorgestellt. Das zweite Kapitel ist ein Einstieg in das Thema Testen. Anschließend behandelt das dritte Kapitel das Testen im Finanzdienstleister und stellt den TestDirector ausführlich vor. Die im Zuge dieser Bachelorarbeit erarbeiteten Ideen zur Standardisierung der Testdokumentation der Projekte werden im vierten Kapitel erläutert. Zielorientiertes Software-Messen und die GQ(I)M-Methode stellen den Inhalt des fünften Kapitels dar. Im sechsten Kapitel werden die abgeleiteten Metriken für die verschiedenen Rollen präsentiert. Projektübergreifendes Reporting am Beispiel des Reportingtools Dashboard wird Thema des siebten Kapitels sein. Abschließend folgt im achten und letzten Kapitel eine Zusammenfassung dieser Arbeit. 7
2 Systematisches Testen von Software Einen wichtigen Beitrag zur Qualitätssicherung in der Software-Entwicklung wird durch systematisches Testen von Software gewährleistet. Ziel dieses Kapitels ist, einen Überblick über das Thema Testen und die damit verbundenen Begriffe und Aktivitäten zu geben. 2.1 Begriff und Ziel des Testens Die Intuition der meisten Menschen entspricht der Vorstellung, ein System auszuprobieren und aus den resultierenden Ergebnissen und Beobachtungen zu folgern, ob es seine Funktionen erfüllt, d.h. es zu testen. In der Wissenschaft wird der Begriff Testen jedoch genauer definiert. In der Literatur werden oft folgende Definitionen gefunden: Testen ist die Ausführung eines Programms mit dem Ziel Fehler zu entdecken [1]. und Testen ist die Vorführung eines Programms oder Systems mit dem Ziel zu zeigen, dass es tut, was es tun sollte [2]. Auf den ersten Blick scheinen sich die beiden Definitionen zu widersprechen und es stellt sich die Frage, welche die korrekte ist. In der Tat beide. Es wird jedoch nicht vom Gleichen gesprochen. Im ersten Fall wird Testen als ein Prüfverfahren vorgesehen, bei dem Systeme oder Programme ausgeführt werden, um vorhandene Defekte und Fehler zu finden. In diesem Sinne ist ein Test erfolgreich, wenn es zu einem Ergebnis führt, das sich von den spezifischen Anforderungen des Systems unterscheidet. Im zweiten Fall dient das Ausführen des Programms dem Nachweis, dass die Vereinbarten Leistungen erbracht worden sind. Das Software-Produkt wird validiert und erprobt, ob es die von ihm erwarteten Funktionalitäten erfüllt. Hier spricht man auch von Abnahmetest. Andererseits ist nicht jede Ausführung eines Programms ein Test. Unabhängig von der Methode und dem Ziel gehört zu der Spezifikation eines Tests immer ein vordefiniertes Soll- Ergebnis, das mit dem Ist-Ergebnis zu vergleichen ist. Eine genauere Definition des Testens und dessen Ziel, die zusätzlich auf die Testdaten und die Testreferenz eingeht, ist in deutschen Normierungen [DIN] wie folgt eingeführt: Ziel des Software-Tests ist es, durch Ausführung des Testobjekts auf einem Rechner mit ausgewählten Testdaten in einer definierten Umgebung festzustellen, ob sich das Testobjekt in diesen Fällen so verhält, wie es eine definierte Testreferenz vorschreibt. Zur Prüfung einer Software existieren mehrere Verfahren. Der Software-Test besitzt aber einen entscheidenden Vorteil: Der Test ist in der Praxis das einzige Verfahren, mit dem die realen Einsatzbedingungen eines Software-Systems, zum Beispiel Zielrechner, Compiler und Betriebssystem, angemessen berücksichtigt und die dynamischen Eigenschaften des Systems, beispielsweise das Laufzeit verhalten und die durch den Zielrechner gegebene Rechengenauigkeit, geprüft werden können [4]. 2.2 Arten von Tests Beim Testen wird immer ein bestimmtes Ziel verfolgt. Durch das Ziel wird festgelegt, auf welche Aspekte die Testfälle ausgelegt werden. In [6] werden im Wesentlichen folgende Testarten unterschieden: Fehlertest: Das Ziel beim Fehlertest ist die Aufdeckung der evtl. versteckten Fehler in einem Softwaresystem bevor dies an den Kunden ausgeliefert wird. Dabei wird versucht, ein unkorrektes Verhalten des Systems auszulösen um Fehler zu erkennen. 8
Die wesentliche Arbeit beim Fehlertest ist die Auswahl von Eingabedaten, die mit hoher Wahrscheinlichkeit ein Fehlverhalten auflösen. Funktionstest: Eine andere Bezeichnung dafür ist Black-Box-Test, da das System wie eine Black Box ist, dessen Verhalten nur durch die Eingaben und die dazugehörigen Ausgaben untersucht wird. Dabei wird also nur die Funktion betrachtet und nicht die Art der Implementierung. Eine Funktion ist in der Regel die kleinste, beim Tests gesondert zu prüfende Programmeinheit. Eine Funktion ist also eine Software- Komponente, die innerhalb des Software-Systems eine spezielle, abgrenzende Aufgabe erfüllt. Die Funktionstests werden auf Grundlage der Spezifikation erstellt. Diese Tests sollen gewährleisen, dass die an das System gestellten Anforderungen erfüllt werden. Integrationstest: Beim Funktionstest werden die einzelnen Systemkomponenten untersucht. Werden durch die Integration mehrere Teile zusammengeführt, so muss beim Testen auch speziell auf das Zusammenspiel und die Schnittstellen zwischen diesen Teilen geachtet werden. Das Ziel des Integrationstest ist, die durch diesen komplexen Prozess aufgedeckten Fehler aufzufinden. Da die einzelnen Komponenten aufeinander zusammenwirken, ist es in der Regel schwierig, die Fehlerquelle zu identifizieren. Deshalb ist es ratsam, den Integrationsprozess inkrementell durchzuführen. Zunächst wird eine möglichst kleine Anzahl von Komponenten integrieret und getestet. Bei erfolgreichem Test werden neue Komponenten hinzugefügt und erneut getestet. Abnahmetest: Das Ziel des Abnahmetests ist zu zeigen, dass das System bei der Ausführung vordefinierter Abnahmetestfälle die Anforderungen bzw. Bedürfnisse des Auftraggebers erfüllt. Abnahmetest werden hauptsächlich in der Endphase des Projekts auf einer realen Umgebung des Auftraggebers durchgeführt. 2.3 Probleme und Fehler beim Testen Eine wesentliche Aufgabe beim Testen besteht darin, die Testdaten auszuwählen. Eine Schwäche des Tests ist, dass nur für die ausgewählten Daten nachgewiesen werden kann, dass das Testobjekt gemäß der Spezifikation keine Abweichungen aufweist und keine Fehlfunktionen enthält. Dijkstra (1972) beschreibt, dass Testen nur die Anwesenheit von Fehlern zeigen kann, aber nicht die Abwesenheit. Nur ein vollständiger Test mit allen Eingabewerten und allen möglichen Kombinationen kann die absolute Korrektheit eines Software-Programms nachweisen. In der Praxis kann so ein Test aufgrund von sehr großen Anzahl von Testfällen und die dafür benötigte Zeit nicht durchgeführt werden. Davon abgesehen, dass es bei einigen Fällen eine unendliche Anzahl von Eingabewerten geben kann. Ein anderes Problem tritt auf, wenn die Ist- und Sollergebnisse nicht korrekt ermittelt werden. Weicht nach der Testdurchführung das Soll- vom Ist-Ergebnis aus, so liegt nicht immer tatsächlich eine Fehlerwirkung des Testobjekts vor, da auch andere Faktoren wie z.b. Fehler in der Testspezifikation oder im Testfall selbst Ursache für eine beobachtete Differenz sein können. Zusätzlich können die Testergebnisse falsch interpretiert werden und so nicht fehlerhafte Funktionen als solche angesehen werden. 9
2.4 Tätigkeiten beim Testen Im Folgenden wird Testen durch die Testaktivitäten und ihr Zusammenwirken veranschaulicht. Abbildung 2.1 [4] zeigt eine graphische Darstellung dieser Aktivitäten. Die gegenseitige Beeinflussung wird durch die Pfeile dargestellt. Die Planung, Organisation und Dokumentation beziehen sich auf die Gesamtheit aller zu prüfenden Testobjekte. Die weiteren Tätigkeiten beziehen sich auf ein einzelnes Testobjekt. Abbildung 2.1: Testaktivitäten und ihr Zusammenwirken In Anlehnung an Systematisches Testen von Software [4] werden folgende Testtätigkeiten definiert: Die erste Tätigkeit, die sich auf ein Testobjekt bezieht ist die Testfallermittlung. In einem Testfall wird eine bestimmte Eingabekonstellation festgelegt, mit der das Testobjekt getestet werden soll. Die Testfälle werden in der Regel aus Anforderungen bzw. Spezifikationen abgeleitet. Das Ziel dabei ist Identifizierung von Testfällen, mit denen nachgewiesen werden kann, dass die System-Funktionen vorhanden und ausführbar sind. Die 10
Testfälle behandeln sowohl das Normalverhalten als auch das Ausnahmeverhalten des Systems. Bei der Testdatengenerierung werden den Testfällen konkrete Testdaten zugewiesen. Da die Anzahl der möglichen Eingabewerte sehr hoch ist, wird aus jedem Wertebereich ein Repräsentant ausgewählt. Bei der Bestimmung von Sollergebnissen werden zu jedem Testfall die Ausgangswerte aus der Testreferenz, i. A. der Anforderungsspezifikation oder des Software-Entwurfs, abgeleitet. Die Ermittlung des Sollergebnisses beim Testen hat eine sehr entscheidende Bedeutung, denn das Ergebnis eines Testfalls kann nur dann als erfolgreich bezeichnet werden, wenn ein gültiges Referenzergebnis zur Verfügung steht und anhand dessen das Fehlverhalten des zu testenden Objekts erkannt werden kann. Bei der Testdurchführung wird das Testobjekt mit den entsprechenden Eingabedaten ausgeführt. Voraussetzung dafür ist die Bereitstellung des zu testenden Systems. Dabei sind die Testergebnisse, d.h. die Ausgabewerte, die das Testobjekt generiert, in geeigneter Form festzuhalten. Um die Überwachung des Testablaufs werden durch Hard- oder Software realisierte Funktionen zur Verfügung gestellt. Dadurch wird während der Testdurchführung eine Aufzeichnung des Programms ermöglicht (Monitoring). Bei der Testauswertung werden die Testergebnisse, die bei der Testdurchführung erzeugt wurden, also das Ist-Verhalten, mit den in der Testspezifikation vordefinierten Sollergebnissen verglichen. Anhand dessen wird festgestellt, ob sich das System wie gewünscht verhält oder Fehler aufweist. Falls Abweichungen zwischen dem Ist- und Sollverhalten festgestellt werden, so ist als erstes zu überprüfen, ob das auf die getestete Software zurückzuführen ist und keine anderen Faktoren wie ungenaue Testspezifikation oder fehlerhafte Testfälle dafür verantwortlich sein könnten. Liegt tatsächlich ein Fehler vor, so wird dieser an den Entwickler gemeldet und die Behebung des Fehlers priorisiert. Nach der Behebung des Fehlers muss das Testobjekt erneut getestet werden bis der Testfall erfolgreich verläuft. Die Testplanung ist eine projektübergreifende Testaktivität. Dabei werden die Testobjekte, die zu testenden Merkmale, die Kriterien zur Auswahl der Testfälle sowie die Abbruch- und die Wiederaufnahmekriterien festgelegt. Weiterhin sind die Testfälle zu priorisieren und die Reihenfolge der Durchführung zu definieren. Ziel dabei ist, dass die kritischen Teile des Systems zuerst getestet werden. Darüber hinaus muss die Testumgebung, die Hardware- und Softwarekonfiguration einschließlich Betriebssystem festgelegt werden. Schließlich werden die für die Testdurchführung benötigte Zeit, Testpersonal sowie deren Aufgaben und Verantwortlichkeiten bestimmt. Im Rahmen der Testorganisation werden die Testfälle, Testdaten und die Testergebnisse verwaltet. Zu dem wird festgelegt, ob und welche Testunterstützungswerkzeuge eingesetzt werden. Weiterhin wird die Art der Dokumentation und die Speicherung der Testdaten festgelegt. Dies ist von entscheidender Bedeutung um Tests wiederholen zu können. Damit können Tests, die einen Fehler im System aufgedeckt haben, erneut ausgeführt werden um zu entscheiden, ob die Behebung des Fehlers erfolgreich war oder nicht. Eine sehr wichtige Testaktivität für die vorliegende Arbeit ist die Testdokumentation. Diese wird im nächsten Teilabschnitt ausführlich beschrieben. 11
2.5 Dokumentation beim Testen Um Tests systematisch auszuführen, müssen sie vorher sorgfältig geplant und vorbereitet werden. Diese Tätigkeiten erfordern einen großen Ressourcen- und Zeitaufwand. Deshalb sollte der größtmöglichen Nutzen aus diesem Aufwand gezogen werden. Die Dokumentation von Tests ist von zentraler Bedeutung für diesen Nutzen [5]. Die Dokumentation enthält die geplanten Testfällen sowie die beim Ausführen resultierten Ergebnissen. Auch bei der Beschreibung der Testfälle und bei der Testdurchführung können Fehler auftreten. Werden diese aber dokumentiert, so kann die Dokumentation selbst geprüft werden und die Fehler nachvollzogen werden. Die meisten Software-Programme sind an den Bedürfnissen der Kunden ausgerichtet und werden damit mit der Zeit aktualisiert und angepasst. Dabei muss erneut eine hohe Anzahl von Tests evtl. nur mit geringen Veränderungen durchgeführt werden. Die Dokumentation kann diesen Aufwand deutlich verringern und die Wiederholbarkeit von Testfällen sicherstellen. Werden Beim Testen Fehler entdeckt, so kann der Entwickler mit der Hilfe der Dokumentation den gleichen Testfall unter gleichen Bedingungen in gleicher Testumgebung wiederholen um den Fehler zu lokalisieren und zu beheben. Deshalb ist es nur dann sinnvoll, Programme zu testen, die unter Konfigurationskontrolle stehen. Denn nur so kann die getestete Version des Programms wiederhergestellt werden. Die Testdokumentation besteht aus mehreren Teilen. Dazu gehört der Testplan, die Beschreibung der Testfälle, die Testdaten und die Bedingungen, unter denen die Tests durchgeführt wurden sowie die Testergebnisse und die Dokumentation der evtl. gefundenen Fehler. Bei mittleren oder großen Projekten ist die Anzahl der durchzuführenden Testfällen und die damit verknüpften Testdokumenten so hoch, dass allein die Verwaltung dieser Dokumente einen großen Aufwand erfordert. Aus diesem Grund werden Testdokumentationswerkzeuge eingesetzt um den Testdokumentationsprozess zu unterstützen. An dieser Stelle ist noch mal darauf hinzuweisen, dass im Finanzdienstleister das Testdokumentationstool TestDirector als verbindliches Tool zur Dokumentation von Tests verwendet wird (siehe Kapitel 3 Testen im Finanzdienstleister). 12
3 Testen im Unternehmen Der Finanzdienstleister ist sich über die Bedeutung des Testens im Klaren und legt sehr großen Wert darauf, seinen Kunden ausreichend getestete und qualitativ gesicherte Anwendungssysteme anzubieten. Um den Testprozess und die Tester bei ihren Aktivitäten zu unterstützen, setzt der Finanzdienstleister den TestDirector als verbindliches Werkzeug zur Testüberstützung ein. 3.1 Vorstellung des TestDirectors Der TestDirector ist ein webbasiertes Tool zur Dokumentation, Verwaltung und Durchführung von Testfällen. Darüber hinaus unterstützt der TestDirector die Erfassung und Verfolgung des Status von Anforderungen und Defects 3. Zusätzlich können (halb-)automatisch Statistiken und Analyse-Reports über den aktuellen Status des Testprozesses generiert werden. 3.1.1 TestDirector-Struktur Der TestDirector besteht aus folgenden vier Komponenten: 1. REQUIREMENTS Anforderungen des Kunden werden zunächst in RequisitePro 4 erfasst. RequisitePro hat eine Schnittstelle zum TestDirector. Nächtlich findet eine Synchronisation statt, sodass alle Anforderungen in den TestDirector-Beriech REQUIREMENTS übertragen werden. Im TestDirector werden den Anforderungen Testfälle zugeordnet. Jede Anforderung hat dann abhängig vom Status der ihr zugeordneten Testfälle ihren eigenen Status. Werden einer Anforderung keine Testfälle zugeordnet, so hat diese Anforderung den Status Not Covered. Sonst ist der Cover-Status einer Anforderung der Ausführungsstatus der damit verknüpften Testfälle. Siehe Ausführungsstatus eines Testfalls in Tabelle 4.3. Zur besseren Übersicht und effizienteren Verwaltung werden die Anforderungen in einer hierarchischen Struktur abgelegt. Siehe Abbildung 3.1. Abbildung 3.1: Anforderungs-Struktur und Status in einem TestDirektor-Projekt 3 In der Terminologie des Unternehmens sind Defects Abweichungen, Fehler oder Fehlverhalten in einem Programm, die während des Testens erkannt werden. 4 Bei RequisitePro handelt es sich um ein Anforderungsmanagementtool der Firma IBM Rational, das im Unternehmen zur Unterstützung des Anforderungsmanagements eingesetzt wird. 13
Weiterhin können jeder Anforderung zusätzliche Attribute zugeordnet werden, wie z.b. Priority für die Angabe der Priorität, mit der diese Anforderung umgesetzt werden soll, oder Type zur Beschreibung des Anforderungstyps, z.b. funktional oder nicht funktional. Siehe Abbildung 3.2. 2. TEST PLAN Abbildung 3.2: Attribute einer Anforderung Die Erstellung und Beschreibung der Testfälle geschieht im Bereich TEST PLAN. Die Testfälle können in einer hierarchischen Struktur abgelegt werden. Jeder Testfall besteht aus mehreren Schritten. In jedem Schritt werden die Eingangs- und die erwarteten Ausgangsdaten beschrieben. Siehe Abbildung 3.3. Abbildung 3.3: Testfall-Struktur und Beschreibung eines Testfalls 14
Einem Testfall können eine Menge von Attributen angehören wie z.b. Status, das den momentanen Status des Testfalls angibt und darüber informiert, ob der Testfall in der Beschreibungsphase Design oder Bereit zum Ausführen Ready ist. Siehe Abbildung 3.4. Abbildung 3.4: Attribute eines Testfalls Zusätzlich können verschiedene Arten von Dokumenten oder Bildern einem Testfall unter Attachments angehängt werden. Unter Regs Coverage kann einem Testfall eine oder mehrere Anforderungen zugeordnet werden. 3. TEST LAB Im Bereich TEST LAB findet die Testausführung statt. Zunächst werden die einzelnen Testfälle zu einem so genannten TestSet zusammengefasst. Ein TestSet besteht aus einem oder mehreren Testfällen, die in einer logischen Reihenfolge ausgeführt werden. Um verschiedene Testszenarien abzubilden, können die Testfälle in mehreren TestSets unterschiedlich kombiniert werden. Die Aufteilung der einzelnen TestSets in einer Baumstruktur erlaubt eine flexible Zusammenstellung der TestSets je nach Release, Teststufe oder Anwendung. Siehe Abbildung 3.5. Abbildung 3.5: TestSet-Struktur und Status in einem TestDirektor-Projekt 15
Einem TestSet können verschiedene beschreibende Attribute angehören wie z.b. Close Date, das angibt, an welchem Datum diese Tests aufgeführt wurden. Siehe Abbildung 3.6. Abbildung 3.6: Attribute eines TestSets Auch einem TestSet können unter Attachments verschiedene Dokumente angehängt werden. 4. DEFECTS Werden während des Testens Abweichungen oder Fehler festgestellt, so werden diese vom Testdurchführenden als ein Defekt im Bereich DEFECTS erfasst und einem Bearbeiter zugeordnet. Darüber hinaus kann ein Defekt einem entsprechenden Testfall zugeordnet werden. Beim Erstellen eines Defekts können verschiedene Attribute zur besseren Beschreibung des Defekts gefüllt werden. Siehe Abbildung 3.7. Abbildung 3.7: Attribute eines Defekts 16
Eins der wichtigsten Attribute ist der Status eines Defekts. Beim Erstellen des Defekts wird der Status auf New gesetzt. Wird der Defekt vom Lösungsverantwortlichen z.b. aufgrund falscher Zuordnung abgelehnt, so setzt dieser den Status auf Rejected. Nimmt er den Defekt an, so setzt er den Status auf Open. Nach Behebung des Defekts wird der Status auf Fixed gesetzt. Falls die Lösung vom Defektersteller nicht akzeptiert wird, so setzt dieser den Status auf Not accepted. Der Lösungsverantwortliche dokumentiert dann die erneute Annahme durch den Status Reopen. Wird der Defekt erfolgreich behoben und die Lösung akzeptiert, ist der Status auf Closed zu setzen. Siehe Abbildung 3.8 [3]. New Rejected Open Reopen Fixed Not accepted Closed Abbildung 3.8: Lebenszyklus eines Defekts als Aktivitätsdiagramm 17
3.1.2 Analyse und Reports In allen Bereichen des TestDirectors (REQUIREMENTS, TEST PLAN, TEST LAB, DEFECTS) können Standard-Reports in Form von Graphen oder Diagramme über den aktuellen Status eines TestDirector-Projekts erstellen werden. Mit Graphen wird eine Fortschrittanalyse der Daten auf Zeitbasis gezeigt. Eine Zusammenfassung der Datenbereiche kann als Diagramm dargestellt werden. Abbildung 3.9 zeigt ein Beispiel-Report für den aktuellen Stand der Defects bzgl. Status und Priorität in einem TestDirector-Projekt. 3.2 Rollenkonzept Abbildung 3.9: Beispiel-Report in einem TestDirector-Projekt Zur Administration und Nutzung des TestDirectors im Finanzdienstleister werden verschiedene Gruppen mit unterschiedlichen Rechten definiert. Im Folgenden eine Zusammenfassung der Aufgaben und Verantwortlichkeiten der für diese Arbeit relevanten Gruppen: TDAdmin: Dieser Gruppe gehört nur der technische User admin der TestFactory an. Er ist für die Einrichtung von TestDirector Repositories und die zentrale Benutzereinrichtung verantwortlich. Defect_Bearbeiter: Die Angehöriger dieser Gruppe haben ausschließlich eine Sicht auf den TestDirector-Bereich DEFECTS und dort nur eingeschränkte Modifikationsrechte. 18
Tester: In dieser Gruppe haben die Benutzer alle Rechte außer Löschen auf alle TestDirector- Bereiche. Im Allgemeinen werden folgende Rollen dieser Gruppe zugeordnet: Tester, Entwickler, Qualitätssicherer oder Integratoren und Abnehmer. Projekt_Manager: Diese Gruppe hat alle Rechte auf die TestDirector-Bereiche und zusätzliche Rechte zur Administration eines TestDirector Projektrepositories. Dieser Gruppe werden i.a. folgende Rollen zugeordnet: Projektleiter und Projektmanager. 3.3 Ist-Zustand der Projekte im TestDirector Momentan werden durch die Testfacotry keine Vorgaben oder Empfehlungen gegeben, wie die Ablagestruktur der Testfälle im TestDirector aussehen soll. So ist es jedem Projekt überlassen, die eigene Ordnerhierarchie in den Bereichen TEST PLAN und TEST LAB zu bestimmen. Demzufolge sind die Reihenfolge und die Anzahl der Ebenen sowie die Kriterien zur Gliederung der Objekte in den Projekten völlig unterschiedlich. Abbildung 3.10 zeigt beispielhaft die Strukturen von drei TestDirector-Projekten. In a) wird nach Teststufe, dann nach Release und Anwendung gegliedert. Bild b) zeigt eine Gliederung nach Release, Testart, Baseline und Team. In Bild c) wird eine Gliederung nach Anwendung, Release, Betriebssystem und Testart gezeigt. Abbildung 3.10: Strukturen von drei TestDirector-Projekten Außerdem sind die Attribute in den Projekten bzgl. Reihenfolge und Bestimmung von obligatorischen Feldern unterschiedlich. Einige Projekte enthalten zusätzliche Attribute, die in anderen Projekten nicht verwendet werden. Abbildung 3.11 a) und b) zeigt beispielhaft die Attribute im Bereich DEFECTS in zwei TD-Projekten. Formatiert Abbildung 3.11: a) Attribute im Bereich DEFECTS in einem TestDirector-Projek 19
Abbildung 3.11: b) Attribute im Bereich DEFECTS in einem anderen TestDirector-Projekt Auch die Attributwerte und Attributbezeichnungen sind nicht in allen Projekten einheitlich. Abbildung 3.12 zeigt die verschiedenen Werte des Attributes Priority in drei TestDirector- Projekten. Abbildung 3.12: Werte des Attributs Priority in drei TestDirector-Projekten 3.4 Probleme beim Reporting Um aussagekräftige Reports zu erstellen ist die genaue Kenntnis der projektspezifischen Ablagestruktur, der Attribute und deren Werte erforderlich. Eine Gesamtübersicht über den Teststatus von außen, z.b. aus Sicht der Integration und Abnahme, ist sehr schwer nachvollziehbar. Eine einheitliche Sicht über mehrere Projekte ist nicht möglich. Außerdem können die generierten Reports abweichende Ergebnisse vom tatsächlichen Status enthalten wenn einige Fälle nicht betrachtet werden wie z.b. das Verschieben von Testfällen in neuen Ordnern im jeweiligen Projekt oder das Kopieren und Einfügen von Testfällen zwischen verschiedenen Projekten. Solche Aktivitäten können zu Verlusten von Daten Führen wenn einige Attribute im neuen Projekt nicht existieren. Sind die Attribute physikalisch in verschiedener Reihenfolge gespeichert, so kommt es zu unkorrekten Zuordnung der Attributwerte. Demzufolge können die Statistiken keine korrekte Ergebnisse zeigen. Im TestDirector sind also eine große Menge von relevanten Informationen, die wegen fehlender einheitlicher Struktur nicht genutzt werden können, was ein großer Verlust für das Testmanagement darstellt. 20