Bug-Tracking-Board: von der Meldung bis zu Reproduktion und Release

Projekte & Entwicklung

Bug-Tracking-Board: von der Meldung bis zu Reproduktion und Release

Das Entwicklungsteam, das eine Fehlermeldung erhält, nutzt dieses Bug-Tracking-Board vom Tag der Meldung bis zur Veröffentlichung der Korrektur. Das Whiteboard bündelt eine Matrix, die die Bearbeitungsreihenfolge nach Auswirkung und Häufigkeit festlegt, die Grundsätze der Triage, eine Reproduktionsvorlage mit Beispiel, die 6 Schritte von der Meldung bis zum Release sowie Kriterien für den Fall, dass sich der Fehler nicht reproduzieren lässt. Das Aufgabenboard hat 5 Spalten - Meldung, Reproduktion, in Korrektur, in Prüfung und veröffentlicht - und startet mit 5 Hauptaufgaben - Meldung, Reproduktion, Korrektur, Release und Weitergabe - samt Teilaufgaben, alle offen.

0 Likes 0 Kopien Autor: WeProcess
Bug-Tracking Qualitätssicherung Fehlerbehebung Reproduktionsschritte Release-Prüfung
Kostenlos registrieren und diese Vorlage nutzen

Mit einem kostenlosen Konto können Sie diese Vorlage aus dem Marktplatz kopieren

Whiteboard-Vorschau

Vorschaumodus Bug-Tracking-Board: von der Meldung bis zu Reproduktion und Release

Whiteboard-Vorschau

(1) Grundlagen der Bug-Bearbeitung (z... (2) Auswirkung × Häufigkeit (Bearbeit... Schwer und gelegentlich Schwer und ständig Gering und gelegentlich Gering und ständig (3) Reproduktionsvorlage (unverändert... (4) Von der Meldung bis zum Release d... (5) Wenn es sich nicht reproduzieren ... (6) Vor der Korrektur zu prüfen (7) Bedingungen für den Abschluss Bug-Tracking-Board Anleitung: (1) Me... Vorgehen und Absc... Regeln und Abläufe Stopp-Kriterium Beispiele und Rec... Ein einziger EingangJede Meldung wird zur Karte auf diesem Board. Was per Chat kommt, wandelt die Person, die es sieht, vor der Antwort in eine Karte um. Reihenfolge nach AuswirkungNicht nach Eingangsreihenfolge: erst in der Matrix unten platzieren, dann eine zuständige Person zuweisen. Was alles andere stopptDaten werden in Produktion beschädigt oder eine Zahlung wird doppelt ausgeführt. Diese zwei Fälle gehen vor laufender Arbeit. Beispiel für SchweregradSev1: Zahlung schlägt bei allen Nutzern fehlSev2: Speichern in einem bestimmten Browser nicht möglichSev3: Darstellungsfehler 縦軸: Auswirkung (g... In diesem Sprint korrigieren. Oft fehlen eingegrenzte Bedingungen, investieren Sie zuerst Zeit in deren Identifikation. Höchste Priorität. Alles andere stoppen und beginnen; auch ohne bekannte Ursache zuerst einen Workaround veröffentlichen, um die Auswirkung zu stoppen. Sammeln lassen und zusammen mit verwandten Änderungen korrigieren. Bewegt sich 3 Monate nichts, vorerst schließen. Alle stoßen täglich darauf, die gefühlte Belastung ist groß. Regelmäßig zuerst das mit dem geringsten Aufwand abarbeiten. (1) UmgebungOS / Browser / App-Version / Plan.Z. B. macOS 15, Chrome 130, bezahlter Plan (2) SchritteNummeriert, so detailliert, dass andere es nachvollziehen können.Z. B. 1. Vorgang öffnen 2. Fälligkeitsdatum leeren 3. Speichern klicken (3) Erwartung und ErgebnisZ. B. erwartet = gespeichert und zurück zur Liste / tatsächlich = Speichern-Button bleibt grau und reagiert nicht (4) Häufigkeit und BelegZ. B. 5 von 5 Malen. Screenshots und Konsolenfehlermeldung anhängen, mit Uhrzeit des Auftretens (1) MeldungZur Karte machenPrüfen Sie, ob die 4 Punkte der Vorlage ausgefüllt sind, und fragen Sie sonst beim Melder nach. (2) TriageIn der Matrix platzierenLegen Sie den Quadranten nach Auswirkung und Häufigkeit fest und bestimmen Sie sofort Reihenfolge und Verantwortliche. (3) Reproduktion prüfenSelbst nachvollziehenPrüfen Sie, ob es mit denselben Schritten auftritt. Wenn nicht, ändern Sie die Bedingungen und versuchen Sie es 3-mal. (4) Ursache findenBereich eingrenzenGleichen Sie den Zeitpunkt des ersten Auftretens mit den letzten Änderungen ab und grenzen Sie bis zum verursachenden Code ein. (5) Korrigieren und prüfenZusammen mit TestFügen Sie zuerst einen Test hinzu, der den Fehler erkennt, korrigieren Sie dann und bestätigen Sie in produktionsnaher Umgebung. (6) ReleaseAn Melder zurückmeldenBestätigen Sie die Behebung in Produktion und teilen Sie das Ergebnis sowie das Ende des Workarounds mit. Fehlende Schritte vermuten (Bildschirmaufnahme erbitten) Umgebungsunterschiede vermuten (Version, Verbindung, Erweiterungen) Tritt es nach 3 Versuchen nicht auf, vorerst zurückgeben Beim Zurückgeben notieren, was getestet wurde Seit wann es auftritt (mit letzten Änderungen abgleichen) Ob es weitere Meldungen mit derselben Ursache gibt Ob sich vorab ein Workaround mitteilen lässt Ein Regressionstest wurde hinzugefügt Die Behebung in Produktion wurde bestätigt Das Ergebnis wurde dem Melder mitgeteilt Die Ursachenverteilung wird monatlich überprüft
100%

Zum Verschieben ziehen, zum Zoomen scrollen

Inhalt des Aufgabenboards

Meldung 16 Einträge

Meldeweg einrichten
Bug reproduzieren
Ursache beheben
Prüfen und releasen
Teilen und schließen
Vorlage verteilen
Schweregrad klären
Schritte nachgehen
Umgebung eingrenzen
Ohne Repro zurück
Ursache eingrenzen
Test zuerst bauen
Erneut verifizieren
Release prüfen
Melder informieren
Trends reflektieren

Reproduktion 0 Einträge

In Korrektur 0 Einträge

In Prüfung 0 Einträge

Veröffentlicht 0 Einträge

← Zurück zu den Vorlagen