Software-Test / Testmanagement

ADLM 4/4: Testmanagement mit IBM Rational Quality Manager (RQM)

Nach sehr vielen Jahren meiner Tätigkeit im Bereich Qualitätssicherung, Software-Test und Testmanagement, konnte ich eine Vielzahl von Einblicken und Erfahrungen mit unterschiedlichen Tools sammeln, welche das Managen von Testaktivitäten unterstützen, erleichtern und beschleunigen. Aus meiner Sicht und Erfahrung sind folgende zwei Hauptfaktoren für eine erfolgreiche Tool-Unterstützung des Testmanagements wichtig:

  1. Usability/Funktionalität – einfache und intuitive Handhabe des Tools
  2. Übersichtlichkeit/Auswertbarkeit – schnelle und einfache Möglichkeit einen aktuellen Status über den Stand der Testaktivitäten zu erhalten

In diesem Blog, als letzten Teil der Serie – „Application Development LifeCycle Management“ und das passende Werkzeug, möchte ich über meine Erfahrungen mit dem RQM berichten, welcher einer der drei Teile der IBM Rational Suite ist.

tool-384740_1280

Usability/Funktionalität

Durch meine langjährige Tätigkeit im Testbereich habe ich bereits sehr viele Softwareprodukte kennengelernt. Dazu gehört natürlich die Software, welche ich getestet habe, als auch unterstützende Software. Mein Zugang ist der, dass ich mir ein neues Programm zu allererst ganz ohne Einschulung „vornehme“, also auf die intuitive Bedienung prüfe. In den allermeisten Fällen gelingt das sehr gut und ich kann nach kürzester Zeit meinen Nutzen daraus ziehen. Als ich begonnen habe mit dem RQM zu arbeiten, musste ich feststellen, dass es ganz ohne Wissen nicht geht. Allerdings konnte ich recht bald die ersten Testfälle erfassen.

 

Testfallerfassung

Übersicht Abschnitte eines Testfalls

Abb. 1: Übersicht Abschnitte eines Testfalls

Ein Testfall wird mittels einer Vorlage, welche wiederrum in Abschnitte eingeteilt ist wie etwa Zusammenfassung, Testfalldesign, Vorbedingungen, erwartetes Ergebnis, Anhänge, usw. erstellt. Auf den ersten Blick eine gute Sache, in der täglichen Arbeit allerdings etwas mühsam, da man die Abschnitte immer extra anklicken muss um sie bearbeiten zu können und nicht auf einmal auf dem Schirm hat. Wem alle zur Verfügung gestellten Abschnitte zu viel sind, kann diese ausblenden. Auch die Möglichkeit einen bestehenden Testfall zu duplizieren, um sich viel Schreibarbeit zu ersparen, funktioniert gut.

Funktionalitäten wie Statusübergänge bzw. Workflows können mit entsprechenden Berechtigungen flexibel eingestellt werden. Was ich vermisst habe ist eine E-Mail-Notifikation bei Änderungen von Elementen im RQM. Das wäre vor allem bei größeren Teams von Bedeutung. Somit muss man sich rein auf die Disziplin der Mitarbeiter verlassen.

Hat man nun eine bestimmte Menge an Testfällen erstellt, können diese zu Testplänen zusammengefasst werden. Je nachdem wie viele Testfälle vorhanden sind, ist das schnell erledigt. Sind dem Projekt oder Programm sehr viele Testfälle zugeordnet, dann müssen die Testfälle gefiltert werden, da die Suche einige Zeit in Anspruch nehmen kann. Hier muss man vorab sehr genau überlegen, wie man Projekte im RQM umsetzt, um nicht zu große Datensammlungen zu bekommen.

 

Testdurchführung

Im RQM gibt es das Element Testfallausführungsdatensatz. Dieser ist vor allem für die späteren Auswertungen sehr wichtig. Hier gibt es zwei Möglichkeiten diese Testfallausführungsdatensätze zu verwenden:

  1. Pro Testfall mehrere Testfallausführungsdatensätze – dies kann dazu verwendet werden, einen Testfall in mehreren Varianten zu testen (Systemkonfigurationen, Web-Browser, Testdatenvarianten, …)
  2. Pro Testfall einen Testfallausführungsdatensatz – also eine 1:1 Zuordnung
Zusammenspiel der Module RTC und RQM in der Rational Suite

Abb. 2: Zusammenspiel der Module RTC und RQM in der Rational Suite

 

Jede Testausführung kann jederzeit wiederholt werden, also ein anderes Ergebnis liefern (Fehlgeschlagen, Bestanden, Ohne Ergebnis, Geblockt, …).

Bei fehlgeschlagenen Testausführungen, sollte ein Defect erstellt werden. Dieser befindet sich im RTC (Rational Team Concert) und ist mit dem jeweiligen Testfall verlinkt. Das Fehlermanagement befindet sich somit komplett im RTC, dort können auch Auswertungen über die vorhandenen Fehler gemacht werden.

Wie man die Testausführungsthematik schließlich verwendet, ist einem selbst überlassen bzw. kann je Projekt unterschiedlich gehandhabt werden. Hier ist jedoch Vorsicht geboten, da die Statistiken genau auf diese Daten abfragen. Somit muss das Thema der Auswertbarkeit vorab überlegt werden, wo ich bereits beim zweiten Hauptfaktor bin.

 

Übersichtlichkeit/Auswertbarkeit

Folgende Statistiken/Auswertungen verwende ich für meine Teststatusberichte:

  1. Teststatus – Wie steht es um meine Tests im Moment? Wie viele Testfälle wurden bereits getestet? Wie viele davon wurden positiv und wie viele negativ getestet?
  2. Fehlerstatistik – Wie viele Fehler wurden bisher gefunden? Welchen Status haben diese aktuell? Welche Kritikalität haben die Fehler?

 

Dashboards

Hier gibt es einerseits die Möglichkeit Dashboards einzurichten. Dashboards haben den Vorteil, dass ich eine grafische Darstellung zur Verfügung habe und diese in Teststatusberichte einfach übernehmen kann. Hier kommen die Testfallausführungsdatensätze ins Spiel, denn auf diese setzt die Auswertung des Teststatus auf und nicht auf die Testfälle, wie ich zuerst vermutet hatte. Hier musste ich die Variante mit einem Testfallausführungsdatensatz pro Testfall wählen, um eine aussagekräftige Statistik für den Teststatus zu erhalten.

Abb. 2: Kreisdiagramm Teststatus

Abb. 3: Kreisdiagramm Teststatus

 

Für das tägliche Arbeiten habe ich das RQM als etwas umständlich und teilweise sehr langsam erlebt. Möchte man bestimmte Testfälle herausfiltern, beispielsweise zu einer bestimmten Anforderung, so muss man sich im RTC eine Auswertung basteln. Aber die Bearbeitung findet trotzdem im RQM statt und man muss sehr viele Fenster handeln und verliert leicht die Übersicht – Fensterstress. Direkt im RQM kann ich das nur bewerkstelligen, wenn ich in der Überschrift des Testfalls ein Kürzel oder Ähnliches hinterlege. Auch da gilt, dass je nach vorhandener Testfallanzahl, das Filtern länger dauern kann, da es sich um eine „JustInTime“-Filterung (reagiert sofort, wenn etwas eingegeben wird) handelt.

Abb. 3: Balkendiagramm Fehlerstatus

Abb. 4: Balkendiagramm Fehlerstatus

 

Fazit


Das Werkzeug bzw. die Suite kann wirklich viel und es kann die tägliche Arbeit gut unterstützen. In Bezug auf ADLM (Application Develoment Lifecycle Management) habe ich eine automatisierte Möglichkeit vermisst, über Änderungen bestehender Anforderungen (aus dem RDNG heraus) im RTC und RQM informiert zu werden. Somit sehe ich das Zusammenspiel der drei Komponenten der Rational Suite nur bedingt als optimal. Darüber hinaus sollte man sich auf jeden Fall einschulen lassen, um das Potential des Tools wirklich kennen zu lernen. Die Usability ist definitiv verbesserungswürdig, aber bekanntlich gewöhnt sich der Mensch an vieles. Am Markt findet man gute und vor allem günstigere Alternativen, mit denen man das alles auch abdecken kann, mit dem Vorteil, dass das ADLM in einem Tool handhabbar ist und nicht aus drei zusammengestoppelten Modulen besteht.

 

ADLM 3/4: Projektmanagement mit der IBM Rational Suite
ADLM 2/4: Softwarebasierte Unterstützung für Anforderungsmanagement – Pro und Kontras gäniger Tools
ADLM 1/4: Welches ist das richtige Werkzeug für Application Development Lifecycle Management?

Passende Artikel

Kommentare gesperrt.