Les développeurs devraient-ils saisir des bogues dans le système de suivi des bogues?
Lors du développement (fonctionnalités ou corrections de bogues), il m'arrive parfois de découvrir des bogues qui ne sont pas directement liés à ce sur quoi je travaille. Que dois-je faire dans cette situation. Il suffit de le réparer? Essayez de vous rappeler de le réparer plus tard? Écrivez-le quelque part? Ou entrez-le dans le système de suivi des bogues?
Je l'entre généralement dans le système de suivi des bogues et laisse le processus se dérouler (c.-à-d. Tri, assignation, etc.). Cependant, je n'ai presque jamais vu un autre développeur entrer dans un bug. (Pourquoi donc?)
Si vous découvrez un bogue, je ne vois aucune bonne raison pas pour le saisir dans le système de suivi des bogues, que vous le corrigiez ou non. C'est à cela que sert le système de suivi des bogues, après tout.
Dans certains cas, il peut être plus judicieux de le signaler à une personne QA qui a plus d'expérience avec le système, mais dans tous les cas, le bogue doit être suivi.
Il est possible qu'il y ait une raison, valide ou non, que les développeurs ne devraient pas entrer de bogues. Une raison possible pourrait être que le système de suivi des bogues est visible pour les étrangers, et avoir trop de bogues signalés semble mauvais. C'est une très mauvaise raison, qui devrait être traitée d'une autre manière qui permet toujours de suivre les bogues. Demandez à votre patron.
(Bien sûr, s'il y a un bogue dans le code sur lequel vous travaillez toujours, et qu'il n'apparaît dans rien de ce qui a été publié, il n'est pas nécessaire de le suivre dans le système, bien qu'un commentaire TODO dans le code source puisse être une bonne idée. Pour prendre un cas extrême, "Ce code ne se compilera pas parce que je n'ai pas encore tapé le point-virgule à la fin de cette ligne" n'est pas un bogue à signaler.)
Quant à savoir pourquoi les autres développeurs n'entrent pas de bogues, vous devrez leur demander. Ils devraient probablement.
Vous devez saisir les bogues dans le système de suivi des bogues dans les deux cas:
lorsque le bug concerne directement le code sur lequel vous travaillez,
lorsque le bogue concerne le code sur lequel vous ne travaillez pas actuellement ou la partie sur laquelle un autre développeur travaille.
Ceci est essentiel, car le système de suivi des bogues est conçu pour ... suivre les bogues. Chaque bug. Si vous découvrez quelque chose de mal, ne vous contentez pas de le réparer. Documentez-le via le système de suivi des bogues. Lorsque plus tard, un client exécutant une version précédente du logiciel signalera un bogue qui est un double exact, vous pourrez le lier à votre rapport. Si vous n'avez rien à créer de lien, vous perdrez votre temps (ou votre collègue) à rechercher le bogue dans les révisions précédentes, puis essayez de le résoudre, et finalement vous constaterez que le bogue a déjà été résolu comme par magie.
Cela explique également pourquoi les pigistes doivent utiliser à la fois le contrôle de version et le système de suivi des bogues: ces deux outils ne sont pas uniquement destinés aux équipes.
Il n'y a aucune raison valable de ne pas introduire de défaut dans le système de suivi des défauts. Le seul endroit où j'ai vu des corrections de bogues appliquées sans suivi est parce que le processus était fondamentalement interrompu. Si tel est le cas, corrigez le processus.
les raisons de ne pas participer sont:
- Le processus mesure et punit en fonction du signalement des défauts - ne signalez pas, ne soyez pas puni. Dans ce cas, quittez l'organisation
- Le processus est un fardeau - il faut trop d'efforts et de temps pour entrer dans un défaut et arriver au point de le réparer. Le processus doit être modifié pour permettre aux développeurs de suivre rapidement un bogue léger tout au long du processus de triage/acceptation/correction.
- Certains développeurs sont paresseux/bâclés/hackers qui ne se soucient pas de l'impact de ce qu'ils font sur les autres. Recrutez des développeurs professionnels.
- Je suis un groupe d'un seul homme, ne vois pas le point. Allez travailler pour un groupe de 2 hommes et vous serez ....
Corriger le bogue immédiatement est probablement une mauvaise idée. Tout d'abord, quelqu'un d'autre peut travailler sur le même correctif, ce qui entraîne des efforts en double, et aussi, selon la méthodologie de développement que vous suivez, prioriser ce sur quoi travailler ensuite (corriger un bogue ou implémenter une nouvelle fonctionnalité) est plus un décision de gestion puis décision de développement.
La décision n'est pas claire et implique des compromis.
(certains) PROS
Le suivi des bogues est essentiel pour la communication, en particulier dans les grandes équipes. L'un des meilleurs avantages d'avoir plusieurs yeux sur le code est la capacité de détecter les problèmes plus tôt, et cet avantage est perdu si les bogues ne sont pas enregistrés ou suivis lors de votre développement.
- Souvent, les bogues sont plus facilement corrigés lorsque vous êtes déjà dans une partie du code, en essayant de le comprendre.
- Même sur des équipes plus petites, il y a beaucoup d'avantages à avoir du moral en étant capable de lister les bugs, et de progresser pour les corriger - parfois, l'avantage moral est crucial même sur des projets à un seul homme.
- La détection précise des bogues peut être très difficile après coup - voir un bogue dans le code peut économiser beaucoup de travail ultérieur en jouant au détective, essayant de comprendre où le problème s'est produit à l'origine.
- Il est bon pour votre développement général en tant que développeur de prêter attention aux bogues tels que vous les voyez et de prendre l'habitude d'améliorer/nettoyer/lire le code de manière critique
La journalisation des bogues tels que vous les trouvez est, en règle générale, une bonne habitude.
(certains) CONS
La saisie de bogues dans un système de suivi des bogues peut être onéreuse et longue, et peut vraiment perturber le travail de développement - plus souvent lorsque vous travaillez en grandes équipes. Vous devrez peut-être:
- vérifiez si votre entrée est un doublon avant d'entrer (cela peut même être implicite, il est décourageant d'entrer votre bug dans la file d'attente uniquement pour le fermer)
- fournir des cas de test reproductibles pour votre rapport
- accepter les interruptions ultérieures avec des questions sur les détails du bogue, pour accepter/vérifier un correctif une fois écrit
- pensez aux informations non liées qui sont souvent collectées dans les systèmes de suivi des bogues, comme le produit qui est probablement le plus affecté, la priorité du bogue, etc.
Parfois, le suivi des bogues n'est tout simplement pas l'utilisation la plus efficace de votre temps.
Ce sont deux principes généraux qui peuvent être difficiles à équilibrer - trouver une bonne stratégie est un peu un art. Dans des situations comme celles-ci, je pense qu'il est préférable d'adopter une heuristique flexible, que je modifie au besoin pour un projet, une équipe, un environnement de travail donné et vos compétences générales. Ma stratégie suit généralement un schéma comme suit:
- Enregistrez toujours les problèmes tels que vous les voyez tout au long de votre journée, quelque part. Peut-être sur un collant, peut-être dans un fichier sur le côté. Peut-être que tout ce que vous enregistrez est un nom de fichier et un numéro de ligne, peut-être plus. Ne laissez pas le problème interrompre trop votre ligne de pensée actuelle.
Prenez le temps au début de chaque nouvelle journée de travail, dans le cadre de votre préparation au travail, pour faire face aux collants. Je prends 10 à 15 minutes pour parcourir ma liste des problèmes détectés de la veille et faire ce qui suit est le plus rapide:
- Corrigez le problème et validez-le (probablement pour des corrections ou des fautes de frappe sur une seule ligne). Si vous n'êtes pas autorisé à valider sans rapport de bogue, créez un projet parallèle pour les petites validations. Lorsque suffisamment de correctifs s'accumulent dans le projet parallèle, prenez les quelques heures nécessaires pour les documenter et les valider.
- Enregistrez le problème dans un système de suivi des bogues (pour les problèmes évidents qui prennent plus de temps à résoudre, mais sans surcharge)
- Enregistrez le problème dans un document "à regarder lorsqu'il n'est pas occupé" (j'ajoute généralement un commentaire de type "// TODO - cela semble cassé, corrigez-le" à la source). Prenez régulièrement une journée (j'essaie une fois par mois) pour parcourir la liste et la consigner comme il convient - demande de fonctionnalité, rapport de bug, discussion avec le manager, etc ...
Au fil du temps, j'ai trouvé toutes sortes de réglages aussi utiles. Par exemple:
- Dans des environnements plus rigides, je pourrais simplement décharger le travail de rapport de bogues à l'équipe de test - demandez à un testeur de me rencontrer de temps en temps pendant une heure, remettez-lui la liste des problèmes et demandez-lui de faire la journalisation. Dans les environnements où les tests de journalisation sont très importants, le testeur sera généralement ravi de l'augmentation gratuite de leur productivité.
- Certaines équipes refusent d'autoriser les correctifs qui n'ont pas de rapport de bogue client derrière eux. Je garderais un projet plein de correctifs sur le côté et les commettrais instantanément lorsque le problème pertinent est signalé par un client, pour des points de brownie gratuits.
- Certaines équipes exigent que la personne "propriétaire" d'un morceau de code soit celle qui effectue les corrections. Je traiterais le code "propriétaire" comme un testeur et me réunirais de manière informelle pour transmettre les problèmes occasionnellement
Je trouve que, généralement, lorsque vous suivez ce type de stratégie, de plus en plus de vos pairs et d'autres membres de l'entreprise commenceront à respecter votre travail et votre engagement envers la qualité. Après assez de temps, vous aurez le respect et l'autorité nécessaires pour optimiser l'ensemble du processus à votre guise. Gardez un œil sur ces opportunités et saisissez-les le cas échéant.
Je crois que si un développeur rencontre un bogue qui n'est pas lié à ce qu'il travaille et qu'il ne corrigera pas, il devrait le saisir dans le système juste pour en avoir certains enregistrement. De cette façon, lorsque QA commence à tester (et qu'ils ne sont toujours pas corrigés), vous pouvez leur donner cette liste de bogues en tant que "défauts connus" afin qu'ils ne commencent pas à signaler les mêmes bogues.
Peut-être que d'autres développeurs qui trouvent des bogues en gardent une trace s'ils prévoient de le corriger, mais dans ce cas, ils courent le risque que 2 développeurs trouvent et corrigent le même bogue indépendamment.
J'ajouterais que même si le bogue a déjà été corrigé (ce qui n'aurait pas dû se produire avant de l'enregistrer dans un outil de suivi des problèmes), c'est une bonne idée de le suivre.
De cette façon, si le problème devait se poser à nouveau à l'avenir (des régressions se produisent!), Il est relativement facile de reconnaître le problème comme "déjà traité" et de lire comment il a été résolu la première fois.
Pourquoi donc? Parce que la plupart des développeurs examinent le problème qu'ils doivent soulever et le code qu'ils doivent écrire et comprendre, il est plus facile de ne pas déranger.
Mais, que ce soit la bonne chose à faire dépend de votre processus. Avez-vous une équipe QA? Pensez-vous que cela les dérange si vous changez simplement de code qui ne sera pas suivi? Qu'en est-il des revues de code? Sautera-t-il par cette fissure? Et l'entreprise? Ont-ils besoin de savoir que vous avez corrigé un bogue pour ne pas le soulever plus tard?
Et les autres développeurs? Et s'ils le réparent d'une manière différente en même temps? Et s'ils découvrent un bug similaire plus tard et tout ce que vous pouvez faire est de dire "oh, putain, je sais que nous avons eu quelque chose comme ça avant - maintenant qu'est-ce que c'était?"
Il y a environ un million de raisons pour enregistrer des bogues dans le système de suivi des bogues. Si vous êtes SÛR que vous ne rencontrez aucun de ces problèmes, alors ne vous embêtez pas. Mais si vous n'êtes pas sûr, vous devez l'enregistrer, même si la plupart des gens ne le font pas.
Bien sûr, vous devez le saisir. Ou du moins, signalez-le à votre personnel d'assurance qualité si c'est votre processus normal.
Même si vous corrigez simplement le bogue vous-même, vous voudrez un enregistrement de la modification afin qu'elle puisse ensuite être testée pour vous assurer que le correctif fonctionne réellement et qu'il n'y a pas eu de régression. Il est également possible qu'un utilisateur signale le bogue à un moment donné, et s'il est dans le système et marqué comme corrigé, vos techniciens de support peuvent leur dire qu'il a déjà été corrigé.
La programmation est fondamentalement un travail complexe. Les bugs sont complexes. j'ai donc l'habitude d'évaluer un bug par deux facteurs:
- À quelle fréquence ce type de bogues peut-il réapparaître à l'avenir? Que cette estimation soit exacte ou non, continuez d'estimer.
- Quand ce genre de bogues réapparaît, est-ce facile à comprendre? Ceci est précis lorsque vous analysez ce bogue et le corrigez.
Je classerais un bogue dans l'un des types suivants:
- Réapparaîtra probablement à l'avenir et sera facile à comprendre
- Réapparaîtra probablement à l'avenir, mais difficile à comprendre
- Réapparaît rarement à l'avenir et facile à comprendre
- Réapparaît rarement à l'avenir, mais difficile à comprendre
Dans le cas 1, un livre de recettes ou FAQ est un bon appareil pour l'équipe pour corriger de tels bugs à l'avenir.
Dans le cas 2, un enregistrement élaboré et compréhensible est nécessaire pour l'équipe car c'est un gaspillage d'effort si un autre programmeur subit à nouveau de tels bogues. Par exemple: fuite de mémoire.
Dans le cas 3, je pense que ce n'est pas grave qu'il n'y ait plus rien à enregistrer car vous ne passerez pas trop de temps à corriger un bug facile. Par exemple, une faute de frappe pour id d'élément en HTML.
Dans le cas 4, ces bogues créent un dilemme. Il faut du temps pour écrire un enregistrement élaboré et compréhensible pour décrire de tels bogues. Mais ce record est rarement utilisé à l'avenir. Sans enregistrement, cependant, l'apparition de ces bogues serait à nouveau une lutte. Par exemple, de tels bogues apparaissent à cause d'un virus informatique dans l'ordinateur de quelqu'un.
Si vous voyez quelque chose, dites quelque chose!
J'entre même des rapports de bogue sur mes propres modules car je ne veux pas interrompre ma tâche en cours. Et je peux m'assurer que toutes les étapes de reproduction sont incluses :-)
Et c'est encore mieux quand quelqu'un d'autre peut voir que vous avez répertorié quelque chose comme un bug connu. Ils aiment aussi savoir que quelqu'un d'autre l'a trouvé.
En effet, vous devriez les enregistrer dans le système, et au cas où ce n'est pas pratiqué, il est bon de commencer.
Dans mon passé, je faisais partie d'une équipe produit, et nous étions sur la version bêta d'un nouveau produit et parfois nous avons parfois trouvé des bogues que nous avions l'habitude de noter et d'envoyer par courrier aux personnes respectives qui manipulaient les modules (nous avions un système de suivi des bogues, mais nous n'avons pas pensé à les y pousser). Plus tard, lorsque les jours se sont écoulés, les articles de la poste ont commencé à être ignorés en raison d'autres priorités et qui ont finalement conduit à des nuits blanches.
Alors, cogne un jour, Nirvana! Pourquoi n'utilisons-nous pas le traqueur de bogues, même si vous avez trouvé quelque chose qui ressemble à un bogue et pourrait être possible qu'il n'en soit pas un (votre pensée sur le processus est erronée/défectueuse). Cela fait au moins partie de la liste qui pourrait ensuite être testée et le plus important de tous une rétroaction expliquant pourquoi c'est critique ou d'un autre côté, c'est parfait et c'est ainsi que cela devrait fonctionner pour des raisons 1 ... 2 ....
Maintenant, vous avez la liste et aussi pour ceux qui ont mal compris certaines parties de l'application, ils ont la rétroaction sur laquelle ils peuvent clarifier leurs pensées. Une situation gagnant-gagnant.
Je pense que c'est plus une question politique qu'une question sur les meilleures pratiques.
- est-ce que l'entrée de bug blâme le sombody?
- le client peut-il lire les entrées de bogue et voit qu'il y a des erreurs supplémentaires. Est-ce un problème de réputation pour votre entreprise?
- est-ce vraiment un bug ou une fonctionnalité que vous ne connaissez pas?
- qui paiera le correctif?
À mon avis, c'est une bonne pratique d'ajouter des bogues non triviaux dans le système de suivi, mais la direction doit décider comment y faire face.
Pour les cas non triviaux, vous ne devriez pas résoudre le problème sans consulter quelqu'un d'autre pour vous assurer que
- c'est vraiment un bug et non une fonctionnalité
- sombody else peut tester le correctif et s'assurer que le correctif n'introduit pas de nouveau bogue elsewere (régression)
En supposant que son code déjà testé (et en particulier s'il est publié) soit absolument.
Il ya un certain nombre de raisons à cela:
Memory - Il est très peu probable que le système oublie le bug, n'importe quel développeur peut le faire.
Métriques - Le nombre de bogues trouvés, fermés et le temps nécessaire peuvent être de bonnes mesures faciles à capturer pour vous dire comment la qualité de votre code progresse
rgence - Cela peut sembler être la chose la plus importante au monde pour le développeur, mais le temps passé à résoudre ce problème peut être mieux consacré à quelque chose que les utilisateurs finaux veulent en premier (voir aussi la mémoire).
Duplication - Peut-être qu'il a déjà été repéré et est en cours d'examen/correction par quelqu'un d'autre. Alternativement, il est peut-être tombé sous le coup de la règle d'urgence et a été repoussé. Bien sûr, le fait que vous l'ayez retrouvé ne signifie pas seulement que cela ne devrait pas être fait, cela peut signifier que (comme cela continue de se produire) qui est maintenant plus urgent à corriger.
Analyse des causes profondes - Le bogue le plus simple à corriger est celui qui n'a jamais été là. Il se peut que l'équipe se penche sur ce bug pour découvrir comment il est apparu. Il s'agit définitivement de ne pas punir le responsable (qui n'aide jamais) mais de découvrir comment éviter la situation à l'avenir.
Analyse d'impact plus large - Le bogue le moins cher à trouver est celui que vous connaissiez avant de le trouver. En regardant ce bogue (en particulier après avoir fait une analyse des causes profondes), il peut rapidement devenir clair que ce problème pourrait exister à d'autres endroits du code. En conséquence, l'équipe peut choisir d'aller le trouver avant de lever la tête laide à un moment plus embarrassant.
Le temps consacré à ces informations (le cas échéant) dépend en grande partie de la maturité et du niveau de qualité du code. L'analyse des causes profondes risque d'être exagérée pour une petite équipe travaillant sur le code de démonstration, mais une grande équipe sur le développement critique de l'entreprise doit probablement tirer les leçons de manière efficace et efficiente.
Par expérience, il existe deux grandes raisons pour lesquelles les développeurs évitent d'utiliser l'outil:
- L'outil et/ou le processus de gestion des bogues est perçu comme trop lourd pour le développement
- Les développeurs trouvent le défi mental de corriger le bogue plus intéressant que les choses sur lesquelles ils travaillent actuellement.
Le point 1 implique qu'un système meilleur/plus simple peut être nécessaire; ou bien une justification plus convaincante du système existant pourrait être de mise.
Le point 2 devrait être un signe d'avertissement utile pour le responsable du développement concernant les allocations de tâches actuelles.
Je suis principalement d'accord avec FrustratedWithFormsDesign mais je pense qu'il est encore plus clair si l'ensemble du problème se décompose en deux domaines:
- Rapport de bogue.
- Correction de bugs.
Ceux-ci sont souvent traités comme étant les mêmes et les séparer sera certainement très utile.
Ceux-ci peuvent être gérés avec: Rapport de bogue: - mettez-le dans le système, comme tout le monde le dit.
Correction de bugs: - Chaque semaine ou deux (ajustez votre calendrier de développement, etc.) tout le monde se réunit sur le projet et décide ce qui doit être corrigé, par qui, etc. C'était tout le monde sur la même page et peut voir ce qui doit être être terminé. Dans Agile Development, c'est la réunion de planification de Sprint.
Un bon outil que les gens veulent utiliser fait également une grande différence. J'aime Pivotal Tracker et il a réussi mon test `` outil vraiment utile '' quand j'ai commencé à l'utiliser juste pour garder une trace des choses que je veux faire ou corriger dans mes propres projets privés!