Comment fermer un bug qui n'est plus pertinent

Je fais actuellement partie d'une équipe de développeurs Web de taille moyenne. Nous utilisons jira pour le suivi des bogues.

Nous travaillons sur un produit avec des changements de présentation fréquents. Souvent, des bogues sont déposés à propos d'un bogue dans la mise en page dans certains navigateurs. Parfois, au moment où nous nous attaquons à un bug de faible priorité, la disposition a déjà changé et elle n'est plus pertinente.

• Comment devrions-nous le fermer?
  Ce que je veux dire, c'est comment traiter ces problèmes? Bien que Jira soit le logiciel de suivi des bogues que nous utilisons, je suis plus intéressé par la façon de gérer ce type de problèmes en général.
• Est-ce même important? (Nous pourrions revenir à la mise en page plus tard, mais c'est très peu probable)

Des nuances comme celle-ci sont importantes si vous considérez le suivi des problèmes comme un moyen de communiquer l'état des problèmes signalés dans le projet. À cette fin, il est logique d'investir des efforts pour s'assurer que le rapport de bogue est facile à lire et à comprendre.

Cette situation devient beaucoup moins déroutante si vous la regardez du point de vue d'un testeur. Si votre équipe n'a pas de testeur, imaginez-en un (ou mieux encore, embauchez-en un ^{1 , 2 , 3} ).

D' accord, donc il y avait un bug une fois, testeur peut le reproduire en utilisant les anciennes versions de votre application (note de côté dans le cas peu probable que vous ne conservez pas de copies des anciennes versions, vous avez beaucoup beaucoup de problèmes plus difficiles dans votre équipe que des bogues obsolètes). Le testeur peut le voir et peut dire ce qui ne va pas, qu'est-ce qui en fait un bug.

Maintenant, vous dites que "la disposition a déjà changé et qu'elle n'est plus pertinente" - le front haut n'est plus pertinent transforme l'esprit du testeur en une déclaration beaucoup plus simple: le problème a disparu .

• Il est important de noter ici que le testeur professionnel doit être à l'aise de considérer le système comme une boîte noire . De ce point de vue, peu importe exactement comment le problème est survenu, ce pourrait être un changement de disposition ou de la magie noire ou une refonte totale, ou un changement de code concret, peu importe.

Du point de vue de la boîte noire, votre situation est assez simple. Il y avait un problème, il est toujours reproductible dans les anciennes versions, maintenant vous prétendez que la nouvelle version n'a plus ce problème. Pour un testeur, cela revient à affirmer que le bogue est corrigé et, respectivement, à la nécessité de vérifier si la réclamation est vraie.

Un testeur professionnel prendrait votre ancienne version, regarderait comment le problème est présent là-bas, puis prendrait une version plus récente et vérifierait si elle a disparu ou est toujours là.

Par le haut, la façon la plus précise de gérer les bogues comme vous le décrivez serait de les fermer comme résolus et corrigés . Bien sûr, cela ne ferait pas de mal si vous clarifiez dans les commentaires que le correctif s'est produit comme un effet secondaire involontaire du changement de mise en page.

L'un des JIRA personnalisés avec lesquels je travaillais dans un projet précédent avait la résolution "Fixed By Design" pour communiquer des changements assez profonds ayant de nombreuses conséquences, certaines intentionnelles, d'autres non. Pour les cas comme vous le décrivez, cela pourrait également être envisagé au lieu de "Fixe", car il indique au lecteur de ticket qu'il s'agit plus d'un effet secondaire que d'un changement de code intentionnel.

Nous résolvons des problèmes tels que «Obsolète». Ce n'est pas une option de résolution par défaut dans JIRA mais c'est assez facile à ajouter.

JIRA (et je suis sûr que d'autres suiveurs de bogues) vous permettent de spécifier des résolutions personnalisées afin que vous puissiez configurer une résolution "Overtaken By Events" ou "Irrelavant", ou similaire pour vous permettre d'exprimer la fermeture comme vous le souhaitez

Est-ce que ça importe? cela dépend, pour nous, je dirais oui car notre client est trop préoccupé par le nombre de problèmes ouverts dans notre tracker, donc pour nous, il est utile de pouvoir dire que ceux-ci sont fermés car ils ne sont plus pertinents sans supprimer complètement le problème .

Même sans un client préoccupé par les numéros de problème, l'élagage des anciens problèmes ouverts qui ne sont plus pertinents est certainement utile juste pour réduire l'encombrement dans le navigateur.

Nous utilisons FogBugz, mais je suis sûr que la même chose (ou similaire) s'applique ici:

Nous utilisons simplement "Résolu (Fixé)" et commentons dans la résolution éditer quelque chose comme "Fixé par le cas 12345".

FogBugz correspond à "case \ d +" et relie les deux sous Cas associés, mais si Jira ne le fait pas, il devrait être simple d'ajouter simplement un lien.

Ceci est l' OMI mieux qu'une variante « Trop Localized » parce qu'il était un bug réel, et mieux qu'un simple « obsolète » , car il a été fixé, cette fonction n'a pas été tout simplement supprimé.