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

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 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.

Testaufwand ebenenweise optimieren

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.

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.

Anforderungen, Testpläne

Definition der Anforderungen

Für die Anforderungsdefinition verwendet der Autor in den Projekten häufig zwei Dokumenttypen: zum einen das Lastenheft, das der Kunde zur Angebotsfindung in einem Format seiner Wahl, etwa ein PDF oder als Excel-Liste, vorlegt, und zum anderen die Detailspezifikation in Form eines Pflichtenhefts, das als Basis für die weitere Projektplanung und -durchführung dient. Um die Dokumente für spätere Projektphasen und Werkzeuge verwendbar zu gestalten, wird das Pflichtenheft in einem standardisierten Format erstellt, wobei die einzelnen Anforderungen in Tabellenform angelegt sind.

Die Tabellenformulare dienen der Synchronisierung mit dem TFS, der die Anforderungen zentral speichert. Für die Anbindung von Word-Dokumenten hat AIT das Zusatzwerkzeug WordToTFS entwickelt.

Das Word-Pflichtenheft bleibt das führende Dokument für die funktionalen Beschreibungen der Spezifikation, denn es dient als Vertragsgrundlage gegenüber dem Kunden. Über einen Änderungsprozess lassen sich Change Requests in den TFS einstellen und die Anforderungen nach ihrer Freigabe im Word-Dokument verändern. Nach der Abnahme des Dokuments werden die Änderungen durch eine erneute Synchronisierung in den TFS übernommen.

Die Anforderungen liegen somit in einem zentralen Repository, auf das sich über Client-Applikationen zugreifen lässt. Die Idee ist, dass jede Rolle im Team zwar spezifische Werkzeuge verwendet, allerdings auf die gleiche Datenbasis zugreifen kann. Für den fachlichen Tester bietet Microsoft den Test Manager 2010 als Client-Applikation an. Im Testing Center der Applikation lassen sich die Anforderungen direkt aus dem TFS öffnen, anlegen und bearbeiten. Die Anforderungen im TFS dienen als Planungselemente für Release- und Iterationsplanung und als Ausgangsbasis für die Definition der Tests.

Ableitung von Akzeptanzkriterien und Testplänen

Um Akzeptanzkriterien und Testplänen abzuleiten, werden für die Anforderungen Akzeptanzkriterien und Systemtests in Form von Testfällen angelegt. Häufig passiert das in einem separaten Tool. Die Verbindung zwischen Test und Anforderung ist aufwendig über IDs oder Ähnliches zu pflegen. Der TFS kann Testfälle verwalten und direkt mit den Anforderungen über Artefakt-Links verbinden. Diese Verknüpfungen sind in Abfragen verwendbar. Beispielsweise lässt sich eine Liste der Anforderungen mit verknüpften Testfällen oder eine Auflistung aller Anforderungen abfragen, für die noch kein Testfall erstellt wurde. Das bietet einen schnellen Überblick der noch offenen Arbeit auch für den Tester.

Häufig stellt sich die Frage, ob nicht schon die Anforderungsdefinition, zum Beispiel in Form von Szenarien, für die Tests ausreichend ist. Das lässt sich in den meisten Fällen verneinen. Testfälle definieren ein möglichst in sich geschlossenes Szenario, das aus einzelnen Testschritten und konkreten Testdaten besteht, die möglichst unterschiedliche Fälle innerhalb der Applikationslogik abdecken. Ist die Anforderungsdefinition noch generisch und arbeitet mit Wertebereichen, ist der Testfall eine konkrete Ausprägung der späteren Verwendung der Applikation durch den Benutzer. Oft identifiziert der Tester bereits während der Testfallerstellung Lücken oder Widersprüche in den Anforderungen, was teure Fehlerbehebungen in späteren Phasen spart.

Abbildung 5 zeigt das Formular eines Testfalls im Testing Center mit der Beschreibung der einzelnen Testschritte. Zu jedem Schritt lassen sich erwartete Ergebnisse in Form von Text und angehängten Dokumenten angeben. Über Testparameter kann man Testdaten hinterlegen, um eine mehrfache Ausführung des Tests mit verschiedenen Benutzereingaben zu definieren. Benötigt man mehrere zusammenhängende Testschritte in den Testfällen immer wieder, lassen sich diese als sogenannter Shared Step auslagern und zentral verwalten. Es ist sogar möglich, das Action Log des zentralen Schritts aufzuzeichnen und dann in den referenzierenden Testfällen abzuspielen.

Die Testfälle sind nicht nur bloße Definitionen der Testschritte mit verknüpften Anforderungen. Sie stellen vollständige Planungselemente – sogenannte Work Items im TFS-Vokabular – dar, werden zum Beispiel einer Person zugewiesen sowie in Iteration und Bereich klassifiziert. Die Generizität der Work Items erlaubt die Anpassung des Formulars und der dahinter liegenden Zustandsmaschine, die für Testfälle die Zustände "Design", "Ready" und "Closed" definiert. Ein Testfall wird demnach entworfen, dann zum Test freigegeben und letztlich nach erfolgten Testzyklen und Abnahme der getesteten Funktionen geschlossen. Bei Bedarf lässt sich der Testfall allerdings auch wieder öffnen.

Eine Anforderung bedarf häufig der Definition mehrerer Testfälle. Für einen Anwendungsfall zum Beispiel bieten sich unterschiedliche Szenarien (Normalfall und Ausnahmefälle) an. Das reicht allerdings noch nicht für einen vollständigen Testplan. Dieser soll ganze Systeme in Form von Anforderungsgruppen abdecken. Testpläne sind ein zentraler Bestandteil des Testing Center und fungieren als Ausgangspunkt für die weitere Planung und Ausführung der Tests. Dabei liegen der Testplan und seine Elemente wiederum im Team Foundation Server.

Öffnet man nun einen Testplan im Testing Center, kann die Planung beginnen. Erst strukturiert man ihn dazu in Unterelemente, sogenannte Testsuiten, die die Testfälle enthalten. Über diese Strukturierungsmechanismen lassen sich Funktionsgruppen, Produktbereiche oder auch Testteams unterscheiden – je nach individuellem Projekt-Setup. Über die unterschiedlichen Testsuite-Typen kann man unterschiedlich Testfälle zusammenstellen, wobei sich diese mehrfach referenzieren lassen, zum Beispiel wenn die Testfälle mehreren Testkonfigurationen zugewiesen werden. Eine solche Konfiguration repräsentiert eine zu testende Umgebung über Variablen wie das Betriebssystem, die Sprache oder die Browserversion. Einen Testfall kann man in mehreren Testumgebungen wiederverwenden. Man unterscheidet drei Typen von Testsuiten:

Testsuite-Typ	Beschreibung
Suite	Sie stellt einen einfachen Strukturierungsknoten ähnlich einem Verzeichnis dar. Testfälle lassen sich manuell hinzufügen, was keine Auswirkungen auf den Testfall hat.
Query-based Suite	Durch eine Work-Item-Abfrage, die zum Beispiel einen Filter auf die Teststufe enthält, werden Testfälle aus dem Repository aufgelistet. Entspricht ein Testfall nicht mehr den Kriterien der Abfrage, entfernt man ihn aus der Suite. Das hat keine Auswirkungen auf den Testfall.
Requirement	Sie repräsentiert eine Anforderung aus dem Projekt. Es wird etwa ein Work Item vom Typ "Requirement" referenziert, und fügt man einen Testfall zur Suite hinzu, wird dieser mit der Anforderung verknüpft. Entfernt man die Verknüpfung, ist der damit entkoppelte Testfall nicht mehr Bestandteil der Suite.

Die Abbildung 6 zeigt einen mit den einfachen Suiten und Requirements strukturierten Testplan für die Akzeptanz- und Systemtestebene. Der linke Bereich des Testing Center stellt die Struktur der Suiten dar, im rechten Teil sind die der ausgewählten Suite zugeordneten Testfälle aufgelistet.

Auch Suiten haben einen Zustand, dargestellt durch ein kleines Icon links neben dem Suite-Namen. Die Zustände reichen von "In Planning" (= noch nicht bereit zum Testen) über "In Progress" (= bereit zum Testen) bis zu "Completed". Letzteres bedeutet, dass alle Tests absolviert und in dieser Suite nicht mehr auszuführen sind. Dadurch lässt sich die Menge der auszuführenden Tests trotz umfangreicher Testpläne für den Tester übersichtlich halten.

Die folgende Tabelle zeigt zudem die Navigationsleiste im oberen Teil des Testing Center mit den Bestandteilen Plan, Test, Track und Organize.

Bereich	Beschreibung
Plan	Der Planungsbereich ist der Verwaltung des ausgewählten Testplans verschrieben. Darin enthalten sind Einstellungen zur Durchführung, individuelle Testsuiten und Testfälle.
Test	Für die Ausführung der Tests dient der Testbereich. Hier lassen sich Testläufe starten, Testergebnisse speichern und Fehlerberichte anlegen. Zudem kann man die zurückliegenden Testläufe auswerten.
Track	Zur erweiterten Auswertung ist der Track-Bereich da. Zum einen können hier Differenzen zwischen zwei Builds des Systems analysiert, zum anderen die von Code-Änderungen betroffenen Tests ermittelt werden.
Organize	Dieser Bereich bietet eine Übersicht zum schnellen Zugang zu und zu Bearbeitung von Testplänen, -fällen und -konfigurationen.

Testdurchführung

Ergebnisse im Schnelldurchgang – Testdurchführung

Nachdem die Tests geplant und Konfigurationen zugewiesen wurden, lassen sich diese individuell oder in Form einer Test-Suite ausführen. Dabei startet der Tester einen Testlauf, in dessen Kontext er Diagnosedaten auf dem Testsystem erfasst. Beispielsweise zeichnet er ein Video der Ausführung, die Systemkonfiguration, parallel gestartete Programme oder das Eventlog auf. Vor dem Start des Testlaufs verändert sich das Testing Center zum Test Runner – einer verkleinerten Applikation, die sich an den Rand des Bildschirms anordnet, um den Desktop im sichtbaren Bereich zu halten. Der Test Runner zeigt einen Testfall mit seinen Testschritten, wie er vom Tester durchzuführen ist, direkt neben der zu testenden Anwendung. Das ermöglicht nicht nur einen schnellen Wechsel für den Tester, sondern auch das Aufzeichnen der oben beschriebenen Diagnosedaten in der Testumgebung.

Während der Testdurchführung erfasst der Tester nicht nur Logdaten, sondern zeichnet auch Benutzerinteraktionen mit der Anwendung, das sogenannte Action Log, auf. Damit gemeint sind alle Klicks und Tastatureingaben auf und mit den Steuerelementen der Testanwendung sowie die Verwendung der Testparameterwerte zum Befüllen von Steuerelementen. Das zuletzt aufgezeichnete Action Log lässt sich mit dem Testfall verknüpfen und bei der nächsten Ausführung abspielen, was für beschleunigte Regressionstests sorgt. Statt immer wieder das Login und die Navigation bis zum problematischen Eingabedialog der Testapplikation durchgehen zu müssen, kann der Tester mit einem Klick auf "Play" die automatische Instrumentierung starten und so im "Fast Forward"-Modus zum spannenden Teil des Testfalls springen. Das beschleunigt nicht nur, sondern motiviert zugleich, da dem Tester eintönige Klickorgien erspart werden. Voraussetzung für die Interaktion ist, dass ein zeitgemäßer Browser bei Webapplikationen beziehungsweise eine kompatible Oberflächentechnik für Windows-Applikationen verwendet wurde.

Wenn der Tester die beschriebene Aufzeichnung beziehungsweise Automatisierung der Benutzerinteraktionen anhand der Applikation überprüft, wird er mit großer Wahrscheinlichkeit Einschränkungen registrieren. So müssen alle verwendeten Steuerelemente die Standards MSAA (Microsoft Active Accessibility) und UIA (Microsofts UI Automation) erfüllen – also Schnittstellen für die alternative Steuerung der Applikation zum Beispiel durch Sprache und Gesten.

Kommunikation mit dem Entwickler

Sollte ein Testschritt fehlschlagen, also das tatsächliche vom erwarteten Ergebnis abweichen, markiert der Tester den Schritt mit "Fail". Zusätzlich kann er nun einen Kommentar, einen Screenshot und einen kompletten Fehlerbericht direkt aus dem Test Runner heraus anlegen. Der Fehlerbericht ist dabei nicht nur ein Formular für die Eingabe der textuellen Fehlerbeschreibung, sondern auch bereits mit den Diagnosedaten der Testausführung angereichert. Es entsteht ein sogenannter "Rich Bug", wie ihn Abbildung 8 darstellt.

Die im Beispiel gezeigte Fehlermeldung enthält zusätzlich zu allgemeinen Informationen wie Titel, ID, zugewiesener Bearbeiter und Version die durch den Tester ausgeführten Schritte mit Ergebnis und direktem Link zur Position innerhalb des aufgezeichneten Videos. Ein Link zum angelegten Screenshot ist ebenfalls enthalten. Alle Daten sind wiederum im zentralen Repository des Team Foundation Server gespeichert.

Neben den Verbesserungen für die Kommunikation zwischen Tester und Entwickler resultiert aus den Rich Bugs ein weiterer Vorteil. Diese unterstützen den Tester bei der Verifizierung der Fehlerbehebung. Der Tester kann im Abschnitt "Verify Bugs", wie in Abbildung 9 dargestellt, die vom Entwickler gelösten Bugs auflisten und per Klick den Testfall, der zur Identifikation des Fehlers führte, erneut ausführen, was die Zahl der nach der Fehlerbehebung erneut ausgeführten Tests reduziert. Zudem hilft das zuvor beschriebene "Fast Forward"-Abspielen bei der erneuten Ausführung des Tests, da man bis zum kritischen Testschritt springen kann.

Auswertungsmöglichkeiten

Ein Testergebnis ist eine Fehlermeldung in Form eines "Bugs". Doch auch die positiven Resultate sind interessant. Einen Überblick über die Ergebnisse des Testlaufs bietet "Analyze Test Runs" im Track-Bereich. Ein Testlauf sammelt alle Informationen zur Ausführung von Tests durch einen Tester beziehungsweise in einer automatisiert getesteten Lab-Umgebung. Dazu gehören Metadaten wie Titel, Start- und Endzeit, ausführender Tester sowie eine Übersicht in Diagramm- und Listenform der ausgeführten Testfälle und deren Ergebnis.

Über den Testlauf kann man weiter in die Testergebnisse navigieren. Dort finden sich die einzelnen Testschritte, Kommentare und aufgezeichneten Informationen zur Testdurchführung. Da sich ein Testfall durchaus mehrfach ausführen lässt, gibt es für diesen eine Ergebnishistorie, die alle bisherigen Ausführungen zusammenfasst und sie in ihrer zeitlichen Reihenfolge darstellt.

Eine grundlegende Auswertung hält nicht bei den Testläufen. Die Verknüpfung zu den getesteten Anforderungen dient nun zur Generierung von Übersichten, die die Testergebnisse im Kontext der Anforderungshierarchie zeigen. Sie zeigen erfolgreiche, fehlgeschlagene und noch nicht ausgeführte Tests. Wie im Bericht "Requirements Overview" in Abbildung 11 zu sehen, wird zudem der Fortschritt der Anforderungen hinsichtlich der Implementierungsaufgaben dargestellt. Beispielsweise lässt sich während einer iterativen Entwicklung der Status der Anforderungsentwicklung und -abnahme überwachen, was den Kommunikationsaufwand der Projektverantwortlichen reduziert, da sie gezielt die fehlgeschlagenen Tests und offenen Fehler verfolgen können.

Der Team Foundation Server bietet viele weitere Daten zur Auswertung über das zentrale Berichtswesen an, zum Beispiel zum Testplanungsfortschritt oder zum Status über alle definierten Testfälle. Über die standardisierte Schnittstelle lassen sich Anwendungen wie Excel oder der Report Builder für das Erstellen von Berichten nutzen.

Fazit

Änderungen effizienter Testen – Regressionstests

Während der Testausführung erhebt der Tester Diagnosedaten. Die reichen von den Systeminformationen (CPU, Rechnername, Betriebssystemversion) über das Event-Log bis hin zu Benutzerinteraktionen und der Test-Impact-Analyse. Letztere dient der Ermittlung von Regressionstests nach Code-Änderungen. Testet man eine .NET-Anwendung, werden die während des Tests instrumentierten Code-Zeilen registriert. Änderungen am Quellcode der getesteten Applikation lassen sich durch den Test Manager analysieren und die zu wiederholenden Tests ermitteln. Das kann jedoch nur ein Indiz auf die Regressionstest sein, werden doch Änderungen an Konfigurationsdateien oder "unmanaged" Code-Teile nicht berücksichtigt. In jedem Fall
lassen sich die "Hot-Spots" unter den Tests identifizieren, die in jedem Fall erneut zu testen wären.

Doch auch manuell lassen sich Testsuiten für Regressionstests aus den bestehenden Testsuiten und -fällen zusammenstellen. Im Testing Center kann der Tester dazu einen neuen Testplan "Version 1.1 Regression" anlegen. Ihm fügt er nun über den Kontextmenüeintrag "Copy Suite from another test plan" Kopien der Suiten aus dem Testplan für Version 1.0 des zu testenden Produkts hinzu. Dabei werden lediglich die Zusammenstellungen der Testfälle, nicht aber die Testfälle selbst dupliziert. Im Anschluss kann man den kopierten Testsuiten weitere Testfälle hinzufügen oder irrelevante entfernen. Dadurch kann der Testmanger den Testaufwand für Planung und Durchführung von Hot-Fix-Versionen optimieren, wenn keine Ressourcen für die vollständige Wiederholung aller Tests bereitstehen oder das gar nicht gewünscht ist. So kann der Tester eine Testbibliothek mit verschiedenen Testfällen in unterschiedlichen Suiten aufbauen, die sich beliebig wiederverwenden lassen.

Fazit

Mit dem Test Manager lässt sich die Qualitätssicherung um ein funktionsstarkes Werkzeug ergänzen, ohne Medienbrüche oder redundante Daten befürchten zu müssen. Alle Daten sind im Team Foundation Server hinterlegt und dadurch von anderen Clients aus verfügbar. Das spart Kosten für unnötige Tool-Integrationen und senkt den Schulungsaufwand bei den Benutzern. Microsoft liefert damit eine erste vielversprechende Version einer umfassenden Werkzeugkette, die auch die Qualitätssicherung in Softwareentwicklungsprojekten zum Ziel hat.

Sven Hubert
ist seit mehreren Jahren für die AIT GmbH & Co. KG in Stuttgart als Berater tätig und seit April 2010 Most Valuable Professional (MVP) für Visual Studio ALM. Zu seinen Schwerpunkten gehört neben der Projektleitung das Application Lifecylce Management. (ane)