Guten Freitag allerseits, Freunde! Ende Juni starten wir eine neue Gruppe beim
QA Specialist- Kurs, der im Mittelpunkt der heutigen Veröffentlichung stehen wird.
Es gibt viele Indikatoren, anhand derer Sie die Effektivität des Testerteams messen können. Eine davon ist das Verhältnis der zurückgewiesenen Fehler oder die Anzahl der abgelehnten Fehlerberichte geteilt durch die Gesamtzahl der empfangenen Berichte. Sie müssen denken, dass wenn die Anzahl der abgelehnten Berichte Null ist, das gut ist, aber es ist nicht so einfach. Schauen wir uns die Arten der zurückgewiesenen Fehler an, sehen Sie, wie sie sich auf die Rate der zurückgewiesenen Fehler auswirken, und berechnen Sie das richtige Verhältnis für Ihr Team.
Es gibt drei Kategorien von zurückgewiesenen Fehlern:
- Nicht reproduzierbare Fehler;
- Falsche Fehler
- Doppelte Fehler.
Beginnen wir mit den Fehlern selbst.
Nicht reproduzierbare Fehler
Es gibt zwei Arten von nicht reproduzierbaren Fehlern. Der erste ist ein Fehler, der wirklich schwer zu reproduzieren ist. Dies kann ein Fehler sein, der aus dem Zusammenspiel mehrerer Parameter resultiert, von denen einige Sie nicht einmal kennen.
Angenommen, Sie haben mehrere Tests hintereinander durchgeführt und einer der Tests hat den Konfigurationsparameter vom Standardwert A auf einen anderen Wert B geändert. Der Fehler tritt nur auf, wenn der Konfigurationsparameter den Wert B enthält und der Eingabewert C ist Wenn Sie versuchen, den Fehler zu reproduzieren, möchten Sie höchstwahrscheinlich mit einem bekannten Status beginnen, um das System zu initialisieren (oder möglicherweise eine Neuinstallation durchzuführen). Es tritt kein Fehler auf, da der Konfigurationsparameter jetzt wieder den Standardwert A enthält.
Eine andere Variante dieser Art von nicht reproduzierbarem Fehler besteht darin, dass der Test tatsächlich einen Fehler festgestellt hat, die Wiedergabeinformationen jedoch keine Daten enthalten: einen Schritt, einen bestimmten Eingabewert oder das Verständnis, dass der Fehler nur bei einem bestimmten Verfahren auftritt. Versuche, den Fehler zu reproduzieren, führen daher zu nichts.
In beiden oben genannten Fällen liegt jedoch tatsächlich ein Defekt am Produkt selbst vor.
Die zweite Art von nicht reproduzierbarem Fehler ist, wenn der Fehler nicht wiederholt werden kann, weil er nicht existiert. Der Tester hat möglicherweise etwas bemerkt, das jedoch falsch interpretiert wurde, oder das zum Testen verwendete System weist möglicherweise ein Problem auf, z. B. eine fehlerhafte Hardwarekomponente, einen inkompatiblen Treiber oder falsche Zugriffseinstellungen. Versuche, den Fehler auf einem ordnungsgemäß konfigurierten System zu reproduzieren, schlagen fehl.
Diese beiden Fehlertypen werden in den Fehlermeldesystemen normalerweise als "abgelehnt - kann nicht reproduziert werden" gekennzeichnet.
Falsche Fehler
Diese Art von Fehler tritt auf, wenn der Tester entscheidet, dass sich das Produkt auf eine bestimmte Weise verhalten soll, und einen Fehler meldet, wenn das Verhalten nicht den Erwartungen entspricht. Eine detailliertere Untersuchung der Anforderungen zeigt jedoch, dass die Erwartungen des Testers falsch waren und das Produkt tatsächlich ordnungsgemäß funktionierte. Das heißt, das getestete Produkt funktionierte ordnungsgemäß, und der Tester, der mit den Anforderungen nicht ausreichend vertraut war, machte einen Fehler.
Solche Fehler werden in Fehlerberichtssystemen normalerweise als "abgelehnt - kein Fehler" oder "abgelehnt - von der Architektur" gekennzeichnet (dh das Verhalten stimmt mit der Architektur überein).
Doppelte Fehler
Wiederholte Fehler sind die Fehler, die man bereits gemeldet hat, und der nächste meldet sich danach. Ein Fehler wiederholt sich nur, wenn die „Symptome“ seines Auftretens gleich sind. Und wenn die Grundursache des Fehlers dieselbe ist, sich jedoch herausstellt, dass die „Symptome“ unterschiedlich sind, ist dies keine Wiederholung des Fehlers!
Diese Fehler werden in Fehlermeldesystemen normalerweise als "abgelehnt - duplizieren / wiederholen" gekennzeichnet.
Wie abgelehnte Fehler ein Team beeinflussen
Offensichtlich ist ein falscher Fehler eine Art Zeitverschwendung, die der Tester damit verbracht hat, den Fehler zu reproduzieren und zu melden, die Zeit, die diejenigen, die die Fehler sortieren, damit verbringen, sie zu lesen und zu verstehen, und die Zeit, die Entwickler damit verbringen, einen nicht reproduzierbaren Fehler zu reproduzieren oder um etwas zu reparieren (und zu stören), das dieses Update nicht benötigte.
Neben der Tatsache, dass die abgelehnte Fehlerquote oder RDR ein Maß für die Ineffizienz des Testerteams ist, spricht er auch über die Professionalität von Testern im Allgemeinen. Ein Fehler, der aufgrund des Mangels an erforderlichen Informationen im Bericht nicht reproduziert werden kann, weist darauf hin, dass die Tester nicht genau waren und nicht hart genug gearbeitet haben, um diesen Fehler mithilfe der oben beschriebenen Schritte zu reproduzieren. Bei Fehlern, die nur selten reproduziert werden, haben die Tester die niedrige Wiedergabefrequenz im Bericht im Allgemeinen nicht notiert.
Das Auftreten eines falschen Fehlers zeigt an, dass Tester die Produktanforderungen nicht vollständig verstehen. Wiederholte Fehler weisen darauf hin, dass die Tester keine Mindestsuche in der lokalen Fehlerdatenbank durchgeführt haben, um zu überprüfen, ob sie früher aufgetreten ist. Oder es bedeutet, dass der Spezialist, der diesen Fehler gemeldet hat, nicht der erste war, der die richtigen Schlüsselwörter in den Namen aufgenommen hat, um die Suche nach seinen anderen Kollegen zu erleichtern.
Wenn sich herausstellt, dass der gefundene Fehler zurückgewiesen wird, bin ich ärgerlich, weil ich als Laie angesehen wurde. Einerseits bedeutet dies, dass ich die gefundenen Fehler verteidigen werde. Wenn mein Bericht abgelehnt wird, gehe ich wie folgt vor:
- Ich überprüfe erneut, ob der Fehler in meinem System reproduziert wird, und füge die Wiedergabeschritte hinzu, wenn ich etwas verpasst habe.
- Wenn mein Missverständnis der Anforderungen durch eine mehrdeutige Anforderung oder eine falsche Dokumentation verursacht wurde, werde ich darauf bestehen, dass der Fehler als Dokumentationsfehler markiert und erst geschlossen wird, wenn die Dokumentation korrigiert wird.
- Wenn ich der Meinung bin, dass das Verhalten des Produkts bei der Erfüllung der Anforderung falsch ist, werde ich mit Architekten und Entwicklern über die Anforderungen sprechen und versuchen, sie davon zu überzeugen, dass die Anforderungen aktualisiert werden müssen (am Ende vertrete ich die Meinung des Kunden!).
- Wenn der Fehler als Duplikat zurückgewiesen wird, werde ich sicherstellen, dass er nicht auf die gleiche Weise markiert wurde oder nicht "gemäß demselben Szenario" angezeigt wird.
Andererseits macht mich eine gewisse Wahrscheinlichkeit der Fehlerabweisung vorsichtig. Wenn ich nicht ganz sicher bin, ob ich einen Fehler gefunden habe, werde ich vor dem Melden noch etwas Zeit damit verbringen, dies zu überprüfen. Ich frage oft einen Kollegen, ob ich die Anforderungen richtig interpretiere oder ob der Fehler auf dem System eines anderen reproduziert wird.
Stellungnahme gegen das völlige Fehlen abgelehnter Fehler
Das Testteam sollte das RDR-Niveau überwachen und sich bemühen, es zu reduzieren. Die Frage ist nur, welche RDR als gut anzusehen ist.
Auf den ersten Blick scheint 0% das optimale Ergebnis zu sein, aber ich bin damit nicht einverstanden. Ich glaube, wenn der RDR auf einem gesunden Niveau gehalten wird, ist dies normal, denn wenn er nahe Null liegt, leidet das Testteam offensichtlich unter nicht weniger schwerwiegenden Problemen als beispielsweise einem zu hohen RDR.
Das Testteam muss große Anstrengungen unternehmen, um einen extrem niedrigen RDR zu erreichen. Jeder abgelehnte Fehler wird analysiert, um zu verstehen, was schief gelaufen ist, und jeder Tester, der einen abgelehnten Fehler gemeldet hat, muss erklären, was tatsächlich passiert ist und wie eine solche Situation in Zukunft vermieden werden kann. Infolgedessen melden Tester Fehler, bei denen sie absolut sicher sind.
Wenn sie ein Verhalten bemerken, von dem sie glauben, dass es die Verwendbarkeit des Produkts beeinträchtigt, ziehen sie es vor, dieses Verhalten als selbstverständlich zu betrachten, anstatt zu rechtfertigen, dass sie einen Fehler gefunden haben, der tatsächlich kein Fehler ist, der auf Anforderungen basiert. Wenn sie Beweise dafür haben, dass ein Fehler aufgetreten ist, es jedoch kein gutes Szenario für die Reproduktion gibt, werden sie es vorziehen, ihn nicht zu melden. sie wollen sich wirklich nicht aufregen. Wenn sie auf einen leichtfertigen Fehler stoßen, entscheiden sie sich möglicherweise, ihn überhaupt nicht zu melden, da kleinere Fehler ihn nicht immer beheben. Warum also das Risiko eingehen und befürchten, dass der gefundene Fehler zurückgewiesen wird?
Kurz gesagt, das Streben nach einem sehr niedrigen RDR führt zu Stress und ungesundem Verhalten im Testteam und erhöht auch die Wahrscheinlichkeit, dass einige Fehler unbemerkt bleiben.
Wir brauchen Tester, die nicht nur offensichtliche Fehler melden, sondern auch vor verdächtigem Verhalten im Projekt warnen. Wir glauben, dass Tester, die großen Wert darauf legen, dass der Fehler auch auf Kosten doppelter Berichte nicht verschwindet, besser sind als Tester, die stundenlang prüfen, ob in Berichten bereits ein Fehler gemeldet wurde oder nicht, aus Angst, dass dies der Fall ist mache ein Duplikat. Wir möchten, dass sich die Tester wohl fühlen, indem sie das Wort des Systemarchitekten oder die Anforderungsspezifikation in Frage stellen, auch wenn dies bedeutet, dass einige ihrer Fehler als zurückgewiesen markiert werden.
Wir brauchen Tester, die keine Angst haben, von Zeit zu Zeit Fehler zu machen. Dies bedeutet, dass ein Gleichgewicht erforderlich ist, sodass einige kleine RDR als akzeptabel angesehen werden.
Finden des optimalen Ausschusskoeffizienten für zurückgewiesene Fehler
Meine Faustregel lautet, dass der RDR 15 Prozent betragen sollte. Dieser Wert basiert auf meiner Erfahrung mit dem Testerteam, das in jeder Hinsicht ein gutes und effektives Team war. Es war unser RDR während mehrerer Projekte, die nacheinander durchgeführt wurden, während das andere Team, das an denselben Projekten und parallel zu uns arbeitete, obwohl es weniger produktbewusst war und als weniger effektiv angesehen wurde, einen RDR von 30 Prozent hatte .
Ich glaube nicht, dass es eine andere Rechtfertigung für diese Bedeutung gibt als mein inneres Gefühl. Das ist definitiv nicht wissenschaftlich. Ich werde nicht mit einem Team streiten, das auf 10 oder 20 Prozent ausgerichtet ist, aber ich denke, dass es bereits ein Problem ist, 30 Prozent zu ertragen oder ein Ziel von 5 Prozent zu setzen.
Letztendlich ist dies eine Entscheidung, die vom Testerteam getroffen werden muss, basierend auf den Eigenschaften des Produkts, dem Fachwissen des Teams, dem Entwicklungsmodell, der Erfahrung des Entwicklungsteams und vielem mehr. Ich empfehle Ihnen dringend, RDR im Auge zu behalten und darüber nachzudenken, ob Sie etwas damit anfangen müssen. Und wenn es zu hoch oder zu niedrig ist, sollten geeignete Maßnahmen ergriffen werden.
Traditionell warten wir auf Ihre Kommentare und laden Sie zu einem
kostenlosen Webinar ein , das am 14. Juni stattfinden wird. Bis dann!