Alle Kollektionen
Anfangen
Neuling
Bug Disputes – Gute und schlechte Beispiele
Bug Disputes – Gute und schlechte Beispiele

Lerne hier den Unterschied zwischen guten und schlechten Bug-Disputes.

André avatar
Verfasst von André
Vor über einer Woche aktualisiert

"Ein Bug-Dispute ist eine Funktion, die dir die Möglichkeit gibt, eine Anfrage an unsere Disput-Manager zu stellen, um einen abschließenden Blick darauf zu werfen, wenn du glaubst, dass dein Bug legitim ist oder ohne Grund herabgestuft wurde."

Motivation

Eine Ablehnung eines Bugs zu akzeptieren, ist nie einfach, aber unsere erfahrenen Tester wissen, wie man damit umgeht. Sie wissen, wann und wie sie einen erfolgreichen Bug-Dispute einreichen können, um ihren Bug-Report von den Dispute-Managern abschließend überprüfen zu lassen. Ein Bug-Dispute ist eine Funktion, die dir die Möglichkeit gibt, eine Anfrage an unsere Disput-Manager zu stellen, um einen abschließenden Blick darauf zu werfen, wenn du glaubst, dass dein Bug legitim ist oder ohne Grund herabgestuft wurde. Mehr über die Funktion Bug-Dispute findest du hier.

Wann solltest du einen Bug-Dispute einreichen

Um zu verhindern, dass du einen Monat lang von Bug-Disputes ausgeschlossen wirst, reiche Bug-Disputes nur für Bugs ein, von denen du zu 100% überzeugt bist. Das mag etwas abschreckend klingen - soll es aber nicht. Wir möchten, dass du dir über den von dir gemeldeten Bug und über die im Kommentar des TL bereitgestellten Ablehnungs-/Herabstufungsgründe Gedanken machst.

Stelle dir die Frage: "Habe ich etwas übersehen? Habe ich eine Log-Datei hochgeladen, um meine Behauptung im Bug-Report zu stützen? Ist es möglich, dass ich vergessen habe, etwas im Bug-Report zu teilen? Habe ich das Produkt richtig verstanden?". Sobald du diese Fragen beantwortet hast, wirst du wissen, ob du einen Bug-Dispute einreichen solltest oder nicht.

Was sollte ein guter Bug-Dispute enthalten

Hast du jemals darüber nachgedacht, eine Beschwerde vor Gericht einzureichen? Es unterscheidet sich nicht so sehr vom Einreichen eines Bug-Disputes. Beides muss Folgendes enthalten:

  • Die offizielle Begrüßung für den Prüfer

  • Die Erklärung, warum du sie kontaktiert hast

  • Den Grund, warum du glaubst, dass deine Rechte gefährdet wurden

  • Zusätzliche Beweise wie Anhänge, Links und Protokolle

  • Den vorgeschlagenen Lösungsweg für das Problem

  • Die offizielle Grußformel am Ende

Lösen des Disputes: Die Rolle der Dispute-Manager

Das Ziel der Dispute-Manager ist es, Fairness bei der Lösung von Streitigkeiten zwischen Teamleitern und Testern sicherzustellen.

Wenn beide Seiten gültige Argumente vorlegen und das Gewicht ihrer Ansprüche gleich ist, wird dem Tester der Vorteil gegeben und die Dispute-Manager treffen Entscheidungen zugunsten des Testers. In solchen Fällen haben die Anliegen des Testers Priorität.

Wenn jedoch ein Dispute abgelehnt wird, bedeutet das, dass es legitime Gründe für die Ablehnung gibt und der Tester sollte daraus lernen.

Die Dispute-Manager bemühen sich, ein faires Gleichgewicht für Tester aufrechtzuerhalten, indem sie immer die Regeln und die Qualität des Bug-Reports berücksichtigen und ihre umfangreiche Erfahrung bei der Überprüfung von Bug-Disputes anwenden. Ihr Ziel ist es, so fair wie möglich in ihrem Entscheidungsprozess zu sein.

Ein positives Beispiel für einen Bug-Dispute

Oben hast du gesehen, was erforderlich ist, um deinen Bug-Dispute erfolgreich zu gestalten. Jetzt schauen wir uns an, wie es in der Praxis aussieht. Das untenstehende Beispiel behandelt eine realistische Situation. Manchmal müssen Tester nicht alle oben genannten Elemente verwenden, um zu beweisen, dass das Problem gültig ist. Im positiven Beispiel unten siehst du, dass der Tester nur 4 Elemente verwendet hat:

  • Die Begrüßung "Hallo Dispute-Team"

  • Die Erklärung, warum der Tester das Problem als Bug betrachtet

  • Die möglichen Auswirkungen und die betroffene Zielgruppe, sofern der Bug nicht behoben wird

  • Die offizielle Grußformel am Ende lautet "Bitte überprüft es erneut! Danke!".

Wenn wir berücksichtigen, dass der Tester sich so kurz wie möglich aber so detailliert wie nötig gehalten hat, können wir schließen, dass das Finden des richtigen Gleichgewichts ebenfalls der Schlüssel zum Erfolg ist. Die Bereitstellung zusätzlicher Informationen, die nicht im ursprünglichen Bug-Report enthalten waren, kann auch die Chancen erhöhen, dass der Dispute angenommen wird. Zum Beispiel kann ein zweiter Screencast oder eine Konsolen-Logdatei in Google Drive hochgeladen und als Link im Dispute geteilt werden.

Ein negatives Beispiel für einen Bug-Dispute

Mit Wut oder harten Worten in einen Bug-Dispute zu gehen, ist nie eine gute Idee. Du kannst es versuchen, aber du wirst mit einer Ablehnung, einer Warnung oder sogar einer Sperre auf unserer Plattform enden. Überlege also, welche möglichen Szenarien auftreten können, wenn du unhöflich, unprofessionell oder brachial bist. Klingt schlecht, oder?

Einige unserer Tester hingegen lesen unsere Regeln nicht oder vergessen sie, was zu Ablehnungen von Bug-Reports und Disputes führt. Im unten gezeigten Fall schrieb der Tester:

  • Der Titel und das tatsächliche Ergebnis sollten ähnlich sein.
    Der Titel soll eine kurze Beschreibung davon liefern, wann und wo was genau passiert ist. Er sollte so kurz wie möglich und so umfangreich wie nötig sein. Andererseits sollten Tester in den tatsächlichen Ergebnissen im Detail erklären, worin das Problem besteht, den Umfang des Problems darlegen, welche andere Seiten betroffenen sind (falls vorhanden) usw. Das Teilen all dieser Details im Titel des Bug-Reports wäre unmöglich.

  • Das Video zeigt genau die Sequenz aller Schritte und zeigt das beschriebene Problem.
    Im Screencast sollten nicht alle Schritte gezeigt werden, die nötig sind, um den Bug zu reproduzieren. Nur die letzten ein oder zwei Schritte sollten im Video gezeigt werden.

Was im Bug-Dispute fehlte:

  • Die offizielle Begrüßung zu Beginn

  • Die Kenntnis unserer Regeln

  • Die Kenntnis unserer Standards für die Qualität von Bug-Reports

  • Zusätzliche Informationen zur Stützung der Behauptung zum Schweregrad des Bugs

Weitere Beispiele für Fehler beim Einreichen eines Bug-Disputes sind:

  • Das Senden von "Bitte überprüfen!" im Bug-Dispute

  • Schreiben von "Danke TL. Ich verstehe!" in der Annahme, dass sie auf einen Kommentar im Bug-Bericht geantwortet haben

  • Ansprache des Dispute-Managers als TL

  • Lügen über unbeantwortete Anfragen usw.

Denke daran, dass wir die Historie jedes einzelnen Bug-Reports einsehen können. Der Weg der Wahrheit und harten Arbeit ist die einzige Garantie dafür, dass wir dich für mögliche Beförderungen in Betracht ziehen. Wenn du deine Karriere bei uns machen möchtest, stelle sicher, dass du die richtigen Schritte in diese Richtung unternimmst.

Hat dies Ihre Frage beantwortet?