Comment appliquez-vous ou maintenez-vous la qualité des rapports de bogues dans votre outil de suivi de bogues ?

Question

Des rapports de bogues de haute qualité sont essentiels pour un suivi efficace des bogues. Dans un monde idéal, tous les rapports de bogues contiendraient des informations essentielles telles que la version du logiciel affectée et une description étape par étape sur la manière de reproduire le bogue.

En réalité, cependant, la qualité des bugs signalés peut varier considérablement.Il peut s'agir de mises en ligne (« la fonctionnalité X ne fonctionne pas, corrigez-la ! »), de demandes de fonctionnalités, de PEBKAC ou d'inintelligibles.

Comment appliquez-vous ou maintenez-vous la qualité des rapports de bogues dans votre outil de suivi des bogues pour rester efficace ?

Answer 1

Je suis d'accord avec Jon Limjap : votre personnel d'assurance qualité doit être suffisamment compétent pour publier des rapports de bogues appropriés, à condition de recevoir une formation de base et des directives appropriées.Néanmoins, il existe des moyens d'appliquer et d'encourager de meilleurs rapports de bogues :

• La plupart des logiciels de suivi de bogues ont un moyen de marquer certains champs du rapport de bogue comme obligatoires, de sorte que le rapporteur doive réellement choisir la valeur appropriée afin de réussir à créer le bogue.
• Il est généralement possible d'inclure un modèle de base pour le rapport de bogue, quelque chose du genre

Scénario:

Résultats attendus:

Résultats actuels:

Remarques:

• Vous pouvez (et devez) fournir un outil de rapport de bogues qui sera exécuté sur la machine problématique, rassembler les informations pertinentes et les regrouper dans un fichier d'archive (et peut-être le placer sur le bureau).Vous demandez ensuite à votre personnel de l'exécuter chaque fois qu'il rencontre un bug qu'il souhaite signaler et de joindre l'archive au bug.Cet outil doit être facile à utiliser (il suffit d'exécuter un exécutable) afin qu'ils puissent joindre les informations de diagnostic à n'importe quel bogue sans avoir à se demander s'il est pertinent ou non.Cet outil est généralement également très utile auprès des clients.
• Enfin et surtout : « l’éducation, l’éducation, l’éducation ».Les gens apprennent le meilleur de l'expérience - assurez-vous simplement que chaque fois que quelqu'un ouvre un bug sans les informations appropriées incluses, la personne qui gère le bug ira parler à celui qui a ouvert le bug, et lui expliquera ce qui manque et pourquoi c'est important.

Ce sont des pratiques que nous utilisons avec beaucoup de succès sur mon lieu de travail actuel et je pense qu'elles sont assez universelles pour s'adapter à la plupart des environnements de travail.

Answer 2

Avant, je pensais que la qualité du rapport de bug était importante.Je le pense toujours...les bugs que je signale contiennent des informations beaucoup plus utiles que celles saisies par QA ou par Operations.Cependant, j'en suis venu à admirer le modèle de FogBugz.C'est extrêmement simple de saisir un bug.Le simple fait de savoir qu'il existe une condition d'erreur est utile, même s'il n'y a pas beaucoup d'informations à l'appui.De plus, les utilisateurs ont l’impression que quelque chose est en train de se faire.

Answer 3

Écrivez un bon tutoriel, mais pas trop long, sur l'utilisation du tracker et sur ce qui est requis pour chaque champ.Créez un exemple de référence à usage général que d’autres peuvent utiliser s’ils sont bloqués.

J'ai une copie de référence pour éditer les pages de manuel de Docbook et en l'utilisant à plusieurs reprises, je connais déjà la plupart de la syntaxe par cœur.

Answer 4

Cela dépend si vous parlez d'un examen d'assurance qualité fermé et d'une version bêta publique.

S'il s'agit d'une version bêta publique, il n'est pas conseillé de laisser les utilisateurs modifier directement votre liste de bogues.Quelqu'un devrait être chargé de regrouper les commentaires et les rapports des utilisateurs et de discerner quels sont les bogues réels et lesquels sont des doublons et lesquels donnent une sorte d'indice sur la façon de les reproduire.

Toutefois, s'il s'agit d'un bug publié par votre personnel légitime d'assurance qualité, vous avez un problème de compétence vis-à-vis de vos employés.Des directives appropriées doivent être définies sur la manière de signaler les bogues, en particulier pour clarifier les étapes de réplication.

Answer 5

Question difficile.J'essaierais de voir si le système a un moyen de faire en sorte que certains champs dont vous avez besoin soient saisis, j'essaierais d'avoir tous les bugs critiques qui vous apparaissent d'une manière ou d'une autre (e-mail, rss) afin que vous puissiez bondir rapidement, mais surtout ça votre équipe est consciente de la norme de qualité et s'y tient, les directives sont publiées et publiques, ce genre de choses.

En supposant qu'il s'agisse de votre équipe :Si vous pouvez avoir une certaine structure qui est utilisée à chaque fois dans un champ de commentaires, par rapport à ce qui est attendu lors de sa saisie, alors ce serait bien aussi - encore mieux si votre logiciel a un plan de notes par défaut dans lequel vous pouvez définir cette structure sur un formulaire vierge.

Dans une certaine mesure cependant, cela dépend de l'individu, il doit être conscient que cela fait partie des normes de communication, que cela est attendu comme une exigence du poste et qu'il est responsable envers tous les autres membres de l'équipe - parce que d'autres personnes devraient le faire. Je ne serai pas en mesure de les traquer pour obtenir plus de détails si cela pouvait être évité.

D'autant plus que le délai d'exécution pour corriger les bugs sur les éléments de moindre priorité peut être long et que les gens risquent d'oublier les détails.

En supposant qu'il s'agisse d'utilisateurs :Ce n'est pas possible dans une large mesure, mais j'essaierais, si possible, de poser des questions sous quelque forme que ce soit, d'une manière que les gens puissent comprendre.

Pas entièrement sur ce sujet, mais dans le sens de « comment poser les questions », cet article sur le blog 37 Signals est-il : texte du lien

Même si vous devez avoir un autre formulaire posant les questions visibles à vos utilisateurs, qui alimente uniquement les données du programme de bug, je le ferais juste pour poser les bonnes questions.

Quel produit?Quelle version (photos montrant comment la trouver) ?Il serait utile d'inclure une copie d'écran, s'ils pouvaient ouvrir le programme et appuyer sur un bouton pour envoyer automatiquement un fichier journal, si cela les empêchait de poursuivre leur travail, s'il perdait leurs modifications, etc.

Pour les utilisateurs, il s'agit probablement davantage de la façon dont vous posez les questions et de leur faire savoir que vous avez besoin de répondre à certaines questions, ou à celles que vous trouveriez les plus utiles, vous obtiendrez alors probablement de meilleures réponses.

Answer 6

Utilisez quelque chose comme Voix de l'utilisateur pour que les utilisateurs finaux signalent les bogues et les demandes de fonctionnalités.Les entrées du suivi des bogues devraient vraiment être internes - elles sont trop techniques pour les utilisateurs finaux et aussi, à mon humble avis, exposent un peu trop de fonctionnement interne.