VSTS im Einsatz: Test & Qualitätssicherung

… von Microsoft erhältlichen Tools erzeugt
werden. In der VSTS-Community werden
vielfältige Anstrengungen unternommen,
einerseits das Editieren von Prozessvorlagen
zu erleichtern und andererseits „fertige“
Vorlagen für gängige Entwicklungsprozesse
(z.B. Scrum, RUP) zu erstellen.
Einige Tools und Prozessvorlagen sind
schon (kommerziell) erhältlich.

Work Items und Reporting

Work Items sind die zentralen Elemente
der TFS-Entwicklungsprozesse. Ein Work
Item ist ein Container für Informationen
aller Art, deren Status nachgehalten werden
soll. Die für ein Projekt relevanten
Work-Item-Typen sind als Teil einer Prozessvorlage
definiert, z.B. Task, Risk oder
Bug. Alle im Projektverlauf angelegten
Work Items werden in einer Datenbank gespeichert
und bilden die Basis für die Projektüberwachung.
Der Vorteil liegt auch
hier wieder darin, dass die Infos durch vordefinierte
oder angepasste Datenbankabfragen
oder Reports jedem Benutzer
über den integrierten Team-Explorer zur
Verfügung stehen. Somit kann jederzeit
z.B. eine Liste der gefundenen, in Arbeit
befindlichen oder erledigten Fehlermeldungen
abgerufen werden. Die Autoren
halten das Konzept der Work Items und
des zentralen Data Warehouse für sehr
mächtig. Beim Erstellen und Anpassen
von Reports stellt sich jedoch schnell heraus,
dass detaillierte SQL- oder MDXKenntnisse
erforderlich sind, da die Reporting-
Features des SQL Server 2005
direkt genutzt werden. Alleine der Umstand,
dass die „Description“ eines Work
Items nicht im Data Warehouse gespeichert
ist, erfordert zusätzlich den Zugriff
auf relationale Datenbanken und mündet
z.B. für einfache Iteration-Reports schnell
in komplexe SQL-Statements. Hier wäre
ein standardmäßig in VSTS integriertes
Reporting-Modul wünschenswert, das
z.B. auch Projektleiter in die Lage versetzt,
ohne SQL-Kenntnisse schnell und sicher
Reports erstellen zu können. Sind die Report-
Definitionen erst einmal erstellt, ist
die Nutzung der Reports sehr effektiv.

Abb. 1: Ein Beispiel für einen Report in VSTS
Einhaltung von Coding-Guidelines

Ein wichtiges Element von Entwicklungsprozessen
sind Richtlinien. Diese schreiben
ein bestimmtes Vorgehen oder Aspekte
vor, die genau so einzuhalten sind. Die beste
Richtlinie ist aber nutzlos, wenn die Umsetzung
nicht kontrolliert wird. Die Einhaltung
von Richtlinien wird deswegen meist
durch Reviews, also Überprüfungen, kontrolliert.
Eine weithin bekannte Review-Art
ist das Code-Review, das häufig „manuell“
durchgeführt: Ein Reviewer oder ein Review-
Gremium untersucht (schlimmstenfalls
ausgedruckten) Sourcecode auf die
Einhaltung von Coding-Guidelines. Das
Verfahren ist sehr zeitintensiv und fehleranfällig.
Selbst erfahrene Reviewer können
nicht reproduzierbar die vollständige
Einhaltung der Vorgaben sicherstellen. Besonders
im vorherrschenden Projektdruck
stellt diese manuelle Vorgehensweise ein
Risiko für die Software-Qualität dar. Denn
um dem Zeitdruck Rechnung zu tragen,
werden meist nur Stichproben durchgeführt
(die Auswahl der Stichproben sollte
in diesem Fall risikobasiert erfolgen, um
wenigstens die kritischen Teile des Codes
zu überprüfen). Aber gerade die Analyse
des Codes kann wesentlich zur Qualitätssicherung
beitragen und ist prädestiniert,
automatisiert zu werden. In diesem Bereich
unterstützt VSTS den Entwickler mit dem
Feature „Code Analysis“ (Abb. 2).

Abb. 2: Code Analysis in VSTS

Hinter diesem Feature versteckt sich
das bisher separat erhältliche Tool FxCop,
das von Microsoft in die Entwicklungsumgebung
integriert wurde und in den Projekteigenschaften
aktiviert werden kann.
Der Entwickler kann aus einer Fülle von
Regeln (aus elf Kategorien) diejenigen auswählen,
die überprüft werden sollen, und
jeden Regelverstoß per Voreinstellung als
Warnung oder als Fehler definieren. Die
Einhaltung der Regeln, die als notwendig
betrachtet werden, lässt sich auf diese Weise
bereits beim Kompilieren erzwingen.
Regelverstöße können auch selektiv unterdrückt
werden. Zu diesem Zweck bietet
das Kontextmenü der entsprechenden Warnung
in der „Error List“ nach dem Kompilieren
die Option Suppress Message(s).
Diese Regelausnahmen sollten jedoch begründet
und dokumentiert werden, damit
nicht sämtliche Warnungen auf diese Weise
„weggeklickt“ werden.

Zu beachten ist, dass die Codeanalyse
nicht den Code selbst überprüft, sondern die
kompilierte Assembly. Die Untersuchung
erfolgt über Reflection, sodass Formatierungsregeln
wie Kommentare, Reihenfolgen
von Methoden oder die Anzahl der
Leerzeilen zwischen Methoden nicht geprüft
werden können. Auch Namenskonventionen
für lokale Variablen können
nicht überprüft werden, da diese in der
Assembly nicht mehr enthalten sind. Der
Vorteil der Untersuchung der Assembly
liegt darin, dass das Regelwerk sprachunabhängig
ist und eigene Regeln implementiert und in VSTS eingebunden werden
können, die dann allen .NET-Sprachen zur
Verfügung stehen. …

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.