Définition d'un bug logiciel. Blizzard Entertainment insiste sur le fait que mon «bug» n'est pas du tout un bug. Ont-ils raison? [fermé]

Selon Wikipepdia,

Un bogue logiciel est le terme commun utilisé pour décrire une erreur, une faille, une erreur, une panne ou une défaillance dans un programme ou un système informatique qui produit un résultat incorrect ou inattendu, ou fait en sorte qu'il se comporte de manière involontaire.

Récemment, j'ai trouvé un "bogue" dans StarCraft 2 qui produit un résultat inattendu: http://eu.battle.net/sc2/en/forum/topic/2868627470

Le problème est que si je garde StarCraft 2 minimisé pendant une longue période, le jeu ne se déconnecte pas et ne génère aucune forme de timeout. Il se déconnecte cependant après la première bataille et perd parfois aussi des données de jeu (statistiques de match).

Malheureusement, selon Blizzard:

Le jeu n'est pas conçu pour être minimisé pendant une aussi longue période de temps. (Blizzard) ne peut pas considérer un tel comportement comme erroné car StarCraft II n'est pas censé être minimisé pendant des heures.

Alors, mon "bug" est-il vraiment un bug?

Pour une équipe logicielle, un bug est un problème logiciel qui doit être corrigé. Tous les problèmes logiciels ne doivent pas être résolus.

La mise à jour du logiciel coûte cher. Blizzard vous dit que votre problème est un cas de bord. En d'autres termes, le problème de cas de bord que vous avez découvert n'est pas nécessairement quelque chose qu'ils ont testé ou dont ils tiennent compte. Résoudre le problème vous aidera, mais selon toute vraisemblance, cela n'aidera pas beaucoup d'autres. Pourtant, le coût de la correction du bogue pourrait être élevé. Au lieu de cela, ils peuvent investir leurs ressources dans de nouvelles fonctionnalités ou même terminer Diablo III.

Cela me rappelle le chat au micro-ondes , en particulier le cas de Mme Smith en 1983.

Le fait est que vous vous attendez à ce que le produit fonctionne de cette manière. Principalement parce qu'un certain nombre de produits similaires fonctionnent comme ça, c'est-à-dire si vous les minimisez pendant des heures puis les ouvrez, ils fonctionnent (bien que l'inverse ne soit pas aussi rare que vous ne le pensez).

Mme Smith savait de son expérience, que le fait de sécher ses chats dans le four ne leur nuirait pas (en supposant une certaine prudence bien sûr). Plus précisément par expérience qu'elle a eue avec tous les fours qu'elle a essayés. Elle a ensuite supposé que ce serait la même chose pour le four à micro-ondes qu'on lui avait donné. Cette hypothèse était fausse. Les micro-ondes ne sont pas conçues pour sécher les chats. Les fours conventionnels ne le sont pas non plus. Il se trouve qu'ils ne tuent pas le chat dans le processus en tant qu'effet secondaire des processus physiques qu'ils utilisent pour générer de la chaleur.

Maintenant, en tant que producteur de micro-ondes, vous pouvez placer une bobine de chauffage et un certain nombre de capteurs dans le micro-ondes. Ce dernier déterminerait si le contenu actuel est un chat et utiliserait la bobine au lieu des micro-ondes.

De la même manière, que l'on pourrait produire un micro-ondes adapté aux chats secs, Blizzard pourrait créer une version de SC2 qui convient pour rester dans un état minimisé pendant de longues périodes.

Personnellement, je serais prêt à payer plus d'argent pour un four à micro-ondes compatible avec le séchage de chat juste pour le plaisir (en supposant qu'il y ait un gros logo de séchage du chat devant moi, je peux le montrer fièrement). Mais je ne me soucierais pas d'un jeu qui peut rester minimisé pendant des heures.

SC2 a été conçu pour répondre à certaines exigences. Votre attente n'en fait pas partie. Vous êtes libre de mesurer SC2 en fonction de vos attentes. Mais que Blizzard les inclue tous ou non dans l'étendue de leurs besoins est finalement leur choix.

Tout ce que vous pourriez vraiment discuter, c'est que c'est un échec de conception. Le bon sens veut que, à moins qu'une fraction substantielle des utilisateurs ne soit déroutée par la conception ou mécontente, c'est suffisant. Je suis sûr que si suffisamment d'utilisateurs déclarent partager vos attentes, Blizzard céderait et l'inclurait dans la conception. Cela rendrait votre problème un bug réel et Blizzard le corrigerait.

Je pense que c'est un cas de logiciel non utilisé tel que défini par les spécifications. Ils disent

Le jeu n'est pas conçu pour être minimisé pendant une aussi longue période de temps.

Ce qui signifie qu'ils ont une définition quelque part de ce qui compte comme une "longue période de temps". Si vous minimisez le programme pendant plus d'une "longue période de temps", cela va au-delà de leurs spécifications et au-delà de ce qu'ils ont testé (en supposant qu'ils l'ont formellement testé) et ils ne garantissent pas ce qui se passera. Bien sûr, cela aurait été bien si le manuel quelque part disait "nous n'avons testé ce programme que pour être minimisé pendant des périodes ne dépassant pas 10 minutes. Minimisez plus longtemps à vos risques et périls!".

Donc non, je ne pense pas que ce soit vraiment un bug. Dans mon bureau, cela s'appellerait un «problème de formation des utilisateurs» (ce qui, je dirais, est une forme de problème de communication , car dans ce cas, car aucune période maximale de minimisation du temps n'a été communiquée à l'utilisateur) car l'utilisateur est n'utilise pas le programme correctement. Non pas que cela aide beaucoup Blizzard, à moins qu'ils ne le mettent dans le manuel ...

Pas un bug. Un bug est un comportement non conforme à la spécification. Si la spécification indique que le cas d'utilisation n'est pas un comportement pris en charge, alors tout comportement - perçu comme valide ou non - dans ce cas d'utilisation est «par conception».

Dans ce scénario, le jeu qui fonctionne peut être perçu comme un comportement indéfini.

Si j'étais un chef d'équipe de développement sur ce projet, je l'appellerais un bogue mais mineur car il est bien en dehors des attentes de fonctionnement normales du logiciel. Si cela devait être travaillé, je l'attribuerais probablement à un programmeur junior ou à une nouvelle recrue plus comme un exercice d'apprentissage pour eux qu'autre chose.

C'est une bonne idée de suivre ces bogues mineurs car ils peuvent indiquer des problèmes potentiellement plus importants. Par exemple, le bogue d'enregistrement de données que vous avez rencontré. Cela semble mineur en raison de la façon dont cela s'est produit, mais il peut y avoir d'autres cas de perte de données. En utilisant un système de rapport de bogues, vous pouvez trouver tous les cas où un problème similaire est survenu et voir s'il y a un élément commun. Dans un système complexe, avoir ce genre de chose documenté peut vous aider à trouver des bogues plus sérieux et plus subtils.

Je vais être en désaccord avec la plupart des gens ici.

En tant qu'ancien joueur de Starcraft (original), je peux attester que c'est (ou était, au moins) un comportement très courant. Les utilisateurs quittent le jeu 24h / 24 et 7j / 7 pour conserver leur position dans les salles de chat et rejoindre les jeux à leur retour. Je suis sûr que le Battle.net mis à jour a quelques améliorations qui peuvent réduire le besoin de cela, mais cela se produit toujours beaucoup.

Il serait beaucoup plus logique qu'il ne vous permette pas de rejoindre un jeu sans vous reconnecter si votre session a expiré d'une manière ou d'une autre. Le fait qu'il vous permette de rejoindre des jeux après avoir expiré votre session est un bug pour moi. Ce qui est troublant ici, et quelque chose qui n'a pas encore été vraiment évoqué, c'est que les développeurs doivent comprendre leurs utilisateurs. Cela peut très bien être un cas de bord, mais c'est un cas de bord pour les joueurs très dévoués qu'ils devraient être configurés pour plaire.

Techniquement, ils peuvent faire valoir que c'est par conception, et ce n'est pas quelque chose qu'ils ont l'intention de réparer. C'est toujours une faute à mes yeux, qui dépend finalement d'eux qu'ils le classent ou non comme un bug. Cela ne signifie pas que les joueurs sont d'accord.

Quoi qu'il en soit, je pensais que je poserais une réponse légèrement différente de ce qui a été publié jusqu'à présent.

Un bug peut raisonnablement être défini comme "toute déviation par rapport au comportement prévu du logiciel".

De toute évidence, ils (et c'est leur logiciel pour qu'ils puissent déterminer comment il doit se comporter) n'ont jamais voulu que le logiciel gère ce scénario, donc il ne répond pas à cette définition de bogue.

Cependant, ce que je dirais est, à tout le moins, sous-optimal est la façon dont il gère cette condition.

L'entrée et la sortie des ordures (c'est-à-dire que l'utilisateur fait quelque chose de stupide ou de mauvais ou d'inattendu et que quelque chose de mauvais se produit en conséquence) a été considérée comme un mauvais comportement. Je dirais au moins qu'il devrait être plus élégant dans la façon dont il gère cette condition.

Donc, pas strictement un bug, mais une mauvaise gestion d'un cas de bord.

Cela dit, si j'étais eux, ce n'est pas quelque chose que j'envisagerais probablement de corriger (trop cher pour trop peu d'avantages), bien que je puisse le mentionner à l'équipe pour référence future, c'est quelque chose qu'ils auraient pu mieux gérer.

La définition d'un bug n'a rien à voir avec le comportement du logiciel. Un bug est défini selon que le comportement du logiciel correspond à son intention. Et qui doit dire quelle était l'intention? (Puisque je traite avec des programmeurs ici, je vais clarifier la première phrase - il n'y a pas de comportement logiciel possible qui, en soi, constitue un bug).

Gardez à l'esprit qu'en général, un bug est quelque chose que les développeurs de logiciels sont censés corriger. La définition d'un bug est donc basée sur ce qu'ils veulent corriger. Par exemple, "fonctionner correctement plus de 50% du temps est une fonctionnalité que nous prévoyons de publier dans les futures versions". Tout peut être défini comme n'étant pas un bogue en prétendant que le logiciel n'a jamais été conçu pour résoudre ce problème particulier. Donc, dans la pratique, ce qui constitue un bug est une considération purement politique.

(En passant, cela coupe dans les deux sens. Pour un client qui n'a pas à payer pour les corrections de bugs mais doit payer pour le nouveau développement "il ne fait pas une fonctionnalité à laquelle je viens de penser mais que j'ai maintenant décidé est 100% impliqué par les choses que j'ai mentionnées "est clairement un bug.)

Je n'envisagerais pas de ne pas déconnecter un bug. Ce n'est qu'un bug s'il était censé (par conception, intention) se déconnecter et ce n'est pas le cas. J'appellerais ce que vous avez soumis une demande de fonctionnalité.

Cela dit, perdre des données après la bataille - cela pourrait être le bug. Je ne sais pas grand chose sur Starcraft, mais je soupçonne que ce n'est pas par conception.