Sans compter que ça dépend énormément du type de bug. Si le bug c'est une faute de frappe (ça peut être extrêmement bloquant, par exemple un export de fichier "pdd" au lieu de "pdf" <- déja vu, comme bug idiot, dans un produit professionnel en plus), il faudra m'expliquer comment tu justifies plusieurs jours de tests.
Ça dépend aussi de comment le produit en question est codé. Parce que dans une grosse suite bureautique, j'imagine qu'il y a des centaines de modules indépendants. Si l'API est bien documentée, en principe, personne n'aurait dû profiter d'une fonction bugguée pour coder un compensant qui dépend de ce bug pour fonctionner. Et ça de toutes manières, ça doit se "sentir" quand on corrige le bug en fonction de l'importance du composant buggué etc. Un bug qui porte sur le correcteur orthographique, si tu crains des répercussions sur le dessins des cercles à la souris, tu devrais peut-être penser à revoir l'architecture du programme.
Enfin, j'imagine aussi que les bugs sont corrigés en série sur une version instable, puis la release est freezée et testée, avant d'être distribuée au client. Je vois mal des "gros clients" se contenter d'un diff et d'un lien vers le cvs... Je conçois donc qu'une batterie de tests sur plusieurs plateformes etc. peuvent être particulièrement longue (mais elle peut être au moins en partie automatisée, surtout si les releases sont fréquentes, ca doit valoir le coup), mais en tout cas, un bug mineur -> plusieurs jours de tests me semble être une équivalence hasardeuse, et ce même pour un gros projet. C'est peut-être ce qu'on raconte à un décideur pressé pour faire passer une facture salée, mais je reste persuadé qu'il y a des manières de s'organiser en interne pour maintenir la qualité du produit tout en gagnant du temps.
[^] # Re: Obsolescence
Posté par arnaudus . En réponse à la dépêche OpenOffice.org au Ministère de l'Agriculture et de la Pêche (MAP). Évalué à 4.
Ça dépend aussi de comment le produit en question est codé. Parce que dans une grosse suite bureautique, j'imagine qu'il y a des centaines de modules indépendants. Si l'API est bien documentée, en principe, personne n'aurait dû profiter d'une fonction bugguée pour coder un compensant qui dépend de ce bug pour fonctionner. Et ça de toutes manières, ça doit se "sentir" quand on corrige le bug en fonction de l'importance du composant buggué etc. Un bug qui porte sur le correcteur orthographique, si tu crains des répercussions sur le dessins des cercles à la souris, tu devrais peut-être penser à revoir l'architecture du programme.
Enfin, j'imagine aussi que les bugs sont corrigés en série sur une version instable, puis la release est freezée et testée, avant d'être distribuée au client. Je vois mal des "gros clients" se contenter d'un diff et d'un lien vers le cvs... Je conçois donc qu'une batterie de tests sur plusieurs plateformes etc. peuvent être particulièrement longue (mais elle peut être au moins en partie automatisée, surtout si les releases sont fréquentes, ca doit valoir le coup), mais en tout cas, un bug mineur -> plusieurs jours de tests me semble être une équivalence hasardeuse, et ce même pour un gros projet. C'est peut-être ce qu'on raconte à un décideur pressé pour faire passer une facture salée, mais je reste persuadé qu'il y a des manières de s'organiser en interne pour maintenir la qualité du produit tout en gagnant du temps.