Est-il bon que les testeurs rivalisent pour voir qui ouvre le plus de bogues?
Je suis développeur de logiciels. Il existe une équipe de testeurs qui suivent et exécutent des cas de test écrits par l'analyste, mais effectuent également des tests exploratoires. Il semble que les testeurs se soient battus pour voir qui ouvre le plus de bogues, et j'ai remarqué que la qualité des rapports de bogues a 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 concernant les améliorations d'écran, la convivialité ou des bogues stupides.
Est-ce bon pour le projet? Sinon, comment puis-je (en tant que développeur de logiciels), essayer de changer la pensée et les attitudes de l'équipe de testeurs?
Un autre problème est dû au fait que le délai est estimé et ne peut pas changer, de sorte que le délai approche, les testeurs se bousculent pour terminer leurs cas de test, ce qui entraînera une baisse de la qualité des tests. Cela entraînera la présence de bogues légitimes dans le produit final reçu par le client.
OBS: Ce concours n'est pas une pratique de l'entreprise! C'est une compétition entre les testeurs uniquement organisée par eux, et sans aucun prix.
Je ne pense pas que ce soit bien qu'ils fassent un concours pour trouver le plus de bugs. S'il est vrai que leur travail consiste à trouver des bogues, leur travail n'est pas de "trouver les plus bogues". Leur objectif n'est pas d'en trouver le plus, leur objectif est d'aider à améliorer la qualité du logiciel. Les récompenser pour avoir trouvé plus de bogues revient à 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 leur donne une incitation à se concentrer sur la recherche de nombreux bugs peu profonds, plutôt que de trouver les bugs les plus critiques. Comme vous le mentionnez dans votre édition, c'est exactement ce qui se passe dans votre organisation.
On pourrait faire valoir que tout bogue qu'ils trouvent est un jeu équitable et que tous les bogues doivent être découverts. Cependant, étant donné que votre équipe a probablement des ressources limitées, préférez-vous qu'un testeur se concentre plusieurs heures ou jours pour sonder profondément votre système en essayant de trouver de très gros bugs, ou passer plusieurs heures ou jours à parcourir l'application à la recherche d'erreurs typographiques et de petites des erreurs dans l'alignement des objets sur une page?
Si l'entreprise veut vraiment en faire un jeu, donnez aux développeurs le pouvoir d'ajouter des points à un bug. les "bogues stupides" obtiennent des points négatifs, les bogues difficiles à trouver avec des rapports bien écrits obtiennent plusieurs points. Cela déplace alors l'incitation de "trouver le plus" à "être le meilleur pour faire votre travail". Cependant, ce n'est pas recommandé non plus, car un programmeur et un analyste QA pourraient travailler ensemble pour compléter artificiellement leurs nombres.
Conclusion: ne faites pas un jeu pour trouver des bugs. Trouvez des moyens dans votre organisation de récompenser le bon travail et n'en restez pas là. La gamification récompense les gens qui atteignent un objectif. Vous ne voulez pas qu'un analyste QA ait pour objectif de "trouver le plus de bugs", vous voulez que leur objectif soit "d'améliorer la qualité du logiciel". Ces deux objectifs ne sont pas les mêmes.
Je vais être un peu en désaccord avec les autres réponses. "Trouver des bogues" pour un testeur est un peu comme "écrire du code" pour un développeur. Le montant brut n'a pas de sens. Le travail du testeur est de trouver autant de bugs qui existent qu'ils le peuvent, pas de trouver le plus de bugs. Si le testeur A trouve 5 des 10 bogues dans un composant de haute qualité et le testeur B trouve 58 des 263 bogues dans un composant de faible qualité, alors le testeur A est le meilleur testeur.
Vous voulez que les développeurs écrivent la quantité minimale de code pour résoudre un problème particulier, et vous voulez qu'un testeur rédige le nombre minimum de rapports qui décrivent correctement le comportement rompu. La compétition pour trouver le plus de défauts est comme la compétition pour écrire le plus de lignes de code. Il est beaucoup trop facile de se glisser dans le jeu pour être utile.
Si vous voulez avoir des testeurs en compétition, cela devrait être plus directement basé sur ce qu'ils sont là pour faire, c'est-à-dire valider que le logiciel fonctionne comme décrit. Alors peut-être que les gens se disputent pour voir qui peut écrire les cas de test les plus acceptés, ou mieux encore, écrire l'ensemble des cas de test qui couvrent le plus de code.
La meilleure mesure de la productivité des développeurs est le nombre de tâches terminées multiplié par la complexité des tâches. La meilleure mesure de la productivité du testeur est le nombre de cas de test exécutés multiplié par la complexité du cas de test. Vous voulez maximiser cela, pas de bugs trouvés.
D'après mes expériences personnelles, ce n'est pas une bonne chose. Cela conduit presque toujours les développeurs à déposer des bogues en double, ridicules ou complètement invalides. Vous en verrez généralement beaucoup apparaître soudainement à la fin d'un mois/trimestre alors que les testeurs se précipitent pour atteindre les quotas. La seule chose pire que cela, c'est quand 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 les unes contre les autres à ce stade, et l'une ne peut réussir sans donner à l'autre une mauvaise apparence.
Vous devez rester concentré sur l'utilisateur ici. Un utilisateur n'a aucune idée du nombre de bogues déposés lors des tests, il ne voit que celui qui a réussi. En fin de compte, les utilisateurs ne se soucient pas si vous déposez 20 rapports de bogues ou 20 000, tant que le logiciel fonctionne quand ils l'obtiennent. Une meilleure mesure 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.
Cependant, c'est beaucoup plus difficile à suivre. Il est assez facile d'exécuter une requête de base de données pour voir combien de rapports de bogues ont été déposés par une personne spécifique, ce qui, je pense, est la principale raison pour laquelle la métrique "bogues déposés" est utilisée par tant de personnes.
Il n'y a rien de mal à créer un jeu à partir de la recherche de bugs. Vous avez trouvé un moyen de motiver les gens. C'est bon. Cela a également révélé une incapacité à communiquer les priorités. Mettre fin au concours serait un gaspillage. Vous devez corriger les priorités.
Peu de vrais jeux ont un système de notation simple. Pourquoi la chasse aux bogues?
Plutôt que de marquer le jeu simplement en fonction du 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 de priorité élevé. Intégrez la qualité du rapport de bogue au score. Demandez aux développeurs de fournir aux testeurs des commentaires sur la qualité du rapport de bogue.
Le réglage fin de l'équilibre du jeu n'est pas une tâche simple, alors soyez prêt à passer du temps à bien faire les choses. Il doit communiquer clairement vos objectifs et être amusant. Ce sera également quelque chose que vous pourrez ajuster en fonction des besoins de l'entreprise.
Trouver des bogues est leur travail. Tant qu'ils ne rendent pas les choses moins efficaces (par exemple, en ouvrant un bogue pour ech de 10 fautes de frappe au lieu d'un pour en couvrir plusieurs), cela les encourage à faire exactement ce qu'ils sont censés faire, donc Je ne vois pas beaucoup d'inconvénients.
Ceci est une extension de @ CandiedOrange's réponse .
Pour commencer à déplacer l'attention sur des objectifs plus utiles, considérez quelque chose de très informel et non officiel. Par exemple, les développeurs pourraient acheter de petits jetons et trophées.
Chaque jour où au moins un bug significatif a été signalé, laissez un jeton "Bug du jour" sur le bureau du testeur. Une fois par semaine, organisez une cérémonie avec une procession de développeurs offrant un jeton ou un trophée "Bug de la semaine" plus grand et meilleur. Rendez la remise du trophée "Insecte du mois" encore plus spectaculaire, 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 qu'un bogue ait été trouvé lors des tests. Des copies des citations doivent être placées dans un endroit où les testeurs peuvent tous les lire.
L'espoir est que les testeurs détourneraient leur attention de la recherche du plus grand nombre de bugs pour collecter le plus de trophées et de jetons. Leur meilleure stratégie pour ce faire serait de lire les citations et de réfléchir aux approches de test susceptibles de faire ressortir des bogues que les développeurs jugeront importants.
Ignorez simplement les rapports de bogues sans importance. Étant donné que tout cela 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 avez observé que cela aboutit à des rapports de faible qualité qui ne sont pas ciblés sur les fonctionnalités requises et que les testeurs finissent par aggraver le problème et se démènent pour achever le travail qu'ils sont réellement "supposés". "à faire.
Sinon, comment puis-je (en tant que développeur de logiciels), essayer de changer la pensée et les attitudes de l'équipe de testeurs?
Soulevez le problème avec votre chef de projet. Ils devraient considérer ce genre de chose comme faisant partie de leur travail. Si votre PM ne veut pas ou est incapable de s'en occuper, vous êtes en quelque sorte coincé à développer vos propres stratégies d'adaptation. (Ce qui serait une question différente)