Quand est-il acceptable d'expédier un produit avec un bug connu?

Quand est-il acceptable d'expédier un produit avec un bug connu?

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?

Cela doit toujours être OK, car il n'existe pas de logiciel sans bugless.

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.

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.

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.

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).

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:

1. Occurrence
2. Gravité
3. Détection

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.