White Paper - pure-systems€¦ · White Paper pure::variants Connector for ClearQuest 5 / 19...

White Paper Effizientes Management von Tests und Defects in variantenreichen Systemen mit pure::variants und IBM Rational ClearQuest

HerausgeberHerausgeberHerausgeberHerausgeber © pure-systems GmbH

Agnetenstraße 14 39106 Magdeburg

http://www.pure-systems.com

AnsprechpartnerAnsprechpartnerAnsprechpartnerAnsprechpartner

Taha BoulaguigueTaha BoulaguigueTaha BoulaguigueTaha Boulaguigue IBM Deutschland GmbH

[email protected]

Dave GööckDave GööckDave GööckDave Gööck pure-systems GmbH

[email protected] +49 391 544569 41

White Paper pure::variants Connector for ClearQuest

2 / 19

InhaltsverzeichnisInhaltsverzeichnisInhaltsverzeichnisInhaltsverzeichnis 1. Einführung............................................................................................................................................3

1.1. Variantenmanagement im Product / Application Lifecycle ...............................................3 1.2. Variantenmanagement im Testmanagement & Defect Tracking .....................................4

1.2.1. Nutzung für Deployment, QA, Auswertung, Visualisierung......................................4 1.2.2. Verbesserung des Testmanagements / Defect Trackings .......................................4

2. Vorstellung der Lösung......................................................................................................................5 2.1. Toolumgebung von IBM Rational ...........................................................................................5

2.1.1. IBM Rational Software Delivery Platform....................................................................5 2.1.2. IBM Rational ClearQuest ................................................................................................5

2.2. Variantenmanagement mit pure::variants ............................................................................7 2.2.1. Technologische Grundlagen ..........................................................................................8

2.3. pure::variants Connector for ClearQuest ..............................................................................9 3. Beispiel für den TestManager – Tutorial: ....................................................................................11

3.1. Vorbereitungen in ClearQuest...............................................................................................11 3.2. Vorbereitungen in pure::variants..........................................................................................11 3.3. Tests im ClearQuest anlegen und konfigurieren ...............................................................11 3.4. Tests mit pure::variants verbinden.......................................................................................12 3.5. Testlogs in ClearQuest anlegen............................................................................................13 3.6. Testergebnisse in pure::variants anzeigen.........................................................................13

4. Beispiel für das Defect Tracking – Tutorial: ................................................................................15 4.1. Vorbereitungen ........................................................................................................................15 4.2. Defects mit pure::variants verbinden...................................................................................15 4.3. Statusinformationen der Fehler in pure::variants anzeigen ............................................16 4.4. Defect-Status in ClearQuest ändern....................................................................................17

5. Zukünftige Entwicklung der Anbindung .......................................................................................18 6. Referenzen.........................................................................................................................................19


3 / 19

1.1.1.1. EinführungEinführungEinführungEinführung Verwandte Produkte bestehen zu großen Teilen aus identischen Bestandteilen und nur we-nige Unterschiede spezifizieren die einzigartige Funktionalität. Der Produktlinienansatz nimmt diese Zweiteilung auf und trennt die Produktbestandteile nach Gemeinsamkeiten und Unter-schieden. Dabei repräsentieren die Gemeinsamkeiten genau die Bestandteile, die in allen Pr-oduktvarianten enthalten sind. Die effiziente Nutzung dieses Ansatzes ist eine Herausforde-rung. In ihrer Umsetzung, dem Variantenmanagement, liegt enormes Potential zur Verbesse-rung der Ressourceneffizienz. Durch Variantenmanagement wird das Wissen um die Funktio-nalität der Bestandteile, ihrer Anforderungen und Einschränkungen effektiver verwaltet und besser zugänglich gemacht und somit auch erfolgreicher nutzbar.

Dieses White Paper zeigt, wie mit Hilfe eines durchdachten Variantenmanagements sowohl Tests als auch Defects besser in variantenreichen Systemen verwaltet werden können. Insbe-sondere im Kontext einer Softwareproduktlinie liegt hier häufig enormes Potenzial.

1.1.1.1.1.1.1.1. Variantenmanagement im Product / Application LifecycleVariantenmanagement im Product / Application LifecycleVariantenmanagement im Product / Application LifecycleVariantenmanagement im Product / Application Lifecycle Variantenmanagement ist eine durchgängige Aktivität, die im gesamten Lebenszyklus der Pro-dukt- bzw. Anwendungsentwicklung eine wichtige Rolle spielt. Aus diesem Grunde ist die nahtlose und effektive Integrierbarkeit eines Tools zum Variantenmanagement in die einge-setzte Toolumgebung bedeutend für seine maximale Effizienz.

So kann eine Anbindung an ein bestehendes Requirements Management dafür genutzt wer-den, Featuremodelle (siehe Abschnitt 2.2.1.1 Featuremodellierung) automatisiert zu erstellen, mit Variabilitätsinformationen anzureichern und ihre Informationen für den weiteren Verlauf der Entwicklung nutzbar zu machen. Durch die Verknüpfung des Variantenmanagements mit den genutzten Tools zum Design und zur Implementierung, eröffnet sich die Möglichkeit für einen einfachen Import von Familienmodellen (siehe Abschnitt 2.2.1.2 Familienmodellierung) und somit der effizienten Umsetzung variantenspezifischer Implementierungen. Wenn darüber hinaus auch das Konfigurationsmanagement um die Fähigkeiten des Umgangs mit Varianten bereichert wird, sind auch die Generierung und der Build spezifischer Lösungsvarianten ohne Schwierigkeiten möglich.

Da der Produktlebenszyklus mit der fertigen Implementierung einer Software nicht abge-schlossen ist, sondern die Bereiche des Testmanagement, wie auch des Defect Tracking mit steigender Softwarekomplexität immer größere Bedeutung erlangen, ist es unabdingbar auch

Variantenmanagement im Application Lifecycle

Var

iant

enm

anag

emen

t

pure

::var

iant

s —

Anforderungsmanagement — RequisitePro

Testmanagement, Defect Tracking — ClearQuest

Konfigurationsmanagement — ClearCase

Softwaredesign und Implementierung

Software Architect / Systems Developer


4 / 19

hier der Bildung von Varianten Aufmerksamkeit zukommen zu lassen. Auch können Informati-onen über den Workflow zu einzelnen Bestandteilen der Produktlinie mit Bezug auf ihre Varia-bilität oder Variantenzugehörigkeit die Produktqualität erhöhen wie auch die Effektivität der Entwicklung steigern.

1.2.1.2.1.2.1.2. VariantenmanagementVariantenmanagementVariantenmanagementVariantenmanagement im Testmanagement im Testmanagement im Testmanagement im Testmanagement & Defect Tracking & Defect Tracking & Defect Tracking & Defect Tracking Wie eben beschrieben, ist das Variantenmanagement eine durchgängige Aktivität, die auch im Defect- und Testmanagement Beachtung finden muss. Oftmals sind Defects und Tests nicht für alle Produktvarianten relevant. Dieses Wissen muss erfasst und genutzt werden, um unnö-tigen Entwicklungs- und Testaufwand vermeiden zu können. Es ist grundsätzlich wichtig, voll-ständige Nachverfolgbarkeit und Nachvollziehbarkeit auch variantenspezifisch durchführen zu können. Damit lassen sich Aufwand und Risiko bei auftretenden Problemen besser abschät-zen. Zum Beispiel können Probleme in zur Auslieferung anstehenden Produktvarianten anders behandelt werden als Fehler oder fehlgeschlagene Tests an bisher nicht ausgelieferten Vari-anten.

Es gibt zwei wichtige Ansätze, die hier Beachtung finden müssen.

1.2.1.1.2.1.1.2.1.1.2.1. Nutzung für Deployment, QA, Auswertung, VisualisierungNutzung für Deployment, QA, Auswertung, VisualisierungNutzung für Deployment, QA, Auswertung, VisualisierungNutzung für Deployment, QA, Auswertung, Visualisierung Zum einen ist die Auswertung variantenbezogener Daten, wie Testergebnisse und Statusin-formationen eine große Herausforderung. Zwar bietet beispielsweise ein Werkzeug zum Test-management häufig effiziente Möglichkeiten Testfälle logisch zu strukturieren, Testlogs effi-zient zu verwalten und umfangreiche Auswertungen zuzulassen, stellt aber keine Information über Varianten mit dar. Da allerdings eine Modellierung von Varianten über Eigenschaften und deren Abhängigkeiten im Testmanagement meist nur mit großem Aufwand möglich oder sehr unpraktikabel ist, kann eine Verknüpfung mit einem expliziten System zum Variantenmanage-ment hier die Leistungsfähigkeit beider Plattformen bestmöglich entfalten. Zu diesem Zwecke können Testfälle mit einzelnen Elementen aus dem Variantenmanagement verknüpft und in die Modellierung mit einbezogen werden, so dass dort die relevanten Statusinformationen zur variantenspezifischen Auswertung und Visualisierung vorhanden sind. Außerdem stehen die Informationen für die weitere Nutzung im Workflow der Produktentwicklung zur Verfügung, so dass sie für Deployment Prozesse, umfangreiches Qualitätsmanagement und in anderen Be-reichen genutzt werden können.

1.2.2.1.2.2.1.2.2.1.2.2. Verbesserung des Testmanagements / DVerbesserung des Testmanagements / DVerbesserung des Testmanagements / DVerbesserung des Testmanagements / Defect Trackingsefect Trackingsefect Trackingsefect Trackings Auf der anderen Seite steht das Potenzial, aus den gewonnenen Informationen des Variante-managements eine Steigerung der Effizienz insbesondere des Testmanagements, aber auch des Defect Trackings zu erwirken. Folgende Punkte sind hier denkbar:

- Automatische Generierung variantenspezifischer Testsuites, um die Prozesse der Vor-bereitung und des Testens zu beschleunigen und sicherzustellen, dass für den Testlauf einer Variante auch alle relevanten Tests berücksichtigt werden.

- Automatische Generierung von „Stubs“ für Testpläne, Testfälle, etc. um zum Beispiel eine gewünschte Mindesttestabdeckung für alle Varianten der Produktlinie sicherzu-stellen oder Prozesse des Testmanagements zu beschleunigen.

- Automatische Generierung von variantenspezifischen Buglisten, die eben genau die Fehler enthalten, die die konkrete Variante betreffen.


5 / 19

2.2.2.2. Vorstellung der LösungVorstellung der LösungVorstellung der LösungVorstellung der Lösung Im Folgenden wird eine Lösung vorgestellt, die für das Testmanagement oder das Defect Tra-cking den Einsatz von IBM Rational ClearQuest und für das Variantenmanagement die Nutzung von pure::variants aus dem Hause pure-systems voraussetzt.

2.1.2.1.2.1.2.1. Toolumgebung von Toolumgebung von Toolumgebung von Toolumgebung von IBM RIBM RIBM RIBM Raaaationaltionaltionaltional ClearQuest ist ein Werkzeug, welches als Teil der IBM Rational Software Delivery Platform entwickelt und vertrieben wird. Es wird vornehmlich zum Testmanagement, Defect Tracking und Change Management eingesetzt.

2.1.1.2.1.1.2.1.1.2.1.1. IBM RatiIBM RatiIBM RatiIBM Ratioooonal Software Delivery nal Software Delivery nal Software Delivery nal Software Delivery PlatformPlatformPlatformPlatform Die IBM Rational Software Delivery Platform ist eine komplette, durchgängige Entwicklungs-plattform, die den gesamten Lebenszyklus von Anwendungen abdeckt. Mit dieser Plattform können Software-Lösungen verschiedenster Art und für alle Branchen entwickelt und einge-setzt werden. Dazu gehören beispielsweise Anwendungen für Web, Client/Server, Desktop, Real Time, Embedded oder auch Software für die Medizintechnik oder für den Mobilfunk.

Die IBM Software Delivery Platform wurde auf einer Basis entwickelt, die beispiellose Auto-matisierung und Teamarbeit während des gesamten Entwicklungszyklus ermöglicht: dem uni-versellen Entwicklungsrahmen Eclipse. Eclipse ist ein Open Source Software-Entwicklungsprojekt mit über 100 Anbietern als aktive Teilnehmer. Eclipse ermöglicht rollen-basierte Benutzerschnittstellen, die jedem Mitglied des Teams eine angepasste Sicht der all-gemeinen Unternehmens und Entwicklungsressourcen bieten. Mit Eclipse als zentralem Kern wird die IBM Software Delivery Platform von einer Vielzahl von Partnern unterstützt und durch ein dynamisches Ökosystem von Tools und Services erweitert.

2.1.2.2.1.2.2.1.2.2.1.2. IBM RationalIBM RationalIBM RationalIBM Rational ClearQuest ClearQuest ClearQuest ClearQuest Um die Qualität eines Software-Produkts auf allen Ebenen sicherzustellen, bietet IBM Rational verschiedene Funktionalitäten an. Das Portfolio umfasst Werkzeuge für Testplanung und -steuerung, Komponententests und Laufzeitanalyse, Funktions- und Regressionstests, sowie Performance-Tests.

Prozess- & Portfolio-

management

Change- & Releasemanagement

Qualitätsmanagement

Architektur & Implementierung

Governance & Lifecycle Management

Integriertes Anforderungsmanagement

IBM Rational Software Delivery Platform


6 / 19

IBM Rational ClearQuest ist ein Werkzeug für die Testplanung und -Steuerung, mit integrier-tem Fehler- und Änderungsmanagement.

Ausgehend von den fachlichen oder technischen Spezifikationen werden Testpläne in Ratio-nal ClearQuest erstellt, die logisch zusammenhängende Testfälle beinhalten. Die Testfälle werden durch die Zuordnung von weiteren Eigenschaften wie Testiteration und Konfiguration verfeinert und mit einer manuellen oder automatischen Implementierung verknüpft. Diese Imp-lementierung ist beispielsweise ein mittels der IBM Rational Test-Tools (Manual / Functional / Performance Tester) erstelltes Test-Script. Einzelne konfigurierte Testfälle bzw. Suiten werden mittels den entsprechenden Test-Tools ausgeführt und die Testergebnisse in Rational Clear-Quest protokolliert. Fehler und Abweichungen können dann direkt in das Fehlermanagement

Metrik Data- Warehouse

Testplanung, Teststeuerung,

Testauswertung

Requirements Management

Testerstellung und Testausführung

IBM Rational Tools für den Tester

RequisitePro ClearQuest ProjectConsole

Manual Tester Functional Tester Performance Tester

Testplanung

Testmanagement Testerstellung Testauswertung

Testausführung

IBM Rational ClearQuest Testmanagement-Modell


7 / 19

übergeben werden. Nach der Testdurchführung können vielfältige Auswertungen in Rational ClearQuest generiert werden.

Die untenstehende Grafik zeigt den entsprechenden Prozesskreislauf:

2.2.2.2.2.2.2.2. Variantenmanagement mit Variantenmanagement mit Variantenmanagement mit Variantenmanagement mit pure::variantspure::variantspure::variantspure::variants Die Basistechnologie pure::variants verfügt über alle Eigenschaften, die für eine erfolgreiche, werkzeuggestützte Entwicklung und Realisierung von Produktlinien erforderlich sind. Sie ist durchgängig während aller Phasen der Entwicklung, angefangen bei der Anforderungsanalyse und dem Softwaredesign, über die Implementierung bis hin zur Erstellung, Testen, Nutzung und Wartung einsetzbar. Alle grundlegenden Mechanismen sind unabhängig von Program-miersprachen und eingesetzten Entwicklungstechnologien und -plattformen.

Die pure::variants Technologie verfügt über herausragende Integrationsfähigkeiten. Sie kann leicht in bestehende Entwicklungsprozesse und -umgebungen eingebunden werden. Durch die Kopplung mit unterschiedlichen, bereits beim Anwender vorhandenen Werkzeugen zum Configuration Management, Requirements Engineering, Modellierung und Testen ergibt sich eine einheitliche Lösung. Die Anbindung an beliebige Werkzeuge ist durch das XML-basierte Austauschformat und eine Vielzahl offener Schnittstellen jederzeit möglich. Leistungsfähige Importer ermöglichen die Integration in bestehende Softwareprojekte und verringern den Ein-stiegsaufwand erheblich. Für spezifische Anforderungen ist pure::variants durch Integration zusätzlicher Module flexibel erweiterbar. Dabei haben alle Module vollständigen Zugriff auf das Variantenwissen.

ClearQuest Test-

management

Rational Test Tools

RequisitePro

Testergebnis

Testplan

anlegen

ClearQuest Fehler-

management

Testfälle

definieren

konfigurierte Testfälle

konfigurieren

ausführen

Fehler Record

Verweis auf Anforderungen

beschreiben / aufzeichnen / generieren

Fehler erfassen

Implemen-tierung

Testscripte

Verweis auf Anforderungen

proto-kollieren

Fehler aufgetreten?

Testprozesskreislauf


8 / 19

2.2.1.2.2.1.2.2.1.2.2.1. Technologische GrundlagenTechnologische GrundlagenTechnologische GrundlagenTechnologische Grundlagen In dem pure::variants zu Grunde liegenden Ansatz wird der Prozess des Variantenmanagement in vier Bereiche bzw. Schritte unterteilt. Dabei ist jeder Bereich an einem anderen Punkt im Entwicklungslebenszyklus angesiedelt.

2.2.1.1.2.2.1.1.2.2.1.1.2.2.1.1. FeaturemodellierungFeaturemodellierungFeaturemodellierungFeaturemodellierung

Basierend auf einer inhaltlichen Analyse der umzusetzenden Anforderungen werden Feature-modelle (auch Merkmalmodelle) entworfen, in denen insbesondere die Abhängigkeiten der einzelnen Merkmale der Produktlinie untereinander erfasst werden. Featuremodelle lassen sich gut grafisch darstellen, hierarchisieren und sind leicht verständlich.

In der Verknüpfung mit anderen im Entwicklungslebenszyklus einer Produktlinie eingesetzten Werkzeugen, können die Basisdaten für Featuremodelle häufig aus einem bestehenden Requi-rements Management gewonnen werden und dann mit den gewünschten variantenbezogenen Zusatzinformationen angereichert werden. Darüber hinaus besteht zu jedem Merkmal einer Produktlinie meist eine gewisse Menge an Metainformationen, wie Testfälle und deren aktuel-ler Ausführungsstatus, Change Requests, Defects, Workflow Informationen, etc.. Diese Infor-mationen werden meist in weiteren Werkzeugen und Datenbanken gesammelt, stehen für eine weitere Bearbeitung zur Verfügung und können mit den Merkmale in pure::variants verknüpft werden.

2.2.1.2.2.2.1.2.2.2.1.2.2.2.1.2. FamilienmodellierungFamilienmodellierungFamilienmodellierungFamilienmodellierung

Ausgehend vom Featuremodell und weiteren Anforderungen für die einzelnen abzuleitenden Softwaresysteme und Produkte wird das Design der Lösung(en) durchgeführt. Dabei werden die Elemente der Lösung mit ihren Beziehungen, Einschränkungen und Anforderungen im Fa-milienmodell erfasst und stehen damit einer automatischen Verarbeitung zur Verfügung.

Es besteht hier ebenfalls die Möglichkeit die Basisdaten für die Familienmodelle aus der Imp-lementierung bzw. Umsetzung der Produktlinie zu generieren und dann mit den entsprechen-den weitergehenden Informationen anzureichern. Hier ist oft eine Kopplung mit dem beste-henden Konfigurationsmanagement eine effektive Lösung. Neben der Modellierung der Lö-sung werden ihre Bestandteile mit den Merkmalen in den Featuremodellen verknüpft, so dass eine durchgängige Berücksichtigung von Variabilität von der Anforderung zur Lösung möglich

Prozess des Variantenmanagements

Analyse von Anforderun-gen: Erfas-sung von abstraktem Variabili-tätswissen der Produkt-linie.

Entwurf der Lösung: Er-fassung von Wissen über die Realisie-rung der Produktlinie.

Realisierung der Lösung: Bildung der Varianten durch Selek-tion der Ele-mente, die jeweils ent-halten sein sollen.

Automatisier-te Verarbei-tung des ge-sammelten Wissens zur Generierung von Varian-ten.

Feat

urem

odel

lieru

ng

Fam

ilien

mod

ellie

rung

Var

iant

enko

nfig

urat

ion

Tran

sfor

mat

ion


9 / 19

ist. Wie auch bei den Merkmalen der Produktlinie entsteht während ihrer Implementierung eine Vielzahl an Metainformationen, die auch hier mit den Elementen aus den Familienmodel-len in Bezug gesetzt werden können.

2.2.1.3.2.2.1.3.2.2.1.3.2.2.1.3. VariantenkonfigurationVariantenkonfigurationVariantenkonfigurationVariantenkonfiguration

Nachdem alles relevante Wissen über die Produktlinie und ihre Lösung erfasst wurde, können die einzelnen Produkte beziehungsweise Varianten abgeleitet werden. Durch die Kopplung der Lösung mit den Anforderungen, ist eine Auswahl der gewünschten Merkmale ausreichend um eine spezifische Lösung, also eine Variante abzuleiten. Außerdem ermöglicht die nun vorhan-dene Modellierung von Abhängigkeiten und Einschränkungen, dass die gewünschte Konfigu-ration auf Gültigkeit geprüft wird, bzw. dass pure::variants in der Lage ist, den Anwender beim Erstellen einer korrekten Variante unterstützen kann.

Hier können die verknüpften Metainformationen ausgewertet werden, so dass sich sehr leicht Metriken erstellen lassen, um variantenspezifische Informationen zu Implementierungsstand, Testabdeckung, Fehlerrate, etc. zu gewinnen.

2.2.1.4.2.2.1.4.2.2.1.4.2.2.1.4. TransformatiTransformatiTransformatiTransformationononon

Die Konfiguration einer Variante liefert eine Lösungsbeschreibung, die sich zum Beispiel für eine automatische Generierung der Produktvariante nutzen lässt. Zu diesem Zweck stellt pu-re::variants die Transformation bereit. Sie lässt sich frei anpassen und ermöglicht die Einbin-dung eigener Module, um den Transformationsprozess zu steuern.

Da zur Modellierung Informationen aus den verschiedenen Bereichen des Lebenszyklus der Produktentwicklung miteinander verknüpft wurden, stehen all diese Informationen nun für die Transformation zur Verfügung. Je nachdem, welche Transformationsmodule in pure::variants eingebunden wurden, werden während der Transformation nun verschiedene Aktionen durchgeführt. Zum Beispiel kann ein Buildprozess zur Generierung einer Variante gestartet werden, für den im Vorfeld eine variantenspezifische Zusammenstellung von Quellen und ein Makefile generiert wurden.

Informationen aus dem Testmanagement können genutzt werden, um variantenspezifische Testsuites zu generieren. Das Defect Tracking ermöglicht die Erzeugung variantenspezifischer Fehlerlisten zur weiteren Verarbeitung.

2.3.2.3.2.3.2.3. purpurpurpure::variants e::variants e::variants e::variants Connector for ClearQuestConnector for ClearQuestConnector for ClearQuestConnector for ClearQuest Der pure::variants Connector for ClearQuest bietet eine Verknüpfung zwischen Variantenma-nagement und Testmanagement bzw. Defect Tracking. In Abschnitt 1.2 wurde angesprochen, an welchen Stellen bei der Verknüpfung von pure::variants und ClearQuest Potenzial liegt. In der aktuellen Version liegt das Hauptaugenmerk auf der Visualisierung der Darstellung von Status bezüglich eines Elements.

Die im ClearQuest angelegten Defects, wie auch die Testfälle können mit den einzelnen Ele-menten in pure::variants verknüpft werden. Durch diese Verknüpfung kann es den jeweils letz-ten Status des ClearQuest Eintrages abfragen. Im Falle eines Fehlers, wie einem noch nicht behobenen Defects oder eines fehlgeschlagenen Tests, gibt pure::variants eine entsprechen-de Warnung aus. Die Verknüpfungen werden über die ID des jeweiligen Eintrages der Clear-Quest Datenbank hergestellt und in einem speziellen Attribut eines Elements abgelegt. Die Attributwerte, also die einzelnen Links, können wie üblich mit Restriktionen belegt werden und so nur in konkreten Varianten relevant sein. Dadurch können Fehler modelliert werden, die nur


10 / 19

bei einer konkreten Konfiguration von bestimmten Bestandteilen der Produktlinie auftreten oder Tests, die nur ausgeführt werden können und deren Ergebnis nur relevant ist, wenn auch alle entsprechenden getesteten Eigenschaften im Produkt enthalten sind.

Der pure::variants Connector for ClearQuest hält eine Verbindung zur ClearQuest Datenbank und Aktualisiert in regelmäßigen Abständen seine Statusinformationen. So sind Veränderun-gen direkt sichtbar und die Informationen lassen sich zur Unterstützung von Deploymentpro-zessen heranziehen.

Im Folgenden ist an zwei Beispielen erläutert, wie genau der pure::variants Connector for ClearQuest arbeitet. Zum einen gehen wir auf ein Szenario im Testmanagement ein, zum ande-ren auf ein Beispiel aus dem Defect Tracking. Darauf folgt noch ein kurzer Ausblick, welche Entwicklungen in künftigen Generationen des Connectors noch zu erwarten sind.


11 / 19

3.3.3.3. BeiBeiBeiBeispiel spiel spiel spiel für den TestManager für den TestManager für den TestManager für den TestManager –––– TutorTutorTutorTutoriiiial:al:al:al:

3.1.3.1.3.1.3.1. Vorbereitungen in ClearQuestVorbereitungen in ClearQuestVorbereitungen in ClearQuestVorbereitungen in ClearQuest 1. Anlegen einer ClearQuest User Datenbank CQPV im

ClearQuest Designer

2. Verbindung zur neuen Datenbank im ClearQuest Ec-lipse Client herstellen

3. Im ClearQuest TestManager eine neue Asset-Registry WeatherStation hinzufügen

4. Erstellung eines Testplans WeatherStationTestPlan

5. Anlegen eines Konfigurationsattributes ps:VariantNames mit jeweils einem Wert für jede gewünschte Variante

6. Erstellen jeweils einer Konfiguration für jede Varian-te

3.2.3.2.3.2.3.2. VorbereituVorbereituVorbereituVorbereitungen in pngen in pngen in pngen in puuuure::variantsre::variantsre::variantsre::variants 1. Beispielprojekt zur Wetterstation erstellen

(File->New->Example…->Weather Station)

2. Featuremodell Weather Station.xfm zur Wet-terstation öffnen

3.3.3.3.3.3.3.3. Tests im ClearQuest anlegen und konfiguriTests im ClearQuest anlegen und konfiguriTests im ClearQuest anlegen und konfiguriTests im ClearQuest anlegen und konfigurieeeerenrenrenren Eine mögliche, sinnvolle Repräsentation von Varianten in Clear-Quest kann über Konfigurationen erfolgen, weshalb in Abschnitt 3.1 für jede relevante Produktvariante genau eine Konfiguration angelegt wurde. Testfälle, die nun in Testplänen angelegt und verwaltet werden, sind hierbei unabhängig von der konkreten Variante. Das heißt, die unkonfigurierten Testfälle decken die Funktionalität der gesamten Produktlinie ab.

Information zur Variantenzugehörigkeit eines Tests wird durch seine Konfiguration dargestellt. Da für jede relevante Variante genau eine Konfiguration existiert, wird für jede Variante, in der die getestete Funktionalität enthalten ist ein konfigurierter Test angelegt.


12 / 19

Im letzten Schritt können nun Testsuites erstellt und konfiguriert werden, wobei jeweils eine Testsuite für eine Variante angelegt werden kann. Dies ermöglicht es, jede Variante genau nach den in ihr enthaltenen Funktionalitäten und Implementierungen abzutesten. In einem pro-duktiven Szenario können viele Schritte automatisiert aus pure::variants heraus vorgenommen werden.

1. Für die gewünschten Features aus der Wetterstation im ClearQuest Eclipse Client Test-fälle anlegen. (z.B.: LCD, DataTransfer, Pressure, Temperature, Wind)

2. Für jeden Testfall die gewünschten konfigurierten Testfälle anlegen. Dabei wird für je-de Variante, in der das getestete Feature enthalten ist ein konfigurierter Test angelegt.

3. Für jede Variante eine Testsuite anlegen und konfigurieren. Bei der Konfiguration der Testsuite werden ihr alle Tests der ihr zugehörigen Konfiguration zugeordnet.

3.4.3.4.3.4.3.4. Tests mit pure::variants Tests mit pure::variants Tests mit pure::variants Tests mit pure::variants verbindenverbindenverbindenverbinden Um die Statusinformationen aus dem ClearQuest abzufragen um sie dann in den einzelnen Varianten auswerten zu können, müssen die im ClearQuest angelegten Testfälle mit den Ele-menten in pure::variants verknüpft werden. Die konfigurierten Testfälle werden den entspre-chenden Varianten dann automatisch zugeordnet, indem das zuvor angelegte Attribut pv:VariantName ausgewertet wird.

1. In den Preferences von pure::variants prüfen, ob die Einstellungen für den Connector richtig gesetzt sind.

a. Unter „Variant Management -> External Tools -> ClearQuest Tests“ müssen die Local ClearQuest Test Settings auf die unter Abschnitt 3.1 erstellte Verbindung gesetzt werden.

b. Unter „Variant Management -> External Tools“ sollte ClearQuest Tests aktiviert sein. Hier kann es für die ersten Schritte nützlich sein, eine kürzere Zeit für die Updates einzustellen und somit die Update time auf 10 Sekunden zu stellen.

c. Unter „Variant Management -> Visualisation“ sollte Show restrictions und Show attributes aktiviert sein.

d. In der Toolbar von pure::variants muss Automatically Validate Model aktiviert sein.

2. Ein Element im Featuremodell auswählen und über sein Kontextmenü (New -> ClearQuest Test) eine neue Verknüpfung zu einem Test erstellen.

a. Der Connector nutzt zur Kommunikation mit der ClearQuest Datenbank eine Verbindung, die im ClearQuest Client konfiguriert wurde. Beim ersten Verbin-dungsversuch fragt der Connector nun nach der notwendigen Authentifizie-rung. (In einer leeren Datenbank von ClearQuest wird häufig ein User admin angelegt, ohne Passwort.)

b. Es öffnet sich ein Dialog zur Auswahl des Tests. In einer Liste stehen alle Test-fälle zur Verfügung. Nach Auswahl des gewünschten Tests und Beendigung des Dialogs, wurde dem Element ein Attribut cq:Tests hinzugefügt, mit der Test-nummer als Wert.


13 / 19

c. Dies muss für jeden Testfall gemacht werden, der mit dem Variantenmanage-ment verknüpft werden soll und somit dort zur Auswertung zur Verfügung ste-hen soll. Im Relations View wird für jeden Test, der mit dem aktuell gewählten Element verlinkt ist, eine Relation angezeigt, die mit Informationen aus der ClearQuest Datenbank angereichert wurde.

3. In einigen Fällen ergeben sich bedingte Tests. Dies könnten bspw. Tests sein, die das Zu-sammenspiel zwischen verschiedenen Funkti-onalitäten abtesten. Über das Kontextmenü des jeweiligen Attributwertes für einen Testfall können Restriktionen hinzugefügt werden um eben die Gültigkeit des jeweiligen Tests einzuschränken.

3.5.3.5.3.5.3.5. Testlogs in ClearQuest anlegenTestlogs in ClearQuest anlegenTestlogs in ClearQuest anlegenTestlogs in ClearQuest anlegen Um in pure::variants nun die Testergebnisse auswerten zu können, werden nun einige Testlogs im ClearQuest angelegt.

1. Im Test Manager des ClearQuest Eclipse Clients zu einem konfigurierten Testfall navi-gieren.

2. Über das Kontextmenü des Testfalles ein neues Testprotokoll erstellen Neu (Testpro-tokoll), den folgenden Dialog mindestens mit den notwendigen Daten und einer kurzen Notiz zur Ausführung füllen und schließen.

Um in pure::variants ein wenig mehr Daten zur Verfügung zu haben, ist es sinnvoll, für mehrere Tests Testlogs zu definieren und einige auf passed und andere wiederum auf failed zu setzen.

3.6.3.6.3.6.3.6. Testergebnisse in pure::variants anzeigenTestergebnisse in pure::variants anzeigenTestergebnisse in pure::variants anzeigenTestergebnisse in pure::variants anzeigen Nach diesen Schritten stehen nun alle Informationen zur Auswertung und Anzeige in pu-re::variants zur Verfügung. Es gibt verschiedene Arten, wie nun das Ergebnis eines Testlogs in der Oberfläche von pure::variants angezeigt werden kann.

1. Der Test ist fehlgeschlagen:

In diesem Fall wird in pure::variants ein Marker am linken Rand des Modells erzeugt. Dieser markiert das Element bzw. den Link auf den fehlgeschlagenen Test. So ist direkt in den Modellen ersichtlich, wo potenziell für eine Variante Fehler auftreten können.

In den Variantenmodellen wird der Problemmarker nur angezeigt, wenn das entspre-chende Element in der Variante enthalten ist und der entsprechende Test nicht durch

Tests im Editor und deren Anzeige im Relations View


14 / 19

Restriktionen aus der Lösung entfernt wurde. Außerdem versucht pure::variants über das Konfigurationsattribut pv:VariantName oder über den Konfigurationsnamen he-rauszufinden, welcher konfigurierte Testfall zu der entsprechenden Variante gehört, so dass nur die relevanten Testlogs ausgewertet werden.

ACHTUNG: Das entsprechende Variantenmodell muss geprüft werden, damit die Mar-ker dort angezeigt werden. Entweder durch Auslösen eines einmaligen checkings durch den Check-Button , oder durch die Aktivierung des automatischen checkings.

2. Der Test ist erfolgreich durchgeführt worden:

In diesem Fall werden keine Marker in den Modellen angezeigt. Lediglich im Relations View ist durch ein entsprechendes Symbol leicht ersichtlich, dass der Test erfolgreich durchgeführt werden konnte.

3. Der Test ist noch nicht durchgeführt worden oder in einem unbekannten Zustand:

Hier wird ein Marker mit einem Fragezeichen generiert . So ist sehr leicht erkennt-lich, dass hier noch Handlungsbedarf besteht und unzureichend getestet wurde.

Neben der Anzeige von Markern in den Modellen, werden die Informationen zum Status auch im Matrix View eines Configuration Spaces angezeigt. Beim Doppelklick auf den Ordner des Config Spaces, öffnet sich ein Editor, in dem für jede Variante eine Spalte angezeigt wird. Jede Zeile entspricht einem Element und es kann direkt abgelesen werden, wie der Selektionssta-tus ist.

Über das Kontextmenü dieses Matrix Views, erhält man unter „Visualize… -> ClearQuest Test State“, eine andere Sicht auf die Selektionen der Varianten bzw. auf die Zustände der Tests der einzelnen Elemente. So ist sehr schnell ersichtlich, in welchen Varianten noch fehlerhafte Tests vorkommen oder welche noch getestet werden müssen. Die Symbole sind dieselben, wie sie auch bei den Markern in den Modellen benutzt werden.

Variantenübersicht – Anzeige der Markersymbole im Matrix View


15 / 19

4.4.4.4. Beispiel für das Defect Tracking Beispiel für das Defect Tracking Beispiel für das Defect Tracking Beispiel für das Defect Tracking –––– Tutorial: Tutorial: Tutorial: Tutorial:

4.1.4.1.4.1.4.1. VorbereitungenVorbereitungenVorbereitungenVorbereitungen 1. Die Vorbereitungen zur Einrichtung der ClearQuest Datenbank entsprechen denen in

Abschnitt 3.1. Darüber hinaus ist die Einrichtung einer Abfrage für die Auflistung der Defects sinnvoll. Dies ist am einfachsten über das Kontextmenü von Public Queries im ClearQuest Navigator möglich, indem man einen Query ohne Filter über die Defects er-stellt.

2. Für das Variantenmanagement bei Defects ist es, im Gegensatz zu den Tests, in der Regel nicht notwendig ihrer Strukturierung besondere Aufmerksamkeit zukommen zu lassen. Aus diesem Grunde ist es ausreichend, einige Fehler im ClearQuest anzulegen um eine Arbeitsgrundlage für dieses Beispiel zu haben. (z.B.: LCD, USB-Port, Pressure, Temperature)

3. In pure::variants sollte wie unter Abschnitt 3.2 beschrieben das Beispiel mit der Wet-terstation verfügbar gemacht werden.

4. Die Preferences von pure::variants müssen unter „Variant Management -> External Tools -> ClearQuest Defects“ und unter „Variant Management -> External Tools“ für das Defect Tracking entsprechend gesetzt werden, wie es für das Testmanagement in 3.4 unter 1. beschrieben ist.

4.2.4.2.4.2.4.2. Defects Defects Defects Defects mit pure::variants verbindenmit pure::variants verbindenmit pure::variants verbindenmit pure::variants verbinden Ähnlich wie beim Testmanagement auch, müssen die im ClearQuest angelegten Defects mit den Elementen in pure::variants verknüpft werden.

1. Ein Element im Featuremodell auswählen und über sein Kontextmenü (New -> Clear-Quest Defect) eine neue Verknüpfung zu einem Defect erstellen.

a. Der Connector nutzt zur Kommunikation mit der ClearQuest Datenbank eine Verbindung, die im ClearQuest Client konfiguriert wurde. Beim ersten Verbin-dungsversuch fragt der Connector nun nach der notwendigen Authentifizie-rung. (In einer leeren Datenbank von ClearQuest wird häufig ein User admin angelegt, ohne Passwort.)

b. Es öffnet sich ein Dialog zur Auswahl des Defects. In einer Liste stehen alle eingetragenen Fehler zur Verfügung. Nach Auswahl des gewünschten Defects,

Query zur Anzeige aller Fehler in ClearQuest


16 / 19

und Beendigung des Dialogs, wurde dem Element ein Attribut cq:Defects hin-zugefügt, mit der Fehlernummer als Wert.

c. Dies muss für jeden Defect gemacht werden, der mit dem Variantenmanage-ment verknüpft werden soll und somit dort zur Auswertung zur Verfügung ste-hen soll. Im Relations View wird für jeden Defect, der mit dem aktuell gewähl-ten Element verlinkt ist, eine Relation angezeigt, die mit Informationen aus der ClearQuest Datenbank angereichert wurde.

2. Über das Kontextmenü des jeweiligen Attributwertes für einen Defect können Restrik-tionen hinzugefügt werden um den aktuellen Bearbeitungsstatus variantenspezifisch auswerten zu können bzw. einen Defect eben an gewisse Bedingungen zu koppeln (z.B.: Ein Fehler, der nur im Zusammenspiel mit einer anderen Funktionalität auftritt und daher nicht in jeder Variante relevant ist.

4.3.4.3.4.3.4.3. StatusinformatStatusinformatStatusinformatStatusinformationen der Fehlerionen der Fehlerionen der Fehlerionen der Fehler in pure::variants a in pure::variants a in pure::variants a in pure::variants annnnzeigenzeigenzeigenzeigen Nach diesen Schritten stehen nun, analog zur Anbin-dung an das Testmanagement, alle Informationen zur Auswertung und Anzeige in pure::variants zur Verfü-gung. Es gibt verschiedene Arten, wie nun der aktuel-le Status eines Defects in der Oberfläche von pure::variants angezeigt werden kann.

1. Der Defect ist noch offen bzw. nicht bearbeitet:

In diesem Fall wird in pure::variants ein Marker am linken Rand des Modells erzeugt. Dieser markiert das Element bzw. den Link auf offenen Defect. So ist direkt in den Mo-dellen ersichtlich, wo in einer Variante Fehler zu erwarten sind bzw. festgestellt wur-den. Wenn der Defect als Enhancement oder Minor eingestuft wurde, ist sein Marker-symbol gelb , bei einem höheren Schweregrad ist es rot .

In den Variantenmodellen wird der Fehler nur angezeigt, wenn das entsprechende Element in der Variante enthalten ist und er nicht durch Restriktionen aus der Lösung entfernt wurde. Außerdem muss das entsprechende Variantenmodell geprüft werden.

ACHTUNG: Das entsprechende Variantenmodell muss geprüft werden, damit die Mar-ker dort angezeigt werden. Entweder durch Auslösen eines einmaligen checkings durch den Check-Button , oder durch die Aktivierung des automatischen checkings.

2. Der Fehler wurde geschlossen:

In diesem Fall werden keine Marker an den Modellen angezeigt. Lediglich im Relations View ist durch ein entsprechendes Symbol leicht ersichtlich, dass der Fehler geschlossen wurde.


17 / 19

3. Der Defect ist in einem unbekannten Zustand:

Hier wird ein Marker mit einem Fragezeichen generiert . Dies tritt eher selten auf. Insbesondere dann, wenn keine Verbindung zur ClearQuest Datenbank hergestellt werden kann.

Neben der Anzeige von Markern in den Modellen, werden die Informationen zum Status auch im Matrix View eines Configuration Spaces angezeigt. Beim Doppelklick auf den Ordner des Config Spaces öffnet sich ein Editor, in dem für jede Variante eine Spalte angezeigt wird. Jede Zeile entspricht einem Element und es kann direkt abgelesen werden, wie der Selektionssta-tus ist.

Über das Kontextmenü dieses Matrix Views, erhält man unter „Visualize… -> ClearQuest De-

fects State“, eine andere Sicht auf die Selektionen der Varianten. So ist sehr schnell ersicht-lich, in welchen Varianten noch offene Defects vorkommen. Die Symbole sind dieselben, wie sie auch bei den Markern in den Modellen benutzt werden.

4.4.4.4.4.4.4.4. DefectDefectDefectDefect----Status in ClearQuest ändernStatus in ClearQuest ändernStatus in ClearQuest ändernStatus in ClearQuest ändern Der Connector for ClearQuest synchronisiert sich regelmäßig mit der ClearQuest Datenbank. So werden immer die aktuellen Statusinformationen angezeigt und die Zustände der Fehlerbe-arbeitung lässt sich effektiv und variantenbezogen auswerten.

1. Im ClearQuest Navigator eine Anfrage starten um die Defects anzuzeigen.

2. Im Ergebnis, über das Kontextmenü mittels Change State den Status auf einen anderen Wert setzen. (z.B. Den Fehler über Close bzw. Resolve auf closed bzw. resolved setzen und dabei in der Resolution z.B. fixed eintragen, oder umgekehrt über Reopen bzw. Re-ject den Fehler wieder öffnen und die Resolution wieder zurücksetzen.)

Für dieses Beispiel kann ein wenig mit den Zuständen experimentiert werden, um direkt zu sehen, wie sich die entsprechenden Änderungen auf pure::variants auswirken.

Variantenübersicht – Anzeige der Markersymbole im Matrix View


18 / 19

5.5.5.5. Zukünftige Entwicklung der AnbindungZukünftige Entwicklung der AnbindungZukünftige Entwicklung der AnbindungZukünftige Entwicklung der Anbindung Aktuell ist es mit dem Connector for ClearQuest möglich variantenspezifische Visualisierungen der aktuellen Zustände von Tests oder Defects zu erstellen und auszuwerten. Durch die um-fangreichen Informationen, die pure::variants bezüglich der Variantenbildung enthält und zu-sammenführt, ist es für die Zukunft geplant, die entsprechenden Einträge im ClearQuest auto-matisch vorzunehmen. So könnten aus Feature- und Familienmodellen „Stubs“ von Testfällen im ClearQuest erzeugt werden, um eine Mindestabdeckung von Tests sicherzustellen.

Eine weitaus interessantere und weitergehende Option ist die automatische Erzeugung eines Großteils der Elemente in der ClearQuest Hierarchie. In den Modellen von pure::variants kön-nen alle notwendigen Informationen hinterlegt werden, um von den Konfigurationsattributen über die Konfigurationen selbst bis hin zu den konfigurierten Testfällen und den Testsuiten alle Daten ins ClearQuest zu importieren. Die Informationen zum Ausführen der konkreten Testfälle würde dann wie gewohnt im ClearQuest gepflegt werden, die strukturelle Information würde jedoch aus dem Variantenmanagement extrahiert werden. Außerdem wird im ClearQuest wei-terhin die Historie der Tests, sowie alle Information zu ihrer Ausführung verwaltet und zugäng-lich gemacht.


19 / 19

6.6.6.6. ReferenzenReferenzenReferenzenReferenzen Für einführende Einblicke in ClearQuest, wie auch pure::variants, ist die jeweilige Dokumenta-tion, wie auch die vorhandenen Einsteigertutorials empfohlen.

Mehr Informationen und Ressourcen (Dokumentationen, Tutorials, White Paper, Evaluation Software) sind auf den Webseiten von pure-systems, wie IBM Rational zu finden.

http://www.pure-systems.com

http://www.ibm.com/developerworks/rational/

http://www.ibm.com/software/rational/

White Paper - pure-systems€¦ · White Paper pure::variants Connector for ClearQuest 5 / 19...

Documents

Transcript of White Paper - pure-systems€¦ · White Paper pure::variants Connector for ClearQuest 5 / 19...