3 worst defect reporting habits
Mängel sind ein ernstes Geschäft und kleine Fehler können teuer sein.
Sie wissen, was zu tun ist, wenn Sie einen Defekt finden. Sie melden es; entweder in a Defect Tracker / Fehlermanagement-Tool oder in einer Excel-Tabelle. Die zugrunde liegenden Prinzipien sind für beide Methoden gleich.
Fehlermanagement-Tools garantieren keine bessere Berichterstattung. Es sind gute Praktiken, die den Tag retten.
Um das Gute zu schätzen, müssen wir erkennen, was nicht.
Was du lernen wirst:
- 3 Worst Defect Reporting-Gewohnheiten und wie man sie bricht
- # 1) Faulheit
- # 2) Rauschen
- # 3) Mangel an Kreativität
- Literatur-Empfehlungen
3 Worst Defect Reporting-Gewohnheiten und wie man sie bricht
Hier geht:
# 1) Faulheit
Nehmen Sie sich nicht die Zeit, das Beste zu tun, was Sie können.
Dies ist das Fehlerverfolgungsprozess in den meisten Teams gefolgt:
((Hinweis- Klicken Sie auf ein Bild, um es zu vergrößern.)
Wie Sie sehen können, überprüft der Testleiter die Fehler, bevor er sie an die QS-Teams sendet.
Diese Überprüfung beinhaltet die Bestätigung von:
- Gültigkeit - Ist es ein Fehler?
- Vollständigkeit - Titel, Schritte, Daten, Screenshot usw.
- Duplikate
- Reproduzierbar oder nicht ... usw.
Ich weiß aus erster Hand, dass es unmöglich ist, dass eine Qualitätssicherung zu 100% gründlich ist.
Also die Einstellung: „Ich werde das Problem so melden, wie ich es möchte. Die QS-Leitung kann erneut überprüft werden. Er kann entscheiden, ob der Fehler gültig / vollständig ist oder nicht. Dies ist das Ende Ihres QS-Teams und Ihrer Glaubwürdigkeit.
Wussten Sie, dass einige Kunden eine SLA für die Anzahl akzeptabler ungültiger Fehler haben? Sobald die Anzahl überschritten wird, bestrafen sie die Auftragnehmer für jeden gemeldeten ungültigen Mangel?
Abhilfe:: Führen Sie Ihre Due Diligence durch und sind Sie für Ihre Ergebnisse verantwortlich. Ein Defekt kam zurück, weil nicht genügend Informationen vorhanden waren oder dass es sich nicht um einen Fehler handelt? Es ist möglicherweise nicht immer die Schuld des Entwicklungsteams. Es ist nicht so, dass sie die Probleme in der Anwendung nicht besitzen möchten. Es könnte ein echtes QA-Team-Durcheinander sein. Lass es nicht zu.
# 2) Rauschen
Machen wir das mit einemBeispiel.
Unten ist ein Screenshot von OpenEMRs Patientenbildschirm erstellen. Es ist ein Open-Source-Krankenhausmanagementsystem.
In diesem Bildschirm kann der Benutzer das Geburtsdatum des Patienten über eine Kalenderfunktion eingeben. Was es nicht tut, ist den Eintrag auf die Auswahl aus dem Kalender zu beschränken. Was ich meine ist, Sie können das Geburtsdatum wie '31-Mar-1983' aus dem Kalender auswählen. Ändern Sie es später in '31-Feb-1983'.
Warum am 31. Februar? Implementieren Fehler erraten und versuchen Sie es mit negativen Daten im Feld; Was ist der springende Punkt beim Testen, nicht wahr?
Sobald ich fertig bin, klicke ich auf 'Patient erstellen'. Da das Datum ungültig ist, erwarte ich, dass das System einen Fehler anzeigt und den Patienten nicht erstellt. Das passiert aber nicht. Es erstellt den Patienten wie folgt.
Beachten Sie die Felder Alter und Geburtsdatum im folgenden Bildschirm:
Beim Testen können Sie dies einige Male versuchen und Folgendes entscheiden:
- Es ist ein Fehler.
- Es ist reproduzierbar.
- Es ist kein Duplikat (Wenden Sie sich zur Bestätigung an Ihr Team)
- Sie kennen die genaue Beschreibung des Problems
- Außerdem kennen Sie die genauen Schritte, die dies ermöglichen.
Jetzt, wo Sie den Rohstoff haben, können Sie loslegen.
Sie beginnen es zu melden. Das Zuweisen der Schwere des Fehlers ist ein obligatorischer Schritt, und Ihr Team verwendet möglicherweise etwas Ähnliches wie das folgende Tabelle als Referenz:
Schwere | Einschlag |
---|---|
1 (kritisch) | • Dieser Fehler ist kritisch genug, um das System zum Absturz zu bringen, Dateien zu beschädigen oder potenziellen Datenverlust zu verursachen • Es kommt zu einer abnormalen Rückkehr zum Betriebssystem (Absturz oder Systemfehlermeldung). • Die Anwendung bleibt hängen und das System muss neu gestartet werden. |
2 (hoch) | • Es kommt zu einem Mangel an wichtigen Programmfunktionen bei der Problemumgehung. |
3 (mittel) | • Dieser Fehler beeinträchtigt die Qualität des Systems. Es gibt jedoch eine intelligente Problemumgehung, um die gewünschte Funktionalität zu erreichen - beispielsweise über einen anderen Bildschirm. • Dieser Fehler verhindert, dass andere Bereiche des Produkts getestet werden. Andere Bereiche können jedoch unabhängig getestet werden. |
4 (niedrig) | • Es liegt eine unzureichende oder unklare Fehlermeldung vor, die sich nur minimal auf die Produktnutzung auswirkt. |
5 (Kosmetik) | • Es liegt eine unzureichende oder unklare Fehlermeldung vor, die keine Auswirkungen auf die Produktnutzung hat. |
Da dieser Defekt das System nicht zum Absturz bringt oder eine wichtige Funktionalität blockiert oder verhindert, dass die anderen Bereiche der Anwendung getestet werden, entscheiden wir uns möglicherweise für 'Niedrig'.
Sieht ungefähr richtig aus?
FALSCH. Aus den Daten des Patienten geht hervor, dass alle Impfungen und sonstigen Erinnerungen überfällig sind. Dies kann richtig sein oder auch nicht. Für einen Patienten bestimmt sein Alter, ob er einen Kinderarzt oder einen Allgemeinarzt usw. aufsucht.
Es beeinflusst die Dosierung von Medikamenten und viele andere Behandlungsbereiche, die wir möglicherweise nicht einmal kennen.
Also werde ich mit 'Hoch' gehen. Ich bin damit einverstanden, dass es unwahrscheinlich ist, dass das Krankenhauspersonal das Geburtsdatum eines Patienten falsch eingibt. Dies sei jedoch ein Faktor, der sich auf die Priorität auswirkt, wann das Problem behoben werden muss.
Meine Aufgabe als Tester ist es, sicherzustellen, dass ich die Schwere des Problems so gut wie möglich kommuniziere.
Abhilfe:: Beeilen Sie sich nicht, sich zu melden. Stellen Sie zu 100% sicher, dass Sie die Auswirkungen der Probleme aus verschiedenen Blickwinkeln verstehen. Dies ist der beste Mehrwert, den Tester bieten können. Wir sagen nicht nur: 'Etwas funktioniert nicht'. Wir sagen auch: 'Hier ist, was passieren wird, wenn dies weiterhin nicht funktioniert.' Tonnenweise Unterschiede, nicht wahr?
# 3) Mangel an Kreativität
Die Tester haben eine wunderbare Gelegenheit, Vorschläge zur Verbesserung der Software zu machen.
In deiner Fehlermanagement-Tool Sie können auch einen Fehler vom Typ 'Verbesserungsvorschlag' einreichen. Hier können Sie kreativ werden.
Abhilfe:: Querdenken. Wenn Sie der Meinung sind, dass einem bestimmten Feature ein „Wow“ -Faktor fehlt und Sie wissen, wie Sie ihn einbringen können, bringen Sie die Idee vor. Im schlimmsten Fall könnte es abgelehnt werden und das ist in Ordnung. Der wichtige Teil ist es zu versuchen.
Verwenden Sie diese Superkraft auch mit Vorsicht. Versuchen Sie, keine Kommentare wie 'Ich hasse die Farbe des Banners, bitte ändern Sie es.'
Hier ist eine guteBeispieleines Verbesserungsvorschlags, auf den ich gestoßen bin: Ersetzen von 'E-Mail an Händler' durch die Option 'Mit dem Händler chatten' auf einer Autohaus-Website. Es wird vorausgesagt, dass mehr Verkehr in Verkäufe umgewandelt wird.
Ich wünschte ich wäre so kreativ! Aber vielleicht können wir alle darauf hinarbeiten.
Hier ist ein Bonus. Eine Checkliste, um diese schlechten Gewohnheiten loszuwerden:
1. Vermittelt mein Titel das Problem klar und präzise?
Zum Beispiel:'Patient erstellen funktioniert nicht' ist kein guter Titel. 'Patienten erstellen schlägt fehl, auch wenn alle Eingabefelder korrekte Werte enthalten' lautet.
zwei. Wie hoch ist die Reproduzierbarkeit?
Mit anderen Worten, passiert es immer? Kenne ich die genaue Reihenfolge der Schritte, die das Problem wiederholen?
3. Ist dieses Problem plattform-, browser- oder benutzerspezifisch?
Vier. Sind die Schritte abgeschlossen und Sie kommen zu Ihrem Problem?
5 . Habe ich einen Screenshot dabei?
6. Muss ich meinen Screenshot mit Anmerkungen versehen, um bestimmte Bereiche hervorzuheben?
7. Ist der Name der angehängten Bilddatei beschreibend?
Verwenden Sie nicht so etwas wie 'Untitled.jpg'. Geben Sie ihm einen beschreibenden Namen.
8. Habe ich die Testdaten aufgenommen?
Zum Beispiel:Fügen Sie einen Fehler in einem Admin-Modul hinzu, für den Berechtigungsnachweise erforderlich sind. Das Entwicklungsteam hat möglicherweise Zugriff auf die QS-Umgebung. Sie möchten keine Verzögerung und Nachverfolgung von so etwas Grundlegendem.
9. Kann ich weitere Details angeben, um meinen Defekt zu verstärken?
((Beispiel:ein Verweis auf die FRD oder ein Gespräch mit dem Kunden usw.)
10. Verstehe ich, wie schwerwiegend das Problem aus verschiedenen Perspektiven ist?
elf. Kenne ich die Grundursache des Problems? Wenn ja, habe ich Beweise (möglicherweise Protokolldateien) und kann ich diese einschließen? Bitte beachten Sie, dass Sie dies möglicherweise nicht immer wissen oder wissen müssen. Aber wenn Sie dies tun, tut es nicht weh, es aufzunehmen.
12. Ist der Fehlerbericht frei von Grammatik-, Format-, Rechtschreib- und Interpunktionsproblemen?
Videos zum Anschauen mit VR-Headset
13. Kenne ich einen Weg, um das Produkt zu verbessern?
Denken Sie, dass dies zeitaufwändig ist? Nun, sobald es zur Gewohnheit wird, wird es nicht mehr sein.
Rooting zum Besseren Fehlerberichterstattung Routinen!
Über den Autor: Dieser Artikel wurde vom STH-Teammitglied Swati verfasst.
Fühlen Sie sich frei, Ihre Fragen / Kommentare unten zu posten.
Literatur-Empfehlungen
- Warum ist Bug Reporting eine Kunst, die jeder Tester lernen sollte?
- Was ist der Defekt- / Fehlerlebenszyklus beim Testen von Software? Tutorial zum Fehlerlebenszyklus
- Beispiel für Fehlerberichte für Web- und Produktanwendungen
- Was ist eine fehlerbasierte Testtechnik?
- Fehlermanagementprozess: So verwalten Sie einen Fehler effektiv
- Fehler-Triage-Prozess und Möglichkeiten zur Behandlung von Fehler-Triage-Besprechungen
- Wie schreibe ich einen guten Fehlerbericht? Tipps und Tricks
- 3 Strategien zum Umgang mit einem Blockerdefekt