SDB:Fehlerdefinitionen

Dieser Artikel beschreibt das Vorgehen bei gefundenen Fehlern, egal ob Anwender aktiv oder passiv bei der Entwicklung beteiligt sind.

Getestet mit openSUSE		Empfohlene Artikel		Verwandte Artikel
	12.3 12.2 12.1 11.4 11.3 11.2		SDB:Fehler berichten		SDB:YaST Fehler berichten

Vorab Infos

Dies ist eine erweiterte Version des Novell-Bugzilla-Dokuments , das Begriffe definiert, die beim Ausfüllen von Fehlern genutzt werden, zusammen mit einigen Beispielen, die für openSUSE- ind SUSE Linux Enterprise-Produkte in Novells Bugzilla relevant sind. Zwischen diesen beiden Dokumenten sollte es keine Diskrepanz geben, ist dem doch so, dann melden Sie dies bitte auf der opensuse-testing-Mainlingliste.

Fehlerschweregrade

Das severity-Feld beschreibt die Ausmaße eines Fehlers.

Blocker

• Hält Entwickler oder Teste davon ab, ihre Arbeit zu erledigen. Betrifft den Entwicklungsprozess.
• (Dokumentation) Schlüsseldokumentation für kritische Tests und Überprüfungen fehlt.

Beispiele:

• Unmöglich, sich anzumelden
• Unmöglich, kritische Tests durchzuführen
• Unmöglich, dass System zu aktualisieren

Critical

• Absturz, Datenverlust, Datenverfälschung, schwere Speicherlecks.
• (Dokumentation) legt keine Aktionen fest oder warnt nicht vor solchen, die zu Datenverlust oder Datenverfälschung führen.

Beispiele:

• Absturz ist wiederholbar oder für mehrere Benutzer augenscheinlich
• Speicherlecks, die während der Durchschnittsnutzung in einer Woche oder weniger zu OOM-Fehlern führen

Major

• Bedeutender Verlust von Funktionen, wie sie in den Produktanforderungen für diese Ausgabe angegeben sind oder im aktuellen Produkt existieren.
• (Dokumentation) fehlende, irreführende, ungenaue oder widersprüchliche Informationen bis zu dem Grad, dass ein Befolgen der Dokumentation den erfolgreichen Abschluss einer grundlegenden Aufgabe unmöglich macht.

Beispiele:

• Hält obligatorische Funktionen davon ab, korrekt zu funktionieren
• In vorherigen Ausgaben vorhandene Funktionen funktionieren nicht mehr

Normal

• Verlust unbedeutender Funktionen
• (Dokumentation) fehlende, irreführende, ungenaue oder widersprüchliche Informationen in der Dokumentation, ein erfolgreicher Abschluss der Aufgabe ist aber möglich.

Beispiele:

• Hält wichtige oder wünschenswerte Funktionen davon ab, korrekt zu funktionieren

Minor

• Probleme, die einfach gesehen werden können (bspw. kosmetisch, UI, leicht dokumentierbar).
• (Dokumentation) enthält stilistische Probleme oder Formatierungsfehler, aber die Funktionalität wird nicht behindert.

Beispiele

• Tippfehler in Zeichenketten

Fehlerprioritäten

Das priority-Feld beschreibt die Wichtigkeit und die Reihenfolge, in der ein Fehler behoben werden sollte. Dieses Feld wird von den Entwicklern/Ingenieuren genutzt, um ihre Arbeit zu priorisieren.

P0 - CritSit

Diese Priorität ist für Novells L3-Team reserviert. Sie wird nicht für Defekte in in Entwicklung befindlichen Produkten genutzt.

P1 - Urgent

Nutzen Sie diese Priorität für dringliche Probleme.

Beispiele:

• Blocker: Ist im allgemeinen ein P1
• Critical: Nautilus stürzt auf allen x86_64-Installationen beim öffnen einer Datei ab
• Major: Fingerabdruckunterstützung authentifiziert unabhängig von den Fingerabdrücken
• Normal: Paketverwaltungsprotokoll wird nicht rotiert (wodurch es schnell riesig wird)
• Minor: SLED ist im Startbildschirm falsch geschrieben

P2 - High

Nutzen Sie diese Priorität für obligatorische Mängel, Verbesserungen und Arbeitselemente. Das gilt für Elemente, die in dieser Ausgabe gelöst sein müssen.

Beispiele:

• Critical: Nautilus stürzt auf allen x86_64-Installationen beim Öffnen einer Datei über ssh ab
• Major: Fingerabdruckunterstützung (obligatorische Fähigkeit) funktioniert nicht mit gnome-screensaver
• Normal: Paketverwaltungssystem ist nicht in der Lage, Pakete auf Grund von regulären Ausdrücken zu sperren (aber es wird eine Gleichwertigkeit zu rug benötigt)
• Minor: Benachrichtigung über eine potentielle Sicherheitslücke wird auf dem Bildschirm verdunkelt

P3 - Medium

Nutzen Sie diese Priorität für wünschenswerte Mängel, Verbesserungen und Arbeistelemente. Das gilt für Elemente, die wir gerne beheben würden, für die wir aber nicht die Auslieferung verschieben.

Beispiele:

• Critical: Nautilus stürzt bei einer bestimmten Nicht-Standard-Konfiguration beim Öffnen einer Datei über SSH ab
• Major: Fingerabruckunterüstützung (obligatorische Fähigkeit) funktioniert nicht mit sudo
• Normal: Paketverwaltungssystem zeigt nicht den korrekten Fortschritt an
• Minor: Benachrichtigungen hüllen den Text nicht passend ein und können ihn manchmal abschneiden

P4 - Low

Nutzen Sie diese Priorität für optionale Mängel, Verbesserungen und Arbeitselemente. Diese Priorität ist nicht so stark wie wünschenswert.

Beispiele:

• Critical: Nautilus stürzt bei einzelnen Nutzern beim Öffnen einer Datei über ssh mit einer Rückverfolgung ab
• Major: Fingerabdruckunterstützung (obligatorische Fähigkeit) funktioniert bei Nutzern mit komplexer Konfiguration nicht mit sudo
• Normal: Paketverwaltungssystem zeigt für Verbesserungsaktualisierungen nicht das korrekte Symbol an
• Minor: Benachrichtigungen haben manchmal nicht das korrekte Symbol

P5 - None

Zeigt an, dass keine Priorität zugeordnet wurde.

Setzen und Ändern von Prioriäten und Schwergraden

Wenn Sie einen Fehlerbericht erstellen, dann setzen Sie bitte den korrekten Schwergrad (severity). Der für den Bericht zuständige Ingenieur wird den Schweregrad überprüfen und die Priorität setzen. Das Ändern des Schweregrads und der Priorität sollte nur vom Vorgesetzten des Ingenieurs und dem Produktbesitzer vorgenomen werden - besonders von den Projekt- und Produktverwaltern. Wenn Sie mit den Werten nicht zufrieden sind, ändern Sie sie bitte nicht, sondern setzen statt dessen einen Kommentar ab, in dem Sie erklären, warum Sie damit nicht zufrieden sind.

Found By

Fülgen Sie dies bitte folgendermaßen korrekt aus:

• Kunden werden repräsentiert durch: Customer, Novell Technical Services, IS&T und Consulting.
• Die openSUSE-Gemeinschaft wird durch "community user" repräsentiert.
• Novell-Partner nutzen "Third party developer/partner".
• QA nutzen die Attribute Component Test und System Test; Ingenieure nutzen Developer.

Found in Version

Bitte geben Sie die Version des Produkts an, da bei der Beobachtung des Fehlers genutzt wurde. Sobald es korrekt gesetzt ist, sollte es nicht mehr geändert werden. Es bietet wertvolle historische Informationen.

Fixed in Milestone

Das Fixed in Milestone enthält üblicherweise einen Satz von versionsspezifischen Meilensteinen. Dieses Feld wird automatisch vom Bausystem gesetzt.

Ship Stopper Bugs

Wenn Sie einen Fehler finden, den Sie als Auslieferungsstopper ansehen, dann setzen Sie das flah "SHIP_STOPPER" auf "?" und fügen Sie - für die openSUSE-Distribution - Stephan Kulow <coolo@novell.com> als Empfänger hinzu. Coolo wird entscheiden, ob es sich wirklich um einen Auslieferungsstopper handelt und wird den Wert des flags auf "+" (markiert es als Auslieferungsstopper) oder "-" (markiert es nicht als Auslieferungsstopper) setzen.

Setzen Sie SHIP_STOPPER bitte nur auf "?" und lassen Sie Coole den Rest erledigen.