Pourquoi il n'est pas recommandé de poster plusieurs défauts dans le même numéro / ticket?

Je ne sais pas si c'est le lieu de poser la question conceptuelle suivante (Stackoverflow ne l'est certainement pas).

J'ai vu cette question dans un examen à choix multiples (réponse unique), similaire aux examens ISTQB :

Pourquoi il n'est pas recommandé de signaler plusieurs défauts dans le même problème / ticket?

une. Afin de garder le rapport concis et clair.

b. Parce que les développeurs peuvent corriger un seul bogue.

c. Parce que les testeurs du groupe de test sont évalués en fonction de la quantité de bogues qu'ils trouvent.

ré. Les systèmes de gestion des bogues ne prennent pas en charge cette fonctionnalité de plusieurs bogues.

Ma seule opinion est que ac'est la bonne réponse.

b- ne peut pas l'être car le correctif-rétroaction-résolu-fermé devrait éviter ce cas. c- Evidemment faux.

d - Les plugins Redmine / Trac prennent en charge plusieurs champs.

La réponse selon la feuille de réponses est b.

Quelqu'un peut-il expliquer pourquoi? Les commentaires avec opinion sur les réponses sont les bienvenus.

Imaginez si Stack Overflow avait une ligne directrice: au lieu de poser une question, vous venez poser, dans la même question, tout ce qui vous vient à l'esprit, tous vos problèmes que vous avez eus au cours des deux dernières semaines. Que signifieraient les votes positifs et négatifs? Quels seraient les titres des questions? Comment accepter la meilleure réponse? Comment baliser la question?

Le système de suivi des bogues est fait pour ... suivre les bogues. Le suivi d'un bug signifie:

1. Création d'un enregistrement indiquant qu'un bogue peut exister, avec des informations sur la façon de le reproduire,

2. Confirmant qu'en effet, le bogue existe et est un bogue, pas quelque chose de par sa conception,

3. En affirmant que le bug est maintenant résolu,

4. Confirmer que le bogue a été résolu.

Dans un modèle très simpliste, 1 et 4 seront effectués par le client, et 2 et 3 - par le développeur.

Imaginez le journal suivant:

• Jour 1 [Client] Lorsque vous appuyez sur le bouton «Supprimer» dans la fenêtre «Détails du produit», l'application se bloque. Le redémarrage de l'application montre que le produit n'a pas été supprimé. Le comportement attendu est de supprimer le produit.

• Jour 4 [Développeur] <Problème reproduit>

• Jour 5 [Développeur] <Problème résolu dans la révision 5031>

• Jour 12 [Client] <Ticket fermé: problème résolu>

Le journal est simple et clair . Vous pouvez facilement suivre ce qui a été fait et quand , quelle révision a résolu quel bogue, etc. Par exemple, si le système de suivi des bogues est intégré au contrôle de version, lorsque vous affichez une révision spécifique, vous pouvez vérifier quels bogues ont été résolus.

Il est facile de trouver des informations . Il est facile de voir son état (est-il reproduit? Si le ticket a été fermé, pourquoi?). Il est facile de filtrer les tickets (je veux afficher les tickets qui ne concernent que l'interface utilisateur des plugins, étant donné que je ne veux que les tickets ouverts, plus d'une semaine et qui m'ont été attribués par notre concepteur d'interaction et qui sont de priorité moyenne ou élevée).

Il est facile de réaffecter un ticket ou de déterminer à l'origine quelle est la personne qui devrait être responsable du bug.

Imaginez maintenant le journal suivant:

• Jour 1 [Client] L'application se bloque lorsque j'appuie sur le bouton «Supprimer» dans la fenêtre «Détails du produit». De plus, la couleur d'arrière-plan du panneau de gauche est bleu foncé, alors qu'elle devrait être violette. J'ai également noté que le texte de la fenêtre «Détails du produit» n'est pas bien traduit en allemand; est-ce attendu? Quand la traduction finale sera-t-elle disponible? BTW, avez-vous reçu la nouvelle icône que j'ai envoyée pour l'action "Publier le produit"? Je ne le vois pas dans la fenêtre "Synchroniser les données".

• Jour 6 [Développeur] J'ai changé la couleur en violet.

• Jour 7 [Développeur] Oui, il est normal que la traduction en allemand soit incomplète.

• Jour 8 [Client] Ok pour l'allemand. Et l'italien? Lucia vous a envoyé le fichier XML il y a deux jours.

• Jour 9 [Développeur] C'est ok maintenant.

• Jour 10 [Client] Ok pour le bouton "Supprimer"? Étrange, à mon ordinateur, il se bloque toujours.

• Jour 11 [Développeur] Non, je voulais dire que ça va pour la traduction italienne.

• Jour 12 [Client] Je vois. Merci. Mais il y a un problème avec la couleur. Vous l'avez changé en violet foncé, mais il devrait être violet clair, comme le panneau supérieur de la fenêtre principale.

• Jour 13 [Développeur] J'ai mis à jour l'icône.

• Jour 14 [Client] L'icône? Quelle icône?

• Jour 15 [Développeur] L'icône que vous m'avez demandé de mettre à jour.

• Jour 16 [Client] Je ne vous ai jamais demandé de mettre à jour une icône.

• Jour 17 [Développeur] Bien sûr, vous avez demandé. Voir ce ticket. Vous avez écrit que l'icône de publication du produit doit être mise à jour. Je l'ai fait.

  ⁞

• Jour 100 [Client] Alors, qu'en est-il des entrées dans le journal?

• Jour 101 [Développeur] Je ne sais pas de quoi vous parlez. Ce n'est même pas dans ce ticket, mais en 6199. Je ferme celui-ci comme résolu. <Ticket fermé: problème résolu>

• Jour 102 [Client] Désolé de le rouvrir, mais le problème n'est pas résolu. Je parle des entrées dans le journal: je vous ai dit la semaine dernière que le texte est parfois invalide lorsqu'il contient des caractères unicode. Te souviens tu? <Billet rouvert>

• Jour 103 [Développeur] Je me souviens vaguement de quelque chose comme ça, mais après avoir fouillé les trois dernières pages de ce ticket, je ne trouve aucune trace. Pouvez-vous réécrire quel était le problème?

  ⁞

• Jour 460 [Développeur] J'ai passé deux heures à chercher une trace de ce que vous avez dit sur les fichiers envoyés cryptés via le réseau. Je ne suis pas sûr de pouvoir trouver la demande précise.

• Jour 460 [Client] Vous devriez vraiment être plus organisés. Je vous ai informé à quatre reprises de ce problème au cours des deux dernières semaines. Pourquoi oubliez-vous tout?

  ⁞

De quoi parle ce journal? Il a été résolu 43 fois et rouvert 43 fois. Cela signifie-t-il que le développeur est tellement stupide qu'il ne peut pas résoudre le même problème pendant 460 jours? Ah, non, attendez, ce ticket a été attribué à 11 développeurs pendant ce temps. Quel est le problème? Comment rechercher un problème spécifique? Il est en fait attribué à Vanessa, mais ses cinq collègues sont également concernés par sept des onze problèmes de ce billet. Quand le ticket doit-il être fermé? Est-ce lorsque la moitié des problèmes sont résolus? Ou peut-être dix sur onze?

Remarque: vous pouvez penser que ces journaux n'existent pas. Croyez-moi, j'en ai vu plus d'une fois.

Juste pour commenter votre déclaration:

ne peut pas être comme le correctif-rétroaction-résolu-fermé devrait éviter ce cas

Cela suppose que tous les bugs soulevés seront corrigés en même temps. Imaginez un scénario dans lequel un ticket est généré contre la version 1 du produit avec deux problèmes:

1. Un bouton de réinitialisation de formulaire soumet en fait le formulaire, plutôt que d'effacer les valeurs
2. La taille de police du bouton est de 110% alors qu'elle devrait être de 115%.

Les deux sont corrects pour un testeur à soulever, car ce sont tous les deux des défauts de mise en œuvre. Mais disons que le propriétaire du produit décide que la première sous-tâche est un bloqueur à libérer (c'est-à-dire qu'il doit être corrigé avant que le produit puisse être mis en ligne), mais la deuxième tâche est un problème mineur (c'est-à-dire qu'elle peut être corrigée dans une v1. 1 version).

Dans ce cas, nous n'avons pas d'autre choix que de diviser # 2 en son propre ticket (ou risquer de l'oublier). Si nous pouvons le faire, cela signifie qu'ils peuvent être mis en œuvre, testés et déployés indépendamment les uns des autres, auquel cas il est logique d'avoir des problèmes individuels dès le départ.

Portée:

Cette réponse (et la question) semble uniquement applicable au suivi des défauts de code, où le code source ne fonctionne pas conformément aux spécifications ou aux intentions des programmeurs.

Au contraire, il est courant que les tickets de défauts GUI contiennent plusieurs spécifications, car chaque ticket GUI est en fait une "refonte" (défaut de conception), une "spécification révisée" ou une "demande de fonctionnalité" (fonctionnalité manquante).

Un objectif important du suivi des défauts est de communiquer et de coordonner entre plusieurs rôles (programmeurs, testeurs, clients et gestionnaires).

Dans les projets où la qualité du code a une grande importance (par rapport à la convivialité par exemple), le suivi des défauts peut se composer de plusieurs facettes, dont l'une se concentrerait sur le suivi des défauts du code , séparément du suivi des améliorations et des demandes d'assistance client.

Le but du système de suivi des défauts de code est:

• Pour permettre le suivi indépendant et sans ambiguïté des défauts reproductibles indépendamment , et
• Fournir la meilleure approximation (correspondance biunivoque) de la cause première de chaque défaut.

Ce faisant, il devrait maximiser les qualités souhaitables suivantes:

• Échelle efficace à mesure que le nombre de défauts augmente avec le temps.
• Prévenir le syndrome de la cible mobile.

Avertissement: cette reformulation est issue de mon expérience personnelle. Il peut être insuffisant ou incorrect aux fins de l'examen de certification.

Un suivi indépendant et sans ambiguïté signifie que:

1. Chaque défaut valide peut être résolu ou non résolu , sans ambiguïté.

   • Raison 1: simplifier la gestion,
     • Exemple: il permet d'utiliser le "nombre de tickets non résolus" comme métrique.
   • Raison 2: se traduire en élément exploitable
     • Exemple: s'il n'est pas résolu, la responsabilité incombe au programmeur affecté. S'il est résolu mais pas fermé, la responsabilité incombe au testeur (vérificateur) affecté.
   • Conséquence: dans cette méthodologie, un défaut partiellement résolu mérite d'être décomposé en plusieurs défauts dépendants.

2. Les défauts reproductibles indépendamment doivent être suivis indépendamment.

   • «Reproductibles indépendamment» signifie qu'ils peuvent avoir différents états. L'un peut sembler fixe tandis que l'autre reste cassé.
   • Raison: minimiser l'inadéquation entre le suivi des défauts et l'analyse des causes profondes.
     • On pense que chaque cause première qui peut être attribuée à un défaut de code nécessite au moins un changement de code.
     • Si deux défauts sont reproductibles indépendamment, plusieurs modifications de code seront nécessaires.
     • Si deux défauts sont reproductibles indépendamment, ils doivent tous deux être testés (vérifiés), car la réussite d'un test n'implique pas que l'autre test passera.
   • Exemple 2: si l'on croyait initialement que deux symptômes avaient la même cause fondamentale et étaient donc classés dans le même ticket, et qu'ils se sont ensuite révélés être reproductibles indépendamment, alors ils devraient être divisés en deux tickets.

Regardez-le du point de vue d'une autre personne utilisant le système, qui apparaît quelques mois plus tard. Ils trouvent un bug dans le programme. Ils parcourent Google et voient qu'il existe un ticket d'assistance correspondant au problème qu'ils rencontrent. Et bon, c'est fermé! Impressionnant! Il a été corrigé dans la dernière version! Alors, ils se mettent à jour ... et le bug est toujours là? Quel est le problème avec ces développeurs stupides?!?

Rien, en fait. Il s'avère qu'il y a un problème avec la personne qui soumet le rapport de bogue. Ils ont soumis deux bogues dans le même ticket. L'un était facile à réparer et s'est réparé rapidement, et l'autre pas. Même si vous utilisez quelque chose comme Fix-Feedback-Resolved-Closed, il peut toujours être moins clair que ce qui se passe, en particulier pour un observateur extérieur.

Il est préférable de donner à chaque bogue son propre ticket, et si vous avez plusieurs bogues liés mais apparemment distincts, la plupart des systèmes de suivi des bogues ont une fonctionnalité qui vous permet de lier un bogue à un autre. (Et sinon, vous pouvez simplement le mettre dans le rapport. "Voir aussi le bug # 12345.")