Werkzeugkette für das Test-Management mit dem Team Foundation Server 2010

Der erstmals im Team Foundation Server 2010 enthaltene Test Manager ergänzt die Qualitätssicherung in Softwareentwicklungsprojekten um ein funktionsreiches Werkzeug. Der Artikel über Konzepte und neue Möglichkeiten des TFS für das manuelle und automatische Testen.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 17 Min.
Von
  • Sven Hubert
Inhaltsverzeichnis

Der erstmals im Team Foundation Server 2010 enthaltene Test Manager ergänzt die Qualitätssicherung in Softwareentwicklungsprojekten um ein funktionsreiches Werkzeug. Der Artikel erläutert die Konzepte und neuen Möglichkeiten des TFS für das manuelle und automatische Testen.

Als Anbieter individueller Softwareprodukte steht der Arbeitgeber des Autors, die AIT AG, auf beiden Seiten der Projektabwicklung. Zum einen als Zulieferer für Kunden, zum anderen häufig auch auf Seite des Kunden zur Koordination der Zulieferer spezieller Komponenten wie Maschinenteile oder Softwaretreiber. Zur wesentlichen Koordinierung gehören:

Die AIT-Werkzeugkette zur Durchführung von Softwareentwicklungsprojekten (Abb. 1)
  • die Spezifikation der Anforderungen
  • die Definition von Akzeptanzkriterien und Testplänen
  • die Überwachung des Projekt- und Testfortschritts
  • die Zusammenführung der Produktteile (Integrationstests)
  • Übergabe beziehungsweise Abnahme der Lieferungen (Akzeptanztests)
  • Verifikation der Korrektheit bei Änderungen (Regressionstests)

Erfahrungsgemäß steht man in diesen und ähnlichen Konstellationen gemeinsam vor folgenden Aufgaben:

  • Änderungsmanagement (Auswirkungsanalyse, Nachvollziehbarkeit, Dokumentation)
  • Projekttransparenz (Fortschritt, zu erwartende Qualität, Kosten von Änderungen)
  • Abnahme (Vollständigkeitsprüfung, Umgang mit Nachforderungen usw.)

Zum Bewältigen gibt es dafür zahlreiche Werkzeuge. Für eines, Microsofts Team Foundation (TFS) Server 2010, hat AIT eine durchgängige Werkzeugkette zur Durchführung von Softwareentwicklungsprojekten erarbeitet. In diesem Artikel steht das Thema Qualitätssicherung im Vordergrund. Anhand eines Ebenenmodells erläutert er Konzepte und Möglichkeiten des TFS für das manuelle und automatische Testen.

Für das Ausnutzen der Testkapazitäten bietet es sich an, Testebenen zu definieren, auf denen man die Testziele verfolgt. Dafür kommen unterschiedliche Testtypen zum Einsatz. Die weiteren Ausführungen beziehen sich auf das sich am V-Modell orientierende Modell von Testebenen aus Abbildung 2. Dieses ist jedoch kein Vorgehens-, sondern ein Strukturierungsmodell und lässt sich sowohl in Wasserfall- als auch in agilen Projekten einsetzen.

Testebenen - von den Anforderungen über das Design zur Implementierung (Abb. 2)

Auf der linken Seite des Modells ist die Erarbeitung des Lösungsraums aus dem Problemraum abgebildet – von der Anforderung über die Spezifikation bis zur Implementierung. Der Problemraum umfasst dabei die Geschäftsprozesse und fachlichen Anforderungen an die zu entwickelnde Software. Der Lösungsraum enthält die technisch orientierten Funktionen der Software und deren konkrete Umsetzung.

Auf der rechten Seite sind die zur jeweiligen Ebene zugehörigen Tests zu finden. Diese sind in die Bereiche Build-Verifikation und Systemtest unterteilt. Der Grad der Automatisierung und die Ausführungshäufigkeit der Tests nehmen von unten nach oben ab. Die Testabdeckung des Gesamtsystems steigt hingegen. So werden die in Form von Unit-Tests implementierten Komponententests bei jeder Code-Änderung automatisch ausgeführt. Sie prüfen allerdings lediglich die Schnittstelle einer Komponente. Die Integrationstests sind auf das Testen des Zusammenspiels mehrerer Komponenten über verschiedene Schnittstellen hinweg ausgelegt und größtenteils ebenfalls automatisiert. Im Systemtest soll man das Gesamtsystem mit allen integrierten Komponenten in der Zielumgebung prüfen. Die Tests müssen nicht nur Logikbausteine, sondern auch die Bedienoberfläche und externe Schnittstellen – wenn nicht bereits im Integrationstest geschehen – berücksichtigen. Die Automatisierung liegt hierbei häufig deutlich unter 100 Prozent. Manuell bleiben häufig die Akzeptanztests, in denen ein Auftraggeber beziehungsweise Kunden die Abnahme vornehmen, was zumeist in Form von Checklisten geschieht.

Im Folgenden soll der Bereich der System- und Akzeptanztests näher betrachtet werden. Der Bereich der Build-Verifikationstests ist Gegenstand eines späteren Artikels.