Est-il possible de suivre ou de mesurer la cause des bugs ou est-ce juste demander des conséquences inattendues?

Question

existe-t-il une méthode de suivi ou de mesure de la cause des bugs qui n'entraîneront pas de conséquences inattendues des membres de l'équipe de développement? Nous avons récemment ajouté la possibilité d'attribuer la cause d'un bogue dans notre système de suivi. Des exemples de causes comprennent: le code incorrect, le code manqué, les exigences incomplètes, les exigences manquantes, les tests incomplets, etc. Je n'étais pas un partisan de cela, car je pouvais le voir conduire à des comportements invraisemblés de l'équipe de Dev. À ce jour, ce champ a été masqué parmi les membres de l'équipe et non activement utilisé.

Nous sommes maintenant au milieu d'un projet où nous avons un nombre plus grand que normal de bugs et ce type d'informations serait bon d'avoir pour mieux comprendre où nous nous sommes mal tournés et où nous pouvons apporter des améliorations à l'avenir. (ou ajustements maintenant). Afin d'obtenir de bonnes données sur la cause des bugs, nous aurions besoin d'ouvrir ce champ pour la saisie par des membres de l'équipe DEV et QA et je suis inquiet que cela conduirait de mauvais comportements. Par exemple, les gens peuvent ne pas vouloir corriger un défaut qu'ils ne créaient pas parce qu'ils le penseront que cela reflète mal sur leur performance, ou que les personnes risquent de perdre du temps à se disputer sur la classification d'un défaut pour des raisons similaires.

Quelqu'un a-t-il trouvé un mécanisme pour faire ce type de suivi sans conduire de mauvais comportements? Est-il possible de s'attendre à des données utiles des membres de l'équipe si nous expliquons à l'équipe le raisonnement derrière les données (ne pas conduire des indicateurs de performance individuels, mais des mesures de réussite du projet)? Y a-t-il un autre moyen de faire un meilleur moyen de faire ce type de chose (un post mortem plus ad-hoc ou une discussion ouverte sur les problèmes peut-être)?

Answer 1

Beaucoup de packages de contrôle de version ont des choses comme svn blame. Ce n'est pas une métrique directe pour suivre un bogue, mais cela peut vous dire qui a vérifié les modifications à une version qui a un bogue majeur dedans.

Il y a aussi des programmes tels que http://www.bugzilla.org/ qui aident à suivre les choses au fil du temps .

Mais aussi loin que de creuser vraiment pourquoi les insectes existent, oui, cela vaut vraiment la peine d'être examinée, bien que je ne puisse pas donner une métrique standard pour collecter ces informations. Il existe un certain nombre de raisons pour lesquelles un système pourrait être très buggy:

• spécifications mal écrites
• Timelines précipitées
• Programmation à faible compétence
• Mauvais moral
• manque de test bêta ou qa
• manque de préparation de logiciels de manière à ce qu'il soit même réalisable pour le test bêta ou qa
• Ratio de temps médiocre consacré à nettoyer les bugs vs obtenir une nouvelle fonctionnalité sur
• Rapport sur le temps passé à faire des améliorations sans bugs vs OBTENIR LA FONCTIONNALITÉ OUT
• Un système complexe dépassant facile à casser
• Un environnement changeant en dehors de la base de code, telle que l'administration de la machine
• blâme pour les erreurs affectant la compensation de programmateur ou la promotion

C'est juste pour nommer quelques-uns ... Si trop de bugs sont un gros problème, alors la direction et les programmeurs de direction et de tout autre titulaire de titres dans l'ensemble du processus doivent s'asseoir et discuter de la question.

Answer 2

Les taux de bogue élevés peuvent être un symptôme d'un calendrier trop précipité ou inflexible.La commutation d'une approche de défaut zéro peut aider.Fixez tous les bugs avant de travailler sur le nouveau code.

L'attribution de raisons est une bonne technique pour voir si vous avez une zone de problèmes.Les métriques typiques que j'ai vues et rencontrées sont une scission même entre:

• Erreurs de spécification (manquantes, incorrectes, etc.)
• Bugs d'application (code incCorrect, code manquant, données incorrectes, etc.)
• Tests incorrects / aucune erreur de non-erreur (généralement des attentes incorrectes ou des spécifications non encore implémentées)

ReveIwing et vérifier que les causes de défaut peuvent être utiles.