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:
Création d'un enregistrement indiquant qu'un bogue peut exister, avec des informations sur la façon de le reproduire,
Confirmant qu'en effet, le bogue existe et est un bogue, pas quelque chose de par sa conception,
En affirmant que le bug est maintenant résolu,
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.