Einführung einer integrierten Werkzeugkette

Testmanagementlösung: Der Teufel liegt im Detail
Kommentare

Seit jeher gilt: Hohe Softwarequalität erfordert ein hochwertiges Testmanagement. Doch weil Entwicklungsprojekte in puncto Umfang und Komplexität heutzutage immer anspruchsvoller werden, muss auch das Testmanagement neuen Anforderungen genügen. Dieser Artikel ist ein Anwendungsbericht über den Einsatz einer durchgängigen Werkzeugkette zur optimalen Unterstützung des Tests und des anforderungsbasierten formalen Nachweises der Funktionalität eines komplexen Systems im Rahmen eines Luftfahrtprojekts.

Gemäß den vertraglichen Vereinbarungen galten hinsichtlich der Systementwicklung während des beschriebenen Luftfahrprojekts folgende Rahmenbedingungen:

Das zu entwickelnde System (Abb. 1) ist gemäß V-Modell in mehrere hierarchische Stufen aufgeteilt. Es besteht aus einer Anzahl von Subsystemen, die sich ihrerseits aus verschiedenen HWCIs (Hardware Configuration Items) und CSCIs (Computer Software Configuration Items) zusammensetzen lassen. Von Ebene zu Ebene sind die Anforderungen miteinander verbunden und sollen im Anschluss an die Integration den auf der jeweiligen Stufe erforderlichen Tests unterzogen werden. Die Testaktivitäten lassen sich in informelle und designbasierte Tests einteilen. Darüber hinaus werden Aktivitäten zum formalen Nachweis der Systemanforderungen gegenüber dem Auftraggeber durchgeführt.

Abb. 1: Dekomposition des Systems

Abb. 1: Dekomposition des Systems

Bei der Fülle der zu liefernden unterschiedlichen Testdokumente für die jeweilige Teststufe zählt die Unterstützung der automatisierten Erstellung zu den größten Herausforderungen. Die Lieferdokumente schließen den gesamten Testmanagementprozess ein, beginnend mit der Testplanung, dem Schreiben und Ausführen von Testprozeduren in unterschiedlichen Testumgebungen sowie dem Erstellen von Testreports auf der Basis der ausgewerteten Ergebnisse. Wesentlichster Aspekt ist dabei die Einhaltung der Projektvorhaben hinsichtlich der Dokumentenstruktur (Testplanung, Testprozedur, Testreport), die im hier betreffenden Bereich sehr hohen inhaltlichen und formellen Ansprüchen genügen müssen. Zusätzlich sollen zur Steuerung der Testplanung und -ausführung geeignete Metriken zur Verfügung stehen, die eine bestmögliche Einflussnahme der gesamten Testmanagementprozesse erlauben und unterstützen sollen.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.


Lösungsarchitektur mit OSLC und REST

Vor der Einführung der neuen Werkzeugkette von IBM Rational gab es Herausforderungen zu bewältigen – verursacht durch die Verwendung nicht integrierter Tools. In den Zeiten, in denen Testdokumente teilweise manuell erstellt und verwaltet wurden, zog das einen erhöhten Pflege- und Aktualisierungsaufwand nach sich. Bei dieser Vorgehensweise bestand stets das Risiko, dass die Dokumente die realen Daten in den Tools nicht korrekt widerspiegelten, beispielsweise wenn eine Anforderung an das System sich änderte, der zugehörige Testfall jedoch nicht aktualisiert wurde. Ein Risiko, welches bei dem im Projekt gewählten iterativen/inkrementellen Entwicklungsprozess natürlich größer wird, da die Systemanforderungen beim Testplanungsprozess noch Änderungen unterliegen können.

Der erste Eckpfeiler der angewendeten IBM-Rational-Lösung ist der Einsatz einer offenen, modernen, webbasierten Integrations- und Kollaborationsplattform namens Jazz (Abb. 2). Jedes Werkzeug der Jazz-Plattform bietet seine Funktionalität durch Open-Services-for-Lifecycle-Collaboration-Schnittstellen (OSLC) an. Wie im Internet werden die Objekte auf dieser Plattform – seien es Anforderungen in IBM Rational DOORS oder Testartefakte im IBM Rational Quality Manager – durch eindeutige URLs identifiziert und können durch OSLC-Dialoge erzeugt, geändert oder gelöscht werden, und zwar toolübergreifend. Anforderungen, die in IBM Rational DOORS gespeichert sind, können deswegen nahtlos von Testern mit Testplänen und Testfällen im IBM Rational Quality Manager verlinkt werden, ohne dass das Testmanagementwerkzeug verlassen werden muss. Werden während der Ausführung von Tests Fehler entdeckt, kann der Tester einen Defekt erzeugen. Dieser Defekt wird von IBM Rational Team Concert – der Change-Management-Lösung der Toolkette – gemanagt und ist mit dem Testfall verbunden. Die Navigation in dieser Toolkette geschieht nahtlos wie im Internet durch das Verfolgen von Links.

Abb. 2: Solution-Architektur

Abb. 2: Solution-Architektur

Ein zweiter Eckpfeiler der Lösung ist die Verwendung von REST-Services für ein werkzeugübergreifendes Reporting. REST-Services sind ebenfalls webbasiert und geben auf Basis von URLs (z. B. für Anforderungen, Testpläne, Testfälle, Testergebnisse und Defekte) Daten zurück. Diese Daten werden vom Dokumentengenerierungswerkzeug – der IBM Rational Publishing Engine – verwendet, um gemäß Projektvorgabe Microsoft-Word-Dokumente in der geforderten Form zu generieren. Über REST-Services können darüber hinaus Daten in ein so genanntes „Data Warehouse“ importiert und zur Statusangabe der Artefakte und entsprechendem Trend Reporting mithilfe von IBM Rational Insight bereitgestellt werden.

Testmanagement mit IBM Rational Quality Manager

In diesem Abschnitt sollen die Vorteile der implementierten Lösung hinsichtlich des Testmanagementprozesses genauer beleuchtet werden.

Zentrales Element für das Testmanagement ist der Testplan (=Englisch für Testkonzept gemäß ISTQB), der im IBM Rational Quality Manager durch eine gleichnamige Datenstruktur repräsentiert wird (Abb. 3). Jeder Testplan wird nach seiner Erzeugung zunächst mit einem oder mehreren Requirements-Modulen in IBM Rational DOORS verbunden, in denen jeweils eine spezielle Sicht (View) auf die im Rahmen der Durchführung dieses Testplans nachzuweisenden Anforderungen existiert. Wie eingangs erwähnt, kann es sich bei den Anforderungen beispielsweise um die eines Subsystems oder eines CSCI/HWCI handeln.

Abb. 3: Testmanagement

Abb. 3: Testmanagement

Im jeweiligen Testplan werden nun die Testcases (=Testfälle) erzeugt, die zum Nachweis der konkreten Anforderungen herangezogen werden, die in der mit dem Testplan verbundenen View enthalten sind. Jeder Testcase kann mittels Anwendung eines Testskripts, welches manuelle oder automatisierte Testschritte enthält, zur Ausführung kommen und erzeugt anschließend ein Ergebnis (Test-Execution-Record/-Result).

Der IBM Rational Quality Manager erlaubt durch die Repräsentation verschiedener Zustände (draft, review, approved) seiner Artefakte (Testplan, Testcase, Testscript) die Unterstützung eines implementierungsbegleitenden Reviewprozesses. Darüber hinaus kann die Ermittlung der Anzahl der Testfälle eines Testplans im jeweiligen Zustand zu einer aussagekräftigen Metrik in der Phase des Testcase-Designs verwendet werden. Oder es ist – gemäß den Erfordernissen im Projekt – die Anzahl bereits erfolgreich getesteter Anforderungen zu einem bestimmten Zeitpunkt zu liefern (Abb. 4).

Abb. 4: Metriken zur Überdeckung von Anforderungen

Abb. 4: Metriken zur Überdeckung von Anforderungen

Neben der Anwendung administrativer Einstellung bei der Einführung des IBM Rational Quality Manager (Nutzer, Projektarea, Dashboards) war es jedoch von besonderer Wichtigkeit, gleich zu Beginn die Struktur der Artefakte im Hinblick auf die Erfordernisse der Dokumentenerstellung festzulegen (Abb. 5). So wurde zunächst bei den verschiedenen Testplänen unterschieden, ob sie für informelle, designbasierte Tests oder zum formalen Nachweis der Systemanforderungen genutzt werden sollten.

Abb. 5: Aufbau der Artefakte (Testplan, Testcase)

Abb. 5: Aufbau der Artefakte (Testplan, Testcase)

Bei den Testfällen wurde besonderes Augenmerk auf die Struktur gelegt, da die dort verwalteten beschreibenden Daten für die spätere Generierung eines Testplandokuments zu verwenden sind (Abb. 6). Für die Darstellung der Inhalte eines Testfalls wurden die folgenden Kategorien verwendet, die zur zusätzlichen Konfiguration hinzugezogen werden können:

  • Testobjectives (=Pass-Fail Criteria)
  • Testmethode (Demonstration, Test, Analyse, Inspektion)
  • Testarea (Servicegruppe des SUT)
  • Test-Use-Case (Anwendungsfall der Servicegruppe)
  • Testlevel (CI, Subsystem, Entity)

Bei den zur Speicherung der Testergebnisse zu verwendenden Testcases Execution Records (TCER) flossen die Information des SUT (=System under Test) mit der jeweiligen Softwareversion (1.0, 2.0) ein. Das TCER diente darüber hinaus zum Vergleich der erzielten Testergebnisse (Integration Test, Dry-Run, FAT) unter Berücksichtigung der zur Ausführung verwendeten Testumgebung.

Das Werkzeug – der IBM Rational Quality Manager – erlaubt es zudem, die Ergebnisse leicht und schnell in Dashboards zu visualisieren, um beispielsweise bei Test-Readiness-Reviews die Resultate eines Dry-Runs präsentieren zu können.

Dokumentengenerierung mit IBM Rational Publishing Engine

Die Erstellung von Dokumenten ist nicht nur ein wichtiges Thema für Kunden im Compliance-Umfeld, sie ist generell ein „Must“. Dokumente dienen als Nachweis für die interne Qualitätssicherung und sind unerlässlich für Auftraggeber und Auftragnehmer, wenn es um das Erreichen von Projektmeilensteinen geht. Testdokumente beinhalten oft eine Vielfalt von Informationen: die zu testende Anforderungen, assoziierte Testpläne/-fälle, Testergebnisse (zu einer gewissen Iteration in einer speziellen Testumgebung) und natürlich entdeckte Fehler. Die Verwendung einer nicht integrierten Toolchain erschwert die Erstellung solcher informationsübergreifenden Reports erheblich, weil die Daten in verschiedenen, nicht miteinander verbundenen „Töpfen“ versteckt sind und der Zugriff auf sie teilweise nicht mit denselben Werkzeugen erfolgen kann.

Die Verwendung der IBM-Rational-Lösung ändert dies. Alle Inhalte und Verknüpfungen der Testartefakte können für die Dokumentengenerierung durch ein einheitliches Werkzeug – die IBM Rational Publishing Engine – herangezogen werden.

Ein weiterer Faktor, der die Dokumentengenerierung erschweren kann, sind Reportinganforderungen, die beim Aufsetzen und der Anpassung des Tools nicht von vorneherein berücksichtigt worden sind. Aus diesem Grund wurden im Projekt frühzeitig die im vorangegangenen Abschnitt erläuterten Anpassungen der Artekfakte (Testplan, Testcase) vorgenommen, damit die Vorgaben hinsichtlich der Dokumentenstruktur entsprechende Berücksichtigung fanden.

Abb. 6: Testplan mit Master-Test-List

Abb. 6: Testplan mit Master-Test-List

Im Rahmen des Projekts wurde eine Vielfalt von Reports angefertigt wie zum Beispiel die Master Test List (Abb. 6), die eine Übersichtstabelle über sämtliche Testfälle, Testfalleigenschaften und verbundenen Anforderungen für einen konkreten Testplan lieferte. Weitere Reports wurden für die Erstellung der Testprozeduren (Testfälle, Testskript) und Testergebnisdokumente (Testfälle, Testskripts, Testergebnisse mit gefundenen Fehlern) erstellt, mit dem Resultat, dass die für die Generierung notwendige Zeit nun im Bereich weniger Minuten liegt.

Metriken mit IBM Rational Insight

Die Überwachung des Fortschritts ist ein wichtiger Aspekt eines jeden Testprojekts. Hierfür sind Metriken in Kombination mit Status und Trendreports von Nutzen. In der Planungsphase werden zum Beispiel Metriken ermittelt, um die Vollständigkeit eines Testplans zu überprüfen. Hier geht es um die Anzahl der Testfälle pro Testplan und ihren Status (draft, ready for review, approved), so wie die Anzahl der Anforderungen, die durch die Summe aller Testfälle abgedeckt (oder noch zu testen) sind.

Zum Zeitpunkt der Testausführung wird die Anzahl bereits ausgeführter Tests und ihr Ausführungsstatus (passed, passed with condition, blocked, deferred, error, failed etc.) ermittelt. Hierbei sind auch der prozentuale Anteil bereits erfolgreich überprüfter Anforderungen von Interesse sowie natürlich Anzahl und Schwere von Fehlern.

In dem Projekt wurden IBM Rational Insight Dashboards und Reports nach Projektvorgaben erstellt, um diese Metriken darzustellen. Abbildung 4 zeigt als Beispiel ein Dashboard mit zwei Reports. Der Report links stellt dar, dass die Testplanung fortschreitet: Eine Anforderung wurde von einem weiteren Testfall abgedeckt. Der Report rechts zeigt, dass eine Anforderung, die schon einen Testfall ohne Ergebnis hatte, jetzt auch getestet wurde – leider mit negativem Ergebnis (Verdict ist „Failed“).

Einführung der Werkzeuge

Die Einführung einer neuen Umgebung ist ein Änderungsprojekt und erfordert einen entsprechenden Fokus auf drei Dimensionen der Projektleitung: Kosten, Zeit und Risiko.

Es hat sich bewährt, die Einführung der Werkzeuge genau zu planen, damit diese rechtzeitig zur Verfügung stehen. Die Planung muss sich auf die Installation, die Konfiguration nach Projektvorgaben und die Schulung von Mitarbeitern beziehen. Es empfiehlt sich eine phasenweise Implementierung, beginnend mit einem Piloten prototypischer Implementierung.

Wichtig ist es auch, alle Anforderungen bezüglich der Dokumentenerstellung von Beginn an im Blick zu haben, da die Reportinganforderungen Einfluss auf das Usage-Model haben.

Es hat sich im Verlauf des Projekts gezeigt, dass sich das Hinzuziehen von Fachleuten mit Spezialwissen gleich zu Beginn der Einführung einer neuen Werkzeugkette positiv im Sinne einer Kosten- und Risikominimierung auswirkt.

Aufwände sind notwendig für Anpassungen nach den Projektvorgaben, die zur sorgfältigen Konfektionierung der Werkzeugkette durchgeführt werden müssen. Es empfiehlt sich daher, eine Phase für „Knowledge Transition“ einzuplanen, damit das Team in die Lage versetzt wird, zukünftige Anpassungen und die Pflege der Werkzeuge selbst vornehmen zu können. Knowledge Transition betrifft deswegen nicht nur die einzelnen Tester, sondern auch das Etablieren lokaler Experten vor Ort.

Fazit

In diesem Artikel haben wir gezeigt, wie in einem Systementwicklungsprojekt die Abbildung des vertraglich geforderten Test- und Verifikationsvorgehens auf die IBM-Rational-Werkzeugkette erfolgt ist. Dies betraf im Einzelnen:

  • die Darstellung der Lösungsarchitektur mit den Komponenten IBM Rational DOORS, Rational Quality Manager, Rational Team Concert, Rational Publishing Engine, Rational Insight und deren Schnittstellen (OSLC, REST)
  • die Erläuterung der vorgenommenen Anpassungen der Rational-Quality-Manager-Testartefakte Testplan und Testcase zur Unterstützung des gesamten Testmanagementprozesses (Planung, Erstellung von Testprozeduren und Reports) mit Fokus auf die automatisierte Generierung der Testdokumente
  • die Benutzung speziell des Rational Quality Manager für einen internen Reviewprozess zur Bewertung der Güte der erstellten Testartefakte (Testplan, Testcase, Testscript)
  • die Erstellung von Reports mit Insight auf der Basis von Metriken zur Steuerung und Überwachung der Testplanung und -durchführung

Unseren Erfahrungen nach bringen die IBM-Rational-Werkzeuge eine Out-of-the-box-Funktionalität mit, welche durch die Implementierung von OSLC- und REST-Schnittstellen den Erwartungen an eine integrierte Werkzeugkette gerecht werden. Das Projekt muss als ein Change-Management-Projekt betrachtet und folglich sorgfältig geplant und durchgeführt werden.

Links & Literatur

[1] IEEE Standard 12207-2008: Systems and software engineering – Software life cycle processes, IEEE Computer Society, 2008

Dieser Artikel stammt aus dem Entwickler Magazin 1.15. Alle Ausgaben finden Sie im Entwickler Magazin Archiv.

Aufmacherbild: detailed illustration of a stylized red devil Foto via Shutterstock / Urheberrecht: phoelix

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -