Devrais-je enregistrer un bogue que j'ai découvert et corrigé?

Je suppose que c'est une situation courante: je teste du code, découvre un bogue, le corrige et valide le correctif dans le référentiel. En supposant que de nombreuses personnes travaillent sur ce projet, devrais-je d'abord créer un rapport de bogue, me l'assigner moi-même et le référencer dans le message de validation (par exemple, "Corriger le bogue #XYZ. Le bogue était dû à X et Y. Corrigé par Q et R ")? Alternativement, je peux ignorer le rapport de bogue et commettre avec un message tel que "Un bogue qui causait A quand B a été corrigé. Le bogue était dû à X et Y. Il a été corrigé par Q et R".

Qu'est-ce qui est considéré comme une meilleure pratique?

Cela dépend de l'audience d'un rapport de bogue.

Si les développeurs le consultent uniquement en interne pour savoir ce qui doit être corrigé, alors ne vous inquiétez pas. C'est juste du bruit à ce point.

Liste non exhaustive de raisons pour vous connecter quand même:

• Les notes de publication incluent des informations sur les bogues corrigés (jusqu'à un certain seuil que ce bogue rencontre) - en particulier s'il existe une vulnérabilité exposée par ce bogue.
• La direction souhaite une notion de "temps passé à corriger les bogues" / "nombre de bogues détectés", etc.
• Les clients peuvent voir l'état actuel du bugtracker (pour voir si leur problème est connu, etc.)
• Les testeurs obtiennent des informations sur une modification à tester.

Je dirais que cela dépend si votre produit a été publié avec le bogue ou non.

S'il est publié avec le bogue que vous avez trouvé, alors oui, créez un rapport de bogue. Les cycles de publication peuvent souvent être longs et vous ne voulez pas que votre bogue soit signalé comme un nouveau problème tant que vous l'avez déjà corrigé.

Si votre bogue n'a pas encore été expédié, je ne suivrais pas le même chemin. Vous allez maintenant avoir des gens qui essaient de recréer votre bogue, ce qu'ils ne peuvent pas car ils ne sont pas encore dans une version, ils perdent essentiellement leur temps.

Vous devriez le faire s'il s'agit d'un bogue qui aurait pu être signalé par un client. Pire cas: vous corrigez le bogue, mais personne ne le sait. Le client rapporte le bogue. Votre collègue essaie de corriger le bogue, mais ne peut le reproduire (car vous l'avez déjà corrigé). C'est pourquoi vous voulez un enregistrement du bogue.

C'est également utile si vous effectuez des révisions de code, où le code est généralement écrit pour une tâche, puis révisé. Dans ce cas, il est préférable d’isoler ce correctif, ce qui peut nécessiter d’inscrire quelque chose dans votre liste de tâches, puis de faire tout le travail.

Cela dépend de plusieurs facteurs.

Pieter B et Caleth en citent tous deux dans leurs réponses:

• Le bug fait-il partie d'une version officielle?
• Le nombre de bugs / le temps passé sur eux est-il suivi spécifiquement?

Il peut également y avoir des procédures internes à suivre, souvent étayées par les exigences d’une certification. Pour certains certificats, il est impératif que chaque modification de code soit décelable dans un enregistrement dans un outil de suivi des problèmes.

De plus, parfois même les corrections de bogues d'aspect trivial ne sont pas aussi triviales et innocentes qu'elles ne le paraissent en premier. Si vous associez en silence un correctif de ce type à la livraison d'un problème non lié et que ce correctif s'avère ultérieurement problématique, il sera beaucoup plus difficile de rechercher, et encore moins d'isoler ou de revenir en arrière.

Seul le responsable de votre projet ou le responsable du "processus de billetterie" peut répondre à cette question.

Mais laissez-moi vous poser la question suivante: pourquoi n'enregistreriez- vous pas un bogue que vous avez corrigé?

La seule raison insondable que je vois, c’est que l’effort de classement, de fermeture et de fermeture du rapport de bogue est beaucoup plus important que le temps nécessaire pour le résoudre.

Dans ce cas, le problème n'est pas que le bogue est si facile à corriger, mais que la paperasserie prend trop de temps. Cela ne devrait vraiment pas. Pour moi, le temps système nécessaire pour créer un ticket Jira consiste à appuyer sur c, puis à saisir un court résumé sur une ligne, puis à appuyer sur Enter. La description n’est même pas trop onéreuse, car je peux couper et coller cela dans le message de validation, avec le numéro de problème. À la fin, . c <Enter>et le problème est fermé. Cela se résume à 5 touches au-dessus de votre tête.

Je ne sais pas pour vous, mais c'est assez peu pour en faire une politique même dans les petits projets pour enregistrer chaque correction de bogue de cette façon.

L’avantage est évident: peu de personnes peuvent facilement travailler avec un système de ticket comme Jira, mais pas avec le code source; il existe également des rapports générés à partir du système de ticket, mais pas à partir de la source. Vous voulez absolument que vos correctifs de bogues y soient, afin de vous informer sur les développements possibles, comme un afflux croissant de petites corrections de bogues sur une ligne, qui pourraient vous donner un aperçu des problèmes de processus, etc. Par exemple, pourquoi devez-vous souvent résoudre de telles corrections de bugs (en supposant que cela se produise souvent)? Est-ce que vos tests ne sont pas assez bons? La correction de bogue était-elle un changement de domaine ou une erreur de code? Etc.

La règle que je suis est que si la section sur laquelle vous travaillez n’a jamais été publiée, si elle ne s’exécute pas encore et si aucun utilisateur ne l’a jamais vue, corrigez rapidement chaque petit bogue que vous voyez et avancez. Une fois que le logiciel a été publié et est en production et qu'un utilisateur l’a vu, chaque bogue que vous voyez reçoit un rapport de bogue et est examiné.

J'ai trouvé que ce que je pense être un bug est une fonctionnalité pour quelqu'un d'autre. En corrigeant les bogues sans les examiner, il est possible que je crée un bogue au lieu de le corriger. Indiquez dans le rapport de bogue quelles lignes vous souhaitez modifier pour résoudre le bogue et votre plan pour le corriger.

En résumé: Si ce module n'a jamais été en production, corrigez rapidement tous les bugs que vous voyez et suivez les spécifications. Si le module est déjà en production, signalez chaque bogue en tant que rapport de bogue à examiner avant la résolution.

Oui .

Certaines réponses exposent déjà des situations dans lesquelles il est utile de créer un rapport de bogue. Quelques réponses. Et ils diffèrent.

La seule réponse est que personne ne le sait. Différentes personnes, à différents moments , auront des opinions différentes sur le sujet.

Alors maintenant, quand vous rencontrez un bogue, vous avez deux solutions:

• demandez-vous s'il vaut la peine d'ouvrir un rapport de bogue ou non, demandez peut-être l'avis d'un collègue ... et plus tard, dans certains cas, regrettez que vous ne l'ayez pas fait parce que quelqu'un vous le demande et si vous aviez déjà le rapport, vous pourriez il suffit de leur indiquer que
• il suffit de créer le rapport

La création du rapport est plus rapide et si ce n'est pas ... automatisez-le.

Comment l'automatiser? En supposant que votre suivi gère les scripts, créez simplement un script que vous pouvez appeler et qui utilisera le message de validation (titre et corps) pour soumettre un rapport de bogue et le fermera comme "implémenté" immédiatement, avec la révision de validation associée au suivi.

Je suis d'accord pour dire que les autres réponses offrent toutes de bonnes règles empiriques et que plusieurs abordent même ce point, mais je pense qu'il n'y a qu'une réponse vraiment sûre ici.

Demandez à votre responsable . Eh bien, votre responsable ou votre chef de projet ou scrum master, etc., en fonction de la structure de votre groupe.

Il existe de nombreux systèmes de bonnes et de mauvaises pratiques, mais le seul moyen de savoir que vous faites le bon choix pour votre équipe est de le demander.

Une conversation d’une minute dans le couloir conviendrait parfaitement: "Hé (patron), si je corrige un bogue mineur qui ne prend que quelques minutes, est-il utile de faire un ticket pour celui-ci ou devrais-je simplement le mentionner dans mon message de validation? " et vous saurez à coup sûr. Toutes les bonnes pratiques du monde sont inutiles si cette méthode agace votre équipe et votre manager.