it-swarm.com.de

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

Ich bin ein Softwareentwickler. Es gibt ein Team von Testern, die vom Analysten geschriebene Testfälle verfolgen und ausführen, aber auch Sondierungstests durchführen. Es scheint, als hätten die Tester konkurriert, um herauszufinden, wer mehr Fehler öffnet, 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 bezüglich Bildschirmverbesserungen, Benutzerfreundlichkeit oder dummen Fehlern 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, bemühen sich die Tester, ihre Testfälle zu beenden, und dies führt dazu, dass die Qualität der Tests abnimmt. Dies führt dazu, dass legitime Fehler im Endprodukt auftreten, das der Kunde erhalten hat.

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

54

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

Wenn sie daraus ein Spiel machen, erhalten sie einen Anreiz, sich darauf zu konzentrieren, viele flache Fehler zu finden, anstatt die kritischsten Fehler zu finden. Wie Sie in Ihrer Bearbeitung erwähnt haben, geschieht genau dies in Ihrer Organisation.

Man könnte argumentieren, dass jeder Fehler, den sie finden, ein faires Spiel ist und dass alle Fehler entdeckt werden müssen. Angesichts der Tatsache, dass Ihr Team wahrscheinlich nur über begrenzte Ressourcen verfügt, möchten Sie lieber einen Testerfokus haben, der mehrere Stunden oder Tage lang tief in Ihr System eindringt und versucht, wirklich große Fehler zu finden, oder mehrere Stunden oder Tage damit verbringt, die App nach typografischen 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 Fehler" erhalten negative Punkte, schwer zu findende Fehler mit gut geschriebenen Berichten erhalten mehrere Punkte. Dies verschiebt dann den Anreiz von "das Beste finden" zu "das Beste, was Sie tun können". jedoch, dies wird auch nicht empfohlen, da ein Programmierer und ein QS-Analyst zusammenarbeiten könnten, um ihre Zahlen künstlich aufzufüllen.

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

87
Bryan Oakley

Ich werde den anderen Antworten ein wenig widersprechen. "Fehler finden" für einen Tester ist ein bisschen wie "Code schreiben" für einen Entwickler. Die Rohmenge ist bedeutungslos. Die Aufgabe des Testers ist es, so viele der vorhandenen Fehler wie möglich zu finden und nicht die meisten Fehler zu finden. Wenn Tester A 5 der 10 Fehler in einer Komponente hoher Qualität findet 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 dass ein Tester die Mindestanzahl an Berichten aufschreibt, 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, das System zu spielen, um nützlich zu sein.

Wenn Sie möchten, dass Tester an Wettbewerben teilnehmen, sollte dies direkter darauf basieren, was sie tun sollen, um zu überprüfen, ob die Software wie beschrieben funktioniert. Lassen Sie also vielleicht Leute konkurrieren, um zu sehen, wer die am meisten akzeptierten Testfälle schreiben kann, oder noch besser, schreiben Sie die Testfälle, die den meisten Code abdecken.

Das bessere Maß für die Entwicklerproduktivität ist die Anzahl der abgeschlossenen Aufgaben mal die Komplexität der Aufgaben. Das bessere Maß für die Produktivität des Testers ist die Anzahl der ausgeführten Testfälle mal die Komplexität der Testfälle. Sie möchten das maximieren, nicht gefundene Fehler.

17
Gort the Robot

Aufgrund meiner persönlichen Erfahrungen ist dies keine gute Sache. Es führt fast immer dazu, dass Entwickler Fehler einreichen, die doppelt, lächerlich oder völlig ungültig sind. In der Regel werden viele davon am Ende eines Monats/Quartals plötzlich angezeigt, wenn Tester sich beeilen, Quoten einzuhalten. Das Einzige, was schlimmer ist, ist, wenn Sie Entwickler auch anhand der Anzahl der in ihrem Code gefundenen Fehler bestrafen. Ihre Test- und Entwicklungsteams arbeiten zu diesem Zeitpunkt 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 während des Testens gemeldet wurden. Er sieht nur den Fehler, der durchgekommen ist. Den Benutzern ist es letztendlich egal, ob Sie 20 oder 20.000 Fehlerberichte einreichen, solange die Software funktioniert, wenn sie sie 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 abgefangen werden sollten.

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

16
bta

Es ist nichts Falsches daran, aus dem Auffinden von Fehlern ein Spiel zu machen. Sie haben einen Weg gefunden, Menschen zu motivieren. Das ist gut. Es hat sich auch herausgestellt, dass Prioritäten nicht kommuniziert wurden. Das Ende des Wettbewerbs 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 Fehler. Es wird eher wie ein Angelwettbewerb sein. Jeder wird nach dem großen Fehler suchen, der eine hohe Priorität erhält. 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 des Spielgleichgewichts ist keine einfache Aufgabe. Seien Sie also bereit, einige Zeit damit zu verbringen, dies richtig zu machen. Es sollte Ihre Ziele klar kommunizieren und Spaß machen. Dies können Sie auch anpassen, wenn sich die geschäftlichen Anforderungen ändern.

6
candied_orange

Fehler zu finden ist ihre Aufgabe. Solange sie die Dinge nicht weniger effizient machen (zum Beispiel indem sie einen Fehler für ech von 10 Tippfehlern anstelle von einem öffnen, um mehrere von ihnen abzudecken), ermutigt dies sie, genau das zu tun, was sie tun sollen Ich kann keinen großen Nachteil sehen.

5
mootinator

Dies ist eine Erweiterung von @ CandiedOranges Antwort .

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 an jedem Tag, an dem mindestens ein schwerwiegender Fehler gemeldet wurde, ein Token "Fehler des Tages" auf dem Schreibtisch des Testers. 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 liefern. Machen Sie die Trophäenlieferung "Bug of the Month" 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 Fehlern auf das Sammeln der meisten Trophäen und Token lenken. Ihre beste Strategie dafür wäre, die Zitate zu lesen und darüber nachzudenken, welche Testansätze wahrscheinlich Fehler hervorrufen, die die Entwickler für wichtig halten.

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

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 verschlimmern und sich bemühen, 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. Sie sollten solche Dinge als Teil ihrer Arbeit betrachten. Wenn Ihr PM nicht bereit oder nicht in der Lage ist, damit umzugehen), stecken Sie in der Entwicklung Ihrer eigenen Bewältigungsstrategien fest (was eine andere Frage wäre).

1
David