Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Nico Orschel
ist Software Process Consultant, Autor und Referent im Umfeld Microsoft ALM bei der AIT und wurde von Microsoft als MVP für VS ALM ausgezeichnet. Er hilft Unternehmen auf Basis von TFS effizienter Software zu entwickeln und zu testen und so ein höheres Qualitätsniveau bei kürzeren Release-Zyklen zu erreichen. Mein Profil auf Google+ .

Nico Orschel

Testplanung von Test Cases

Freitag, 11. März 2011

Im letzten Artikel “Traceability zwischen Work Items, Testplänen und -Suiten” wurde eine AIT TFS Erweiterung vorgestellt, um Testsuite- und Testplan-Informationen für das Visual Studio zugänglich zu machen. Diesen Punkt möchten wir jetzt mit neuen Fragestellungen im Themenbereich “TFS für Testmanager” fortsetzen:

  • Wie kann ich die Auslastung meiner Tester besser planen? oder
  • Wie kann ich meine Testfälle besser auf meine Tester verplanen?

Das Thema Projektmanagement ist bereits seit den TFS Versionen 2005 und 2008 fester Bestandteil der Workflows von Projekt- und Produktmanagern. Viele Projekt- und Produktmanager verwenden für die Projektsteuerung und das Produktmanagement Werkzeuge, wie z.B. MS Excel und MS Project. Im Zusammenhang mit Testmanagement fragt man sich jetzt zurecht: „Warum kann ich als Testmanager nicht einfach auch Excel und Project für meine tägliche Planungsarbeit nutzen?“

Die Basis für jede Testplanung sind Testfälle (Work Item Type: Test Case) aus dem TFS. In diesen können neben den Testschritten und erwarteten Ergebnissen weitere Informationen wie z.B. zum Testdurchführungsaufwand hinterlegt werden. Um große Mengen an Testfällen vorgefiltert abzufragen, werden Work Item Queries benutzt.  Für das Filtern von Test Cases über Work Item Queries existieren zwei  praktikable Ansätze:

  1. Filtern über den Area Path (TFS Konzept) und
  2. Filtern über den Testplan- und Testsuite- und Testplannamen (mit der Erweiterung AIT CurrentTestPath).

Im folgenden betrachten wir zunächst die Unterschiede zwischen beiden Ansätzen.

Area Path:

Das Konzept Area Path ist fester Bestandteil eines jeden Work Items und damit auch fester Bestandteil des Test Case Work Items. Unter Verwendung einer Area lässt sich ein Work Item in eine logische Hierarchie einordnen. Das Zuweisen eines Area Path kann man mit dem Ablegen einer Datei in einen Windows-Ordner vergleichen. Ein Beispiel für eine Abfrage unter Verwendung des Area Path zeigt folgende Abbildung:

SNAGHTML554dc27

Current TestPath:

Das Konzept der AIT Current TestPath benötigt eine eigene Erweiterung auf der TFS-Serverseite. Die Erweiterung speichert Testsuite- und Testplaninformationen in Work Items und ermöglicht damit den direkten Zugriff auf Test Cases über einen Test Path (Team Projekt Name + Testplan Name + Test Suite Name) anstatt eines Area Paths. Ein Beispiel für eine Abfrage unter Verwendung des Test Path zeigt folgende Abbildung:

SNAGHTML2693178

Bewertung / Vergleich:

Vergleicht man die Anwendungsbereiche von Area Path und CurrentTestPath, so ergeben sich jeweils individuelle Anwendungsbereiche.

Der große Vorteil vom Konzept Area Path ist, dass er bereits nativer Bestandteil eines jeden Work Items ist und die Testplanung ohne Erweiterungen auskommen kann. Problematisch kann das Konzept des Area Path nur werden, wenn die Area Path Hierarchie nicht mit der Testplan-Struktur deckungsgleich ist. Sind die Strukturen zu unterschiedlich (keine logische 1:1 Verknüpfung), dann werden die Abfragen und damit die Aggregationen der verschiedenen Planungskennzahlen zu ungenau.

Der große Vorteil der AIT Erweiterung als zweiter Ansatz ist die direkte feingranulare Abfragemöglichkeit von Testplan- und Testsuite-Informationen. Filter können mit diesen Informationen sehr detailliert bis auf Testsuite-Ebene formuliert werden. Ein weiterer Vorteil ist die Unabhängigkeit von Area Path Informationen, weil diese jetzt nicht mehr 1:1 mit den Testplanstrukturen korrelieren müssen. Der Nachteil dieser Lösung ist im wesentlichen die Notwendigkeit einer 3rd Party-Erweiterung auf Serverseite.

Im Rahmen des Artikels werden wir uns auf den Ansatz Area Path beschränken, weil dieser ohne zusätzliche Erweiterungen auskommt.

Step-By-Step

Nachdem die Daten auf Basis einer Work Item Query abgefragt wurden, können wir diese Daten im nächsten Schritt mit Hilfe von Excel-Formeln, Excel-Marcos oder Pivot-Tabellen nach den eigenen Anforderungen für das Testmanagement aufbereitet werden. Zu den Details bzgl. Excel-Funktionalitäten möchte ich Sie auf einschlägige Fachliteratur verweisen.

Ein beispielhafte Umsetzung des zuvor beschriebenen Prozesses stellt das folgende vereinfachte Excel-Szenario dar:

1) Datenabfrage: Abfrage von Planungsdaten über eine TFS Work Item Query mit einem Filter auf einen bestimmten Area Path (hier: \Functional Areas\Account Management )

SNAGHTML5577894

2) Verarbeitung: Aggregation von geplanten Aufwänden pro  Tester über eine Excel-Pivot-Tabelle

SNAGHTML269f015

3) Auswertung: Graphische Aufbereitung der aggregierten Kennzahlen aus 2) zur Auswertung

SNAGHTML26ab24a

4) Planung: Anpassung von Testaufwänden bzw. Umorganisierung von Testverantwortlichkeiten (siehe Schritt 1) ) um eine ausbalancierte Teamauslastung zu erreichen (siehe Schritt 3).

5) Publikation: Veröffentlichung der neuen Planungsdaten durch Hochladen der geänderten Work Item Daten (siehe Schritt 1) )

SNAGHTML5798a8f

Fazit

Mit wenigen Kniffen und Excel-Basis-Wissen sollte es Ihnen jetzt sehr einfach möglich sein, eine Testplanung auf Basis von TFS Daten  zu realisieren. Sind TFS und Excel etwa nur für Projektmanager? … Ich hoffe ihre Antwort lautet jetzt: NEIN.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , , , ,

Hinterlasse eine Antwort