Teilen über

Definieren, Erfassen, Selektieren und Verwalten von Softwarefehlern in Azure Boards

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Wie können Sie Fehler in Ihrem Code nachverfolgen und verwalten? Wie stellen Sie sicher, dass Softwareprobleme und Kundenfeedback schnell behoben und umgesetzt werden, um qualitativ hochwertige Softwarebereitstellungen zu unterstützen? Wie machen Sie gute Fortschritte bei neuen Features, und wie gehen Sie Ihre technischen Schulden an?

Sie benötigen mindestens eine Möglichkeit, um Ihre Softwareprobleme zu erfassen, sie zu priorisieren, einem Teammitglied zuzuweisen und den Fortschritt nachzuverfolgen. Sie sollten Ihre Codefehler auf eine Weise verwalten, die mit Ihren Agile-Methoden in Einklang steht.

Um diese Szenarien zu unterstützen, stellt Azure Boards einen spezifischen Arbeitselementtyp zur Nachverfolgung von Codefehlern mit dem Namen Bug (Fehler) bereit. Fehlerarbeitselemente besitzen alle Standardmerkmale, über die andere Arbeitselementtypen auch verfügen, sowie ein paar mehr. Eine Übersicht über Standardfeatures finden Sie unter Informationen zu Arbeitselementen und Arbeitselementtypen.

Fehler bieten auch folgende Features:

  • Optionen für jedes Team, um auszuwählen, wie es Fehler nachverfolgt möchte
  • Testtools zum Erfassen von Fehlern
  • Integrierte Integration in Azure DevOps zum Nachverfolgen von Fehlern im Zusammenhang mit Builds, Releases und Tests

Hinweis

Fehlerarbeitselement-Typen sind im Basic-Prozess nicht verfügbar. Der Basic-Prozess verfolgt Fehler als Probleme nach und ist verfügbar, wenn Sie ein neues Projekt aus Azure DevOps Services oder Azure DevOps Server 2019.1 oder höher erstellen.

Voraussetzungen

  • Projektzugriff: Sie müssen einem Projekt hinzugefügt sein.

  • Berechtigungen:

    • Die Berechtigungen Arbeitselemente in diesem Knoten anzeigen und Arbeitselemente in diesem Knoten bearbeiten müssen für Sie auf Zulassen festgelegt sein. Standardmäßig sind diese Berechtigungen für die Gruppe Mitwirkende festgelegt. Weitere Informationen finden Sie unter Festlegen von Berechtigungen für die Arbeitsnachverfolgung.

    • Um Arbeitselementen neue Tags hinzufügen zu können, benötigen Sie mindestens Basic-Zugriff, und die Berechtigung Neue Tagdefinition erstellen auf Projektebene muss auf Zulassen festgelegt sein. Die Gruppe Mitwirkende verfügt standardmäßig über diese Berechtigung.

      Hinweis

      Projektbeteiligte können aufgrund ihrer Zugriffsebene auch dann keine neuen Tags hinzufügen, wenn die Berechtigung explizit festgelegt ist. Weitere Informationen finden Sie unter Kurzreferenz zu Beteiligtenzugriff.

  • Arbeitselemente per E-Mail senden: Alle Projektmitglieder, einschließlich derjenigen in der Gruppe Leser, können E-Mails senden, die Arbeitselemente enthalten.

Tipp

Um einen Fehler melden zu können, muss ein Benutzer mindestens über Zugriff vom Typ Stakeholder verfügen. Für einen Benutzer muss die Berechtigung Arbeitselemente in diesem Knoten bearbeiten für den Bereichspfad, an dem der Fehler hinzugefügt wird, auf Zulassen festgelegt sein. Weitere Informationen finden Sie unter Festlegen von Berechtigungen für die Arbeitsnachverfolgung.

Arbeitselementtyp „Fehler“ (Bug)

Die folgende Abbildung zeigt den Fehler-Arbeitselementtyp für den Scrum-Prozess. Der Arbeitselementtyp „Bug“ für Agile- und CMMI-Prozesse (Capability Maturity Model Integration) verfolgt ähnliche Informationen nach. Er wird im Product Backlog zusammen mit Anforderungen oder im Taskboard zusammen mit Aufgaben angezeigt.

Hinweis

Die Anzeige in Ihrem Webportal kann sich von den Screenshots in diesem Artikel unterscheiden. Diese Unterschiede ergeben sich aus an Ihrer Web-App vorgenommenen Aktualisierungen, Optionen, die Sie oder Ihr Administrator aktiviert haben, sowie daraus, welcher Prozess beim Erstellen Ihres Projekts ausgewählt wurde: Agile, Basic, Scrum oder CMMI. Der Basic-Prozess ist mit Azure DevOps Server 2019, Update 1 und höheren Versionen verfügbar.

Screenshot: Formular für Arbeitselementtyp „Bug“ für Scrum-Prozess in Azure DevOps Server 2020 und Clouddienst

Screenshot: Formular für Arbeitselementtyp „Bug“ für Scrum-Prozess in Azure DevOps Server 2019

Fehlerspezifische Felder

Der Arbeitselementtyp „Fehler“ verwendet einige fehlerspezifische Felder. Verwenden Sie die in der folgenden Tabelle beschriebenen Felder, um sowohl das anfängliche Problem als auch die laufenden Ermittlungen und Erkenntnisse zu erfassen. Informationen zu Feldern, die für den für den CMMI-Prozess (Capability Maturity Model Integration) definierten Fehler spezifisch sind, finden Sie unter Feldreferenz für Fehler, Probleme und Risiken. Informationen zu allen anderen Feldern finden Sie unter Index der Arbeitselementfelder.

Feld, Gruppe oder Registerkarte

Verwendung

Schritte zum Reproduzieren (Anzeigename=Repro-Schritte)

Erfassen Sie hier genügend Informationen, damit andere Teammitglieder den Codefehler vollständig verstehen können. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens.

SysteminformationenGefunden in Build

Informationen zur Software und zur Systemkonfiguration, die für den Fehler und anzuwendende Tests relevant sind. Die Felder Systeminformationen und In Build gefunden werden automatisch ausgefüllt, wenn Sie einen Fehler über ein Testtool erstellen. Diese Felder geben Informationen zur Softwareumgebung und dem Build an, in der/dem der Fehler aufgetreten ist. Weitere Informationen finden Sie unter Testen verschiedener Konfigurationen.

Akzeptanzkriterien

Geben Sie die Kriterien an, die erfüllt werden müssen, bevor der Fehler geschlossen werden kann. Beschreiben Sie vor Beginn der Arbeit die Kundenakzeptanzkriterien so klar wie möglich. Teams sollten diese Kriterien als Grundlage für Akzeptanztests verwenden und um zu bewerten, ob ein Element zufriedenstellend abgeschlossen wurde.

In den Build integriert

Gibt den Namen des Builds an, der den Code enthält, mit dem der Fehler korrigiert wird. Dieses Feld sollte angegeben werden, wenn Sie den Fehler auflösen.

Für Azure DevOps in der lokalen Umgebung: Wenn Sie auf ein Dropdownmenü aller Builds zugreifen möchten, die ausgeführt wurden, können Sie die FIELD-Definitionen für Gefunden in Build und In den Build integriert aktualisieren, um eine globale Liste heranzuziehen. Die globale Liste wird jedes Mal automatisch aktualisiert, wenn der Build ausgeführt wird. Weitere Informationen finden Sie unter Auf Build- und Testintegrationsfeldern basierende Abfrage.

Informationen zum Definieren von Buildnummern finden Sie unter Konfiguration klassischer Pipelines.

Priorität1

  • 1: Das Produkt erfordert eine erfolgreiche Auflösung des Arbeitselements, bevor es ausgeliefert wird, und muss bald behoben werden.
  • 2: Das Produkt erfordert eine erfolgreiche Auflösung des Arbeitselements, bevor es ausgeliefert wird, muss aber nicht sofort behandelt werden.
  • 3: Die Auflösung der Arbeitsaufgabe ist optional, basierend auf Ressourcen, Zeit und Risiko.

Schweregrad1

Eine subjektive Bewertung der Auswirkungen eines Fehlers oder Arbeitselements auf das Projekt oder Softwaresystem. Beispiel: Wenn ein Remotelink auf der Benutzeroberfläche dazu führt, dass eine Anwendung oder Webseite abstürzt (was selten vorkommt, aber eine äußerst negative Kundenerfahrung darstellt), können Sie Schweregrad = 2 – Hoch und Priorität = 3 angeben. Zulässige Werte und vorgeschlagene Richtlinien sind:

  • 1 – Kritisch: Muss korrigiert werden. Ein Fehler, der eine oder mehrere Systemkomponenten oder das gesamte System beendet oder zu einer umfangreichen Datenbeschädigung führt. Es gibt keine akzeptablen Alternativmethoden, um die erforderlichen Ergebnisse zu erzielen.
  • 2 – Hoch: Korrektur erwägen. Ein Fehler, der eine oder mehrere Systemkomponenten oder das gesamte System beendet oder zu einer umfangreichen Datenbeschädigung führt. Es gibt eine akzeptable Alternativmethode, um die erforderlichen Ergebnisse zu erzielen.
  • 3 – Mittel: (Standard) Ein Fehler, der dazu führt, dass das System fehlerhafte, unvollständige oder inkonsistente Ergebnisse erzeugt.
  • 4 – Niedrig: Ein kleiner oder kosmetischer Fehler, für den es akzeptable Problemumgehungen gibt, um die erforderlichen Ergebnisse zu erzielen.

Bereitstellung

Das Deployment-Steuerelement (Bereitstellung) unterstützt Links zu und die Anzeige von Releases, die Arbeitselemente enthalten. Um das Steuerelement verwenden zu können, müssen Sie Einstellungen für das Release aktivieren. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Verknüpfen von Arbeitselementen mit Releases.

Entwicklung

Das Development-Steuerelement (Entwicklung) unterstützt Links zu Entwicklungsobjekten sowie die Anzeige von Links, die zu Entwicklungsobjekten erstellt wurden. Zu diesen Objekten gehören Git-Commits und Pull Requests oder TFVC-Changesets sowie versionierte Elemente. Sie können Links aus dem Arbeitselement oder aus den Commits, Pull Requests oder anderen Entwicklungsobjekten definieren. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Verknüpfen von Arbeitselementen mit der Entwicklung.

Hinweise

1 Informationen zum Ändern der Menüauswahl oder der Auswahlliste finden Sie unter Anpassen der Arbeitsnachverfolgung. Die Anpassungsmethode hängt vom Prozessmodell ab, das von Ihrem Projekt verwendet wird.

Auswählen, wie Ihr Team Fehler nachverfolgt

Ihr Team kann Fehler als Anforderungen oder als Aufgaben nachverfolgen. Berücksichtigen Sie die folgenden Faktoren, um die Teamauswahl zu unterstützen.

  • Größe Ihres Teams. Kleinere Teams können den Speicherbedarf schlanker halten, indem sie Fehler als Anforderungen nachverfolgen.
  • Organisationsanforderungen zum Nachverfolgen von Arbeit. Wenn Ihr Team Stunden erfassen muss, entscheiden Sie sich für die Nachverfolgung von Fehlern als Aufgaben.
  • Strukturierung der Arbeit Ihres Teams. Wenn Ihr Team auf das Product Backlog angewiesen ist, um die Arbeit zu priorisieren und Fehler hinzuzufügen, verfolgen Sie Fehler als Anforderungen nach.
  • Tools, die Ihr Team verwenden möchte, z. B. den Bereich „Planung“, das Velocity-Diagramm, Prognose, Rollup und Lieferpläne. Durch das Nachverfolgen von Fehlern als Aufgaben wird die Verwendung mehrerer dieser Tools ausgeschlossen.

In der folgenden Tabelle sind die drei Optionen zusammengefasst, die Teams zum Nachverfolgen von Fehlern haben. Weitere Informationen und Informationen zum Festlegen der Option für Ihr Team finden Sie unter Anzeigen von Fehlern in Backlogs und Boards.

Option

Für diese Zwecke geeignet...

Fehlern als Anforderungen nachverfolgen

Hinweis

  • Fehler werden der Kategorie „Anforderungen“ zugewiesen

Fehler als Aufgaben nachverfolgen

  • Arbeitsaufwand für Fehler ähnlich zu Aufgaben schätzen
  • Fehlerstatus in Sprint Taskboards aktualisieren
  • Fehler mit Anforderungen als untergeordnete Elemente verknüpfen
  • Fehler in den Planungsbereich ziehen, um Fehler einem Sprint zuzuweisen

Hinweis

  • Fehler werden der Kategorie „Aufgaben“ zugewiesen
  • User Storys (Agile), Product Backlog Items (Scrum) oder Anforderungen (CMMI) sind die natürlichen übergeordneten Arbeitselementtypen für Fehler
  • Fehler werden in Lieferplänen nicht angezeigt.

Fehler werden weder in Backlogs noch Boards angezeigt

  • Fehlern mithilfe von Abfragen verwalten

Hinweis

  • Fehler sind der Kategorie „Bugs“ zugeordnet und werden weder in Backlogs noch in Boards angezeigt.
  • Fehler werden weder in Backlogs noch in Boards, Sprintbacklogs, Taskboards oder Lieferplänen angezeigt.
  • Sie können Fehler nicht in den Planungsbereich ziehen, um sie einem Sprint zuzuweisen.

Arbeitselementtyp anpassen

Sie können den Fehler und andere Arbeitselementtypen anpassen. Oder benutzerdefinierte Typen erstellen, um Softwareprobleme oder Kundenfeedback nachzuverfolgen. Bei allen Arbeitselementtypen können Sie die folgenden Elemente anpassen:

  • Benutzerdefinierte Felder hinzufügen oder entfernen
  • Benutzerdefinierte Steuerelemente oder benutzerdefinierte Registerkarten innerhalb des Arbeitselementformulars hinzufügen
  • Workflowstatus anpassen
  • Bedingte Regel hinzufügen
  • Backlogstufe auswählen, auf der Arbeitselemente angezeigt werden

Bevor Sie Ihren Prozess anpassen, sollten Sie den Artikel Über die Konfiguration und Anpassung von Azure Boards lesen.

Informationen zum Anpassen Ihres spezifischen Prozesses finden Sie unter Anpassen eines Vererbungsprozesses.

Informationen zum Anpassen Ihres spezifischen Prozesses finden Sie unter Anpassen eines Vererbungsprozesses oder Anpassen des lokalen XML-Prozessmodells.

Fehler hinzufügen oder erfassen

Sie können Fehler aus verschiedenen Azure DevOps-Tools heraus definieren. Diese Tools umfassen Backlogs und Boards sowie Testtools.

Tipp

Standardmäßig ist das Feld Titel das einzige Pflichtfeld bei der Erstellung eines Fehlers. Fehler können auf die gleiche Weise hinzugefügt werden wie User Storys oder Product Backlog Items mit Azure Boards. Sie können einige Felder zu Pflichtfeldern machen, indem Sie bedingte Regeln auf der Grundlage einer Zustandsänderung hinzufügen. Weitere Informationen finden Sie unter Hinzufügen einer Regel zu einem Arbeitsaufgabentyp (Vererbungsprozess).

Hinzufügen eines Fehlers aus Ihrem Backlog oder Board

Wenn sich Ihr Team für die Verwaltung von Fehlern mit Anforderungen entschieden hat, können Sie Fehler über Ihr Product Backlog oder Board definieren. Weitere Informationen finden Sie unter Erstellen Ihres Backlogs in Azure Boards oder unter Verwenden des Boards.

  • Hinzufügen eines Fehlers aus dem Kanban-Board

    Screenshot: Hinzufügen eines Fehlers über das Product Backlog

  • Hinzufügen eines Fehlers über das Board

    Screenshot: Hinzufügen eines Fehlers über das Board

Tipp

Wenn Sie einen Fehler aus Ihrem Product Backlog oder Board hinzufügen, werden dem Fehler automatisch der standardmäßige Bereichspfad und Iterationspfad zugewiesen, die für das Team definiert sind. Weitere Informationen finden Sie unter Standardeinstellungen für Teams, auf die von Backlogs und Boards verwiesen wird.

Hinzufügen eines Fehlers aus Ihrem Sprint Backlog oder Taskboard

Wenn sich Ihr Team für die Verwaltung von Fehlern mit Aufgaben entschieden hat, können Sie Fehler über Ihr Board, Product Backlog, Sprintbacklog oder Sprint-Taskboard definieren. Sie fügen einen Fehler einem Product Backlog-Arbeitselement als untergeordnetes Element hinzu.

Erstellen eines Fehlers aus einem Testtool

Zu den beiden Testtools, mit denen Sie beim Testen Fehler hinzufügen können, gehören im Webportal „Test Runner“ und die Erweiterung „Testen Feedback“.

Fehlerlebenszyklus und Workflowstatus

Wie bei allen anderen Arbeitselementtypen verfügt auch der Fehler-Arbeitselementtyp über einen klar definierten Workflow. Jeder Workflow besteht aus drei oder mehr Zuständen und einem Grund. Gründe geben an, warum das Element von einem Zustand in einen anderen gewechselt ist. Die folgenden Abbildungen veranschaulichen den standardmäßigen Fehlerworkflow, der für die Prozesse Agile, Scrum und CMMI definiert ist.

Agilität Scrum CMMI
Diagramm: Fehlerworkflowzustände in der Agile-Prozessvorlage Diagramm: Fehlerworkflowzustände in der Scrum-Prozessvorlage Diagramm: Fehlerworkflowzustände in der CMMI-Prozessvorlage

Bei Scrum-Fehlern ändern Sie den Zustand von Committet (ähnlich wie Aktiv) in Fertig. Für Agile und CMMI lösen Sie zunächst den Fehler auf und wählen dann einen Grund aus, der anzeigt, dass der Fehler korrigiert wurde. In der Regel überprüft die Person, die den Fehler erstellt hat, den Fix und aktualisiert den Zustand von Aufgelöst in Geschlossen. Sollten nach dem Beheben oder Schließen eines Fehlers weitere Arbeiten erforderlich sein, können Sie den Fehler reaktivieren, indem Sie den Zustand auf Committet oder Aktiv festlegen.

Hinweis

Der Arbeitselementtyp „Fehler“ im Agile-Prozess verfügte zuvor über eine Regel, die den Fehler wieder der Person zuwies, die ihn erstellt hatte. Diese Regel wurde aus dem Standardsystemprozess entfernt. Sie können diese Automatisierung reaktivieren, indem Sie eine Regel hinzufügen. Informationen zu einem Vererbungsprozess finden Sie unter Automatisieren der Neuzuweisung basierend auf Zustandsänderungen.

Überprüfen eines Fixes

Um einen Fix zu überprüfen, versucht ein Entwickler oder Tester, den Fehler zu reproduzieren, und sucht dann nach weiterem unerwartetem Verhalten. Nötigenfalls sollte der Fehler reaktiviert werden.

Wenn Sie eine Fehlerkorrektur (Fix) überprüfen, stellen Sie möglicherweise fest, dass der Fehler nicht korrigiert wurde, oder Sie sind möglicherweise nicht mit der Auflösung einverstanden. In diesem Fall besprechen Sie den Fehler mit der Person, die ihn aufgelöst hat, erzielen Sie eine Übereinkunft, und aktivieren den Fehler eventuell erneut. Wenn Sie einen Fehler erneut aktivieren, nehmen Sie die Gründe für das erneute Aktivieren des Fehlers in die Fehlerbeschreibung auf.

Schließen eines Fehlers

Sie schließen einen Fehler, wenn ein Teammitglied bestätigt, dass er behoben wurde. Sie können jedoch auch einen Fehler aus einem der folgenden Gründe schließen. Die verfügbaren Gründe hängen vom Projektprozess und den Fehlerübergangszuständen ab.

Agile-Prozess:

  • Zurückgestellt: Fehlerkorrektur bis zum nächsten Produktrelease zurückstellen.
  • Korrigiert: Fehler wurde als „korrigiert“ verifiziert.
  • Duplikat: Fehler verfolgt einen anderen aktuell definierten Fehler nach. Sie können jeden der Fehler mit dem Duplikat/Duplikat von-Linktyp verknüpfen und einen der Fehler schließen.
  • Wie entwickelt: Das Feature funktioniert wie konzipiert.
  • Nicht reproduzierbar: Tests beweisen, dass der Fehler nicht reproduziert werden kann.
  • Veraltet: Das vom Fehler betroffene Feature ist nicht mehr im Produkt enthalten.
  • In das Backlog kopiert: Eine User Story wurde geöffnet, um den Fehler nachzuverfolgen.

Scrum-Prozess:

  • Kein Fehler: Bei dem Fehler wurde verifiziert, dass es sich nicht um einen Fehler handelt.
  • Duplikat: Fehler verfolgt einen anderen aktuell definierten Fehler nach. Sie können jeden der Fehler mit dem Duplikat/Duplikat von-Linktyp verknüpfen und einen der Fehler schließen.
  • Aus dem Backlog entfernt: Bei dem Fehler wurde verifiziert, dass es sich nicht um einen Fehler handelt. Entfernen Sie den Fehler aus dem Backlog.
  • Arbeit abgeschlossen: Fehler wurde als „korrigiert“ verifiziert.

CMMI-Prozess:

  • Zurückgestellt: Fehlerkorrektur bis zum nächsten Produktrelease zurückstellen.
  • Duplikat: Fehler verfolgt einen anderen aktuell definierten Fehler nach. Sie können jeden der Fehler mit dem Duplikat/Duplikat von-Linktyp verknüpfen und einen der Fehler schließen.
  • Abgelehnt: Bei dem Fehler wurde verifiziert, dass es sich nicht um einen Fehler handelt.
  • Bestätigt: Fehler wurde als „korrigiert“ verifiziert.

Tipp

Nachdem ein Fehler geschlossen wurde und der Fix in Bereitstellungen aktiv freigegeben wurde, besteht die empfohlene Vorgehensweise darin, ihn aus Regressionsgründen nicht erneut zu öffnen. Stattdessen sollten Sie erwägen, einen neuen Fehler zu öffnen und diesen mit dem älteren geschlossenen Fehler zu verknüpfen.

Es ist immer ratsam, weitere Details zum Schließen eines Fehlers im Feld Diskussion zu beschreiben, um zukünftige Verwirrung darüber zu vermeiden, warum der Fehler geschlossen wurde.

Schließen von Fehlern beim Zusammenführen von Pull Requests automatisieren

Wenn Ihr Team ein Git-Repository verwendet, können Sie den Zustand in verknüpften Fehlern und anderen Arbeitselementen auf „Schließen“ festlegen, nachdem Pull Requests erfolgreich zusammengeführt wurden. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Festlegen des Zustands von Arbeitselementen in Pull Requests .

Auflisten und Selektieren von Fehlern

Die meisten Teams definieren, unabhängig davon, welche Option sie zum Nachverfolgen von Fehlern gewählt haben, eine oder mehrere Fehlerabfragen. Mit Abfragen können Sie aktive Fehler, nicht zugewiesene Fehler, veraltete Fehler, Fehlertrends und mehr auflisten. Sie können Ihren Teamdashboards Abfragen und Abfragediagramme hinzufügen, um den Fehlerstatus und -fortschritt zu überwachen.

Fehlerabfragen

Öffnen Sie eine freigegebene Abfrage, oder verwenden Sie den Abfrage-Editor, um nützliche Fehlerabfragen zu erstellen, z. B. wie die folgenden Optionen:

  • Aktive Fehler nach Priorität (State <> Done oderState <> Closed)
  • Fehler in Bearbeitung (State = Committed oder State = Active)
  • Für Zielrelease zu behebende Fehler (Tags Contains RTM)
  • Jüngste Fehler – also beispielsweise solche, die innerhalb der letzten drei Wochen geöffnet wurden (Created Date > @Today-21)

Wenn Sie über die für Ihr Team interessanten Abfragen verfügen, können Sie Status- oder Trenddiagramme erstellen. Sie können das von Ihnen erstellte Diagramm auch einem Dashboard hinzufügen.

Selektierungsmodus in Abfrageergebnissen

Halten Sie nach Beginn der Programmier- und Testarbeiten regelmäßige Selektierungsbesprechungen ab, um Ihre Fehler zu überprüfen und zu priorisieren. In der Regel hält der Projektbesitzer die Fehlerselektierungsbesprechungen ab. Teamleiter, Geschäftsanalysten und andere Projektbeteiligte, die zu spezifischen Projektrisiken sprechen können, nehmen an den Selektierungsbesprechungen teil.

Der Projektbesitzer kann eine freigegebene Abfrage für neue und erneut geöffnete Fehler definieren, um Fehler für die Selektierung aufzulisten.

Auf der Seite mit den Abfrageergebnissen können Sie innerhalb der Liste der Fehlerarbeitselemente mithilfe der Auf- und Abwärtspfeile nach oben und unten navigieren. Während Sie jeden Fehler überprüfen, können Sie ihn zuweisen, Details hinzufügen oder die Priorität festlegen.

Screenshot der „Abfrageergebnisse“, „Aktive Fehler“ sowie Selektierungsmodus, rechter Bereich.

Organisieren und Zuweisen von Fehlern zu einem Sprint

Wenn Ihr Team Fehler als Anforderungen nachverfolgt, zeigen Sie die Liste der aktiven Fehler aus Ihrem Backlog an. Mit der Filterfunktion können Sie sich ausschließlich auf Fehler konzentrieren. Aus dem Product Backlog heraus können Sie ebenfalls die folgenden Aufgaben ausführen:

Wenn Ihr Team Fehler als Aufgaben nachverfolgt, verwenden Sie verwaltete Abfragen, um Fehler aufzulisten und zu selektieren. In jedem Sprint werden die dem Sprint zugewiesenen Fehler aus dem Sprint-Backlog oder -Taskboard angezeigt.

Taskboardelemente im Vergleich zu Abfragelistenelementen

Möglicherweise bemerken Sie und fragen sich, warum sich die in einem Sprint Taskboard angezeigten Elemente von einer Abfrageliste unterscheiden können, die in einem entsprechenden Sprint Backlog erstellt wurde.

Es ist möglich, Aufgaben oder Fehler einer Iteration zuzuweisen, ohne sie mit einem übergeordneten Backlog Item zu verknüpfen. Diese Elemente werden in der erstellten Abfrage angezeigt, möglicherweise aber nicht im Taskboard selbst. Das System führt die Abfrage durch und wendet dann ein paar Hintergrundprozesse an, bevor die Taskboardelemente angezeigt werden.

Diese Gründe können dazu führen, dass zur Kategorie „Aufgabe“ gehörende Arbeitselemente nicht in einem Sprint Backlog oder Taskboard angezeigt werden:

  • Die Aufgabe oder der Fehler ist nicht mit einem übergeordneten Backlog Item verknüpft. Auf der Sprint-Backlog-Seite werden nur Fehler und Aufgaben angezeigt, die mit einem übergeordneten Product Backlog Item (Scrum), einer übergeordneten User Story (Agile) oder einer übergeordneten Anforderung (CMMI) verknüpft wurden, deren/dessen Iterationspfad auf den Sprint festgelegt ist.
  • Die Aufgabe oder der Fehler ist ein übergeordnetes Element einer anderen Aufgabe oder eines anderen Fehlers, oder die User Story ist ein übergeordnetes Element einer anderen User Story. Wenn Sie eine Hierarchie von Aufgaben, Fehlern oder User Storys erstellen, werden nur die Aufgaben auf untergeordneter Ebene oder die Storys auf untergeordneter Ebene am unteren Ende der Hierarchie angezeigt. Weitere Informationen finden Sie unter Beheben von Problemen beim Neuanordnen und Schachteln.
  • Das verknüpfte übergeordnete Element der Aufgabe oder des Fehlers entspricht einem Backlog Item, das für ein anderes Team definiert wurde. Oder der Bereichspfad des übergeordneten Backlog Items der Aufgabe oder des Fehlers weicht vom Bereichspfad der Aufgabe oder des Fehlers ab.

Erstellen von mit Fehlern verknüpften Inlinetests

Wenn Ihr Team Fehler als Anforderungen nachverfolgt, können Sie das Board verwenden, um Tests zum Überprüfen von Fehlerbehebungen hinzuzufügen.

Screenshot des Boards: Drei Spalten mit hinzugefügten Inlinetests und Verknüpfung mit Fehlern

Aktualisieren des Fehlerstatus

Sie können den Fehlerstatus aktualisieren, indem Sie Fehler in eine neue Spalte auf einem Board ziehen und ablegen.

Anpassen Ihres Boards zum Nachverfolgen von Zwischenzuständen

Sie können Zwischenspalten hinzufügen, um Ihren Fehlerstatus auf dem Board nachzuverfolgen. Sie können auch Abfragen definieren, die basierend auf dem Status einer Boardspalte filtern. Weitere Informationen finden Sie in den folgenden Artikeln:

Automatisieren der Neuzuweisung von Fehlern auf Grundlage des Workflowstatus

Um ausgewählte Aktionen zu automatisieren, fügen Sie Ihrem Fehler-Arbeitselementtyp benutzerdefinierte Regeln hinzu. Fügen Sie beispielsweise eine Regel hinzu, wie in der folgenden Abbildung gezeigt. Diese Regel gibt an, dass ein Fehler, der von einem Teammitglied behoben wurde, wieder der Person zugewiesen werden soll, die ihn geöffnet hatte. In der Regel überprüft diese Person, ob der Fehler korrigiert wurde, und schließt den Fehler. Weitere Informationen finden Sie unter Anwenden von Regeln auf Workflowzustände (Vererbungsprozess).

Screenshot der zum Wiederzuweisen eines Fehlers auf Grundlage des Auflösungszustands definierten Regel.

Festlegen des Arbeitselementzustands in Pull Requests

Wenn Sie einen Pull Request erstellen, können Sie den Zustandswert (state) der verknüpften Arbeitselemente in der Beschreibung festlegen. Befolgen Sie die Syntax: {state value}: #ID.

Wenn Sie den Pull Request zusammenführen, liest das System die Beschreibung und aktualisiert den Arbeitselementzustand. Im folgenden Beispiel werden die Arbeitselemente 300 und 301 auf „Gelöst“ und die Arbeitselemente 323 und 324 auf „Geschlossen“ festgelegt:

Screenshot: Festlegen des Arbeitselementzustands in einem Pull Request

Hinweis

Dieses Feature erfordert die Installation von Azure DevOps Server-Update 2020.1. Weitere Informationen finden Sie unter Azure DevOps Server 2020 Update 1 RC1 Versionshinweise, Boards.

Integration in Azure DevOps

Eine der Methoden, die von Azure DevOps zur Unterstützung der Integration verwendet werden, besteht darin, Objekte mit anderen Objekten zu verknüpfen. Neben dem Verknüpfen von Arbeitselementen mit Arbeitselementen können Sie auch Arbeitselemente mit anderen Objekten verknüpfen. Sie können mit Objekten wie Builds, Releases, Branches, Commits und Pull Requests verknüpfen, wie in der folgenden Abbildung dargestellt.

Diagramm: Linktypen zum Verknüpfen von Arbeitselementen mit Build- und Releaseobjekten

Sie können einen Link vom Arbeitselement aus oder von den Build- und Releaseobjekten aus hinzufügen.

Das Steuerelement Entwicklung unterstützt das Erstellen und Anzeigen von Links zu Builds, Git-Commits und Pull Requests. Bei Verwendung eines TFVC-Repositorys unterstützt es Links zu Changesets und versionierten Elementen. Wenn Sie den Link auswählen, wird das zugehörige Element auf einer neuen Browserregisterkarte geöffnet. Weitere Informationen finden Sie unter Steuern der Git-Entwicklung von einem Arbeitselement aus.

Screenshot: Steuerelement „Entwicklung“ in Arbeitselementformular mit Beispiellinks zu Builds, Pull Requests und Commits

Das Deployment-Steuerelement (Bereitstellung) unterstützt Links zu und die Anzeige von Releases, die Arbeitselemente enthalten. Die folgende Abbildung zeigt beispielsweise mehrere Releases, die Links zum aktuellen Arbeitselement enthalten. Sie können jedes Release erweitern, um Details zu den einzelnen Stages (Phasen) anzuzeigen. Sie können den Link für jedes Release und jede Stage auswählen, um das zugehörige Release oder die zugehörige Stage zu öffnen. Weitere Informationen finden Sie unter Verknüpfen von Arbeitselementen mit Builds und Bereitstellungen.

Screenshot: Steuerelement „Entwicklung“ im Arbeitselementformular mit Beispielreleases

Pipelines werden häufig so definiert, dass sie automatisch ausgeführt werden, wenn ein neuer Commit in ein Git-Repository erfolgt. Arbeitselemente, die den Commitpipelines zugeordnet sind, werden als Teil der Pipelineausführung angezeigt, wenn Sie Ihre Pipelineeinstellungen anpassen. Weitere Informationen finden Sie unter Anpassen Ihrer Pipeline.

Screenshot: Pipelineeinstellungen mit hervorgehobener Option „In dieser Ausführung enthaltene Arbeitselemente automatisch verknüpfen“ aus dem ausgewählten Branch

Erstellen oder Bearbeiten eines Arbeitselements bei einem Buildfehler

Wenn Sie klassische Pipelines (nicht YAML) verwenden, können Sie bei einem Buildfehler Arbeitselemente erstellen. Weitere Informationen finden Sie unter Erstellen einer Arbeitsaufgabe bei Fehler.

Sie können den Fehlerstatus, Zuweisungen und Trends mithilfe von Abfragen nachverfolgen, die Sie einem Dashboard als Diagramme hinzufügen können. Hier sehen Sie beispielsweise zwei Beispiele, die „Aktive Fehlertrends nach Zustand“ sowie „Aktive Fehler nach Priorität“ im Zeitverlauf zeigen.

Screenshot zweier Abfragediagramme für aktive Fehler, Fehlertrends nach Zustand und nach Priorität.

Weitere Informationen zu Abfragen, Diagrammen und Dashboards finden Sie unter Nachverfolgen Ihrer Arbeit mithilfe von verwalteten Abfragen in Azure Boards bzw. unter Verfolgen des Fortschritts mit auf Status- und Trendabfragen basierenden Diagrammen oder unter Hinzufügen, Umbenennen und Löschen von Dashboards in Azure DevOps.

Verwenden von Analytics-Ansichten und dem Analytics-Dienst zum Erstellen von Fehlerberichten

Der Analysedienst ist die Berichtsplattform für Azure DevOps. Er ersetzt die vorherige, auf SQL Server Reporting Services basierende Plattform.

Analyseansichten bieten vordefinierte Filter zum Anzeigen von Arbeitselementen. Für die Fehlerberichterstattung werden vier Analyseansichten unterstützt. Sie können diese Ansichten wie definiert verwenden oder weiter bearbeiten, um eine benutzerdefinierte, gefilterte Ansicht zu erstellen.

  • Fehler – Gesamter Verlauf nach Monat
  • Fehler – Letzte 26 Wochen
  • Fehler – Letzte 30 Tage
  • Fehler – Heute

Weitere Informationen zur Verwendung von Analyse- bzw. Analytics-Ansichten finden Sie unter Informationen zu Analytics-Ansichten sowie unter Erstellen eines aktiven Fehlerberichts in Power BI basierend auf einer benutzerdefinierten Analyseansicht.

Sie können Power BI verwenden, um komplexere Berichte zu erstellen als eine Abfrage. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit dem Power BI-Datenconnector.

Vordefinierte SQL Server-Fehlerberichte

Die folgenden Berichte werden für Agile- und CMMI-Prozesse unterstützt.

Für diese Berichte müssen SQL Server Analysis Services und SQL Server Reporting Services für Ihr Projekt konfiguriert sein. Informationen zum Hinzufügen von SQL Server-Berichten für ein Projekt finden Sie unter Hinzufügen von Berichten zu einem Projekt.

Marketplace-Erweiterungen

Es gibt mehrere fehlerbezogene Marketplace-Erweiterungen. Weitere Informationen finden Sie unter Marketplace für Azure DevOps.

Weitere Informationen zu Erweiterungen finden Sie unter Von Microsoft entwickelte Azure Boards-Erweiterungen.

Nächste Schritte

Verwenden von Vorlagen zum Hinzufügen und Aktualisieren von Arbeitselementen

Product Backlog und Board

Übersicht

Sprint Backlog und Taskboard

Integration in Azure DevOps

Branchenressourcen