[jamais fini] méthodologie du rapport de bug

[Claude Mauguier]

Il est possible, mais seulement "possible" que j'ai fini d'éradiquer les bugs que vous avez trouvés (avant les prochains)

Alors, CHEF, faut pas mettre [FAIT] mais [PRESQUE FAIT] en titre du fil. Na

[Charlinette]

L'a raison l'ours sur ce coup là...

C'est la première fois que je remarque (alors là on va me dire que j'ai fumé la moquette bouclette) que la carte (refuges.info) s'affiche différemment selon que l'on zoom arrière ou zoom avant sur les vignettes présentes sur les fiches...

Quand on zoom avant, les toponymes disparaissent et les chiffres des courbes de niveau apparaissent... Abracadabra !!

[Charlinette]

Tout comme je n'avais pas remarqué jusque là que la fenêtre qui se trouve en bas de la page quand tu es sur la boite de dialogue pour poster un message ne reprend pas les couleurs du site (reste en bleu, seul la barre d'outil est marron clair)... Capture d'écran faite si besoin (un bon dessin vaut mieux que longues explications).

A moins avis, tu peux mettre "en cours" sur ton titre...

[Dominique]

Il est possible, mais seulement "possible" que j'ai fini d'éradiquer les bugs que vous avez trouvés (avant les prochains)

Alors, CHEF, faut pas mettre [FAIT] mais [PRESQUE FAIT] en titre du fil. Na

Etant donné que le titre du fil est : [FAIT] Ce week end, je casse tout, je considère complètement fait. pas presque

(pour les sceptiques, certains de mes précédentes réponses ayant porté à confusion, je confirme que celle ci est à classer dans la catégorie "délire complet")

[sly]

Il est possible, mais seulement "possible" que j'ai fini d'éradiquer les bugs que vous avez trouvés (avant les prochains)

Alors, CHEF, faut pas mettre [FAIT] mais [PRESQUE FAIT] en titre du fil. Na :laughing:

Malgré la teneur légère et fun, c'est une remarque pertinente : quand un bug est il [FAIT] ?

Je propose de procéder comme ça, sinon c'est vite l'embrouille (et oui, avant toute remarque, je n'ais pas respecté mon propre conseil) :

Lorsque un bug est rapporté, on indique le plus précisément possible comment quand et où il se produit. Une fois que ce bug précis n'est plus là, le sujet passe à [FAIT] [CLOS] ou truc du genre.
Si toutefois il ré-apparait à l'identique, on peut ré-ouvrir le sujet pour dire : à non il est toujours là dans ce cas.

Mais si cela en génère un différent du premier (ça arrive) :
- Bug 1 : Mon billet de 100 euros glisse sous l'armoire : je voudrais le récupérer
- Résolution bug 1 : je pousse l'armoire de toute mes forces et je récupère mon billet
- Bug 2 : Ma tapisserie s'est complètement arrachée dans l'opération : je voudrais remplacer ma tapisserie
- Résolution bug 2 : je dépense mes 100 euros pour réparer ma tapisserie

N'en déplaise aux éternels pessimistes, dans mon exemple, les 2 bugs sont résolus.

Je vous propose de procéder ainsi

[Claude Mauguier]

Il est possible, mais seulement "possible" que j'ai fini d'éradiquer les bugs que vous avez trouvés (avant les prochains)

Alors, CHEF, faut pas mettre [FAIT] mais [PRESQUE FAIT] en titre du fil. Na

Malgré la teneur légère et fun, c'est une remarque pertinente : quand un bug est il [FAIT] ?

Je propose de procéder comme ça, sinon c'est vite l'embrouille (et oui, avant toute remarque, je n'ais pas respecté mon propre conseil) :

Lorsque un bug est rapporté, on indique le plus précisément possible comment quand et où il se produit. Une fois que ce bug précis n'est plus là, le sujet passe à [FAIT] [CLOS] ou truc du genre.
Si toutefois il ré-apparait à l'identique, on peut ré-ouvrir le sujet pour dire : à non il est toujours là dans ce cas.

Mais si cela en génère un différent du premier (ça arrive) :
- Bug 1 : Mon billet de 100 euros glisse sous l'armoire : je voudrais le récupérer
- Résolution bug 1 : je pousse l'armoire de toute mes forces et je récupère mon billet
- Bug 2 : Ma tapisserie s'est complètement arrachée dans l'opération : je voudrais remplacer ma tapisserie
- Résolution bug 2 : je dépense mes 100 euros pour réparer ma tapisserie

N'en déplaise aux éternels pessimistes, dans mon exemple, les 2 bugs sont résolus.

Je vous propose de procéder ainsi

Oui mais :
1 - le fait que tu aies tout cassé pendant le WE peut effectivement être considéré comme FAIT (exégèse de Dominique), j'admets.
2 - MAIS, le chamboulement engendre inévitablement des bugs, à résoudre sur le champ (quoique le champ puisse être vaste, plein de cailloux, de trous, etc.) ce qui constitue un processus non discontinu et donc intégrable au tout, ce qui aboutit logiquement au NON FAIT, à qualifier donc à la rigueur EN COURS, puisque la qualification concerne bien le résultat global d'un acte, avec l'aboutissement conclusif de ses effets, et non la seule initiation de celui-ci.
3 - Le cas qui nous occupe ne peut pas être intégralement assimilé à l'exemple que tu donnes, puisque l'acte initial est susceptible de faire surgir à tout moment de nouveaux bugs (ce qui est arrivé), interdisant toute proclamation d'un succès définitif, et donc limitant l'attribut FAIT au seul processus de lancement initial. Car... :
4 - Tu n'as pas indiqué qu'en remettant l'armoire à sa place tu avais ENCORE déchiré la tapisserie ET rayé le parquet...ce qui relance l'action, dès lors bien loin de se conclure. C'est donc bien EN COURS qui convient

[Dominique]

Lorsque un bug est rapporté, on indique le plus précisément possible comment quand et où il se produit. Une fois que ce bug précis n'est plus là, le sujet passe à [FAIT] [CLOS] ou truc du genre.
Si toutefois il ré-apparait à l'identique, on peut ré-ouvrir le sujet pour dire : à non il est toujours là dans ce cas.

Dans ma boite, le développeur passe le bug à [A TESTER] et le testeur à [CLOS] (ici, on pourra dire 5 jours sans remarques)

[sly]

Oui mais :
1 - le fait que tu aies tout cassé pendant le WE peut effectivement être considéré comme FAIT (exégèse de Dominique), j'admets.

Quelque part, dominique a mis le doigt dessus "tout casser pendant le week end" n'est pas un bug au sens utilisé classiquement en informatique.
Toute tentative de le "terminer" ou de le "faire" échouera en temps que résolution de bug. Je propose donc de le classer en [INVALIDE] c'est à dire : nous refusons de le prendre en charge comme un bug car il n'explique pas quel est le bug précisément.

Toute tentative de le transformer en séquence :
- découverte d'un problème
- détail du problème
- résolution du problème
- validation que le problème est résolu

échouera forcément.

[sly]

Dans ma boite, le développeur passe le bug à [A TESTER] et le testeur à [CLOS] (ici, on pourra dire 5 jours sans remarques)

Dans le monde du libre, j'ai remarqué que cette méthode souffrait d'un gros désavantage :
Le testeur ou rapporteur du bug, se fiche trop souvent de ce qu'il advient de son bug :
- Il dit qu'il y en a un
- le développeur fait ce qu'il peut
--- si ça persiste, le rapporteur insiste
--- si ça répare, le rapporteur ne dit plus rien

Cette méthode est liée à la flemme de suivi par le rapporteur (qui est lui aussi bénévole et cherche juste la résolution) et conduit à une liste de bug de moins en moins gérables car pleine de "a tester"

Dans une société organisée, ce n'est pas pareil, car si le testeur ne fait pas son boulot de testeur, le chef de projet/boss lui tape sur les doigts et si ça se reproduit encore : c'est la porte.

La solution envisagée alors par le monde du libre est plus agressive, c'est celle que j'ai présentée. En gros le statu s'appel "terminé" mais est fictif, il veut en faite dire "a tester" car tout est toujours à tester, mais est retiré de la liste jusqu'a ce que quelqu'un le re-rajoute/ré-ouvre
(les logiciels de suivi de bug comme trac, bugzilla créer par et pour le libre sont pensés, dès la base, à des "bugs de durée infinie" qu'on ouvre, ferme, ré-ouvre, re-ferme, ...)
ça ne choque pas, mais la liste des "vrais bugs", c'est à dire avérés, confirmés, bien décrits et toujours là, c'est la liste que l'on tente de maintenir la plus petite possible pour qu'elle soit utile.

[Charlinette]

Pfffoouu !! c'est shadok ces échanges pour moi...
De façon pragmatique (tentons Gibis) :

Le problème de ce fil de discussion est qu'il a été créé pour signaler les bugs résultants de l'intervention de Sly ce WE (Je casse tout).
Les bugs signalés ne sont pas le fait de ton intervention de ce week-end ? Je l'ignore, je signale ce que je vois quand je le vois... comment savoir s'ils sont antérieurs et jamais dépistés jusqu'à ce jour ou le résultat des travaux de ce WE ?

En second, je peux m'autoriser à clore dans le titre, un bug résolu ?
Et enfin, il faudrait faire un suivi de la résolution définitive ou suivi des bugs que l'on signale (par la personne qui signale) ?

N'aurait-il pas été plus facile de faire un fil pour chaque bug ? Car c'est la raison pour laquelle ce fil de discussion ne s'arrêtera jamais... s'il doit contenir tous les bugs qui apparaissent à partir de ce WE... je suis dans l'incapacité de distinguer les bugs éligibles dans ce fil de discussion.

[sly]

Le problème de ce fil de discussion est qu'il a été créé pour signaler les bugs résultants de 'intervention de Sly ce WE (Je casse tout).

Faisons simple : Mon bug n'en était pas un, je n'aurais pas dû le déclarer comme et me contenter d'un message "merci d'être vigilant", bugs à ouvrir dans la bonne zone du forum.
Il est maintenant classé [invalide], et déplacé dans "la vie du site, ce n'est donc pas un bug" c'est une mise en garde.

Les bugs signalés ne sont pas le fait de ton intervention de ce week-end ? Je l'ignore, je signale ce que je vois quand je le vois... comment savoir s'ils sont antérieurs et jamais dépistés jusqu'à ce jour ou le résultat des travaux de ce WE ? :shock:

Faisons simple : peut importe d'où vient le bug, si on voit un nouveau bug : on ouvre un sujet, on décrit brièvement le problème et ont met [BUG] dans le titre au début pour que ça se voit bien.
Chaque bug son sujet.

En second, je peux m'autoriser à clore dans le titre, un bug résolu ?

Oui, c'est même recommandé pour que nous, développeurs, sachions ce qui ne va pas, et c'est qui est réparé.
(Il peut arriver que nos actions règle un bug que nous avions oublié)

Et enfin, il faudrait faire un suivi de la résolution définitive ou suivi des bugs que l'on signale (par la personne qui signale) ?

Dans quel but ?

[Charlinette]

Dans quel but ?

Dans le monde du libre, j'ai remarqué que cette méthode souffrait d'un gros désavantage :
Le testeur ou rapporteur du bug, se fiche trop souvent de ce qu'il advient de son bug :
- Il dit qu'il y en a un
- le développeur fait ce qu'il peut
--- si ça persiste, le rapporteur insiste
--- si ça répare, le rapporteur ne dit plus rien

Cette méthode est liée à la flemme de suivi par le rapporteur (qui est lui aussi bénévole et cherche juste la résolution) et conduit à une liste de bug de moins en moins gérables car pleine de "a tester"

Et bien c'est suite à cela... ou j'ai mal compris...

[sly]

Dans quel but ?

Dans le monde du libre, j'ai remarqué que cette méthode souffrait d'un gros désavantage :
Le testeur ou rapporteur du bug, se fiche trop souvent de ce qu'il advient de son bug :
- Il dit qu'il y en a un
- le développeur fait ce qu'il peut
--- si ça persiste, le rapporteur insiste
--- si ça répare, le rapporteur ne dit plus rien

Cette méthode est liée à la flemme de suivi par le rapporteur (qui est lui aussi bénévole et cherche juste la résolution) et conduit à une liste de bug de moins en moins gérables car pleine de "a tester"

Et bien c'est suite à cela... ou j'ai mal compris...

ok ! Ben voilà, c'est déjà géré comme ça ;-) Puisque je passe mon temps à fermer des tickets pour ne garder qu'une liste exploitable.
Et je ne dis jamais non à de l'aide (=fermer un ticket quand le bug n'est plus)

[Dominique]

Dans une société organisée, ce n'est pas pareil, car si le testeur ne fait pas son boulot de testeur, le chef de projet/boss lui tape sur les doigts et si ça se reproduit encore : c'est la porte.

La solution envisagée alors par le monde du libre est plus agressive, c'est celle que j'ai présentée. En gros le statu s'appel "terminé" mais est fictif, il veut en faite dire "a tester" car tout est toujours à tester, mais est retiré de la liste jusqu'a ce que quelqu'un le re-rajoute/ré-ouvre
(les logiciels de suivi de bug comme trac, bugzilla créer par et pour le libre sont pensés, dès la base, à des "bugs de durée infinie" qu'on ouvre, ferme, ré-ouvre, re-ferme, ...)
ça ne choque pas, mais la liste des "vrais bugs", c'est à dire avérés, confirmés, bien décrits et toujours là, c'est la liste que l'on tente de maintenir la plus petite possible pour qu'elle soit utile.

Intéressant et très vrai.
J'avais bêtement institué une période de 3 jours pour probation pour une correction mais, tu as raison, ça revient à demander à tous ceux qui n'ont pas constaté que ça ne marche pas de ne rien dire, ce qui est absurde : à moins d'un signalement que ça ne fonctionne toujours pas, je le clos suite aux non réponses.
A moins de nommer des responsables de tests et de suivre leur réponse, ton système est le seul logique.
Merci pour ton expérience