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? 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

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.

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.

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

---

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

• Fehler zusammen mit Anforderungen priorisieren (Stapelrang)
• Fehleraufwand für die Prognose schätzen
• Fehlerstatus auf dem Board aktualisieren
• Fehler in Velocity-Diagramme und kumulative Flussdiagramme einschließen
• In der Lage sein, das Vorhersagetool zur Unterstützung der Sprintplanung zu verwenden
• Fehler in den Planungsbereich ziehen, um Fehler einem Sprint zuzuweisen
• 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
• 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.

Fehler hinzufügen oder erfassen

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

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

  

• Hinzufügen eines Fehlers über das Board

  

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.

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

  

• Hinzufügen eines verknüpften untergeordneten Fehlers aus dem 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.

  

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

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

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.

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.

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:

• Strukturieren von Fehlern in Ihrem Backlog. Stapelrang im Vergleich zu anderen Elementen. Die Stapelrangfolge wird deaktiviert, wenn die Filterung aktiviert wird.
• Zuweisen von Fehlern zu einem Sprint aus Ihrem Backlog über den Bereich Planung
• Zuordnen übergeordneter Fehler zu Features oder anderen 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. 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.

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 Board wie in der folgenden Abbildung gezeigt. Weitere Informationen finden Sie unter Aktualisieren des Arbeitselementstatus.

  

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

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

Festlegen des Arbeitselementzustands in Pull Requests

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

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. Weitere Informationen finden Sie unter Erstellen einer Arbeitsaufgabe bei Fehler.

Überwachen von Fehlerstatus, Zuweisungen und Trends

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.

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.

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

Verwandte Artikel

• Entfernen, Löschen oder Wiederherstellen von Arbeitselementen
• Kopieren oder Klonen eines Arbeitselements

Product Backlog und Board

• Verwenden von Backlogs zum Verwalten von Projekten
• Erstellen Ihres Backlogs
• Definieren von Features und Epics
• Organisieren Ihres Backlogs und Zuordnen untergeordneter Arbeitselemente zu übergeordneten Elementen
• Interaktives Filtern von Backlogs, Boards, Abfragen und Plänen.
• Prognostizieren Ihres Product Backlogs

Übersicht

• Informationen zu Boards und Kanban
• Verwenden des Boards
• Neuanordnen von Karten
• Hinzufügen von Aufgaben oder untergeordneten Elementen als Prüflisten

Sprint Backlog und Taskboard

• Scrum und bewährte Methoden
• Zuweisen von Backlog Items zu einem Sprint
• Hinzufügen von Aufgaben
• Aktualisieren und Überwachen Ihres Taskboards

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