Testing ist Teamarbeit

Testmanagement mit Visual Studio und TFS
1 Kommentar

Erfolg kommt nicht über Nacht, und eine gute Software ist nicht nur das Ergebnis von ein paar Zeilen Visual-Studio-Quellcode. Beim Erstellen einer Software sind die unterschiedlichsten Rollen und Tätigkeiten involviert. Dieses komplexe Gebilde permanent zu optimieren, ist Aufgabe der übergreifenden Disziplin Application Lifecycle Management (ALM).

Das aktuelle Zauberwort für Erfolg in Softwareprojekten lautet derzeit Agilität. Die einfache Zauberformel aus Test-driven Development (TDD) und kurzen Sprints sowie einem motivierten Team versprechen ein in kleinen Schritten entwickeltes Produkt mit hohem Kundennutzen und Umsatz. Kurze Zyklen ermöglichen überschaubare Planungseinheiten und geben einem die Möglichkeit, den eingeschlagenen Weg zu korrigieren. Es gibt nichts Schlimmeres, als über eine lange Zeit hinweg das Produkt am Kunden vorbei zu entwickeln. Die agile Vorgehensweise ermöglicht uns, nach jeder Iteration Feedback von den Stakeholdern einzuholen und es in die Planung der nächsten Sprints einfließen zu lassen. Um den Kundenfokus in den Mittelpunkt zu stellen und auch mit kurzen Zyklen qualitative Software zu entwickeln, werden die Tester in das Entwicklungsteam und den Sprint eingebettet. Die nahtlose Integration der Testing-Tools in den ALM-Prozess garantiert eine effiziente Umsetzung der Qualitätssicherung.

In diesem Artikel wollen wir aufzeigen, wie die Arbeit der Tester durch das Testmanagement mit dem Team Foundation Server und den passenden Visual-Studio-Werkzeugen optimiert werden kann. Dabei wird auf Fragestellungen rund um Testorganisation, Testplanung, Testfallerstellung und Testausführung eingegangen. Unsere Tipps und Tricks helfen Ihnen hoffentlich dabei, viele Stolpersteine beim Testmanagement mit dem TFS von Anfang an zu umgehen. Testmanagement ist keine wirklich neue Disziplin, war aber bedauerlicherweise in den letzten Jahrzehnten ein von der Entwicklung entkoppelter Fachbereich. Dabei fand die Trennung sowohl auf Prozess- und Organisations- als auch auf Werkzeugebene statt. Testen war für viele Entwicklungsabteilungen eine eigene Welt. In vielen Firmen arbeiteten Tester in separaten Teams und hatten dedizierte Prozesse und Werkzeuge. Im Verlauf der letzten Jahre hat sich dank agiler Methoden diese Trennung auf organisatorischer und prozesstechnischer Ebene schrittweise aufgelöst. In der Visual-Studio-Welt haben sich diese Änderungen ebenfalls niedergeschlagen: Beinhalteten die ersten TFS-Versionen 2005 und 2008 nur Source Control, Work Items und Build-Prozesse für Entwickler, markierte die Version 2010 einen Wendepunkt. TFS 2010 ermöglichte als erste Version die gleichberechtigte Zusammenarbeit von Entwicklern, Testern und Produktmanagement auf demselben Datenbestand, obwohl unterschiedlichste Programme eingesetzt wurden.

Abb. 1: Test Case im TFS Web Access Test Hub

Organisation und Erstellung von Tests

Die Grundlage für die Arbeit der Tester bilden Testfälle. Sie beschreiben einzeln auszuführende Testschritte sowie Prüfschritte zur Validierung der Ergebnisse. Das Ergebnis der Prüfschritte entscheidet über Bestehen oder Scheitern eines Testfalls. Im Fall von automatisierten Tests würde man hier von „Assert“ sprechen. Testfälle sind im TFS als so genannte Test Case Work Items abgebildet. Aufgrund dieses Ursprungs bringen Sie alle Funktionalitäten eines normalen Work Items mit, darunter ID, Historie, Zustandsmodell und Anpassbarkeit. An einigen Stellen unterscheiden sie sich aber dennoch von normalen Work Items. Test Cases verfügen im TFS über spezifische Work-Item-Felder zur Abbildung von Testmanagementprozessen. Die wichtigsten Unterschiede betreffen dabei die Felder „Teststeps“ und „Automation Status“, das eigene Statusmodell (Design -> Ready -> Closed) sowie die Möglichkeit, Testschritte und -parameter wiederzuverwenden. Abbildung 1 zeigt exemplarisch ein Test Case Work Item aus einem Demoteamprojekt. Das Work-Item-Feld „Steps“ bildet die manuellen Testschritte eines Testfalls ab. Der Detailgrad der Beschreibung kann hier je nach Einsatzfeld und Zielgruppe stark variieren. In der Praxis ist die Bandbreite von einer groben Schrittreihenfolge (z. B. MENÜ-FILE | NEW PROJECT | NEW USER) bis zum detaillierten Auflisten der einzelnen Schritte (z. B. Öffne Webseite unter URL: , Fülle Nutzer aus mit Name und , Speichere Datensatz, Prüfe Datensatz, Schließe Programm) alles zu finden. Wie auch in anderen Bereichen (z. B. Requirements-Engineering, Architektur) gibt es beim Spezifizieren von Testfällen kein richtig oder falsch, sondern viele feine Zwischenstufen.

Neben der reinen verbalen Beschreibung unterstützt das Steps-Feld auch die Verwendung von gemeinsamen Testschritten (Shared Steps) und Parametern (Shared Parameters). Mithilfe von Shared Steps können Schritte wiederverwendbar in Shared Steps Work Items ausgelagert werden. Diese speziellen Schritte können beliebig oft in andere Test Cases eingebettet werden. Klassiker in der Praxis sind das Starten sowie Initialisieren der Applikation und die Benutzeranmeldung. Diese elementaren Schritte finden sich normalerweise in jedem Testfall wieder. Dank der Auslagerung lässt sich Redundanz verhindern und die Wartung und Pflege vereinfachen. Shared Steps sind für den Tester wie Module für den Softwareentwickler. Test Cases unterstützen seit der ersten Version die Generalisierung von Testschritten über Parameter. Durch Verwendung von Parametern können ebenfalls unnötige Doppelungen von Testfällen vermieden werden. Jede Parameterdatenreihe führt zu einer eigenständigen Ausführung des Testfalls (Testiteration). Ein Parameter kann sehr einfach durch das Präfix @ gefolgt durch den Parameternamen erzeugt werden (z. B. @LoginName). Parametername und -werte konnten bis zum TFS 2013 Update 2 immer nur auf Test-Case-Ebene definiert und gespeichert werden. Waren identische Parameternamen und -werte in mehreren Test Cases notwendig, mussten diese manuell in jedem Test Case eingepflegt werden. Seit TFS 2013 Update 2 besteht nun die einfache Möglichkeit, auch Parameter über das Work Item namens Shared Parameter wiederverwendbar zu machen. Die Pflege und Wartung ist dabei wie bei den Shared Steps nur noch auf dem zentralen Shared Parameter Work Item Type notwendig. Die Arbeit, einzelne Work Items wegen einer Parameteraktualisierung zu ändern, entfällt.

Abb. 2: Hierarchische Organisation von Testartefakten im TFS

Das Erstellen von Test Cases ist eine Sache, das Organisieren eine andere. Wie geht man nun mit einer großen Menge an Test Cases um? TFS verfügt mit Testplänen und Test-Suites über ein Konzept zur Gruppierung und Organisation von Testfällen. Diese Mechanismen sind, projiziert auf die Windows-Welt, mit Ordnern und Ansichten vergleichbar. Testpläne sind die To-do-Listen der Tester. Sie ermöglichen die Organisation und Gruppierung von Testfällen nach Zeitphasen. Im TFS sind sie ebenfalls, wie alle anderen Work Items, zusätzlich über Iterationen und Areas gruppiert. Ein Testplan verfügt bzgl. der Metadaten stets über einen Eigentümer (Owner), ein Start- und Enddatum sowie einen Status (aktiv/inaktiv). Jedes TFS-Teamprojekt, das Testmanagement betreibt, sollte über mindestens einen Testplan verfügen. Organisatorisch sind Testpläne im TFS keine von den Entwicklungs- und Planungsdaten getrennte Einheit, sondern direkt unter den jeweiligen TFS-Teamprojekten aufgehängt (Abb. 2). Die nächste feinere Gruppierungseinheit unter den Testplänen sind Test-Suites. Ist der Testplan primär nach Produkt und Zeitraum gruppiert, wird jetzt nach fachlichen internen Kriterien gruppiert (z. B. nach Modulen oder Bereichen der Software). Es gibt drei Typen von Test-Suites:

  1. Test-Suites (statisch, wie ein Dateiordner)
  2. Requirements-based Test-Suites (Anforderungen, Backlog Items oder User Stories sind gleichzeitig Test-Suites und Testfälle werden automatisch im Hintergrund verlinkt)
  3. Query-based Test-Suites (eine Work-Item-Abfrage bildet die Grundlage für diese dynamische Test-Suite)

Gerade in sicherheitskritischen Projekten hat sich der erste Typ bewährt. Der Vorteil der verbleibenden zwei Typen ist im Testbereich auch gleichzeitig ihr Nachteil: Bei dynamischen Test-Suites kann sich der Inhalt und damit indirekt auch die Testergebnisse zu jeder Zeit ändern. Ein revisionssicheres Reporting ist damit nicht mehr gewährleistet.

Abb. 3: Standardmäßige Test-Suite-Struktur

In vielen Projekten folgen Testpläne und Test-Suites einer Standardstruktur (Abb. 3). Sie werden hier in die Kategorien automatische und manuelle Testfälle eingeordnet. Alle Testfälle im Bereich der automatisierten Tests werden über das TFS Lab Management ausgeführt. Die Einteilung in einen eigenen Bereich ermöglicht eine einfachere Auswahl der auszuführenden Tests für Lab Management Build-Deploy-Test-Workflows (LabDefaultTemplate.XAML). Hat ein Entwickler einen manuellen Testfall automatisiert, wird er vom manuellen in den automatisierten Bereich verschoben. Die Trennung in zwei Bereiche hat den Vorteil, dass sie sowohl eine getrennte als auch eine gemeinsame Auswertung möglich macht. Durch die einheitliche Organisation in einem Testplan kann bei der Planung ebenfalls Aufwand eingespart werden. In den zwei Hauptbereichen wird die Arbeit nach fachlichen Aspekten gruppiert, im Beispiel nach UI und Backend-Services. An dieser Stelle unterscheiden sich die Projekte in der Praxis am meisten. Ihre größte Gemeinsamkeit besteht darin, dass sich Test-Suite-Namen nach dem Area-Pfad-Namen richten. Durch diese Symmetrie ist die Navigation zwischen den Bereichen des Projekt- und Testmanagements relativ ähnlich. Wie in Abbildung 3 zu sehen, wurden die Test-Suite-Namen in den Hauptbereichen gleich gewählt. Auch hier war das Ziel, eine ähnliche Navigation zu ermöglichen.

An dieser Stelle bleibt noch eine wichtige Frage offen: Wie geht man mit Testplänen bei kleinen und großen Sprints bzw. Entwicklungsphasen um, ohne die Übersicht zu verlieren? In Projekten hat sich das Repository/Sprint-Test-Plan-Konzept als guter Weg herausgestellt. Dieses Modell geht von der Annahme aus, dass jedes Softwareprojekt über mindestens zwei Testpläne verfügt: einen Repository- und einen Sprintplan. Im Repository-Testplan werden alle aktuellen und relevanten Testfälle für eine Softwarehauptversion gesammelt und bearbeitet. Er bildet damit den primären Ort für die Testfallspezifikation. Werden existierende Testfälle obsolet bzw. durch neue Versionen ersetzt, dann wird diese Aktivität im Repository durchgeführt. Vorteilhaft ist hier, dass man stets einen guten Überblick über alle aktuellen und notwendigen Testfälle hat. Verlangt eine externe Organisation (z. B. TÜV, Kunde) Auskunft über alle aktuellen Testaktivitäten, kann diese dank des Repositorys schnell gegeben werden. Ein Export ist mit kostenlosen Werkzeugen wie dem eingebauten Web Access HTML Export (TFS 2013 Update 2) bzw. AIT WordToTFS ebenfalls schnell erledigt. Aus dem Repository-Testplan werden anschließend die Sprint-Testpläne erzeugt. Aufgrund begrenzter Ressourcen verfügen diese nur über eine Teilmenge der Testfälle des Repository-Testplans. Welche Testfälle schlussendlich Bestandteile des Sprints werden, entscheidet der Testmanager im Rahmen seiner Test- und Ressourcenplanung. Die Übernahme der Test-Suites und Test-Cases wird auf technischer Ebene in den meisten Fällen per „Copy by Referencing Existing Test Cases“ vorgenommen (Abb. 4). Bei diesem Verfahren werden die Testfälle nicht jedes Mal dupliziert, sondern nur als Referenzen übernommen. Das Ändern eines Testfalls würde sich auf den Repository-Testplan durchschlagen. Sind umfangreiche Anpassungen notwendig, die die Ausführung in der aktuellen Version signifikant ändern, wird empfohlen, ggf. das einzelne Test Case Work Item bzw. den Testplan zu klonen.

Abb. 4: Erstellen von Sprint-Testplänen per Copy-Methode

Das Gegenteil des Kopierens ist das Klonen („Clone a test plan“, Abb. 5). Dabei werden alle Testartefakte (Test-Suites, Testpläne, Test Cases, Requirements, User Stories) als neue unabhängige Elemente dupliziert. Durch die Duplizierung entsteht eine völlig getrennte unabhängige Baseline, sodass sich die Test Cases voneinander getrennt pflegen lassen. Dieser Vorgang ist vergleichbar mit dem Erzeugen eines Branches in der Source Control. Aufgrund der potenziell hohen Anzahl an neuen Work Items wird das Klonen in aller Regel nur beim Erzeugen von Testplänen für neue Hauptversionen angewandt (z. B. von Version 1.0 auf 2.0).

Abb. 5: Erstellen von Release-Testplänen per Clone-Methode

Aufmacherbild: Laboratory pipette with drop of liquid over glass von Shutterstock / Urheberrecht: Olivier Le Queinec

[ header = Seite 2: Manuelle Testausführung über Browser und Rich Client ]

Manuelle Testausführung über Browser und Rich Client

Nachdem die Testfälle definiert sind und die Ausführung geplant ist, geht es nun an das eigentliche Testen. Beim Microsoft Test Manager (MTM) handelt es sich um ein Schweizer Taschenmesser, sprich: Er wird für das Verwalten und Ausführen der Tests eingesetzt und kann zudem auch noch Lab Environments verwalten. Sobald die Testausführung gestartet wird, wandelt sich die Applikation in einen Testrunner am linken Bildschirmrand. Der Tester wird nun durch die zuvor definierten Testschritte geleitet und die definierten Parameter werden für die Testiteration mit den konkreten Werten befüllt.

Wo muss man also den MTM installieren, um die Applikation zu testen? Die Antwort ist aus Beratersicht relativ einfach: „Es kommt drauf an.“ Für die Testausführung stehen uns zwei grundlegende Varianten zur Verfügung: Wir können entweder den MTM oder über den Test Hub einen HTML-basierten Testrunner verwenden. Bei der ersten Variante hat man zudem noch die Wahl zwischen einer MTM-Installation auf der Arbeitsmaschine oder auf dem „System under Test“ (SuT). Wo liegen also die Unterschiede?

Testen mittels MTM hat den großen Vorteil, dass man so genannte „Rich Bugs“ auf Knopfdruck erstellen kann. Von Systeminformationen über Videoaufzeichnungen bis hin zu einem kompletten IntelliTrace-Log ist alles möglich, wodurch die Gefahr eines Bug-Pingpongs zwischen Tester und Entwickler reduziert wird. Mit all diesen zusätzlichen Informationen kann der Fehler problemlos reproduziert werden. Es liegt auf der Hand, dass der MTM auch auf diesem System, also dem SuT, installiert werden muss, wenn mehr und mehr systemnahe Informationen gesammelt werden. Testpuristen unter Ihnen sagen jetzt sicherlich, dass das SuT keinesfalls verändert und somit auch keine zusätzliche Software installiert werden darf. Für solche streng validierten Testsysteme hat Microsoft einen HTML-basierten Testrunner entwickelt, der in einem Browserfenster läuft und keinerlei Einfluss auf das darunterliegende Testsystem hat. Leider haben wir mit dieser Lösung aber auch keinen Zugriff auf das System und können keine Aktionen aufzeichnen oder Diagnoseadapter verwenden. Zudem ist zu bemerken, dass ein SuT auch aus mehreren Maschinen bestehen kann. Wird ein Lab-Environment verwendet, können mittels Testagent ebenfalls Daten von allen beteiligten Maschinen erfasst und rapportiert werden.

Als technische Komponenten für die Erstellung der Rich-Bugs sind sind so genannte Diagnoseadapter zuständig (Abb. 6). In den Test-Settings, die in einem Testplan für manuelle und automatisierte Testausführungen definiert werden können, sind die Einstellungen zu den zu verwendenden Diagnoseadaptern enthalten. Ein Diagnoseadapter schreibt während der Testausführung Daten mit und hängt sie den Testresultaten an. Beim Erstellen eines Bugs werden diese Daten ebenfalls übernommen.

Abb. 6: Diagnoseadapter im Microsoft-Testmanager

Zu beachten ist, dass einige Diagnoseadapter relativ große Datenmengen erfassen. Entsprechend ist hier eine klare Definition nötig, wann welche Adapter mit welchen Einstellungen verwendet werden sollen. Zudem ergibt es Sinn, einige Artefakte nur im Fehlerfall zu speichern. Ein guter Ansatz hierzu ist, verschiedene Testsettings zu erstellen, die dann je nach Situation referenziert werden können. Tabelle 1 zeigt einen möglichen Ansatz für die drei Profile „High“, „Standard“ und „Low“:

Profilname Diagnoseadapter
_High IntelliTrace (nur .NET) Code Coverage (nur ASP.NET) Action Log Screen- und Voice-Rekorder Event Log Systeminformation Code Coverage
_Standard Test Impact (nur .NET) Code Coverage (nur ASP.NET) Action Log Screen- und Voice-Rekorder Event Log Systeminformation
_Low Event Log Systeminformation

Tabelle 1: Test-Settings-Profile und Diagnoseadapter

Oft weisen komplexe Softwaresysteme Eigenheiten auf, die durch die Standarddiagnoseadapter nicht optimal berücksichtigt werden. Ein einfaches Beispiel hierzu wäre ein applikationsspezifisches Log, das gut zur Fehleranalyse oder -reproduzierung verwendet werden könnte. Die gute Nachricht ist, dass die Schnittstelle für Diagnoseadapter offen ist und entsprechend eigene Adapter erstellt und installiert werden können. Hierzu muss die Basisklasse DataCollector abgeleitet werden. Mittels Event Handler kann bis auf die Stufe „Test Step“ das Verhalten des Data Collectors implementiert werden. Für Clientmaschinen mit installiertem MTM kann zudem ein Konfigurationseditor implementiert werden, um über das Settings-UI die Einstellungen anzupassen. Zur Installation werden die Assemblies sowie die Konfigurationsdatei auf allen beteiligten Komponenten, also MTM sowie Test Agents, in das Plug-in-Verzeichnis kopiert.

Ein weiteres sehr nützliches Feature eines lokal auf dem Zielsystem installierten MTM ist die Record- und Replay-Funktionalität. Hierbei handelt es sich nicht um eine vollständige Testautomatisierungslösung, auch wenn die darunterliegende Technologie auf Coded UI aufsetzt. Vielmehr stellt das Action Recording sowie das spätere Abspielen der aufgezeichneten Schritte eine sehr effiziente Unterstützung für den manuellen Tester dar. Test Cases, mit mehreren Datenreihen sind oft mühsam, wenn wieder und wieder dieselben Aktionen hintereinander durchgeführt werden müssen oder ein komplexes Formular mit vielen Daten bestückt werden muss. Definierte Parameterwerte werden am aktuellen Verwendungspunkt vom Test Runner in die Zwischenablage kopiert, was Fehleingaben vermeidet. Mittels Action Recording können die Aktionen sowie das Parameter-Binding bei Dateneingaben zudem beim ersten Ausführen der Testschritte aufgezeichnet werden. Die nachfolgende erneute Ausführung des Test Cases bzw. der weiteren Testiterationen bei mehreren Datenreihen kann nun abgespielt werden. Hierbei werden die aufgezeichneten Schritte mittels Coded UI abgespielt und die gebundenen Datenwerte dynamisch eingefügt. Somit beschränkt sich die manuelle Interaktion des Testers primär auf die Verifikation des erwarteten Verhaltens.

Die gute Unterstützung durch den MTM geht auch beim Rapportieren eines Fehlers weiter. Wenn beim Ausführen des Testfalls ein Fehler festgestellt wird, kann mit einem Knopfdruck ein Bug Work Item erstellt werden (einen Beispielworkflow zeigt Abbildung 7). Hier zeigt der MTM gleich, was er alles bereits über den Fehler weiß. Neben der Referenz auf den Test Case wird ebenfalls rapportiert, bei welchem Schritt sich der Fehler ereignet hat. Sämtliche gesammelten Daten der Diagnoseadapter werden dem Bug als Attachments angefügt. Somit kann sich der Tester auf das Wesentliche konzentrieren und weitere spezifische Details zum Fehlverhalten dokumentieren – daher die große Informationsfülle der Testfälle, aufgrund derer der Entwickler effizient den Fehler korrigieren kann. Ist das SuT als virtuelles Lab-Environment aufgesetzt (System Center Virtual Machine Manager und Hyper-V sind Voraussetzungen), kann ebenfalls mit einem einfachen Klick ein Snapshot über alle beteiligten virtuellen Maschinen erstellt und der Link dazu dem Bug angefügt werden.

Abb. 7: Bugerfassung beim formalen Testen

[ header = Seite 3: Exploratives und formales Testen ]

Exploratives und formales Testen

In der Praxis haben sich zwei grundlegende Arten des Testens herausgebildet: exploratives und formales Testen. Abgrenzen lassen sich beide Arten anhand des Zeitpunkts von Testdesign und Testausführung. Beim formalen Testen finden diese Teilschritte nacheinander statt, d. h. zuerst werden Testfälle spezifiziert, geprüft, abgenommen und am Ende durch einen Tester ausgeführt. In Abhängigkeit vom Testergebnis gilt der Testfall dann als bestanden bzw. fehlgeschlagen. Formales Testen mit dem Testrunner über MTM bzw. den webbasierten Test Hub wurde im vorherigen Abschnitt vorgestellt. Im Gegensatz zum formalen Testen mit seinem hohen Formalisierungsgrad ist dieser beim explorativen Testen hingegen verhältnismäßig gering. Testdesign und Testausführung laufen hier in einem Schritt ab. Da keine Testfälle im Vorfeld existieren, ist diese Testart stark beeinflusst vom Erfahrungsschatz der Tester. So wird sie gerne in neuen bzw. sich schnell ändernden Bereichen eingesetzt. Bei einem solchen Hintergrund können oftmals im Vorfeld nicht alle bzw. keine Testfälle aufgestellt werden. Ein Beispiel aus der Praxis wäre, wenn der SW-Leiter Sie fragen würde, ob Sie sich mal das neue Feature bzw. die neueste Änderung im Dev Build anschauen können. In diesem Augenblick testen sie schon explorativ. Auch für das explorative Testen bietet der MTM eine native Sichtweise an (Abb. 8). Der agile Testrunner funktioniert dabei ähnlich wie ein virtueller Notizblock. Als Nutzer klickt man sich ohne vorgefertigtes Skript durch eine zu testende Anwendung. Während des Durchstreifens der Anwendung werden alle Aktionen auf der Oberfläche aufgezeichnet (Action Recording) und im Anschluss im TFS zentral archiviert. Neben dem Action Recording können auch Video- und Stimmaufzeichnungen sowie Screenshots ohne Zusatzprogramme erstellt werden.

Abb. 8: Exploratives Testen mit dem MTM

Bei der Entscheidung zwischen explorativ und formal ist erneut die typische Beraterantwort angebracht: „Es kommt drauf an.“ Je nach Umfeld können gesetzliche Vorgaben ein stark formales Vorgehen erzwingen. In nicht kritischen Bereichen hat sich aber ein grobes Verhältnis von 60:40 bewährt, d. h. 60 Prozent formales und 40 Prozent exploratives Testen. Formales Testen sichert dabei grundlegende Softwarefunktionalitäten ab (Regressionstests). Trotz aller guten Vorbereitung kommen Sie jetzt in der täglichen Arbeit zu der Problemstellung, dass Tests für existierende Funktionalitäten aufgrund einer gewachsenen Anwendungskomplexität schlichtweg vergessen wurden. Zusätzlich kennen auch Tester die Phänomene des Tunnelblicks und der Ressourcenknappheit. Wichtige und notwendige Tests werden deshalb bei der Testfallspezifikation teilweise aktiv bzw. passiv vergessen. Um nun die schwarzen Flecken des Unbekannten bzw. Undefinierten auszugleichen, mixen wir unseren Testprozess mit 40 Prozent des explorativen Testens. Durch die Kombination beider Verfahren wird schließlich das Gesamtrisiko reduziert.

Anpassung von Testartefakten (neu in TFS 2013 Update 3)

Wie bereits eingangs erwähnt, wurde mit TFS 2010 das Testing in den TFS integriert. Die Umsetzung der Artefakte wie Testplan oder Test-Suite weichen jedoch aus technischer Sicht von der Implementation der Work Items ab. Entsprechend waren bis jetzt keine Anpassungen und keine Änderungsverfolgung (Change Tracking) auf der Stufe des Testplans und der Test-Suite möglich. Mit Update 3 setzt Microsoft nun diese Forderung nach einer besseren Integration der Testartefakte in die Work-Item-Infrastruktur um. Neuerdings ist es möglich, Testpläne und Test-Suites anzupassen und entsprechend eigene Felder hinzuzufügen oder den Workflow auf die eigenen Bedingungen hin anzupassen. Demzufolge kann man sich vorstellen, den Status des Testplans von „Aktiv“ und „Inaktiv“ auf „In Bearbeitung“, „Bereit zum Testen“ und „Abgeschlossen“ zu erweitern oder zusätzliche Felder für den Audit hinzuzufügen. Des Weiteren unterliegen die Testartefakte demselben Change-Tracking-Modell wie alle Work Items. Entsprechend wird jede Änderung eines Feldwerts in der Work-Item-Historie aufgezeichnet und kann entsprechend nachverfolgt werden (Abb. 9 zeigt ein Beispiel). Alle weiteren Work-Item-Funktionalitäten wie Abfragen per Work Item Query oder die Benachrichtigungen per E-Mail (Alerts) stehen ebenfalls zur Verfügung.

Abb. 9: Work Item History eines Test Cases

Die Anpassungen an Testplan und Test-Suite erfolgen analog zur Anpassung von Work Items in TFS. Über das Kommandozeilentool witadmin.exe können die Work-Item-Definitionen herunter- bzw. hochgeladen werden. An dieser Stelle ist auch das TFS-Power-Tools-Add-On für Visual Studio zu empfehlen, das die Arbeit mit Work-Item-Definitionen erleichtert. Mit der Installation von Update 3 auf dem TFS werden bestehende Testpläne und Test-Suites automatisch in Work Items konvertiert.

Die Umstellung auf Work Items beinhaltet nicht nur die Anpassbarkeit, Abfragbarkeit und das Change Tracking, entsprechend wurden auch die Möglichkeiten zur Definition der Zugriffsrechte erweitert. Analog zu bestehenden Work Items können nun Berechtigungen basierend auf dem Area Path vergeben werden. Die neuen Area-Path-Berechtigungen „Manage Test Plans“ und „Manage Test Suites“ ermöglichen die Zugriffsteuerung auf den Testartefakten (Abb. 10). Basierend auf dem Area Path ist es möglich, verschiedenen Gruppen unterschiedlichen Zugriff auf Test-Suites innerhalb desselben Test-Plans zu geben.

Abb. 10: Berechtigungen der Testartefakte pro Area Path

Neben der direkten Möglichkeit zur Anpassung der Testartefakt-Work-Item-Typen bieten sich dank des TFS-Work-Item-APIs noch weitere spannende Möglichkeiten zur Optimierung und Automatisierung des Testprozesses. Beispiele aus der Praxis finden sich in diversen etablierten Werkzeugen, z. B. in freien und kommerziellen Erweiterungen wie AIT WordToTFS und TFS ASAP. Das Erstellen eines Test Cases wird aber auch mit dem TFS-API und den neuen Work-Item-Typen stets ein manueller Prozess bleiben. Gute Testfälle zu erstellen, bedingt schlussendlich menschliche Kreativität. Bei Verwaltungs- bzw. Fleißarbeiten sieht die Sache ganz anders aus: Hier bestehen viele Optimierungspotenziale zur Automatisierung von Tätigkeiten. Im Bereich Testmanagement wären dies exemplarisch:

  • Aggregieren von Testaufwänden vom Testfall zur Test-Suite zum Testplan
  • Publizieren von Statusinformationen vom Testfall zur Test-Suite zum Testplan
  • Automatisches Anlegen von Testplänen, -Suites und -Cases nach Vorlagen
  • Aktivieren/Deaktivieren von Testplänen am Anfang/Ende von Sprints
  • Sperren von Testfällen, Test-Suites und Testplänen

Fazit

Testmanagement auf Basis einer einheitlichen Plattform gemeinsam mit der Entwicklung und dem Produktmanagement war nie so einfach wie mit dem TFS 2013. Der TFS bildet dabei den kompletten Lifecycle über alle Phasen hinweg ab. Ein Fokus der aktuellsten Version ist, viele Funktionen über den Webbrowser ohne Installation zentral zur Verfügung zu stellen. Auch dieser Trend hat vor dem Testmanagement keinen Halt gemacht. Er hat es sogar beflügelt, indem alle Informationen einfach und für jeden zur Verfügung stehen. Dieser einfache Zugriff macht es wiederum für alle Beteiligten einfach, fehlerhafte oder fehlende Informationen zu korrigieren. Der Team Foundation Server 2013 bietet mit seinen webbasierten Testing-Tools sowie mit dem Microsoft Test Manager Werkzeuge für jeden Einsatzzweck und integriert die Tester optimal in den gesamten Application Lifecycle. Werkzeuge alleine machen aber noch kein gutes Testmanagement aus. Das Organisieren der Testfälle und das Planen der Durchführung mittels Repository- und Sprint-Test-Plänen schafft Übersichtlichkeit und eine einfache Testplanung. Die Möglichkeit, Testpläne und -Suites zu kopieren oder zu klonen, ermöglicht zudem das effiziente Verwalten der Testartefakte. Die Unterstützung für exploratives Testing mittels Microsoft Test Manager rundet das Anwendungsgebiet der Werkzeuge ab. Wir empfehlen hierzu einen Testmix nach der 60:40-Regel, um einen ausgewogenen Mix aus Risiko und Aufwand zu erhalten.

Der Exkurs in das neuste Update von TFS 2013 und dessen neue Möglichkeiten in Bezug auf Testmanagement demonstriert die noch bessere Einbindung der Testartefakte in die bekannte Work-Item-Infrastruktur. Als Beispiele sind hier die Anpassbarkeit sowie Automationsmöglichkeiten auf Basis des TFS API zu nennen, sodass man sich beim Testen auf die interessanten Fragestellungen anstatt auf Verwaltungsarbeit konzentrieren kann.

Testmanagement mit TFS im Laufe der Zeit Microsoft hat seine Prozesse im Verlauf der letzten Jahre massiv in Richtung einer regelmäßigen Veröffentlichung von neuen Funktionalitäten geändert. Gerade der Bereich Testmanagement mit TFS und VS hat von diesem Trend und neuen Features bzw. der Aufhebung von technischen Schulden profitiert. Die nachfolgende Auflistung soll Ihnen eine kleine Übersicht geben, was in welcher Version verfügbar ist.
TFS Funktionalität
TFS 2010 Microsoft Test Manager 2010 – Testmanagement, manuelle Testausführung
TFS 2012 MTM – Modus für exploratives Testen, Formatierungen für Testschritte, mehrzeilige Testschritte
TFS 2012.2 MTM – Clone per GUI, Editieren von Test Cases während der Testausführung, Pausieren der Testausführung, Unterstützung von Direct Links und Hierarchie bei der Work-Item-Auswahl
TFS 2012.4 Testmanager im TFS Web Access – nur Testausführung
TFS 2013 Testmanager im TFS Web Access – Unterstützung für Testmanagement und Testausführung
TFS 2013.2 Unterstützung von Shared Parameters, Export von Testplänen und -ergebnissen im Web Access
TFS 2013.3 Testpläne und Test-Suites als Work Items

Tabelle 2: Testmanagement-Funktionen in Abhängigkeit zur TFS-Version

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

1 Kommentar auf "Testmanagement mit Visual Studio und TFS"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Toralf Hochhold
Gast

Wie kann man es technisch umsetzen, dass die Sprinttestergebnisse auf den Testergebnissen der Revision Sammlungen abgebildet werden? Schließlich möchte man nicht am Ende des Sprints die Testergebnisse händisch in den Revision Suites nachtragen um auch dort einen aktuellen Stand zu haben. Zumal man die Ergebnisse der Revision-Sammlung gerne auch auf dem Dashboard als Diagramm zur Verfügung stellt.

X
- Gib Deinen Standort ein -
- or -