Dois-je enregistrer un bug 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 de bogue dans le référentiel. En supposant que de nombreuses personnes travaillent sur ce projet, dois-je d'abord créer un rapport de bogue, m'attribuer à moi-même et y faire référence 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 valider avec un message tel que "Correction d'un bogue qui provoquait A lorsque B. Le bogue était dû à X et Y. 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 ne l'examinent qu'en interne, pour savoir ce qui doit être corrigé, alors ne vous embêtez pas. C'est juste du bruit à ce point.
Liste non exhaustive des raisons de se connecter quand même:
- Les notes de version contiennent des informations sur les bogues corrigés (jusqu'à un certain seuil que ce bogue atteint) - surtout s'il y a une vulnérabilité exposée par ce bogue
- La direction souhaite une notion de "correction du temps passé"/"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 un changement qu'ils doivent 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 bug 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 parce qu'il n'est pas encore dans une version, ce qui fait essentiellement perdre leur temps.
Vous devez 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 signale le bogue. Votre collègue essaie de corriger le bogue, mais ne peut pas le reproduire (car vous l'avez déjà corrigé). C'est pourquoi vous voulez un enregistrement du bug.
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é. Il est préférable dans ce cas d'isoler ce correctif de bogue, ce qui peut nécessiter de mettre 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 énumèrent tous deux dans leurs réponses:
- Le bug fait-il partie d'une version officielle?
- Le nombre de bogues/temps passé sur eux est-il suivi spécifiquement?
Il peut également y avoir des procédures internes à suivre, souvent appuyées par les exigences d'une certification. Pour certains certificats, il est obligatoire que chaque changement de code soit traçable à un enregistrement dans un outil de suivi des problèmes.
De plus, parfois, même des corrections de bugs banales ne sont pas aussi triviales et innocentes qu'elles le paraissent au départ. Si vous associez silencieusement un tel correctif à la livraison d'un problème sans rapport, et que le correctif se révélera plus tard problématique, cela rendra la recherche beaucoup plus difficile, encore moins l'isolement ou le rétablissement.
Cette question ne peut vraiment être répondue que par votre chef de projet ou par la personne en charge du "processus de billetterie".
Mais permettez-moi de demander dans l'autre sens: pourquoi voudriez-vous pas enregistrer un bug que vous avez corrigé?
La seule raison insondable que je vois est que l'effort pour déposer le rapport de bogue, s'y engager et le fermer, est beaucoup plus grand que le temps de corriger le bogue.
Dans ce cas, le problème n'est pas que le bogue est si facile à corriger, mais que la paperasse prend trop de temps. Cela ne devrait vraiment pas. Pour moi, la surcharge pour créer un ticket Jira est d'appuyer sur c, puis d'entrer un bref résumé d'une ligne et d'appuyer sur Enter. La description n'est même pas une surcharge, car je peux couper et coller cela dans le message de validation, avec le numéro du problème. À la fin, . c <Enter> et le problème est clos. Cela se résume à 5 pressions de touches au-dessus.
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 manière.
L'avantage est évident - il y a pas mal de gens qui 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 vraiment que vos corrections de bugs soient là, pour en savoir plus sur les développements possibles, comme un afflux croissant de petits correctifs de 1 ligne, qui pourraient vous donner un aperçu des problèmes de processus ou autre. Par exemple, pourquoi devez-vous faire de telles petites corrections de bugs souvent (en supposant que cela arrive souvent)? Se peut-il que vos tests ne soient pas assez bons? Le correctif a-t-il été un changement de domaine ou une erreur de code? Etc.
La règle que je respecte est que si la section sur laquelle vous travaillez n'a jamais été publiée et qu'elle ne s'exécute même pas encore et qu'aucun utilisateur ne l'a jamais vue, corrigez chaque petit bug que vous voyez rapidement et passez à autre chose. 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 des bogues sans que ces bogues soient examinés, je pourrais créer un bogue au lieu de le corriger. Mettez dans le rapport de bogue les lignes que vous changeriez pour corriger le bogue et votre plan sur la façon de le corriger.
En résumé: Si ce module n'a jamais été en production, corrigez rapidement tous les bogues 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 de le corriger. =
Oui.
Il y a déjà quelques réponses qui exposent des situations dans lesquelles il vaut la peine de créer un rapport de bogue. Quelques réponses. Et ils diffèrent.
La seule réponse est que personne ne sait. Différentes personnes, à différents moments , auront des opinions différentes sur la question.
Alors maintenant, lorsque vous rencontrez un bug, 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 le demande et si vous aviez déjà le rapport, vous pourriez il suffit de les indiquer
- il suffit de créer le rapport
La création du rapport est plus rapide, et s'il ne l'est pas ... automatisez-le.
Comment l'automatiser? En supposant que votre tracker prend en charge 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 fermer immédiatement comme "implémenté", avec la révision de validation associée pour le suivi.
Je vais convenir que les autres réponses offrent toutes de bonnes règles de base et plusieurs abordent même ce point, mais je pense qu'il n'y a qu'une réponse vraiment sûre ici.
Demandez simplement à votre manager. Eh bien, votre manager ou alternativement chef de projet ou scrum master etc selon la structure de votre groupe.
Il existe de nombreux systèmes différents de bonnes et de mauvaises pratiques, mais la seule façon de savoir que vous faites la bonne chose pour votre équipe est de demander.
Quelque chose dans le sens d'une conversation d'une minute dans le couloir ferait l'affaire: "Hé (patron), si je corrige un bug mineur qui ne prend que quelques minutes, cela vaut-il la peine de faire un ticket pour cela ou devrait Je viens de le mentionner dans mon message de validation? " et vous en serez sûr. Toutes les bonnes pratiques du monde sont inutiles si cette méthode agace votre équipe et votre manager.