Statuts des défauts: «WON'T FIX» vs «Canceled»

13

J'ai été impliqué dans plusieurs projets en tant que testeur ou développeur. Dans de nombreux projets, les états des défauts étaient les suivants:

NE FIXERA PAS
Annulé

Utilisez-vous ces statuts et comment les différenciez-vous? Je demande, car la plupart des gens ne peuvent pas expliquer la différence. Ma compréhension est:

WON'T FIX - le développeur ne corrigera pas le défaut, car ce n'est pas un défaut;
Annulé - le défaut ne doit pas être corrigé, en raison de la priorité la plus basse

tools issue-tracking

— sergionni
source

12

Comme d'autres l'ont noté, ces noms de statut ne sont pas très clairs. Je préférerais des noms de statut plus précis et détaillés:

Ne sera pas réparé (le coût de la réparation n'est pas justifié)
Solution de contournement fournie (et il suffit de rendre les utilisateurs heureux)
Pas un bug (mais une fonctionnalité)
Non reproduisible
Dupliquer

— Péter Török
source

Solution fournie, c'est quelque chose de nouveau, d'autres statuts sont connus

— sergionni

1

"Corriger dans une version ultérieure" peut être un autre statut utile. Généralement, nous l'utilisons vers la fin de la période de développement, car nous n'avons pas le temps ni les ressources pour le réparer (bien que nous le voulions). Tant qu'il n'est pas corrigé, les clients en sont informés via une SVA (évaluation de vulnérabilité logicielle). Se débarrasser de ce SVA, nous donne une incitation supplémentaire à le corriger dans la prochaine version.

— Sparky

vous pouvez simplement changer la version de la tâche dans Jira au lieu d'utiliser le statut "

— Réparer

6

Je pense que vous avez les réponses à l'envers

Ne sera pas corrigé - s'appliquerait à un bogue mineur qui n'a pas d'impact ou peut être dans une version plus ancienne donc ne vaut pas le coût du temps des développeurs pour le corriger, mais ils reconnaissent que c'est le bogue.

Annulé - Cela pourrait être un mauvais rapport de bogue s'il n'est pas reproductible ou peut-être que ce n'est pas du tout un bogue.

Ouais. J'avais considéré que «annulé» était appliqué lorsque le «correctif» était en cours d'élaboration mais pas terminé car lors du deuxième dépistage, il a été jugé inutile (soit parce que la section entière du code a été remplacée par quelque chose d'autre, soit parce qu'elle a été trouvée ne pas être un problème). «Ne résoudra pas» peut signifier soit décidé que ce n'est pas un problème ou qu'il est si mineur qu'il ne vaut pas l'investissement nécessaire pour le réparer.

— jwenting

5

Prendre vos 2 descriptions:

NE FIXERA PAS - le développeur ne corrigera pas le défaut, car ce n'est pas un défaut;

Annulé - le défaut ne doit pas être corrigé, en raison de la priorité la plus basse

Il est évident que la différence recherchée est:

NE FIXERA PAS - Ce n'est pas cassé, nous avons intentionnellement prévu ce comportement (par exemple, ne présente pas de bogue);

Annulé - Nous convenons qu'il est cassé, mais il est si trivial / sans conséquence que nous ne nous soucierons jamais de le réparer.

— Dan McGrath
source

en fait, il y a également le statut "Pas un bug", qui est fermé à votre comportement "Ne pas réparer"

— sergionni

Ces descriptions ont tout autant de sens si vous les inversez: "Le ticket est annulé parce que ce n'est pas un bug", "Nous ne le corrigerons pas parce que c'est trivial"

— Kevin Laity

@Kevin, je suis entièrement d'accord. Je dirais qu'ils ont plus de sens lorsqu'ils sont inversés. J'ai répondu uniquement sur la base des informations contenues dans la question.

— Dan McGrath

1

Dans mon entreprise, nous n'utilisons pas de tels statuts et je pense qu'ils ne constituent pas un bon choix d'étiquetage pour les États que vous avez décrits.

Nos états se composent de

Nouveau
en cours
prêt à tester
fermé
réouvert

Et les États devraient être aussi simples que cela. Tout ce qui est plus détaillé, comme s'il s'agissait d'un bogue ou s'il est trop faible, doit être mis dans une note.

— Tim
source

1

Annulé semble impliquer qu'un correctif a été démarré puis arrêté, peut-être parce qu'il s'est avéré avoir besoin de plus de ressources que ce que l'on pensait initialement et plus que le défaut ne le justifie ou que la personne qui a saisi le ticket de défaut a changé d'avis à propos du fait qu'il s'agit d'un défaut. Ne pas réparer semble qu'il y ait un accord sur le fait qu'un défaut existe mais qu'il y a une raison pour ne pas vouloir le réparer pour le moment (coût vs avantage, impact potentiel sur d'autres fonctionnalités, etc.).

— Jason
source