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

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? Außerdem: 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. Außerdem sollten Sie Ihre Codefehler auf eine Weise verwalten, die ihren Agile-Methoden entspricht.

Um diese Szenarien zu unterstützen, stellt Azure Boards einen spezifischen Arbeitselementtyp zur Nachverfolgung von Codefehlern mit dem Namen „Fehler“ (Bug) bereit. Fehlerarbeitselemente besitzen alle Standardmerkmale, über die andere Arbeitselementtypen auch verfügen, sowie ein paar mehr. Eine Übersicht der Standardmerkmale finden Sie unter Nachverfolgen von Arbeit mit User Storys, Problemen, Fehlern, Features und Epics.

Fehler bieten auch die folgenden zusätzlichen Merkmale:

• 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

• Sie müssen einem Projekt hinzugefügt sein.
• Zum Anzeigen oder Ändern von Arbeitselementen müssen die Berechtigungen Arbeitselemente in diesem Knoten anzeigen und Arbeitselemente in diesem Knoten bearbeiten 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 und Zugriff für die Arbeitsnachverfolgung.
• Um neue Tags hinzuzufügen, die Arbeitselementen hinzugefügt werden sollen, müssen Sie über Basic-Zugriff oder höher verfügen, und die Berechtigung Neue Tagdefinition erstellen auf Projektebene muss auf Zulassen festgelegt sein. Standardmäßig sind diese Berechtigungen für die Gruppe Mitwirkende festgelegt. Selbst wenn die Berechtigung explizit auf Projektbeteiligte festgelegt ist, verfügen sie nicht über die Berechtigung zum Hinzufügen neuer Tags, da dies durch ihre Zugriffsebene verhindert wird. Weitere Informationen finden Sie unter Kurzreferenz zu Beteiligtenzugriff.
• Alle Projektmitglieder, auch Mitglieder der Gruppe Leser, können E-Mails senden, die Arbeitselemente enthalten.

Tipp

Um einen Fehler melden zu können, müssen Benutzer*innen mindestens über Zugriff alsProjektbeteiligte verfügen, und die Berechtigung Arbeitselemente in diesem Knoten bearbeiten muss für sie auf Zulassen festgelegt sein für den Bereichspfad, in dem der Fehler hinzufügen wird. Weitere Informationen finden Sie unter Festlegen von Berechtigungen und Zugriff für die Arbeitsnachverfolgung

Arbeitselementtyp „Fehler“ (Bug)

Die folgende Abbildung zeigt den Fehler-Arbeitselementtyp für den Scrum-Prozess. Der Fehler-Arbeitselementtyp für Agile- und CMMI-Prozesse verfolgt ähnliche Informationen nach. Es ist so konzipiert, dass es im Product Backlog zusammen mit den Anforderungen oder im Taskboard zusammen mit den Aufgaben angezeigt wird.

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 Updates, Optionen, die Sie oder Ihr*e Administrator*in aktiviert haben sowie daran, 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.

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

---

Reproduktionsschritte
(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.

---

Systeminfo
In Build gefunden

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 lokales Azure DevOps: Wenn Sie auf ein Dropdownmenü aller Builds zugreifen möchten, die ausgeführt wurden, können Sie die FIELD-Definitionen für In Build gefunden und In Build integriert aktualisieren, sodass diese auf eine globale Liste verweisen. 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 Formatoptionen für Buildnummern.

---

Priorität¹

• 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.

---

Schweregrad¹

Eine subjektive Bewertung der Auswirkungen eines Fehlers oder Arbeitselements auf das Projekt oder Softwaresystem. Beispiel: Wenn ein Remotelink innerhalb der Benutzeroberfläche – ein seltenes Ereignis – dazu führt, dass eine Anwendung oder Webseite abstürzt – eine schwerwiegende Kundenerfahrung, 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. Und 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 jedoch 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:

¹ 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.
• Wie Ihr Team Arbeit organisiert. 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

• Fehler zusammen mit Anforderungen priorisieren (Stapelrang)
• Fehleraufwand für die Prognose schätzen
• Fehlerstatus im Kanban-Board aktualisieren
• Fehler in Velocity-Diagramme und kumulative Flussdiagramme einschließen
• Kann das Prognosetool zur Unterstützung der Sprintplanung verwenden
• Kann Fehler in den Bereich Planung ziehen und dort ablegen, um einem Sprint Fehler zuzuweisen
• Kann Fehler in Lieferplänen anzeigen

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
• Kann Fehler in den Bereich „Planung“ ziehen und dort ablegen, um einem Sprint Fehler 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 „Fehler“ zugeordnet und werden weder in Backlogs noch in Boards angezeigt
• Fehler werden weder in Backlogs noch in Boards, Sprint Backlogs, Taskboards oder Lieferplänen angezeigt
• Kann Fehler nicht in den Bereich „Planung“ ziehen und dort ablegen, um einem Sprint Fehler 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 Konfigurieren und Anpassen von Azure Boards lesen.

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

Fehler hinzufügen oder erfassen

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

Tipp

Standardmäßig ist das Feld Titel das einzige Pflichtfeld beim Erstellen eines Fehlers. Sie können Fehler schnell auf die gleiche Weise hinzufügen, wie Sie User Storys oder Product Backlog Items mit Azure Boards hinzufügen. Wenn Sie einige Felder zu Pflichtfeldern machen möchten, fügen Sie hierzu bedingte Regeln auf Grundlage einer Zustandsänderung hinzu. Weitere Informationen finden Sie unter Hinzufügen einer Regel zu einem Arbeitselementtyp (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 aus Ihrem Product Backlog oder Kanban-Board heraus definieren. Weitere Informationen finden Sie unter Erstellen Ihres Product Backlogs oder Beginnen mit der Verwendung Ihres Kanban-Boards.

• Hinzufügen eines Fehlers aus dem Kanban-Board

  

• Hinzufügen eines Fehlers aus dem Kanban-Board

  

Tipp

Wenn Sie einen Fehler aus Ihrem Product Backlog oder Kanban-Board hinzufügen, wird dem Fehler automatisch der standardmäßige Bereichspfad und der 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 aus Ihrem Kanban-Board, Product Backlog, Sprint Backlog oder Sprint Taskboard heraus definieren. Sie fügen einen Fehler einem Product Backlog-Arbeitselement als untergeordnetes Element hinzu.

• Hinzufügen eines verknüpften untergeordneten Fehlers aus dem Kanban-Board
  Sie fügen einen Fehler auf die gleiche Weise hinzu, wie Sie einem Backlog Item eine Aufgabe hinzufügen. Weitere Informationen finden Sie unter Hinzufügen von Aufgaben oder untergeordneten Elementen als Prüflisten.

  

• Hinzufügen eines verknüpften untergeordneten Fehlers aus dem Sprint Backlog
  Sie fügen einen Fehler auf die gleiche Weise hinzu, wie Sie einem Sprint Backlog eine Aufgabe hinzufügen. Weitere Informationen finden Sie unter Hinzufügen von Aufgaben zu Backlog Items.

  

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“.

• Test Runner: Beim Ausführen manueller Tests können Sie Fehler erstellen auswählen. Weitere Informationen finden Sie unter Ausführen manueller Tests.

  

• Erweiterung „Testen und Feedback“: Wenn Sie explorative Tests ausführen, können Sie zwischen „Fehler erstellen“ und Aufgabe erstellen auswählen. Weitere Informationen finden Sie unter Exploratives Testen mit der Erweiterung „Test und 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

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. Wenn nach dem Auflösen oder Schließen eines Fehler noch weitere Arbeiten gefunden wurden, können Sie ihn 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 Anwenden von Regeln auf Workflowstatus, Automatisieren der Neuzuweisung auf Grundlage einer Zustandsänderung.

Ü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, nachdem er als „korrigiert“ verifiziert wurde. Sie können jedoch auch einen Fehler aus einem der folgenden Gründe schließen. Die zur Auswahl verfügbare 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

Sobald ein Fehler geschlossen wurde und der Fix in Bereitstellungen aktiv freigegeben wurde, besteht die empfohlene Vorgehensweise darin, ihn aufgrund einer Regression nie wieder 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. Anschließend können Sie Ihren Teamdashboards Abfragen und Abfragediagramme hinzufügen, um 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: innerhalb der letzten drei Wochen geöffnete Fehler (Created Date > @Today-21)

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

Selektierungsmodus in Abfrageergebnissen

Nachdem Sie mit dem Programmieren und Testen begonnen haben, sollten Sie regelmäßige Selektierungsbesprechungen abhalten, 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 schnell 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.

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:

• Organisieren von Fehlern in Ihrem Backlog, Stapelrang im Vergleich zu anderen Elementen (Stapelrangfolge ist deaktiviert, wenn Filterung aktiviert ist)
• Zuweisen von Fehlern zu einem Sprint aus Ihrem Backlog über den Bereich Planung
• Unterordnen von Fehlern zu einem Feature oder andere Portfolio Backlog Items über den Bereich Zuordnung
• Anzeigen eines Rollups der Arbeit zu Portfolio Backlog Items.

Wenn Ihr Team Fehler als Aufgaben nachverfolgt, verwenden Sie verwaltete Abfragen, um Fehler aufzulisten und zu selektieren. Anschließend werden in jedem Sprint 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 dass sie mit einem übergeordneten Backlog Item verknüpft sind. 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 wurde nicht mit einem übergeordneten Backlog Item verknüpft. Es werden nur die Fehler und Aufgaben auf der Sprint Backlog-Seite angezeigt, die Sie mit einem übergeordneten Product Backlog Item (Scrum), einer übergeordneten User Story (Agile) oder einer übergeordneten Anforderung (CMMI) verknüpft haben, 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 erstellt haben, werden nur die Aufgaben auf untergeordneter Ebene oder die Storys auf untergeordneter Ebene am Fuß der Hierarchie angezeigt.
• 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 Kanban-Board verwenden, um Tests hinzuzufügen, um Fehlerkorrekturen zu überprüfen.

Aktualisieren des Fehlerstatus

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

• Wenn Ihr Team Fehler als Anforderungen nachverfolgt, verwenden Sie das Kanban-Board, wie in der folgenden Abbildung gezeigt. Weitere Informationen finden Sie unter Erste Schritte mit Ihrem Kanban-Board.

  

• Wenn Ihr Team Fehler als Aufgaben nachverfolgt, verwenden Sie das Taskboard. Weitere Informationen dazu finden Sie unter Aktualisieren und Überwachen Ihres Taskboards.

  

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:

• Hinzufügen von Spalten zu Ihrem Kanban-Board
• Anpassen eines Sprint Taskboards
• Änderungsabfragen für Kanban-Boards

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 Person wieder zugewiesen wird, die den Fehler geöffnet hatte, nachdem er aufgelöst wurde. 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).

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 legen wir die Arbeitselemente #300 und #301 auf „Aufgelöst“ und #323 und #324 auf „Geschlossen“ fest.

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.

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

Verknüpfen von Arbeitselementen mit der Entwicklung

Das Development-Steuerelement unterstützt das Verknüpfen mit und Anzeigen von Links, die zu Builds, Git-Commits und Pull Requests erstellt wurden. Oder wenn ein TFVC-Repository verwendet wird, 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.

Verknüpfen von Arbeitselementen mit Releases

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.

Verknüpfen von Arbeitselementen mit Pipelineausführungen

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.

Erstellen oder Bearbeiten eines Arbeitselements bei einem Buildfehler

Wenn Sie klassische Pipelines (nicht YAML) verwenden, können Sie bei einem Buildfehler Arbeitselemente erstellen. Ausführliche Informationen finden Sie unter Buildoptionen, Erstellen eines Arbeitselements bei Fehlern.

Überwachen von Fehlerstatus, Zuweisungen und Trends

Sie können den Fehlerstatus, Zuweisungen und Trends mithilfe von Abfragen nachverfolgen, die Sie dann 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.

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

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

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

Analytics-Ansichten 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 Analyseansichten finden Sie unter Was sind Analytics-Ansichten und Erstellen eines aktiven Fehlerberichts in Power BI basierend auf einer benutzerdefinierten Analytics-Ansicht.

Sie können Power BI verwenden, um Berichte zu erstellen, die komplexer sind, als diejenigen, die Sie mittels einer Abfrage erhalten können. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit dem Power BI-Datenconnector.

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

Verwandte Artikel

• Verschieben, Ändern des Typs oder Löschen von Arbeitselementen
• Kopieren oder Klonen eines Arbeitselements

Product Backlog und Kanban-Board

• Backlogs, Portfolios und Agile-Projektmanagement
• Erstellen Ihres Backlogs
• Definieren von Features und Epics
• Organisieren Ihres Backlogs, Zuordnen untergeordneter Arbeitselemente zu übergeordneten Elementen
• Interaktives Filtern von Backlogs, Boards, Abfragen und Plänen.
• Prognostizieren Ihres Product Backlogs

Kanban-Board

• Informationen zu Boards und Kanban
• Schnellstart für das Kanban-Board
• Neuanordnen von Karten
• Hinzufügen von Aufgaben oder untergeordneten Elementen als Prüflisten

Sprint Backlog und Taskboard

• Bewährte Methode für Scrum und die Arbeit mit Sprints
• Zuweisen von Backlog Items zu einem Sprint
• Hinzufügen von Aufgaben
• Aktualisieren des Task Boards

Integration in Azure DevOps

• Verknüpfen von User Storys, Problemen, Fehlern und anderen Arbeitselementen
• Einem Arbeitselement oder Pull Request folgen
• Konfigurieren von Ausführungs- oder Buildnummern

Branchenressourcen

• Gute und schlechte technische Schulden (und wie TDD (testgesteuerte Entwicklung) hilft) von Henrik Kniberg
• Verwalten der technischen Schulden, gepostet von Sven Johann und Eberhard Wolff