Qualitätsdashboard (Agile)

Artikel
06/10/2015

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.

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 SharePoint Server Enterprise Edition für das Teamprojektportal zulässig ist. Weitere Informationen finden Sie unter Dashboards.

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.

Um in Office Excel einen Bericht zu ändern, müssen Sie Mitglied der Sicherheitsrolle TfsWarehouseDataReaders in SQL Server Analysis Services sein, und Sie müssen 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 Readers 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.

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.

Informationen zu den den Webparts, die auf dem Qualitätsdashboard angezeigt werden, finden Sie in der Abbildung und der folgenden Tabelle.

Produktqualitätsdashboard

Hinweis

Der Bericht Testplanstatus ist erst verfügbar, wenn das Team Testpläne erstellt und Tests mit Test Runner und Microsoft Test-Manager ausführt.

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
	Gestapeltes Flächendiagramm mit den Testergebnissen aller Testfälle, 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 die einzelnen Zahlen auswählen. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.	Nicht zutreffend
	Liste der letzten Builds und ihrer Status. Sie können weitere Informationen anzeigen, indem Sie einen bestimmten Build wählen. Diese Liste wird von einem Team Web Access-Webpart abgeleitet. Legende: : Der Buildvorgang wurde nicht gestartet. : Der Buildvorgang wird ausgeführt. : Der Buildvorgang war erfolgreich. : Beim Buildvorgang ist ein Fehler aufgetreten. : Der Buildvorgang wurde beendet. : Der Buildvorgang war teilweise erfolgreich.	Ausführen, Überwachen und Verwalten von Builds
	Liste der letzten Eincheckvorgänge. Sie können weitere Informationen anzeigen, indem Sie einen bestimmten Eincheckvorgang wählen. Diese Liste wird von einem Team Web Access-Webpart abgeleitet.	Entwickeln von Code und Verwalten von ausstehenden Ä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 User Stories, und erstellen Sie Getestet von-Links zwischen Testfällen und User Stories.
Definieren Sie Testpläne und weisen Sie Testplänen Testfälle zu.
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.

Hinweis

Weitere Informationen zum Definieren von Bereichs- und Iterationspfaden finden Sie unter Hinzufügen und Ändern von Bereichs- und Iterationspfaden.

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 und Verwalten 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 Verwenden der Standardvorlage für Ihren Buildprozess.
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 Ausführen von Testläufen im Buildprozess.
Regelmäßiges Ausführen von Builds. 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 oder Bearbeiten einer Builddefinition und Ausführen, Überwachen und Verwalten von Builds.

Hinweis

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. Bei fortschreitender Entwicklung des Produkts sollten jedoch in den Tests umfassendere Szenarios und Integrationen untersucht werden. 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 und aktiviert behobene Fehler nicht erneut	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. Mit dieser Abfrage wird die Menge von Fehlern angezeigt, die gemeldet werden, die jedoch nicht durch Tests gefunden wurden und daher nicht für Regressionstests infrage 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:

Freigeben über