Est-il bon que les testeurs soient en compétition pour voir qui ouvre plus de bugs?

Je suis un développeur de logiciels. Une équipe de testeurs suit et exécute des scénarios de test écrits par l'analyste, mais effectue également des tests exploratoires. Il semble que les testeurs se disputent pour savoir qui ouvre le plus de bogues, et j'ai remarqué que la qualité des rapports de bogues avait diminué. Au lieu de tester les fonctionnalités et de signaler les bogues liés au fonctionnement du logiciel, les testeurs ont soumis des bogues liés aux améliorations de l'écran, à la facilité d'utilisation ou à des bugs stupides.

Est-ce bon pour le projet? Sinon, comment puis-je (en tant que développeur de logiciels) essayer de changer les mentalités et les attitudes de l'équipe de testeurs?

Un autre problème est que l'échéance est estimée et qu'elle ne peut pas changer. Ainsi, à l'approche de l'échéance, les testeurs vont se démener pour terminer leurs scénarios de test, ce qui entraînera une baisse de la qualité des tests. Cela entraînera des bogues légitimes dans le produit final reçu par le client.

OBS: Ce concours n'est pas une pratique de l'entreprise! Il s’agit d’un concours organisé uniquement entre les testeurs, et sans aucun prix.

Je ne pense pas que ce soit une bonne chose qu’ils fassent un concours pour trouver le plus de bugs. S'il est vrai que leur travail consiste à rechercher des bugs, leur travail n'est pas "trouver le plus de bugs". Leur objectif n'est pas d'en trouver le plus, mais leur objectif est d'améliorer la qualité du logiciel. Les récompenser pour avoir trouvé plus de bogues équivaut à récompenser un programmeur pour avoir écrit le plus de lignes de code, plutôt que le code de la plus haute qualité.

Le transformer en jeu les incite à se concentrer sur la recherche de nombreux bogues superficiels, plutôt que sur les bogues les plus critiques. Comme vous l'avez mentionné dans votre édition, c'est exactement ce qui se passe dans votre organisation.

On pourrait argumenter que tout bogue qu’ils trouvent est un jeu juste, et que tous les bogues doivent être découverts. Cependant, étant donné que votre équipe dispose probablement de ressources limitées, préféreriez-vous que le testeur se concentre plusieurs heures ou plusieurs jours sur votre système à la recherche de gros bogues, ou passe plusieurs heures ou plusieurs jours à parcourir l'application à la recherche d'erreurs typographiques et de petites erreurs? des erreurs dans l'alignement des objets sur une page?

Si l'entreprise souhaite vraiment en faire un jeu, donnez aux développeurs le pouvoir d'ajouter des points à un bogue. "bugs stupides" obtenir des points négatifs, difficile de trouver des bugs avec des rapports bien écrits obtenir plusieurs points. Cela déplace alors l'incitation de "trouver le plus" à "être le meilleur dans votre travail". Cependant , cela n'est pas recommandé non plus, car un programmeur et un analyste d'assurance qualité pourraient travailler ensemble pour compiler artificiellement leurs chiffres.

En bout de ligne: ne faites pas un jeu hors de la recherche de bugs. Trouvez des moyens dans votre organisation pour récompenser le bon travail et en rester là. La gamification récompense les personnes qui atteignent un objectif. Vous ne voulez pas qu'un analyste d'assurance qualité ait pour objectif de "trouver le plus de bogues", vous voulez que son objectif soit "d'améliorer la qualité du logiciel". Ces deux objectifs ne sont pas les mêmes.

Je vais un peu en désaccord avec les autres réponses. "Trouver des bugs" pour un testeur est un peu comme "écrire du code" pour un développeur. La quantité brute n'a pas de sens. Le testeur doit trouver le plus grand nombre possible de bogues existants, et non le plus grand nombre. Si le testeur A trouve 5 des 10 bogues dans un composant de haute qualité et que le testeur B trouve 58 des 263 bogues dans un composant de basse qualité, alors le testeur A est le meilleur.

Vous voulez que les développeurs écrivant le minimum de code pour résoudre un problème particulier et un testeur écrivant le nombre minimal de rapports décrivant correctement le comportement endommagé. Concourir pour trouver le plus de défauts revient à concurrencer pour écrire le plus de lignes de code. Il est beaucoup trop facile de se glisser dans le système de jeu pour être utile.

Si vous souhaitez que les testeurs soient compétitifs, vous devez vous baser davantage sur ce qu'ils sont censés faire, à savoir valider que le logiciel fonctionne comme décrit. Alors peut-être que des personnes se font concurrence pour savoir qui peut écrire les scénarios de test les plus acceptés ou, mieux encore, écrire l'ensemble des scénarios de test qui couvrent le plus de code.

La meilleure mesure de la productivité des développeurs est le nombre de tâches complétées par la complexité des tâches. La meilleure mesure de la productivité du testeur est le nombre de scénarios de test exécutés fois la complexité du scénario de test. Vous voulez maximiser cela, pas les bugs trouvés.

D'après mes expériences personnelles, ce n'est pas une bonne chose. Cela conduit presque toujours les développeurs à classer des bogues dupliqués, ridicules ou totalement invalides. Vous en verrez généralement apparaître beaucoup à la fin d'un mois ou d'un trimestre, alors que les testeurs s'empressent d'atteindre des quotas. La pire chose à ce sujet, c’est que vous pénalisez également les développeurs en fonction du nombre de bogues trouvés dans leur code. Vos équipes de test et de développement travaillent alors les unes contre les autres, et l’une ne peut réussir sans que l’autre soit mal vue.

Vous devez rester concentré sur l'utilisateur ici. Un utilisateur n'a aucune idée du nombre de bogues répertoriés lors des tests, il ne voit que celui qui est passé. En fin de compte, les utilisateurs ne se soucient pas de savoir si vous déposez 20 rapports de bogue ou 20 000, tant que le logiciel fonctionne au moment où ils le reçoivent. Un meilleur indicateur pour évaluer les testeurs serait le nombre de bogues signalés par les utilisateurs, mais qui auraient dû être raisonnablement détectés par les testeurs.

C'est beaucoup plus difficile à suivre, cependant. Il est assez facile de lancer une requête dans une base de données pour savoir combien de rapports de bogues ont été signalés par une personne en particulier, ce qui, je suppose, est la principale raison pour laquelle la mesure "bugs archivés" est utilisée par autant de personnes.

Il n'y a rien de mal à faire un jeu en trouvant des bugs. Vous avez trouvé un moyen de motiver les gens. C'est bon. Il a également révélé un échec dans la communication des priorités. Mettre fin au concours serait un gaspillage. Vous devez corriger les priorités.

Peu de vrais jeux ont un système de score simple. Pourquoi le bug devrait-il chasser?

Plutôt que de marquer le jeu simplement par le nombre de bogues, vous devez fournir une mesure de la qualité des rapports de bogues. Ensuite, le concours porte moins sur le nombre de bugs. Ce sera plus comme un concours de pêche. Tout le monde cherchera à trouver le gros bug qui obtiendra un score hautement prioritaire. Faites de la qualité du rapport de bogue une partie du score. Demandez aux développeurs de fournir aux testeurs des informations sur la qualité du rapport de bogue.

Il n’est pas une tâche facile d’améliorer l’équilibre du jeu. Soyez donc prêt à passer du temps à le faire. Il devrait communiquer clairement vos objectifs et ce devrait être amusant. Vous pourrez également vous adapter à l'évolution des besoins de votre entreprise.

Trouver des insectes est leur travail. Tant qu’ils ne rendent pas les choses moins efficaces (par exemple, en ouvrant un bogue pour 10 fautes de frappe au lieu d’une pour en couvrir plusieurs), cela les encourage à faire exactement ce qu’elles sont supposées faire, alors Je ne vois pas trop d'inconvénient.

Ceci est une extension de la réponse de @ CandiedOrange .

Pour commencer à attirer l'attention sur des objectifs plus utiles, considérons quelque chose de très informel et non officiel. Par exemple, les développeurs pourraient acheter des petits jetons et des trophées.

Chaque jour où au moins un bogue important a été signalé, laissez un jeton "Bogue du jour" sur le bureau du testeur. Une fois par semaine, organisez une cérémonie avec une procession de développeurs remettant un jeton ou un trophée "Bug of the Week" plus gros et meilleur. Rendez la distribution du trophée "Bug du mois" encore plus dramatique, peut-être avec un gâteau. Chaque jeton ou trophée doit être accompagné d'une citation expliquant pourquoi les développeurs ont pensé que c'était une bonne chose que ce bogue ait été détecté lors des tests. Des copies des citations doivent être placées quelque part où les testeurs peuvent toutes les lire.

L'espoir est que les testeurs détournent leur attention de la recherche du plus grand nombre d'insectes au profit de la collecte du plus grand nombre de trophées et de jetons. Pour ce faire, la meilleure stratégie consiste à lire les citations et à réfléchir aux approches de test susceptibles de générer des bogues importants pour les développeurs.

Ignorez simplement les rapports de bogues sans importance. Comme tout serait très officieux et informel, il pourrait être fermé ou modifié à tout moment.

Est-ce bon pour le projet?

Non . Vous avez vous-même fait remarquer que vous aviez constaté que les rapports de qualité médiocre ne ciblaient pas les fonctionnalités requises et que les testeurs finissaient par aggraver le problème, s'efforçant de terminer le travail qu'ils étaient en réalité "supposés". "faire.

Sinon, comment puis-je (en tant que développeur de logiciels) essayer de changer les mentalités et les attitudes de l'équipe de testeurs?

Relevez le problème avec votre gestionnaire de projet. Ils devraient considérer ce genre de choses comme faisant partie de leur travail. Si votre premier ministre ne veut pas ou ne peut pas en venir à bout, vous êtes en quelque sorte coincé dans l’élaboration de vos propres stratégies d’adaptation. (ce qui serait une question différente)

Je pense que ce sera (ou ce que c'est déjà) si cela continue, vous n'obtiendrez pas nécessairement une qualité inférieure. Bien que je pense que cela va diminuer le rapport quantité / qualité. Cela dépend si c'est une mauvaise chose ou non. Ça dépend si

signaler des bugs concernant les améliorations d'écran, la facilité d'utilisation ou des bugs stupides.

est quelque chose que vous ne voulez vraiment pas. Si cela est clair pour les testeurs, je leur dirais simplement de ne pas faire les choses que vous ne voulez pas signaler, mais de les clarifier. Faites-le quand un de ces rapports réapparaîtra.

La raison pour laquelle ils ont un concours est probablement de s'amuser tout en travaillant, ils n'ont donc probablement pas l'intention de faire un mauvais travail (si cela est considéré comme mauvais).