Qualitätsdashboard (CMMI)

Artikel
08/15/2011

Mit dem Qualitätsdashboard erhalten Sie eine Übersicht über den Status in den Bereichen Test, Entwicklung und Build im Bezug auf die Qualität der Software, die entwickelt wird. Mithilfe des Qualitätsdashboards kann das Team informierte Entscheidungen treffen, die die Teamziele im Zusammenhang mit der Produktqualität unterstützen.

Mit diesem Dashboard können Sie den Teststatus, Buildzustände, den Fortschritt beim Beheben und Schließen von Fehlern, die Rate der Fehlerreaktivierungen, den Prozentsatz des getesteten Codes und die Trends bei Codeänderungen überprüfen. Jede dieser Metriken wird für die letzten vier Wochen dargestellt.

Tipp

Sie greifen über das Teamprojektportal auf Dashboards zu. Sie können auf das Qualitätsdashboard nur zugreifen, wenn dieses Portal aktiviert wurde und die Verwendung von Microsoft Office SharePoint Server 2007 zulässig ist. Weitere Informationen finden Sie unter Dashboards (Agile) oder Zugreifen auf Teamprojektportale und Prozessleitfäden.

In diesem Thema

Im Dashboard angezeigte Daten
Erforderliche Aktivitäten zum Nachverfolgen der Qualität
Beheben von Qualitätsproblemen
Anpassen des Qualitätsdashboards

Sie können mit diesem Dashboard die folgenden Fragen beantworten:

Verlaufen die Tests nach Plan?
Testet das Team die richtige Funktionalität?
Sind die Fehlerkorrekturen des Teams von hoher Qualität?
Sind Tests veraltet?
Verfügt das Team über ausreichende Tests?
Treten Engpässe auf?

Erforderliche Berechtigungen

Zum Anzeigen des Dashboards müssen Sie einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der in SharePoint-Produkte die Berechtigung Lesen für das Teamprojekt zugewiesen wurde. Zum Ändern, Kopieren oder Anpassen eines Dashboards müssen Sie einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der in SharePoint-Produkte die Berechtigung Mitglieder für das Teamprojekt zugewiesen wurde. Weitere Informationen finden Sie unter Hinzufügen von Benutzern zu Teamprojekten.

Zum Ändern eines Berichts in Office Excel müssen Sie Mitglied der TfsWarehouseDataReaders-Sicherheitsrolle in SQL Server Analysis Services sein und einer Gruppe zugewiesen sein oder zu einer Gruppe gehören, der die Berechtigung Mitglieder in SharePoint-Produkte für das Teamprojekt zugewiesen wurde. Weitere Informationen finden Sie unter Gewähren von Zugriff auf die Datenbanken des Data Warehouse für Visual Studio ALM.

Zum Anzeigen einer Arbeitsaufgabe müssen Sie Mitglied der Gruppe Leser sein, oder die Berechtigung Arbeitsaufgaben in diesem Knoten anzeigen muss auf Zulassen festgelegt sein. Zum Erstellen oder Ändern einer Arbeitsaufgabe müssen Sie Mitglied der Gruppe Contributors sein, oder die Berechtigung Arbeitsaufgaben in diesem Knoten bearbeiten muss auf Zulassen festgelegt sein. Weitere Informationen finden Sie unter Verwalten von Berechtigungen.

Im Dashboard angezeigte Daten

Teammitglieder können mithilfe des Qualitätsdashboards die Gesamtqualität des entwickelten Produkts bestimmen. Im Idealfall zeigen Testerfolgsquoten, Fehler und Codeänderungen das gleiche Bild, häufig ist dies jedoch nicht der Fall. Wenn Sie eine Diskrepanz feststellen, müssen Sie den entsprechenden Build und die Datenreihe genauer untersuchen. Im Qualitätsdashboard werden die Testergebnisse, die Codeabdeckung aus Tests, Codeänderungen und Fehler kombiniert, sodass die Ergebnisse aus vielen Perspektiven betrachtet werden können.

Insbesondere werden in diesem Dashboard die Webparts angezeigt, die in der folgenden Abbildung dargestellt und in der folgenden Tabelle beschrieben werden.

Produktqualitätsdashboard

Tipp

Der Bericht Testplanstatus ist erst verfügbar, wenn das Team Testpläne erstellt und Tests mit Test Runner und Microsoft Test Manager ausführt. Informationen zum Definieren von Testsammlungen und Testplänen finden Sie unter Organisieren von Testfällen in Testsammlungen.

Status, Build- und Codediagramme und die Berichte Schritt 1 bis Schritt 6 werden nicht angezeigt, wenn das Data Warehouse für das Teamprojekt nicht verfügbar ist.

Weitere Informationen zum Interpretieren, Aktualisieren und Anpassen der im Qualitätsdashboard angezeigten Diagramme finden Sie in den Themen in der folgenden Tabelle.

Webpart	Angezeigte Daten	Verwandtes Thema
	Ein gestapeltes Flächendiagramm der Testergebnisse aller Tests, gruppiert nach dem letzten während der letzten vier Wochen aufgezeichneten Ergebnis (Nie Ausgeführt, Blockiert, Fehler oder Erfolgreich).	Bericht "Testplanstatus"
	Gestapelte Säulen, die die Anzahl der Builds mit dem Ergebnis Fehler oder Erfolgreich in den letzten vier Wochen darstellen.	Excel-Bericht Buildstatus
	Ein gestapeltes Flächendiagramm der kumulierten Anzahl aller Fehler während der letzten vier Wochen, gruppiert nach Zustand.	Excel-Bericht Fehlerstatus
	Ein gestapeltes Flächendiagramm der Anzahl von Fehlern, die das Team während der letzten vier Wochen aus dem Zustand "Gelöst" oder "Geschlossen" reaktiviert hat.	Excel-Bericht "Fehlerreaktivierungen"
	Ein Liniendiagramm, das den Prozentsatz des Codes darstellt, der in den letzten vier Wochen mit Buildüberprüfungstests (BVT) und anderen Tests getestet wurde.	Excel-Bericht Codeabdeckung
	Ein gestapeltes Flächendiagramm, das darstellt, wie viele Codezeilen das Team in den Eincheckvorgängen vor dem Build in den letzten vier Wochen hinzugefügt, entfernt und geändert hat.	Excel-Bericht Codeänderung
	Liste bevorstehender Ereignisse. Diese Liste wird von einem SharePoint-Webpart abgeleitet.	Nicht zutreffend
	Anzahl der aktiven, gelösten und geschlossenen Arbeitsaufgaben. Sie können die Liste der Arbeitsaufgaben öffnen, indem Sie auf die einzelnen Zahlen klicken. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.	Arbeitsaufgaben und Workflow (CMMI)
	Liste der letzten Builds und ihrer Status. Sie können weitere Informationen anzeigen, indem Sie auf einen bestimmten Build klicken. Diese Liste wird von einem Team Web Access-Webpart abgeleitet. Legende: : Der Buildvorgang wird ausgeführt. : Der Buildvorgang wurde nicht gestartet. : Der Buildvorgang war erfolgreich. : Der Buildvorgang ist fehlgeschlagen. : Der Buildvorgang wurde beendet. : Der Buildvorgang war teilweise erfolgreich.	Verwalten und Anzeigen von abgeschlossenen Builds
	Liste der letzten Eincheckvorgänge. Sie können weitere Informationen anzeigen, indem Sie auf einen bestimmten Eincheckvorgang klicken. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.	Verwenden der Fenster Einchecken und Ausstehende Änderungen

Erforderliche Aktivitäten zum Überwachen der Qualität

Damit das Qualitätsdashboard nützlich und genau ist, muss das Team die in diesem Abschnitt beschriebenen Aktivitäten ausführen.

Erforderliche Aktivitäten zum Nachverfolgen des Testplanstatus

Damit der Bericht "Testplanstatus" hilfreich und genau ist, muss das Team die folgenden Aktivitäten ausführen:

Definieren Sie Testfälle und Anforderungen, und erstellen Sie Getestet von-Links zwischen Testfällen und Anforderungen.
Definieren Sie Testpläne, und weisen Sie Testplänen Testfälle zu. Weitere Informationen finden Sie unter Definieren des Testaufwands mit Testplänen.
Markieren Sie bei manuellen Tests die Ergebnisse jedes Validierungsschritts im Testfall als erfolgreich oder fehlgeschlagen.

Wichtig

Tester müssen einen Testschritt mit einem Status markieren, wenn es sich um einen Validierungstestschritt handelt. Das Gesamtergebnis für einen Testfall gibt den Status aller vom Tester markierten Testschritte wieder. Wenn der Tester einen Testfall als fehlerhaft oder gar nicht markiert hat, weist der Testfall daher den Status "Fehler" auf.

Bei automatisierten Tests wird jeder Testfall automatisch als erfolgreich oder fehlgeschlagen markiert.
(Optional) Weisen Sie jedem Testfall die Pfade Iteration und Bereich zu, damit nach diesen Feldern gefiltert werden kann.

Tipp

Weitere Informationen zum Definieren von Bereichs- und Iterationspfaden finden Sie unter Erstellen und Ändern von Bereichen und Iterationen.

Erforderliche Aktivitäten zum Nachverfolgen des Fehlerstatus und der Fehlerreaktivierungen

Damit die Berichte "Fehlerstatus" und "Fehlerreaktivierungen" hilfreich und genau sind, muss das Team die folgenden Aktivitäten ausführen:

Definieren Sie Fehler.
Aktualisieren Sie den Zustand jedes Fehlers, wenn er vom Team behoben, überprüft, geschlossen oder reaktiviert wird.
(Optional) Geben Sie die Pfade für Iteration und Bereich für jeden Fehler an, wenn Sie nach diesen Feldern filtern möchten.

Erforderliche Aktivitäten zum Nachverfolgen von Buildstatus, Codeabdeckung und Codeänderung

Damit die Berichte "Buildstatus", "Codeabdeckung" und "Codeänderung" nützlich und genau sind, müssen die Teammitglieder die folgenden Aktivitäten ausführen:

Konfigurieren Sie ein Buildsystem. Für die Verwendung von Team Foundation Build muss ein Buildsystem eingerichtet werden.

Weitere Informationen finden Sie unter Konfigurieren des Buildsystems.
Erstellen Sie Builddefinitionen. Sie können eine Reihe von Builddefinitionen erstellen und dann jede dieser Definitionen ausführen, um Code für eine andere Plattform zu erzeugen. Zudem können Sie jeden Build für eine andere Konfiguration ausführen.

Weitere Informationen finden Sie unter Definieren des Buildprozesses.
Definieren Sie Tests, die automatisch als Teil des Builds ausgeführt werden. Sie können im Rahmen der Builddefinition Tests definieren, die als Teil des Builds ausgeführt werden oder einen Fehler auslösen sollen, wenn die Tests fehlschlagen.

Weitere Informationen finden Sie unter Definieren eines Builds mithilfe der Standardvorlage.
Konfigurieren Sie Tests zum Erfassen von Codeabdeckungsdaten. Damit Codeabdeckungsdaten im Bericht angezeigt werden, müssen Teammitglieder Tests zum Erfassen dieser Daten instrumentieren.

Weitere Informationen finden Sie unter Gewusst wie: Konfigurieren von Codeabdeckung mithilfe von Testeinstellungen für automatisierte Tests und SO WIRD'S GEMACHT: Codeabdeckung Daten mit generischen Tests sammeln.
Führen Sie regelmäßig Builds aus. Sie können Builds in regelmäßigen Intervallen oder nach jedem Einchecken ausführen. Mit dem Zeitplantrigger können regelmäßige Builds erstellt werden.

Weitere Informationen finden Sie unter Erstellen einer einfachen Builddefinition und Ausführen und Überwachen von Builds.

Tipp

Teammitglieder können Builds zwar manuell mit Build Explorer bewerten, diese Bewertung wird im Bericht "Buildqualitätsindikatoren" jedoch nicht wiedergegeben. Die Buildbewertung wird im Bericht "Buildzusammenfassung" angezeigt. Weitere Informationen finden Sie unter Beurteilen der Qualität eines abgeschlossenen Builds und Bericht "Buildzusammenfassung".

Beheben von Qualitätsproblemen

In der folgenden Tabelle werden bestimmte Qualitätsprobleme beschrieben, die Sie mit dem Qualitätsdashboard überwachen können, um Maßnahmen zu bestimmen, die das Team ergreifen kann.

Problem	Zu überprüfende Berichte	Hinweise zur Problembehandlung
Buildfehler	Buildstatus	Ein nächtlicher Build ist für Softwareentwicklungsprojekte unerlässlich. Wenn Builds nicht erfolgreich abgeschlossen werden oder Buildüberprüfungstests (BVT) nicht bestehen, muss das Team das Problem sofort beheben.
Fehler bei Tests	Testplanstatus Codeänderung	Wenn die Raten von fehlgeschlagenen Tests und Codeänderungen hoch sind, sollte das Team überprüfen, weshalb bei der Software so häufig Fehler auftreten. Mögliche Ursachen sind die fehlende Einhaltung von Richtlinien für die Entwicklung oder Tests, die für einen frühen Iterationszyklus zu streng sind.
Tests werden bestanden, es werden jedoch viele Fehler gefunden	Testplanstatus Fehlerstatus	Wenn im gleichen Zeitraum viele Tests erfolgreich sind, jedoch auch viele Fehler gefunden werden, kann das Team die folgenden Möglichkeiten untersuchen: Die Tests sind möglicherweise nicht streng genug für die aktuelle Produktphase. In frühen Iterationen sind einfache Tests gut. Mit zunehmender Reife des Produkts sollten die Tests jedoch umfassendere Szenarien und Integrationen abdecken. Die Tests sind möglicherweise veraltet oder testen die falsche Funktionalität. Andere Testverfahren könnten zu besseren Ergebnissen führen. Fehler werden gemeldet, waren jedoch nicht Teil des Tests. Wenn Fehler gemeldet werden, die nicht mit einem Testfall verknüpft sind, unterliegen sie keinen Regressionstests.
Veraltete Tests	Testplanstatus Codeabdeckung Codeänderung	Wenn viele Tests erfolgreich sind, viel Code geändert wird und die Codeabdeckung abnimmt, führt das Team möglicherweise keine Tests aus, in denen der neue Code berücksichtigt wird. Da Tests nicht so schnell entwickelt werden, wie sich der Code ändert, kann die Testabdeckung abnehmen.
Das Team testet, schließt oder reaktiviert behobene Fehler nicht	Fehlerstatus	Wenn im Bericht "Fehlerstatus" eine Zunahme der behobenen Fehler festzustellen ist, werden Fehler von Entwicklern behoben, aber nicht von Testern überprüft und geschlossen. Das Team sollte überprüfen, weshalb dieses Muster entstanden ist.
Zu wenige Tests	Testplanstatus Codeänderung	Wenn das Team wenige Tests ausführt, die Codeänderung hoch und die Codeabdeckung niedriger als erwartet ist, muss das Team möglicherweise mehr Ressourcen für Tests zuweisen. Außerdem sollte das Team sicherstellen, dass sich die Tester auf die gleichen Funktionen konzentrieren wie der Rest des Teams.
Reaktivierungen	Fehlerreaktivierungen	Wenn das Team viele oder zunehmend viele Fehler reaktiviert, lehnen Tester die Korrekturen von Entwicklern häufig ab. Das Team muss auf diese Probleme reagieren, um zu vermeiden, dass viele Ressourcen für die erneute Bearbeitung der abgelehnten Korrekturen zugewiesen werden müssen. Mögliche Ursachen sind eine schlechte Fehlerberichterstellung, ein schlechtes Test-Lab-Management oder eine zu strenge Selektierung.
Unzulängliche Komponententests	Codeabdeckung Codeänderung	Wenn eine Abnahme der Codeabdeckung mit einer Erhöhung der Codeänderungen einhergeht, checken die Entwickler möglicherweise Code ohne entsprechende Komponententests für die Abdeckung ein. In den meisten Fällen sollte die Codeabdeckung sich an 100 % annähern, wenn das Team eine testgesteuerte Entwicklung oder ähnliche Verfahren einsetzt. Wenn Komponententests als BVTs wiederverwendet werden, sollte die Codeabdeckung in den entsprechenden Berichten angezeigt werden.

Anpassen des Qualitätsdashboards

Sie können das Qualitätsdashboard folgendermaßen anpassen:

Ändern Sie die Filter für jeden Excel-Bericht, um bestimmte Produktbereiche oder Iterationen in den Fokus zu rücken.
Fügen Sie ein benutzerdefiniertes Abfragewebpart hinzu, mit dem die Liste der von der Abfrage zurückgegebenen Arbeitsaufgaben angezeigt wird. Sie können z. B. eine Abfrage hinzufügen, mit der alle aktiven Fehler aufgeführt werden, die nicht mit einem Testfall verknüpft sind. Diese Abfrage gibt die Anzahl von Fehlern zurück, die gemeldet werden, aber nicht durch Tests gefunden wurden und daher nicht für Regressionstests in Frage kommen.
Fügen Sie dem Dashboard vorhandene Excel-Berichte hinzu, z. B. Fehlertrends und Fehleranalyse.

Weitere Informationen zum Arbeiten mit Berichten in Office Excel und zum Anpassen dieser Berichte finden Sie auf den folgenden Seiten der Microsoft-Website: