Ist es gut, dass Tester konkurrieren, um zu sehen, wer mehr Fehler verursacht?

54

Ich bin ein Softwareentwickler. Es gibt ein Team von Testern, die vom Analysten geschriebene Testfälle verfolgen und ausführen, aber auch Erkundungstests durchführen. Es sieht so aus, als ob die Tester konkurrierten, um herauszufinden, wer mehr Fehler aufdeckt, und ich habe festgestellt, dass die Qualität der Fehlerberichte abgenommen hat. Anstatt die Funktionalität zu testen und Fehler im Zusammenhang mit dem Betrieb der Software zu melden, haben die Tester Fehler in Bezug auf Bildschirmverbesserungen, Benutzerfreundlichkeit oder dumme Fehler gemeldet.

Ist das gut für das Projekt? Wenn nicht, wie kann ich (als Softwareentwickler) versuchen, das Denken und die Einstellungen des Testerteams zu ändern?

Ein weiteres Problem besteht darin, dass die Frist geschätzt wird und sich nicht ändern kann. Wenn sich die Frist nähert, müssen die Tester ihre Testfälle abschließen, und dies führt dazu, dass die Qualität der Tests abnimmt. Dies führt dazu, dass legitime Fehler im Endprodukt enthalten sind, das der Kunde erhalten hat.

OBS: Dieser Wettbewerb ist keine Praxis der Firma! Es ist ein Wettbewerb zwischen nur den von ihnen organisierten Testern und ohne Preise.

Nur ein neugieriger Geist
quelle
3
Sind die Tester vor einem Build involviert? Bedeutet dies, dass sie an der Entwicklung der Anforderungen oder Anwendungsfälle oder User Stories, der Überprüfung der Designdokumentation oder der Teilnahme an Codeüberprüfungen beteiligt sind? Sind die Berichte, die die Tester einreichen, korrekt und gibt es Überprüfungen, um sicherzustellen, dass die Berichte gültig und vollständig sind? Wenn Sie Ihre Frage bearbeiten könnten, um mehr über die Rollen / Verantwortlichkeiten der Tester und die Verwaltung ihrer Berichte zu erfahren, wäre es hilfreich, eine gute Antwort zu schreiben.
Thomas Owens
35
Wettbewerb ist nicht unbedingt schlecht, kann aber in Verbindung mit Anreizen nachteilige Auswirkungen haben. Diese Frage erinnert mich an eine Geschichte in The Daily WTF, in der Tester mit Entwicklern zusammengearbeitet haben, um zusätzliche Bugs zu erstellen, die dann heldenhaft gefunden werden konnten . Viel Spaß beim Lesen. Wiederholen Sie diesen Fehler nicht.
amon
6
Ihr Punkt ist gut aufgenommen, aber nebenbei schätze ich es, wenn mir jemand sagt, dass meine Arbeit Usability-Probleme hat. Das ist eines der schwierigsten Dinge, die man in Software richtig machen kann, und eines der wertvollsten Dinge, die man richtig machen kann.
jpmc26
9
Nachdem ich aus einem mehr als einjährigen Projekt mit sorgfältiger Qualitätssicherung gekommen bin, kann ich sagen, dass Fehler, die darin bestehen, dass zwischen Elementen oder verschiedenfarbigen Symbolen zu viel Leerraum vorhanden ist, die gleiche Sache möglicherweise unproduktiv erscheinen lassen, letztendlich das Benutzererlebnis verbessern. Oftmals werden die Produktivität verbessert, der technische Support entlastet und eine Anwendung professioneller gestaltet. Dies sind alles wünschenswerte Merkmale. Und ja, manchmal verzögert sich Software aufgrund dessen, aber der zu zahlende Preis lohnt sich normalerweise.
Phyrfox
9
Eine Reihe von Antworten deuten darauf hin, dass die Aufgabe der Tester darin besteht, Fehler zu finden. Diese Denkweise ist es, die das Problem hervorruft, das Sie identifiziert haben. Die Aufgabe der Qualitätssicherung besteht darin, genau zu bestimmen, ob das Produkt einen festgelegten Qualitätsstandard erfüllt oder nicht . Es ist mir egal, ob ein Tester Fehlerberichte erstellt. Es ist mir wichtig, ob ein Tester eine genaue, kundenorientierte Analyse der Produktqualität erstellt. Das ist das, was Anreize geben sollte.
Eric Lippert

Antworten:

87

Ich finde es nicht gut, dass sie einen Wettbewerb daraus machen, die meisten Bugs zu finden. Während es wahr ist, dass ihre Aufgabe darin besteht, Fehler zu finden, ist ihre Aufgabe nicht, "die meisten Fehler zu finden". Ihr Ziel ist es nicht, die meisten zu finden, sondern die Qualität der Software zu verbessern. Sie für das Auffinden weiterer Fehler zu belohnen, entspricht in etwa der Belohnung eines Programmierers für das Schreiben der meisten Codezeilen und nicht für den Code mit der höchsten Qualität.

Das Verwandeln in ein Spiel gibt ihnen einen Anreiz, sich darauf zu konzentrieren, viele flache Fehler zu finden, anstatt die kritischsten Fehler zu finden. Wie Sie in Ihrer Bearbeitung erwähnen, geschieht genau dies in Ihrer Organisation.

Man könnte argumentieren, dass jeder Fehler, den sie finden, faires Spiel ist und dass alle Fehler entdeckt werden müssen. Angesichts der Tatsache, dass Ihr Team wahrscheinlich nur über begrenzte Ressourcen verfügt, sollten Sie lieber mehrere Stunden oder Tage Zeit haben, um tief in Ihrem System nach wirklich großen Fehlern zu suchen, oder mehrere Stunden oder Tage damit verbringen, die App nach Tippfehlern und kleinen Fehlern zu durchsuchen Fehler bei der Ausrichtung von Objekten auf einer Seite?

Wenn das Unternehmen wirklich ein Spiel daraus machen möchte, geben Sie den Entwicklern die Möglichkeit, einem Fehler Punkte hinzuzufügen. "Dumme Bugs" bekommen negative Punkte, schwer zu findende Bugs mit gut geschriebenen Berichten bekommen mehrere Punkte. Dies bewegt dann den Anreiz von "am meisten finden" zu "am besten bei der Erledigung Ihrer Arbeit sein". Dies wird jedoch auch nicht empfohlen, da ein Programmierer und ein QA-Analyst zusammenarbeiten könnten, um ihre Zahlen künstlich aufzufüllen.

Fazit: Machen Sie kein Spiel daraus, Fehler zu finden. Finden Sie Wege in Ihrer Organisation, um gute Arbeit zu belohnen und belassen Sie es dabei. Gamification belohnt Menschen für das Erreichen eines Ziels. Sie möchten nicht, dass ein QA-Analyst das Ziel hat, "die meisten Fehler zu finden", sondern "die Qualität der Software zu verbessern". Diese beiden Ziele sind nicht dasselbe.

Bryan Oakley
quelle
5
Das erste, was ich dachte, war ähnlich - wenn sie es in ein Spiel verwandeln wollen, ist es besser, wenn ein QA-Manager (falls es einen gibt) Punkte auf gefundene Fehler setzt, vorausgesetzt, man kann sich darauf verlassen, dass die Person das beste Interesse hat das Unternehmen im Auge. In dieser Hinsicht kann er den Wettbewerb besser kontrollieren und, ob Sie dies für akzeptabel halten oder nicht, den Wettbewerb sogar willkürlich näher bringen, indem er etwas höhere oder niedrigere Punkte für den Wettbewerb vergibt. ( Andernfalls gibt jeder andere auf, wenn nur eine Person
weiterkommt,
2
Trotzdem würde ich diese Idee nicht empfehlen, da es schnell langweilig wird, wenn Ihre Teammitglieder nicht fast alle identisch sind (was nicht der Fall ist). Es ist besser, gegen sich selbst anzutreten.
DoubleDouble
1
Würdigt die Idee, dass die Messung der QS-Produktivität anhand der Anzahl der gefundenen Fehler der Messung der Produktivität des Programmierers anhand von geschriebenen Codezeilen (oder geschlossenen Story Points) entspricht. Beide sind lächerlich, aber beide bleiben in den Köpfen von PHBs, die keine subtilere Methode zur Quantifizierung der Leistung sehen können.
dodgethesteamroller
Ihre Antwort ist die gleiche Sache, die ich dachte. Aber der @ DoubleDouble-Punkt über das identische Niveau der Tester ist ein guter Punkt zum Nachdenken!
Nur ein Neugieriger
2
Einverstanden. Obwohl mein früherer QA-Job keine festen Quoten hatte, hielten es einige Tester für das Wichtigste, jeden kleinen Trottel, den sie finden konnten, abzuwehren - Dinge wie "das Hemd des Charakters ist zu lang, das tun die meisten Leute Tragen Sie keine so langen Hemden (wenn die Länge der Hemden des Charakters für das Spiel völlig irrelevant war), anstatt nach echten Fehlern zu suchen, wie "Das wiederholte Anschließen / Trennen des Netzwerkkabels auf dem Host [in einem von Kollegen gehosteten Spiel] führt dazu, dass das Spiel verfällt Client und Gewinn werden zum Online-Datensatz des Hosts hinzugefügt ".
Doktor J
17

Ich werde ein bisschen mit den anderen Antworten nicht einverstanden sein. "Finden von Fehlern" für einen Tester ist ein bisschen wie "Schreiben von Code" für einen Entwickler. Die Rohmenge ist bedeutungslos. Die Aufgabe des Testers ist es, so viele Fehler wie möglich zu finden und nicht die meisten. Wenn Tester A 5 der 10 Fehler in einer Komponente hoher Qualität und Tester B 58 der 263 Fehler in einer Komponente niedriger Qualität findet, ist Tester A der bessere Tester.

Sie möchten, dass Entwickler die Mindestmenge an Code schreiben, um ein bestimmtes Problem zu lösen, und Sie möchten, dass ein Tester die Mindestanzahl an Berichten erstellt, die das fehlerhafte Verhalten korrekt beschreiben. Der Wettbewerb um die meisten Fehler ist wie der Wettbewerb um die meisten Codezeilen. Es ist viel zu einfach, in das Spielen des Systems einzusteigen, um nützlich zu sein.

Wenn Sie möchten, dass Tester am Wettbewerb teilnehmen, sollte dies direkter auf der Grundlage der Aufgaben geschehen, dh es muss überprüft werden, ob die Software wie beschrieben funktioniert. Lassen Sie die Leute vielleicht gegeneinander antreten, um herauszufinden, wer die am meisten akzeptierten Testfälle schreiben kann, oder schreiben Sie noch besser die Testfälle, die den meisten Code abdecken.

Das bessere Maß für die Entwicklerproduktivität ist die Anzahl der abgeschlossenen Aufgaben, multipliziert mit der Komplexität der Aufgaben. Das bessere Maß für die Testerproduktivität ist die Anzahl der ausgeführten Testfälle und die Komplexität der Testfälle. Sie möchten das maximieren, nicht gefundene Bugs.

Gort den Roboter
quelle
3
Die Aufgabe des Testers ist es, so viele Fehler wie möglich zu finden und nicht die meisten. Wenn es einen großen Unterschied zwischen diesen Aussagen der Testziele geben soll, ist es für mich verloren.
Atsby
6
Denn wenn Tester A 5 der 10 Fehler in einer qualitativ hochwertigen Komponente findet und Tester B 58 der 263 Fehler in einer qualitativ minderwertigen Komponente findet, ist Tester A der bessere Tester.
Gort the Robot
6
@Atsby Wenn ein einzelnes fehlerhaftes Verhalten es an 10 verschiedenen Stellen manifestiert, ist 1 Fehlerbericht über das tatsächlich fehlerhafte Objekt weitaus besser als 8 separate Fehlerberichte, die 8 von 10 der verschiedenen Symptome beschreiben.
Peteris
8
@Peteris (und Steven) Dies sind beide interessante Punkte, aber sie werden durch die zitierte Aussage von Steven nicht effektiv kommuniziert .
Atsby
@Atsby In dem Satz, den Sie zitieren, ist die erste Klausel eine relative Aussage (finde den größten Bruchteil von Fehlern) und die zweite ist absolut (finde die größte Anzahl von Fehlern). Es ist der Unterschied zwischen dem Sprichwort " Fülle diesen Eimer zu 90%" und " Fülle diesen Eimer mit einer halben Gallone", wenn der Eimer eine Gallone fasst.
dodgethesteamroller
16

Aufgrund meiner persönlichen Erfahrungen ist dies keine gute Sache. Es führt fast immer dazu, dass Entwickler Fehler melden, die doppelt, lächerlich oder völlig ungültig sind. In der Regel tauchen viele davon am Ende eines Monats / Quartals plötzlich auf, wenn die Tester sich beeilen, Quoten einzuhalten. Das Einzige, was noch schlimmer ist, ist, dass Sie Entwickler basierend auf der Anzahl der Fehler, die in ihrem Code gefunden wurden, bestrafen. Ihre Test- und Entwicklungsteams arbeiten an diesem Punkt gegeneinander, und eines kann nicht erfolgreich sein, ohne dass das andere schlecht aussieht.

Sie müssen sich hier auf den Benutzer konzentrieren. Ein Benutzer hat keine Ahnung, wie viele Fehler beim Testen gemeldet wurden. Er sieht nur den Fehler, der durchgekommen ist. Letztendlich ist es den Benutzern egal, ob Sie 20 oder 20.000 Fehlerberichte einreichen, solange die Software funktioniert, wenn sie diese erhalten. Eine bessere Messgröße für die Bewertung von Testern wäre die Anzahl der Fehler, die von Benutzern gemeldet wurden, die aber von Testern vernünftigerweise hätten abgefangen werden müssen.

Dies ist jedoch viel schwieriger zu verfolgen. Es ist ziemlich einfach, eine Datenbankabfrage durchzuführen, um festzustellen, wie viele Fehlerberichte von einer bestimmten Person eingereicht wurden. Ich vermute, dass dies der Hauptgrund dafür ist, dass die Metrik "Fehler abgelegt" von so vielen Personen verwendet wird.

bta
quelle
+1 aber das einzige Problem mit Ihrer besseren Metrik ist, dass es einen Anreiz schafft, das System zur Meldung von Benutzerfehlern nicht zu verbessern ... Die Idee ist richtig, aber es sollte sich möglicherweise um einen allgemeineren Fehler handeln, der außerhalb des offiziellen Testprozesses gefunden wird.
user56reinstatemonica8
@ user568458 - Ich ging davon aus, dass die betreffende Organisation unterschiedliche Teams für die interne Qualitätssicherung und für den kundenseitigen Support hat und dass sich diese Frage nur mit der internen Qualitätssicherung befasst. Wenn beide dasselbe Team sind, haben Sie in der Tat Interessenkonflikte (ob mit meiner Methode oder nicht).
bta
6

Es ist nichts Falsches daran, aus dem Auffinden von Fehlern ein Spiel zu machen. Sie haben einen Weg gefunden, um Menschen zu motivieren. Das ist gut. Es hat sich auch gezeigt, dass es nicht gelungen ist, Prioritäten zu kommunizieren. Den Wettbewerb zu beenden wäre eine Verschwendung. Sie müssen die Prioritäten korrigieren.

Nur wenige echte Spiele haben ein einfaches Punktesystem. Warum sollte der Käfer jagen?

Anstatt das Spiel einfach nach der Anzahl der Fehler zu bewerten, müssen Sie ein Maß für die Qualität der Fehlerberichte angeben. Dann geht es beim Wettbewerb weniger um die Anzahl der Bugs. Es wird eher wie ein Angelwettbewerb sein. Jeder wird versuchen, den großen Fehler zu finden, der eine hohe Priorität hat. Machen Sie die Qualität des Fehlerberichts zu einem Teil der Punktzahl. Lassen Sie die Entwickler den Testern Feedback zur Qualität des Fehlerberichts geben.

Die Feinabstimmung der Spielbalance ist keine einfache Aufgabe. Seien Sie also darauf vorbereitet, einige Zeit damit zu verbringen, dies richtig zu machen. Es sollte deine Ziele klar kommunizieren und es sollte Spaß machen. Dies können Sie auch anpassen, wenn sich die geschäftlichen Anforderungen ändern.

kandierte_orange
quelle
5

Das Finden von Fehlern ist ihre Aufgabe. Solange sie die Dinge nicht weniger effizient machen (zum Beispiel indem sie einen Bug für 10 Tippfehler anstelle eines Fehlers öffnen, der mehrere davon abdeckt), ermutigen sie sie, genau das zu tun, was sie tun sollen, also Ich kann nicht viel von einem Nachteil sehen.

Mootinator
quelle
Konnte nicht mehr mit Moot übereinstimmen. Natürlich könnten die Leute etwas Dummes tun (Datei 100s von Tippfehlern usw.) - aber "die Leute können etwas Dummes tun", wenn sie überhaupt einem Schema folgen.
Fattie
1

Dies ist eine Erweiterung der Antwort von @ CandiedOrange .

Betrachten Sie etwas sehr informelles und inoffizielles, um die Aufmerksamkeit auf nützlichere Ziele zu lenken. Zum Beispiel könnten die Entwickler einige kleine Token und Trophäen kaufen.

Lassen Sie jeden Tag, an dem mindestens ein schwerwiegender Fehler gemeldet wurde, ein "Fehler des Tages" -Token auf dem Schreibtisch des Testers liegen. Halten Sie einmal pro Woche eine Zeremonie mit einer Prozession von Entwicklern ab, die einen größeren und besseren "Bug of the Week" -Token oder eine Trophäe ausliefern. Machen Sie die Trophäenlieferung "Käfer des Monats" noch dramatischer, vielleicht mit Kuchen. Jedem Token oder jeder Trophäe sollte ein Zitat beigefügt sein, aus dem hervorgeht, warum die Entwickler es für gut hielten, dass beim Testen ein Fehler gefunden wurde. Kopien der Zitate sollten an einem Ort aufbewahrt werden, an dem die Tester sie alle lesen können.

Die Hoffnung ist, dass die Tester ihre Aufmerksamkeit von der Suche nach den meisten Bugs auf das Sammeln der meisten Trophäen und Token lenken. Ihre beste Strategie wäre es, die Zitate zu lesen und darüber nachzudenken, welche Testmethoden die Entwickler für wichtig halten.

Ignorieren Sie einfach unwichtige Fehlerberichte. Da alles sehr inoffiziell und informell wäre, könnte es jederzeit heruntergefahren oder geändert werden.

Patricia Shanahan
quelle
Ich müsste zustimmen. Eine Sache: Machen Sie das nicht damit, dass Sie die Zustimmung des Managements einholen. Damit es sich wie ein Spiel anfühlt, ist es wichtig, dass die Tester das Gefühl haben, die Regeln selbst zu verstehen. Wenn das Anmeldesystem das Hauptanliegen ist, teilen Sie es den Teilnehmern im Voraus mit und machen Sie sie darauf aufmerksam. Wenn Anwendungsfalldefekte mit hohem Verkehrsaufkommen die Priorität haben und keine unübersichtlichen Eckfälle, machen Sie dies klar und erläutern Sie, wie die Bewertung erfolgt. Nur klare Prioritäten zu haben, macht Spaß und bringt die Leute dazu, im richtigen Angelloch zu fischen.
candied_orange
1

Ist das gut für das Projekt?

Nein . Sie haben selbst darauf hingewiesen, dass Sie festgestellt haben, dass dies zu Berichten von geringer Qualität führt, die nicht auf die erforderliche Funktionalität abzielen, und dass die Tester das Problem verschärfen und sich anstrengen, um die tatsächlich "angenommene" Arbeit abzuschließen "zu tun.

Wenn nicht, wie kann ich (als Softwareentwickler) versuchen, das Denken und die Einstellungen des Testerteams zu ändern?

Wenden Sie sich an Ihren Projektmanager, um das Problem zu beheben. Sie sollten dies als Teil ihrer Arbeit betrachten. Wenn Ihr PM nicht bereit oder nicht in der Lage ist, damit umzugehen, können Sie Ihre eigenen Bewältigungsstrategien kaum entwickeln. (das wäre eine andere Frage)

David
quelle
-1

Ich denke, wie es sein wird (oder wie es bereits ist), wenn es so weitergeht, wird man nicht notwendigerweise eine geringere Qualität bekommen. Obwohl ich denke, dass es das Verhältnis von Menge zu Qualität verringern wird. Es hängt davon ab, ob dies eine schlechte Sache ist oder nicht. Es kommt darauf an, ob

Fehler über Bildschirmverbesserungen, Benutzerfreundlichkeit oder dumme Fehler melden.

ist etwas, das du wirklich nicht willst. Wenn dies bei den Testern klar ist, würde ich ihnen nur sagen, dass sie nicht die Dinge tun sollen, die Sie nicht melden möchten, aber klar darüber sein sollen. Tun Sie es, wenn einer dieser Berichte erneut angezeigt wird.

Der Grund, warum sie einen Wettbewerb haben, ist wahrscheinlich, dass sie Spaß an der Arbeit haben und daher wahrscheinlich nicht vorhaben, schlechte Arbeit zu leisten (wenn dies als schlecht angesehen wird).

Loko
quelle
1
Ich möchte unbedingt etwas über Usability wissen. Wir bezeichnen sie als "Bugs in the Spec".
RubberDuck
1
@RubberDuck Nun, wenn das mit dem Team 100% klar ist, gibt es einen Grund, es ihnen mitzuteilen, während sie wissen, dass Sie nicht mögen, was sie überhaupt tun, und sie wissen warum. Also warne sie. Wenn dies nicht speziell mit dem Team besprochen wird, denke ich nicht, dass Sie wirklich wütend auf sie werden können, und geben Sie nur ein Beispiel für einen der Berichte, die Sie missbilligen, und lassen Sie sie wissen, dass Sie es nicht so wollen.
Loko