En fait il faudrait définir 2 types de bugs:
- ceux liés aux tests de la nouvelle version (=en RECETTE)
- ceux remontés par les utilisateurs sur la version stable (= en PROD)
Pour moi, les deux catégories sont valables et doivent être étudiées :
La première car cela permet de se donner une indication du niveau de qualité des développements de la nouvelle version (ou du niveau d'exigence des testeurs).
On peut ainsi sortir des stats par appli / par fonctionnalité et regarder quelles sont les nouveautés qui ont généré le plus de bugs.
Exemple: le projet Ktoto, qui présente 100 fonctionnalités par 7 développeurs a provoqué 12 bugs de recette.
Le projet Ktiti lui, présente 50 fonctionnalités avec 8 développeurs mais a engendré 214 bugs.
=> qu'est ce qui fait que le projet Ktiti a été relativement mal codé par rapport au projet Ktoto, que peut on faire pour améliorer le truc ?
l'équipe de dev est elle consciente du truc, travaille t elle rigoureusement avec peu de régressions, utilise t elle les bons outils (que le projet Ktoto pourrait lui conseiller) ?
Ok ça peut sembler un peu extrême mais ça peut servir.
La 2e catégorie de bugs permet aussi de se donner une idée du niveau de qualité final de la version stable.
On peut en sortir des stats sur les bugs / appli ou / fonctionnalité et d'en tirer des conclusions : "Tiens cette partie là n'a pas été assez recettée, vu le nb de bugs en prod. Pourquoi ? Vu la criticité des bugs, est ce que cela vaut le coup qu'on teste ça en priorité ou pas dans la prochaine version ?"
[^] # Re: Plus de 10 000... Correction de bugs ?
Posté par Pierre Tramonson . En réponse à la dépêche KDE 4.3 est sorti. Évalué à 2.
- ceux liés aux tests de la nouvelle version (=en RECETTE)
- ceux remontés par les utilisateurs sur la version stable (= en PROD)
Pour moi, les deux catégories sont valables et doivent être étudiées :
La première car cela permet de se donner une indication du niveau de qualité des développements de la nouvelle version (ou du niveau d'exigence des testeurs).
On peut ainsi sortir des stats par appli / par fonctionnalité et regarder quelles sont les nouveautés qui ont généré le plus de bugs.
Exemple: le projet Ktoto, qui présente 100 fonctionnalités par 7 développeurs a provoqué 12 bugs de recette.
Le projet Ktiti lui, présente 50 fonctionnalités avec 8 développeurs mais a engendré 214 bugs.
=> qu'est ce qui fait que le projet Ktiti a été relativement mal codé par rapport au projet Ktoto, que peut on faire pour améliorer le truc ?
l'équipe de dev est elle consciente du truc, travaille t elle rigoureusement avec peu de régressions, utilise t elle les bons outils (que le projet Ktoto pourrait lui conseiller) ?
Ok ça peut sembler un peu extrême mais ça peut servir.
La 2e catégorie de bugs permet aussi de se donner une idée du niveau de qualité final de la version stable.
On peut en sortir des stats sur les bugs / appli ou / fonctionnalité et d'en tirer des conclusions : "Tiens cette partie là n'a pas été assez recettée, vu le nb de bugs en prod. Pourquoi ? Vu la criticité des bugs, est ce que cela vaut le coup qu'on teste ça en priorité ou pas dans la prochaine version ?"
Bref, je ne suis pas d'accord avec toi :)