La question est probablement trop large. Les raisons en sont infinies.
jmq
7
La question est: expédier avec des bugs ou ne pas expédier du tout :)
Vitor Py
41
Tous les produits sont livrés avec des bugs.
Joel Etherton
4
Définissez BUG. Nous avons récemment expédié un produit qui ne serait pas installé. Great bug: D
Barfieldmv
2
Voulez-vous dire «bogues connus»?
Personne
Réponses:
12
Je suppose que vous parlez d'un bug "connu" (la question n'a pas de sens autrement). Eh bien, la réponse dépend de ces facteurs:
1) Qui est l'utilisateur et comment acceptera-t-il / elle le bogue s'il est trouvé?
2) Quel est l'impact potentiel (dommages) du bug?
3) Est-il possible de retarder l'envoi du logiciel afin de corriger le bug?
4) Plus important encore: qu'attendez-vous de votre logiciel? Délai de mise sur le marché? Qualité? Voulez-vous voir si vos clients utilisent le logiciel assez longtemps pour trouver le bogue?
mais on dirait qu'il est au courant du bogue ... donc à ce stade, il semblerait qu'un programmeur est juste paresseux pour ne pas le corriger en étant conscient de lui ...
Kenneth
7
@Kenneth: Vous pouvez le voir comme ça, mais les produits doivent être expédiés et ils auront toujours des bugs. Cela dépendra de la gravité du bogue pour savoir si vous respectez votre échéance.
Matt Ellen
1
@Matt c'est vrai. Cependant, il me semble que dans la plupart des cas, vous ne voudriez pas expédier sciemment un produit avec des bugs majeurs. Cela signifierait que les bogues restants que vous connaissez seraient mineurs, ce qui dans la plupart des cas serait facilement corrigé ou au moins contourné. Vous ne pouvez pas gérer les bogues que vous ne connaissez pas, mais si le processus de test se déroule correctement, la plupart des bogues devraient être détectés ...
Kenneth
1
Peut-être que mon sarcasme n'était pas clair ... mais dire qu'il est "toujours OK" d'expédier un logiciel de buggy est un peu irresponsable. C'est comme dire "il y aura toujours des meurtriers dans le monde, donc peu importe que j'aille tuer quelques personnes".
DisgruntledGoat
7
@DisgruntledGoat Tous les bogues ne sont pas égaux: certains sont des correctifs faciles, certains sont des catastrophes destructrices de projets. Évidemment, ceux-ci devraient être corrigés. Certains sont des bogues très rares, difficiles à trouver, basés sur des circonstances inhabituelles, et généralement difficiles à corriger sans réécriture majeure. Parfois, ceux-ci doivent simplement rester, car les réparer offre trop peu de valeur et le logiciel doit être livré hier. Son tout sur l'analyse des coûts / risques / avantages.
CodexArcanum
33
C'est un appel au jugement. N'oubliez pas qu'un bogue peut être beaucoup de choses. Si c'est un élément majeur de fonctionnalité qui ne fonctionne pas, vous devez le corriger en premier. Si c'est quelque chose de mineur qui a un impact minimal ou nul sur les utilitaires du programme, vous pouvez le laisser glisser.
Considérez-le donc d'un point de vue coûts / avantages.
Vous expédiez des produits avec des bogues connus lorsque le coût total et le risque de correction du bogue l'emportent sur les problèmes et l'impact négatif pouvant résulter de la présence du bogue.
Donc, si vous avez une période de test de 2 semaines avant de publier, et qu'un petit bogue est détecté, la question est ... est de corriger ce bogue qui vaut les 2 semaines supplémentaires qu'une équipe pourrait maintenant avoir à passer pour tester à nouveau l'application et l' installation (une étape souvent oubliée de la création de logiciels)? Quels sont les coûts pour la réputation ou les ventes si le logiciel est en retard? Les gens vont-ils être en colère? Ils pourraient être très heureux de vivre avec un bogue mineur si la fonctionnalité principale peut être livrée à temps.
Les risques incluent le risque d'introduire un nouveau problème, non seulement dans la correction du bogue, mais aussi des choses qui pourraient survenir lors de la création d'une nouvelle installation.
L'impact négatif est à la fois le temps et les efforts nécessaires pour traiter les clients signalant le bogue, et des choses comme les dommages à la réputation.
Une faute de frappe dans la zone «à propos» est quelque chose que vous devez vraiment corriger. Cela prendra environ 0,7 seconde (en supposant que nous tapons tous les deux à la même vitesse). Cependant, si vous laissez cette faute de frappe, les gens peuvent la voir . C'est la mort instantanée pour la confiance de vos utilisateurs dans votre logiciel s'il y a des erreurs visibles dans l'interface utilisateur.
Cela me semble à peu près juste. La plupart du temps, il y a quelques bugs mineurs connus dans un produit, même au moment de sa sortie. Il s'agit en général de choses très inhabituelles qui ont un effet négligeable sur le fonctionnement et l'utilisation réels du logiciel ou sur des choses que la plupart des utilisateurs ne voient jamais.
glenatron
3
En effet, les fautes de frappe dans votre interface utilisateur brisent la foi en la qualité d'un produit (à tort, car de nombreux programmeurs ne parlent pas bien l'anglais), mais je vois votre point de vue - des bugs triviaux qui ne causent pas de préjudice réel et ne viendront probablement jamais ne valent pas la peine de retenir une version. Laissez-le pour une puce dans 1.01.
Phoshi
Ne laissez pas les fautes d'orthographe dans votre application. Franchement, je suis plus gêné par eux que par un bug réel.
ChaosPandion
1
Je ne sais pas de quoi vous parlez ...;)
Andreas Johansson
6
Les bogues sont de différentes gravités. Dans toutes les sociétés de logiciels dans lesquelles j'ai travaillé, nous avons classé les bogues par ordre de priorité de P0 à P4.
P0 Est-ce que le logiciel ne fonctionne pas / se bloque et pourrait endommager l'entreprise du client. P1 Il ne fonctionne pas comme prévu et se bloque de manière cohérente dans les fonctionnalités de base P2 Il se bloque occasionnellement et / ou une fonctionnalité latérale peut ne pas fonctionner. P3 Certains éléments du logiciel ne fonctionnent pas comme prévu / Problème P4 Cosmétique prévu.
J'ai travaillé dans des endroits où les P4 ne sont tout simplement pas réparés car ils ont un si petit effet sur le logiciel.
Je dirais que c'est correct de livrer si votre logiciel a connu des problèmes P3 / P4, je mettrais cela dans les notes de version et je note qu'ils sont en cours de traitement.
Je n'avais jamais sorti de logiciel avec un problème P0, P1 ou P2 que je connaissais.
C'est ce qu'on appelle un « problème connu ». Google, Microsoft, Apple, etc. expédient tous des produits avec des bogues, connus et inconnus. Essayez de les minimiser, mais n'attendez pas la perfection. Expédiez rapidement, expédiez souvent.
Vous ne pouvez pas expédier de logiciels sans bogues. Le conseil que je peux donner est qu'il vaut toujours mieux dire à votre client: "Cette version ne peut pas faire ça et cela mais nous allons corriger cela" que la situation où le client vous dit que vous avez un bug.
Sur une note sérieuse, à moins que vous ne soyez un programmeur parfait avec une configuration de test parfaite, pour tester parfaitement chaque chemin de code unique et, éventuellement, qui pourrait potentiellement exister, il est improbable que vous expédiez un produit sans fenêtre.
Par conséquent, soyez pragmatique, si tout ce que vous avez rencontré lors de vos tests a été corrigé, tout élément supplémentaire doit être corrigé au besoin.
Tant que vous êtes honnête avec vos clients, vous pouvez envoyer des bogues. Leur parler de tous les bogues existants leur montre que vous avez une bonne connaissance de votre logiciel, et c'est en effet bien testé (si c'est le cas ..). :)
Évidemment, la meilleure chose à faire est d'éviter l'envoi de bugs.
Il est souvent préférable d'avoir un produit expédié à temps, avec une liste des problèmes connus, que de ne pas expédier du tout.
L'une des choses dans le monde de la programmation qui donne confiance aux gens dans un projet est de savoir s'ils ont prévu la sortie et si le calendrier est respecté .
C'est pourquoi Ubuntu est livré tous les six mois, même s'il reste des problèmes ouverts.
Je dirais qu'une bonne règle de base est, "ce bug est-il un showstopper?"
Si le bogue entraîne l'échec d'un «scénario de cheminement heureux», ne le livrez absolument pas avec ce bogue.
Si le bogue provoque l'échec d'un "scénario tangent-vers-le-chemin-heureux" et qu'il n'y a pas de solution de contournement, ne le livrez pas avec ce bogue.
Si un bogue est documenté et qu'il existe une solution de contournement connue, il est probablement correct de le livrer avec ce bogue.
Du point de vue des consommateurs ... Jamais. Mon point est aussi longtemps que vous savez qu'il y a un bogue majeur dans le logiciel, vous ne devriez jamais l'expédier. Cependant, les forces de la nature (entreprise) l'emportent si le cycle de production du logiciel est maintenant au stade où il peut nuire au modèle commercial et qu'il s'agit de bogues mineurs qui ne: (i) compromettent la sécurité du logiciel (ii) nuisent à la convivialité
Comme certains l'ont dit, c'est une question très large. Cela m'amène en fait à une perspective intéressante: les soi-disant «bugs» que vous prétendez ne sont que les défauts qui ont été découverts par vos testeurs. Il pourrait y avoir une infinité de failles supplémentaires. Je viens de rappeler une histoire intéressante que j'ai entendue d'un professeur respecté lors d'un séminaire de troisième cycle: lorsque des gens dans l'un des pays scandinaves utilisaient une machine de vote de type «manuscrite - reconnaissable», certaines personnes ont piraté l'ensemble du système en écrivant du code SQL malveillant (que le système a pris comme entrée normale).
Un autre facteur décisif peut être la relation entre le défaut et votre dernière version. Si le bogue fait partie d'une fonctionnalité nouvelle mais cassée, la non-fonctionnalité ne représente pas une régression de la fonctionnalité. Allez-y et expédiez.
D'un autre côté, si le défaut provoque une perte de fonctionnalités existantes connues pour être utiles aux clients existants, il doit bloquer la version. Une telle version serait un déclassement pour vos clients et ne servirait ni vos intérêts ni les leurs.
Il peut y avoir des nuances de gris. Une régression de la fonction de base ne devrait jamais sortir. Une régression des fonctionnalités périphériques pourrait s'avérer utile pour les utilisateurs principaux si la version contient également de nouvelles fonctionnalités pour lesquelles ils ont manifesté leur intérêt. Un défaut obscur qui n'est pas susceptible d'affecter de nombreux clients peut entrer dans une version, tant qu'une solution de contournement est fournie lorsque cela affecte ces clients. Les défauts dans les fonctionnalités hautement expérimentales qui sont désactivées par défaut de toute façon ne devraient jamais retarder la publication.
Réponses:
Je suppose que vous parlez d'un bug "connu" (la question n'a pas de sens autrement). Eh bien, la réponse dépend de ces facteurs:
1) Qui est l'utilisateur et comment acceptera-t-il / elle le bogue s'il est trouvé?
2) Quel est l'impact potentiel (dommages) du bug?
3) Est-il possible de retarder l'envoi du logiciel afin de corriger le bug?
4) Plus important encore: qu'attendez-vous de votre logiciel? Délai de mise sur le marché? Qualité? Voulez-vous voir si vos clients utilisent le logiciel assez longtemps pour trouver le bogue?
la source
Cela doit toujours être OK, car il n'existe pas de logiciel sans bugless.
la source
C'est un appel au jugement. N'oubliez pas qu'un bogue peut être beaucoup de choses. Si c'est un élément majeur de fonctionnalité qui ne fonctionne pas, vous devez le corriger en premier. Si c'est quelque chose de mineur qui a un impact minimal ou nul sur les utilitaires du programme, vous pouvez le laisser glisser.
Considérez-le donc d'un point de vue coûts / avantages.
Vous expédiez des produits avec des bogues connus lorsque le coût total et le risque de correction du bogue l'emportent sur les problèmes et l'impact négatif pouvant résulter de la présence du bogue.
Donc, si vous avez une période de test de 2 semaines avant de publier, et qu'un petit bogue est détecté, la question est ... est de corriger ce bogue qui vaut les 2 semaines supplémentaires qu'une équipe pourrait maintenant avoir à passer pour tester à nouveau l'application et l' installation (une étape souvent oubliée de la création de logiciels)? Quels sont les coûts pour la réputation ou les ventes si le logiciel est en retard? Les gens vont-ils être en colère? Ils pourraient être très heureux de vivre avec un bogue mineur si la fonctionnalité principale peut être livrée à temps.
Les risques incluent le risque d'introduire un nouveau problème, non seulement dans la correction du bogue, mais aussi des choses qui pourraient survenir lors de la création d'une nouvelle installation.
L'impact négatif est à la fois le temps et les efforts nécessaires pour traiter les clients signalant le bogue, et des choses comme les dommages à la réputation.
la source
Les bogues sont de différentes gravités. Dans toutes les sociétés de logiciels dans lesquelles j'ai travaillé, nous avons classé les bogues par ordre de priorité de P0 à P4.
P0 Est-ce que le logiciel ne fonctionne pas / se bloque et pourrait endommager l'entreprise du client. P1 Il ne fonctionne pas comme prévu et se bloque de manière cohérente dans les fonctionnalités de base P2 Il se bloque occasionnellement et / ou une fonctionnalité latérale peut ne pas fonctionner. P3 Certains éléments du logiciel ne fonctionnent pas comme prévu / Problème P4 Cosmétique prévu.
J'ai travaillé dans des endroits où les P4 ne sont tout simplement pas réparés car ils ont un si petit effet sur le logiciel.
Je dirais que c'est correct de livrer si votre logiciel a connu des problèmes P3 / P4, je mettrais cela dans les notes de version et je note qu'ils sont en cours de traitement.
Je n'avais jamais sorti de logiciel avec un problème P0, P1 ou P2 que je connaissais.
la source
C'est ce qu'on appelle un « problème connu ». Google, Microsoft, Apple, etc. expédient tous des produits avec des bogues, connus et inconnus. Essayez de les minimiser, mais n'attendez pas la perfection. Expédiez rapidement, expédiez souvent.
la source
Vous ne pouvez pas expédier de logiciels sans bogues. Le conseil que je peux donner est qu'il vaut toujours mieux dire à votre client: "Cette version ne peut pas faire ça et cela mais nous allons corriger cela" que la situation où le client vous dit que vous avez un bug.
la source
quand c'est une "fonctionnalité"! ;)
Sur une note sérieuse, à moins que vous ne soyez un programmeur parfait avec une configuration de test parfaite, pour tester parfaitement chaque chemin de code unique et, éventuellement, qui pourrait potentiellement exister, il est improbable que vous expédiez un produit sans fenêtre.
Par conséquent, soyez pragmatique, si tout ce que vous avez rencontré lors de vos tests a été corrigé, tout élément supplémentaire doit être corrigé au besoin.
la source
Tant que vous êtes honnête avec vos clients, vous pouvez envoyer des bogues. Leur parler de tous les bogues existants leur montre que vous avez une bonne connaissance de votre logiciel, et c'est en effet bien testé (si c'est le cas ..). :)
Évidemment, la meilleure chose à faire est d'éviter l'envoi de bugs.
la source
Il est souvent préférable d'avoir un produit expédié à temps, avec une liste des problèmes connus, que de ne pas expédier du tout.
L'une des choses dans le monde de la programmation qui donne confiance aux gens dans un projet est de savoir s'ils ont prévu la sortie et si le calendrier est respecté .
C'est pourquoi Ubuntu est livré tous les six mois, même s'il reste des problèmes ouverts.
la source
Je dirais qu'une bonne règle de base est, "ce bug est-il un showstopper?"
Si le bogue entraîne l'échec d'un «scénario de cheminement heureux», ne le livrez absolument pas avec ce bogue.
Si le bogue provoque l'échec d'un "scénario tangent-vers-le-chemin-heureux" et qu'il n'y a pas de solution de contournement, ne le livrez pas avec ce bogue.
Si un bogue est documenté et qu'il existe une solution de contournement connue, il est probablement correct de le livrer avec ce bogue.
la source
Du point de vue des consommateurs ... Jamais. Mon point est aussi longtemps que vous savez qu'il y a un bogue majeur dans le logiciel, vous ne devriez jamais l'expédier. Cependant, les forces de la nature (entreprise) l'emportent si le cycle de production du logiciel est maintenant au stade où il peut nuire au modèle commercial et qu'il s'agit de bogues mineurs qui ne: (i) compromettent la sécurité du logiciel (ii) nuisent à la convivialité
la source
Comme certains l'ont dit, c'est une question très large. Cela m'amène en fait à une perspective intéressante: les soi-disant «bugs» que vous prétendez ne sont que les défauts qui ont été découverts par vos testeurs. Il pourrait y avoir une infinité de failles supplémentaires. Je viens de rappeler une histoire intéressante que j'ai entendue d'un professeur respecté lors d'un séminaire de troisième cycle: lorsque des gens dans l'un des pays scandinaves utilisaient une machine de vote de type «manuscrite - reconnaissable», certaines personnes ont piraté l'ensemble du système en écrivant du code SQL malveillant (que le système a pris comme entrée normale).
la source
Il y a quelque chose appelé FMEA (mode de défaillance et analyse des effets), il est très utile de décider quand un bogue connu est important ou non:
la source
Un autre facteur décisif peut être la relation entre le défaut et votre dernière version. Si le bogue fait partie d'une fonctionnalité nouvelle mais cassée, la non-fonctionnalité ne représente pas une régression de la fonctionnalité. Allez-y et expédiez.
D'un autre côté, si le défaut provoque une perte de fonctionnalités existantes connues pour être utiles aux clients existants, il doit bloquer la version. Une telle version serait un déclassement pour vos clients et ne servirait ni vos intérêts ni les leurs.
Il peut y avoir des nuances de gris. Une régression de la fonction de base ne devrait jamais sortir. Une régression des fonctionnalités périphériques pourrait s'avérer utile pour les utilisateurs principaux si la version contient également de nouvelles fonctionnalités pour lesquelles ils ont manifesté leur intérêt. Un défaut obscur qui n'est pas susceptible d'affecter de nombreux clients peut entrer dans une version, tant qu'une solution de contournement est fournie lorsque cela affecte ces clients. Les défauts dans les fonctionnalités hautement expérimentales qui sont désactivées par défaut de toute façon ne devraient jamais retarder la publication.
la source