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

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

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

Mindestens benötigen Sie eine Möglichkeit, Ihre Softwareprobleme zu erfassen, sie zu priorisieren, sie einem Teammitglied zuzuweisen und den Fortschritt nachzuverfolgen. Und Sie möchten Ihre Codefehler so verwalten, dass sie mit Ihren agilen Methoden übereinstimmen.

Um diese Szenarien zu unterstützen, bietet Azure Boards einen bestimmten Arbeitselementtyp zum Nachverfolgen von Codefehlern namens "Bug". Fehlerarbeitselemente teilen alle Standardfeatures anderer Arbeitselementtypen mit einigen mehr. Eine Übersicht über standardfeatures finden Sie unter Nachverfolgen der Arbeit mit Benutzergeschichten, Problemen, Fehlern, Features und Epen.

Fehler bieten auch die folgenden zusätzlichen Features:

  • Optionen für jedes Team, um auszuwählen, wie sie Fehler nachverfolgen möchten
  • Testen von Tools zum Erfassen von Fehlern
  • Integrierte Integration in Azure DevOps zum Nachverfolgen von Fehlern, die mit Builds, Versionen und Tests verknüpft sind

Hinweis

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

Voraussetzungen

  • Sie müssen eine Verbindung mit einem Projekt herstellen. Wenn Sie noch kein Projekt haben, erstellen Sie ein Projekt.
  • Sie müssen einem Projekt hinzugefügt werden. Um hinzugefügt zu werden, fügen Sie Benutzern zu einem Projekt oder Team hinzu.
  • Um Arbeitselemente anzuzeigen oder zu ändern, müssen Sie ihre Arbeitselemente in diesem Knoten anzeigen und Arbeitselemente in diesen Knotenberechtigungen bearbeiten, die auf "Zulassen" festgelegt sind. Standardmäßig verfügt die Gruppe "Mitwirkende" über diesen Berechtigungssatz . Weitere Informationen finden Sie unter Festlegen von Berechtigungen und Zugriff für die Arbeitsverfolgung.
  • Um neue Tags hinzuzufügen, die zu Arbeitselementen hinzugefügt werden sollen, müssen Sie über den Einfachen Zugriff oder höher verfügen und die Berechtigungen für die Projektdefinition auf Projektebene erstellen, die auf "Zulassen" festgelegt sind. Standardmäßig verfügt die Gruppe "Mitwirkende" über diesen Berechtigungssatz . Selbst wenn die Berechtigung explizit für einen Stakeholder festgelegt ist, verfügen sie nicht über die Berechtigung, neue Tags hinzuzufügen, da sie über ihre Zugriffsstufe verboten sind. Weitere Informationen finden Sie unter "Kurzübersicht zu den Stakeholdern".
  • Alle Projektmitglieder, auch diejenigen, die zur Gruppe "Leser " gehören, können Arbeitselemente per E-Mail senden.
  • Sie müssen eine Verbindung mit einem Projekt herstellen. Wenn Sie noch kein Projekt haben, erstellen Sie ein Projekt.
  • Sie müssen einem Projekt hinzugefügt werden. Um hinzugefügt zu werden, fügen Sie Benutzern zu einem Projekt oder Team hinzu.
  • Um Arbeitselemente anzuzeigen oder zu ändern, müssen Sie ihre Arbeitselemente in diesem Knoten anzeigen und Arbeitselemente in diesen Knotenberechtigungen bearbeiten, die auf "Zulassen" festgelegt sind. Standardmäßig verfügt die Gruppe "Mitwirkende" über diesen Berechtigungssatz . Weitere Informationen finden Sie unter Festlegen von Berechtigungen und Zugriff für die Arbeitsverfolgung.
  • Um neue Tags hinzuzufügen, die zu Arbeitselementen hinzugefügt werden sollen, müssen Sie über den Einfachen Zugriff oder höher verfügen und die Berechtigungen für die Projektdefinition auf Projektebene erstellen, die auf "Zulassen" festgelegt sind. Standardmäßig verfügt die Gruppe "Mitwirkende" über diesen Berechtigungssatz . Selbst wenn die Berechtigung explizit für einen Stakeholder festgelegt ist, verfügen sie nicht über die Berechtigung, neue Tags hinzuzufügen, da sie über ihre Zugriffsstufe verboten sind. Weitere Informationen finden Sie unter "Kurzübersicht zu den Stakeholdern".
  • Alle Projektmitglieder, auch diejenigen, die zur Gruppe "Leser " gehören, können Arbeitselemente per E-Mail senden.

Tipp

Um einen Fehler zu melden, muss ein Benutzer mindestens über einen Benutzer verfügen, der Zugriff auf Arbeitselemente in diesem Knotenberechtigungssatzauf " Zulassen" für den Bereichspfad hat, in dem er den Fehler hinzufügen wird. Weitere Informationen finden Sie unter Festlegen von Berechtigungen und Zugriff für die Arbeitsverfolgung

Fehler-Arbeitselementtyp

Das folgende Bild zeigt den Fehler-Arbeitselementtyp für den Scrum-Prozess. Der Fehler-Arbeitselementtyp für agile und CMMI-Prozesse verfolgt ähnliche Informationen. Es ist so konzipiert, dass das Produktbacklog zusammen mit Anforderungen oder im Taskboard zusammen mit Aufgaben angezeigt wird.

Hinweis

Die Von Ihrem Webportal angezeigten Bilder unterscheiden sich möglicherweise von den in diesem Artikel angezeigten Bildern. Diese Unterschiede ergeben sich aus Updates, die an Ihre Web-App vorgenommen wurden, Optionen, die Sie oder Ihr Administrator aktiviert haben, und welcher Prozess beim Erstellen Ihres Projekts ausgewählt wurde – Agile, Basic, Scrum oder CMMI. Der Grundlegende Prozess ist mit Azure DevOps Server 2019 Update 1 und höher verfügbar.

Bug work item type, form for Scrum process, Azure DevOps Server 2020 and cloud service.

Bug work item type, form for Scrum process, Azure DevOps Server 2019 and earlier versions to TFS 2017.

Felder, die für Fehler spezifisch sind

Der Arbeitselementtyp "Fehler" verwendet einige fehlerspezifische Felder. Verwenden Sie die felder, die in der folgenden Tabelle beschrieben sind, um sowohl das anfängliche Problem als auch die fortlaufenden Ermittlungen zu erfassen. Informationen zu Feldern, die für den Prozess "Feature Maturity Model Integration" (CMMI) definiert sind, finden Sie unter Fehler, Probleme und Risiken feldverweis. Informationen zu allen anderen Feldern finden Sie unter Arbeitselementfeldindex.


Feld, Gruppe oder Registerkarte

Verwendung


Schritte zum Reproduzieren
(Anzeigename=Repro-Schritte)

Verwenden Sie die Verwendung, um genügend Informationen zu erfassen, damit andere Teammitglieder den Codefehler vollständig verstehen können. Fügen Sie Aktionen ein, um den Fehler zu finden oder zu reproduzieren und das erwartete Verhalten zu erwarten.


Informationen zur Software- und Systemkonfiguration, die für den Fehler und tests relevant ist, die angewendet werden sollen. 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 an und erstellen, wo der Fehler aufgetreten ist. Weitere Informationen finden Sie unter Testen verschiedener Konfigurationen.


Stellen Sie die Kriterien bereit, die erfüllt werden sollen, bevor der Fehler geschlossen werden kann. Bevor die Arbeit beginnt, beschreiben Sie die Kundenakzeptanzkriterien so klar wie möglich. Teams sollten diese Kriterien als Grundlage für Akzeptanztests verwenden und auswerten, ob ein Element zufrieden abgeschlossen wurde.


Gibt den Namen des Builds an, der den Code enthält, der den Fehler korrigiert. Dieses Feld sollte angegeben werden, wenn Sie den Fehler beheben. Für lokale Azure DevOps können Sie auf ein Dropdownmenü aller Builds zugreifen, die FIELD ausgeführt wurden, die Definitionen für "In Build" und "Integriertin Build" aktualisieren, um auf eine globale Liste zu verweisen. Die globale Liste wird jedes Mal automatisch aktualisiert, wenn der Build ausgeführt wird. Weitere Informationen finden Sie unter Abfrage basierend auf Build- und Testintegrationsfeldern.
Informationen zum Definieren von Buildnummern finden Sie unter Buildnummernformatoptionen.


  • 1: Das Produkt erfordert eine erfolgreiche Auflösung des Arbeitselements, bevor es angibt und bald behoben wird.
  • 2: Das Produkt erfordert eine erfolgreiche Auflösung des Arbeitselements vor dem Versand, muss jedoch nicht sofort behandelt werden.
  • 3: Auflösung des Arbeitselements ist optional basierend auf Ressourcen, Zeit und Risiko.

Eine subjektive Bewertung der Auswirkungen eines Fehlers oder eines Arbeitselements auf das Projekt oder Softwaresystem. Beispiel: Wenn ein Remotelink über die Benutzeroberfläche – ein seltenes Ereignis – eine Anwendung oder Webseite abstürzt – eine schwere Kundenerfahrung, können Sie schwere Schweregrad = 2 – Hoch und Priorität = 3 angeben. Zulässige Werte und vorgeschlagene Richtlinien sind:

  • 1 - Kritisch: Muss behoben werden. Ein Fehler, der zum Beenden einer oder mehrerer Systemkomponenten oder des vollständigen Systems führt, oder verursacht umfangreiche Datenbeschädigungen. Und es gibt keine akzeptablen Alternativen, um erforderliche Ergebnisse zu erzielen.
  • 2 - Hoch: Berücksichtigen Sie fix. Ein Fehler, der zum Beenden einer oder mehrerer Systemkomponenten oder des vollständigen Systems führt, oder verursacht umfangreiche Datenbeschädigungen. Eine akzeptable alternative Methode ist jedoch vorhanden, um erforderliche Ergebnisse zu erzielen.
  • 3 - Mittel: (Standard) Ein Fehler, der dazu führt, dass das System falsche, unvollständige oder inkonsistente Ergebnisse erzeugt.
  • 4 – Niedrig: Ein kleiner oder kosmetischer Fehler, der über zulässige Problemumgehungen verfügt, um erforderliche Ergebnisse zu erzielen.

Das Bereitstellungssteuerelement unterstützt Links zu und Anzeige von Versionen, die Arbeitselemente enthalten. Um das Steuerelement zu verwenden, müssen Sie Einstellungen für die Version aktivieren. Weitere Informationen finden Sie unter Link von Arbeitselementen, die später in diesem Artikel veröffentlicht werden.


Das Entwicklungssteuerelement unterstützt Links zu und Anzeige von Links, die an Entwicklungsobjekte vorgenommen werden. Diese Objekte umfassen Git-Commits und Pullanforderungen oder TFVC-Änderungen und versionierte Elemente. Sie können Links aus dem Arbeitselement oder aus den Commits, Pullanforderungen oder anderen Entwicklungsobjekten definieren. Weitere Informationen finden Sie unter Link von Arbeitselementen zur Entwicklung später in diesem Artikel.


Hinweise:

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

Wählen Sie aus, wie Ihr Team Fehler nachverfolgt

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

  • Größe Ihres Teams. Kleinere Teams können einen einfachen Fußbedarf erhalten, indem Fehler als Anforderungen nachverfolgt werden.
  • Organisationsanforderungen zum Nachverfolgen der Arbeit. Wenn Ihr Team Die Stunden nachverfolgen muss, wählen Sie aus, um Fehler als Aufgaben nachzuverfolgen.
  • Wie Ihr Team funktioniert. Wenn Ihr Team auf den Produktrückstand angewiesen ist, um Arbeit zu priorisieren und Fehler hinzuzufügen, verfolgen Sie Fehler als Anforderungen.
  • Tools, die Ihr Team verwenden möchte, z. B. den Planungsbereich, das Geschwindigkeitsdiagramm, die Prognose, das Rollup und die Übermittlungspläne. Das Nachverfolgen von Fehlern als Aufgaben verhindert die Verwendung mehrerer dieser Tools.

In der folgenden Tabelle werden die drei Optionen zusammengefasst, die Teams müssen Fehler nachverfolgen. Weitere Informationen und das Festlegen der Option für Ihr Team finden Sie unter Anzeigen von Fehlern auf Backlogs und Boards.


Option

Wählen Sie aus, wann Sie möchten...


Nachverfolgen von Fehlern als Anforderungen

Hinweis

  • Fehler werden der Kategorie "Anforderungen" zugewiesen.

Nachverfolgen von Fehlern als Aufgaben

  • Geschätzte Arbeit für Fehler ähnlich wie Aufgaben
  • Aktualisieren des Fehlerstatus auf Sprint-Taskboards
  • Verknüpfen von Fehlern mit Anforderungen als untergeordnete Elemente
  • Kann Fehler im Planungsbereich ziehen und ablegen, um Fehler einem Sprint zuzuweisen.

Hinweis

  • Fehler werden der Kategorie "Aufgabe" zugewiesen.
  • User Stories (Agile), Product Backlog Items (Scrum) oder Requirements (CMMI) sind der natürliche übergeordnete Arbeitselementtyp für Fehler
  • Fehler werden in Übermittlungsplänen nicht angezeigt.

Fehler werden nicht auf Backlogs oder Boards angezeigt

  • Verwalten von Fehlern mithilfe von Abfragen

Hinweis

  • Fehler sind der Kategorie "Fehler" zugeordnet und werden nicht auf Backlogs oder Boards angezeigt.
  • Fehler werden bei Backlogs, Boards, Sprint Backlogs, Taskboards oder Übermittlungsplänen nicht angezeigt.
  • Fehler können nicht auf den Planungsbereich ziehen und ablegen, um Einem Sprint Fehler zuzuweisen.

Anpassen des Arbeitselementtyps

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

  • Hinzufügen oder Entfernen benutzerdefinierter Felder
  • Hinzufügen benutzerdefinierter Steuerelemente oder benutzerdefinierter Registerkarten im Arbeitselementformular
  • Anpassen der Workflowzustände
  • Hinzufügen bedingter Regeln
  • Wählen Sie die Backlogebene aus, in der Arbeitselemente angezeigt werden

Bevor Sie Ihren Prozess anpassen, empfehlen wir Ihnen, Azure-Boards zu konfigurieren und anzupassen.

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

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

Informationen zum Anpassen Ihres bestimmten Prozesses finden Sie unter Anpassen des lokalen XML-Prozessmodells.

Hinzufügen oder Erfassen von Fehlern

Sie können Fehler aus mehreren verschiedenen Azure DevOps-Tools definieren. Dazu gehören Backlogs und Boards und Testtools.

Tipp

Standardmäßig ist das Titelfeld das einzige erforderliche Feld beim Erstellen eines Fehlers. Sie können Schnell Fehler auf dieselbe Weise hinzufügen, wie Sie Benutzergeschichten oder Produktrückführungselemente mithilfe von Azure Boards hinzufügen. Wenn Sie einige Felder erforderlich machen möchten, führen Sie dies aus, indem Sie bedingte Regeln basierend auf einer Zustandsänderung hinzufügen. Weitere Informationen finden Sie unter Hinzufügen einer Regel zu einem Arbeitselementtyp (Vererbungsprozess).

Hinzufügen eines Fehlers aus Ihrem Backlog oder Board

Wenn Ihr Team sich für die Verwaltung von Fehlern mit Anforderungen entschieden hat, können Sie Fehler aus Ihrem Produktbacklog oder Kanban-Board definieren. Weitere Informationen finden Sie unter Erstellen ihres Produktrücklaufs oder starten Sie mit Ihrem Kanban-Board.

  • Hinzufügen eines Fehlers aus dem Produktbacklog

    From product backlog, Add bug.

  • Hinzufügen eines Fehlers aus dem Produktbacklog

    From Kanban board, Add bug.

Tipp

Wenn Sie einen Fehler aus Ihrem Produktbacklog oder Kanban-Board hinzufügen, wird der Fehler automatisch dem Standardbereichspfad und dem Iterationspfad zugewiesen, der für das Team definiert ist. Weitere Informationen finden Sie unter "Team-Standardeinstellungen", die von Backlogs und Boards referenziert werden.

Hinzufügen eines Fehlers aus Ihrem Sprint-Backlog oder Taskboard

Wenn Ihr Team sich für die Verwaltung von Fehlern mit Aufgaben entschieden hat, können Sie Fehler aus Ihrem Kanban-Board, Produktbacklog, Sprint-Backlog oder Sprint-Taskboard definieren. Sie fügen einem Produktbacklog ein Fehler als untergeordnetes Element hinzu.

Erstellen eines Fehlers aus einem Testtool

Die beiden Testtools, mit denen Sie Fehler beim Testen hinzufügen können, umfassen das Webportal Test Runner und die & Erweiterung "Testfeedback".

Fehlerlebenszyklus- und Workflowstatus

Wie bei allen anderen Arbeitselementtypen weist der Fehlerarbeitselementtyp einen gut definierten Workflow auf. Jeder Workflow besteht aus drei oder mehr Zuständen und einem Grund. Gründe dafür, warum das Element von einem Zustand zu einem anderen überstieg. Die folgenden Bilder veranschaulichen den Standardfehlerworkflow, der für die Prozesse Agile, Scrum und CMMI definiert ist.

Agilität Scrum CMMI
Bug workflow states, Agile process template Bug workflow states, Scrum process template Bug workflow states, CMMI process template

Bei Scrum-Fehlern ändern Sie den Status von "Commit " (ähnlich wie "Aktiv") in "Fertig". Für Agile und CMMI lösen Sie zuerst den Fehler und wählen einen Grund aus, der angibt, dass der Fehler behoben ist. In der Regel überprüft die Person, die den Fehler erstellt hat, den Fix und aktualisiert den Zustand von "Aufgelöst " auf "Geschlossen". Wenn mehr Arbeit gefunden wurde, nachdem ein Fehler behoben oder geschlossen wurde, können Sie sie reaktivieren, indem Sie den Status auf "Commit" oder " Aktiv" festlegen.

Hinweis

Der Agile-Prozessfehler-Arbeitsaufgabentyp hatte zuvor eine Regel, die den Fehler der Person, die sie erstellt hat, neu zugewiesen hat. Diese Regel wurde aus dem Standardsystemprozess entfernt. Sie können diese Automatisierung erneut ausführen, indem Sie eine Regel hinzufügen. Ein Vererbungsprozess finden Sie unter Anwenden von Regeln auf Workflowzustände, Automatisieren der Neuzuweisung basierend auf Statusänderungen.

Überprüfen eines Fixs

Um einen Fix zu überprüfen, versucht ein Entwickler oder Tester, den Fehler zu reproduzieren und nach unerwartetem Verhalten zu suchen. Falls erforderlich, sollten sie den Fehler reaktivieren.

Wenn Sie eine Fehlerkorrektur überprüfen, stellen Sie möglicherweise fest, dass der Fehler nicht behoben wurde, oder Sie können mit der Lösung nicht einverstanden sein. In diesem Fall besprechen Sie den Fehler mit der Person, die sie behoben hat, zu einer Vereinbarung kommt, und aktivieren Sie den Fehler möglicherweise erneut. Wenn Sie einen Fehler reaktivieren, schließen Sie die Gründe für die Reaktivierung des Fehlers in der Fehlerbeschreibung ein.

Schließen eines Fehlers

Sie schließen einen Fehler, nachdem es als behoben überprüft wurde. Sie können jedoch auch einen Fehler aus einem der folgenden Gründe schließen. Gründe für die Auswahl hängen vom Projektprozess und den Fehlerübergangszuständen ab.

Agiler Prozess:

  • Verzögert: Zurückstellen des Fehlerkorrekturs bis zur nächsten Produktversion.
  • Behoben: Fehler wird als behoben überprüft.
  • Duplikat: Fehler verfolgt einen anderen aktuell definierten Fehler. Sie können jeden Fehler mit dem Typ "Duplikat/Duplikat" verknüpfen und einen der Fehler schließen.
  • As Designed: Feature funktioniert wie entworfen.
  • Kann nicht reproduzieren: Tests beweisen, dass der Fehler nicht reproduziert werden kann.
  • Veraltet: Das Feature des Fehlers befindet sich nicht mehr im Produkt.
  • In Den Backlog kopiert: Ein Benutzerabschnitt wurde geöffnet, um den Fehler nachzuverfolgen.

Scrum-Prozess:

  • Kein Fehler: Fehler wird überprüft, dass es kein Fehler ist.
  • Duplikat: Fehler verfolgt einen anderen aktuell definierten Fehler. Sie können jeden Fehler mit dem Typ "Duplikat/Duplikat" verknüpfen und einen der Fehler schließen.
  • Aus dem Backlog entfernt: Fehler wird überprüft, dass es kein Fehler ist. Entfernen Sie den Fehler aus dem Backlog.
  • Arbeit abgeschlossen: Fehler wurde als behoben überprüft.

CMMI-Prozess:

  • Verzögert: Zurückstellen des Fehlerkorrekturs bis zur nächsten Produktversion.
  • Duplikat: Fehler verfolgt einen anderen aktuell definierten Fehler. Sie können jeden Fehler mit dem Typ "Duplikat/Duplikat" verknüpfen und einen der Fehler schließen.
  • Abgelehnt: Fehler wird überprüft, dass es kein Fehler ist.
  • Überprüft: Fehler wird als behoben überprüft.

Tipp

Sobald ein Fehler geschlossen wurde und der Fix aktiv in Bereitstellungen veröffentlicht wird, empfiehlt es sich, sie aufgrund der Regression nie erneut zu öffnen. Stattdessen sollten Sie einen neuen Fehler öffnen und einen Link zu dem älteren, geschlossenen Fehler herstellen.

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

Automatisieren der Fehlerschließung beim Zusammenführen von Pullanforderungen

Wenn Ihr Team ein Git-Repository verwendet, können Sie den Status in verknüpften Fehlern und anderen Arbeitselementen festlegen, die beim erfolgreichen Zusammenführen von Pullanforderungen geschlossen werden. Weitere Informationen finden Sie unter Festlegen des Arbeitsaufgabenstatus in pull-Anforderung weiter unten in diesem Artikel.

Listen- und Triagefehler

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

Fehlerabfragen

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

  • Aktive Fehler nach Priorität (State <> Done oder State <> Closed)
  • In Bearbeitungsfehler (State = Committed oder State = Active)
  • Fehler beim Beheben einer Zielversion (Tags Contains RTM)
  • Zuletzt verwendete Fehler – Fehler, die innerhalb der letzten drei Wochen geöffnet wurden (Created Date > @Today-21)

Sobald Sie die Interessenabfragen für Ihr Team haben, können Sie Status- oder Trenddiagramme erstellen. Sie können auch das Diagramm hinzufügen, das Sie zu einem Dashboard erstellen.

Triagemodus in Abfrageergebnissen

Nachdem Sie mit dem Codieren und Testen begonnen haben, sollten Sie regelmäßige Triagebesprechungen abhalten, um Ihre Fehler zu überprüfen und zu bewerten. Normalerweise führt der Projektbesitzer die Fehlertriagebesprechungen aus. Teamleiter, Geschäftsanalysten und andere Stakeholder, die über bestimmte Projektrisiken sprechen können, nehmen an den Triagebesprechungen teil.

Der Projektbesitzer kann eine freigegebene Abfrage für neue und erneut geöffnete Fehler definieren, um Fehler auflisten zu können, die triaged sind.

Auf der Seite "Abfrageergebnisse" können Sie schnell in der Liste der Fehlerarbeitselemente mit den Nach-oben- und NACH-UNTEN-Pfeilen nach oben und unten navigieren. Während Sie jeden Fehler überprüfen, können Sie ihn zuweisen, Details hinzufügen oder Priorität festlegen. Weitere Informationen finden Sie unter Triage-Arbeitsaufgaben.

Screenshot of Query Results, Active Bugs, and Triage mode Right pane.

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. Im Produktbacklog können Sie auch die folgenden Aufgaben ausführen:

Wenn Ihr Team Fehler als Aufgaben verfolgt, verwenden Sie verwaltete Abfragen, um Fehler auflisten und zu triagen. Dann werden in jedem Sprint die Fehler angezeigt, die dem Sprint aus dem Sprint-Backlog oder Taskboard zugewiesen wurden.

Taskboardelemente im Vergleich zu Abfragelistenelementen

Sie können feststellen und fragen, 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, aber nicht mit einem übergeordneten Backlogelement verknüpft zu haben. Diese Elemente werden in der erstellten Abfrage angezeigt, werden aber möglicherweise nicht im Taskboard selbst angezeigt. Das System führt die Abfrage aus und wendet dann einige Hintergrundprozesse an, bevor Taskboardelemente angezeigt werden.

Diese Gründe können dazu führen, dass Arbeitsaufgaben, die zur Aufgabenkategorie gehören, nicht in einem Sprint-Backlog oder Taskboard angezeigt werden:

  • Die Aufgabe oder der Fehler wurde nicht mit einem übergeordneten Backlogelement verknüpft. Nur Fehler und Aufgaben, die Sie mit einem übergeordneten Produktbacklogelement (Scrum), einer Benutzergeschichte (Agile) oder einer Anforderung (CMMI) verknüpft haben, mit einem Iterationspfad, der auf den Sprint festgelegt ist, wird auf der Sprint-Backlogseite angezeigt.
  • Die Aufgabe oder der Fehler ist ein übergeordnetes Element einer anderen Aufgabe oder eines Fehlers, oder der Benutzerabschnitt ist ein übergeordnetes Element eines anderen Benutzerabschnitts. Wenn Sie eine Hierarchie von Aufgaben, Fehlern oder Benutzergeschichten erstellt haben, werden nur die Aufgaben auf untergeordneter Ebene oder die untergeordneten Storys unten in der Hierarchie angezeigt.
  • Das verknüpfte übergeordnete Element oder das verknüpfte Element des Vorgangs entspricht einem backlog-Element, das für ein anderes Team definiert ist. Oder der Bereichspfad des übergeordneten Backlogelements oder des übergeordneten Fehlers des Vorgangs unterscheidet sich vom Bereichspfad des Vorgangs oder fehlers.

Erstellen von Inlinetests, die mit Fehlern verknüpft sind

Wenn Ihr Team Fehler als Anforderungen nachverfolgt, können Sie das Kanban-Board verwenden, um Tests hinzuzufügen, um Fehlerkorrekturen zu überprüfen.

Screenshot of Kanban board, 3 columns showing inline tests added and linked to bugs.

Updatefehlerstatus

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

Anpassen des Boards zum Nachverfolgen von Zwischenzuständen

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

Automatisieren der Fehlerzustellung basierend auf dem Workflowstatus

Um auswahlaktionen zu automatisieren, fügen Sie ihrem Arbeitselementtyp benutzerdefinierte Regeln hinzu. Fügen Sie beispielsweise eine Regel wie in der folgenden Abbildung dargestellt hinzu. Diese Regel gibt an, dass ein Fehler der Person zugewiesen wird, die den Fehler geöffnet hat, sobald sie behoben wurde. In der Regel überprüft diese Person, dass der Fehler behoben ist und den Fehler schließt. Weitere Informationen finden Sie unter Anwenden von Regeln auf Workflowzustände (Vererbungsprozess).

Screenshot of rule defined to reassign bug based on resolved state.

Festlegen des Arbeitselementstatus in pull-Anforderung

Wenn Sie eine Pullanforderung erstellen, können Sie den Statuswert der verknüpften Arbeitselemente in der Beschreibung festlegen. Folgen Sie der Syntax: {state value}: #ID. Wenn Sie die Pullanforderung zusammenführen, liest das System die Beschreibung und aktualisiert den Arbeitselementstatus. Im folgenden Beispiel legen wir Arbeitselemente #300 und #301 auf Aufgelöst und #323 und #324 auf "Geschlossen" fest.

Screenshot of setting work item state within a PR.

Hinweis

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

Integration in Azure DevOps

Eine der Methoden, die von Azure DevOps verwendet werden, um die Integration zu unterstützen, besteht darin, Objekte mit anderen Objekten zu verknüpfen. Zusammen mit der Verknüpfung von Arbeitselementen zu Arbeitselementen können Sie auch Arbeitselemente mit anderen Objekten verknüpfen. Verknüpfen Sie Objekte wie Builds, Versionen, Verzweigungen, Commits und Pullanforderungen wie in der folgenden Abbildung dargestellt.

Conceptual image that shows link types used to link work items to build and release objects.

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

Das Entwicklungssteuerelement unterstützt das Verknüpfen und Anzeigen von Links, die mit Builds, Git Commits und Pullanforderungen vorgenommen wurden. Oder wenn ein TFVC-Repository verwendet wird, unterstützt er Links zu Änderungenets und versionierten Elementen. Wenn Sie den Link auswählen, wird das entsprechende Element in einer neuen Browserregisterkarte geöffnet. Weitere Informationen finden Sie unter Drive Git-Entwicklung aus einem Arbeitselement.

Development control on work item form with sample links to build, pull requests, and commits.

Das Bereitstellungssteuerelement unterstützt Links zu und Anzeige von Versionen, die die Arbeitselemente enthalten. Das folgende Bild zeigt beispielsweise mehrere Versionen, die Links zu dem aktuellen Arbeitselement enthalten. Sie können jede Version erweitern, um Details zu jeder Phase anzuzeigen. Sie können den Link für jede Version und Phase auswählen, um die entsprechende Version oder Phase zu öffnen. Weitere Informationen finden Sie unter Verknüpfen von Arbeitselementen zu Bereitstellungen.

Deployment control on work item form with sample releases.

Pipelines werden häufig definiert, um automatisch auszuführen, wenn ein neues Commit auf ein Git-Repository auftritt. Arbeitselemente, die mit den Commitpipelinen verknüpft sind, werden als Teil der Pipelineausführung angezeigt, wenn Sie Ihre Pipelineeinstellungen anpassen. Weitere Informationen finden Sie unter Anpassen Ihrer Pipeline.

Screenshot of Pipeline Settings, Automatically link work items in this run from selected branch.

Erstellen oder Bearbeiten eines Arbeitselements nach einem Buildfehler

Wenn Sie klassische Pipelines (nicht YAML) verwenden, können Sie Arbeitselemente für einen Buildfehler erstellen. Ausführliche Informationen finden Sie unter Buildoptionen, Erstellen eines Arbeitselements zum Fehler.

Sie können den Fehlerstatus, zuordnungen und Trends mithilfe von Abfragen nachverfolgen, die Sie dann diagrammen und einem Dashboard hinzufügen können. Hier finden Sie beispielsweise zwei Beispiele, in denen aktive Fehlertrends nach Status und aktiven Fehlern nach Priorität im Laufe der Zeit angezeigt werden.

Screenshot of two active bug query charts, Bug Trends by State and by Priority.

Weitere Informationen zu Abfragen, Diagrammen und Dashboards; Weitere Informationen zu verwalteten Abfragen und Diagrammen und Dashboards finden Sie unter "Informationen zu verwalteten Abfragen und Diagrammen".

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

Der Analytics-Dienst ist die Berichtsplattform für Azure DevOps, die die vorherige Plattform basierend auf SQL Server Reporting Services ersetzt.

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

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

Weitere Informationen zur Verwendung von Analyseansichten finden Sie unter "Analyseansichten " und "Erstellen eines aktiven Fehlerberichts" in Power BI basierend auf einer benutzerdefinierten Analyseansicht.

Sie können Power BI verwenden, um komplexere Berichte zu erstellen als das, was Sie von einer Abfrage erhalten können. Weitere Informationen finden Sie unter Connect with Power BI Data Connector.

Vordefinierte SQL Server-Fehlerberichte

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

Diese Berichte erfordern, dass Sie SQL Server Analysis Services und SQL Server Reporting Services für Ihr Projekt konfiguriert haben. 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. Siehe Marketplace für Azure DevOps.

Weitere Informationen zu Erweiterungen finden Sie unter Azure Boards-Erweiterungen, die von Microsoft entwickelt wurden.

Versuchen Sie dies als Nächstes:

Produktrückführung und Kanban-Board

Kanban-Board

Sprint-Backlog und Taskboard

Integration in Azure DevOps

Branchenressourcen