Commentaires sur : Rédiger un rapport de bugs, ça n’a pas l’air mais c’est du boulot !

Par : Faire un rapport de bug simple et efficace

Faire un rapport de bug simple et efficace — Mon, 05 Mar 2012 14:36:58 +0000

[…] ! A quoi ressemblerait votre site si les bugs d’affichage n’étaient pas résolus ? Cet article d’Éric le Bihan contient de précieux conseils sur la meilleure manière de rapporter un bug. […]

Par : Jacques

Jacques — Wed, 22 Feb 2012 20:39:26 +0000

… et lorsque vous travaillez avec des webdesigners confirmés, la liste des bugs diminue de 90%… je peux le prouver^^

Par : Frédéric Martinez

Frédéric Martinez — Fri, 06 Jan 2012 16:40:04 +0000

15. Utiliser un vrai outil de gestion de bugs, comme JIRA

16. Faire la formation client AVANT de lui donner un accès à l’outil de gestion de bugs, sinon il utilisera JIRA comme une messagerie alternative à l’e-mail de l’Internet

17. Ne pas prendre en photo l’écran (et transférer l’image de la carte SD à l’ordinateur, puis créer un email et mettre l’image dedans), mais utiliser une capture d’écran

18. Ne pas se contredire :

Est-ce que vous pouvez réduire et agrandir ce bouton s’il vous plaît ?

C’est sans fin.

Par : Eric Le Bihan

Eric Le Bihan — Mon, 28 Nov 2011 10:37:55 +0000

« Yoda Conditions », « Pokémon Exception Handling » and other programming classics

http://www.dodgycoder.net/2011/11/yoda-conditions-pokemon-exception.html

Via @benjamin @kaneel

Par : Frédéric Hewitt

Frédéric Hewitt — Fri, 28 Oct 2011 17:32:03 +0000

14. Décrire le comportement attendu, lorsqu’il y en a un. La ressource de test à probablement déjà les spécifications entre les mains et connait la réponse, pas besoin de forcer quelqu’un d’autre à fouiller la documentation.

Et s’il n’y a pas de comportement attendu, ou si le problème correspond aux spécifications, c’est qu’il faut revoir celle-ci. Du coup le développeur seul ne peut rien faire, autant assigner le bug aussi au chargé de projet et au concepteur.

Par : Julien DIDIER

Julien DIDIER — Fri, 28 Oct 2011 06:50:00 +0000

C’est l’article à insérer en rouge sur fond noir avec typo 400%, sur la page de création de tickets de bugs.
Histoire que les CdP n’oublient jamais.

Par : Eric Le Bihan

Eric Le Bihan — Sat, 22 Oct 2011 22:35:55 +0000

@sebastien
Quand je lis ton commentaire je ne peux m’empêcher de me référer à 37 Signals et leur excellent livre Rework.
Je te cite le passage Répondez à votre propre besoin:
Le moyen le plus simple et le plus direct d’inventer un bon produit ou un bon service est d’en concevoir un dont vous avez besoin, que vous aimeriez utiliser. Ainsi, vous travaillerez à résoudre un problème que vous connaissez et vous saurez tout de suite s’il y a du bon dans ce que vous faites. A 37 Signals, nous concevons des produits dont nous avons besoin pour notre entreprise. Par exemple, nous voulions un outil pour retracer facilement à qui nous avions parlé, ce que nous avions dit et quel suivi donner […]
A titre d’exemple, j’avais besoin de pouvoir quantifier le temps passé sur chacune des parties de chacun des projet sur lesquels nous travaillions et que chacun puisse saisir ses informations. Nous avons donc travaillé sur un outil qui me permettrait de suivre le travail de mon équipe et de fournir des informations. Cet outil, mon équipe et moi l’utilisons au quotidien, il répond à nos besoins et n’a pas fini d’évoluer.

Par : Sébastien

Sébastien — Sat, 22 Oct 2011 21:17:10 +0000

Même constat de mon côté. Combien de bugs incompréhensibles, corrigés par une vidange du cache, dans un navigateur même pas dans les specs, etc.

Pester c’est bien, fermer les bugs qui n’en sont pas aussi. Par contre le problème est bien plus profond que cela. Je vois trois causes majeures :

– la plupart du temps les personnes qui remontent les bugs ne sont pas formées pour. Alors oui, il y a peut être un certain manque de curiosité (aller voir les développeurs pour explication) mais quand un chef de projet n’est même pas capable de me dire sur quel navigateur il se trouvait précisément quand il a remonté le bug, cela relève pour moi d’un problème plus grave.
– les outils de gestion de bugs ne sont pas adaptés. 99% de ces outils ont l’air de venir tout droit du néolithique (Bugzilla, Trac, Mantis…). L’utilisateur se préoccupe plus de comment remonter un bug plutôt que de ce qu’il doit écrire j’ai eu le cas d’une chef de projet qui me demandait à quoi servait toutes les boîtes de texte de Bugzilla et à chaque validation de son bug, l’outil lui renvoyait une erreur parce qu’un champ obligatoire n’était pas renseigné. Pas étonnant qu’ils le fassent mal !)
– ajoutez à ça le manque de temps auquel font généralement face les chefs de projet et on a la combinaison gagnante (ou perdante en ce qui nous concerne).

Pour moi, tant que de nouveaux outils ne verront pas le jour, ça continuera à être comme aujourd’hui.

Par : bertrand

bertrand — Fri, 21 Oct 2011 07:44:17 +0000

J’aurai presque envie que tous ces mauvais bugs report soient simplement clôturés sans autre forme de procès. Un bug décrié en tant que tel doit pouvoir se reproduire ou au moins être décrit convenablement afin que quelqu’un de plus technique puisse comprendre le problème rapporté.

Les c’est cassé, les liens xxx.ccccc.com/order/payment.html et autre ça donne le tournis ne sont pas du tout l’expression d’un bug.
D’ailleurs le lien vers le processus de commande ou n’importe quelle page d’un espace privé ne fonctionnent jamais sans un certain nombres de manipulations préalables de l’utilisateur. Il faut au moins un produit commandé (pour un process commande), un compte pour se connecter, etc et ça n’est pas plus long de les inclure dans le rapport de bug, particulièrement si ce compte possède un historique permettant de constater le bug.

Enfin, ce qui est triste c’est que ce message n’arrivera probablement jamais aux bonnes oreilles. Intégrateurs : poussez, propagez, luttez !

Par : Jean

Jean — Fri, 21 Oct 2011 07:17:16 +0000

Si je rejoins la grosse majorité des remarques/conseils, pour être passé des deux côtés de la barrière, je pense qu’il ne faut pas non plus oublier les contraintes de la personne qui remonte les bugs:
– c’est très dépendant du contexte, mais en règle générale (chargé de communication unique en PME, fondateur de startup,…), il est impossible de passer 30 minutes sur un rapport de bug. Ce n’est pas rentable. Après, c’est le jeu du contrat qui lie le développeur au client (régie ou forfait), et le jeu de la négociation.
– les « je pense » ne sont pas forcément négatif. Le rapporteur n’a souvent pas les compétences techniques, mais peut parfois « sentir », par sa connaissance du produit et de son usage d’où pourrait venir le problème. Pour le développeur, au mieux ça l’aiguille sur la bonne piste, au pire il ignore l’idée.

Sinon pour tout le reste, c’est à imprimer et à donner au client par les développeurs :)