Différence entre un défaut et un bug dans les tests?
Quelle est la différence entre un défaut et un bug?
Un bug est le résultat d'une erreur de codage
Un défaut est un écart par rapport aux exigences
C'est-à-dire: Un défaut ne signifie pas nécessairement qu'il y a un bogue dans le code , il pourrait s'agir d'une fonction qui n'a pas été implémentée mais définie dans les exigences de les logiciels.
De la page Wikipedia sur test de logiciel :
Tous les défauts logiciels ne sont pas causés par des erreurs de codage. Une source courante de défauts coûteux est causée par des lacunes dans les exigences, par exemple des exigences non reconnues, qui entraînent des erreurs d'omission de la part du concepteur du programme. [14] Une source commune de lacunes dans les exigences est les exigences non fonctionnelles telles que la testabilité, l'évolutivité, la maintenabilité, l'utilisabilité, les performances et la sécurité.
Citant Ilene Burnstein du livre Tests de logiciels pratiques (recommandé) qui se sépare de la définition de la "Collection de normes IEEE pour les logiciels Engineering "(1994) et" IEEE Standard Glossary of Software Engineering Terminology "(norme 610.12, 1990):
Erreur
Une erreur est une erreur, une conception erronée ou un malentendu de la part d'un développeur de logiciels
Dans la catégorie des développeurs, nous incluons les ingénieurs logiciels, les programmeurs, les analystes et les testeurs. Par exemple, un développeur peut mal comprendre une notation de conception ou un programmeur peut taper un nom de variable de manière incorrecte.
Défauts (défauts)
Un défaut (défaut) est introduit dans le logiciel suite à une erreur. Il s'agit d'une anomalie dans le logiciel qui peut entraîner un comportement incorrect et non conforme à ses spécifications.
Les défauts ou défauts sont parfois appelés "bogues". L'utilisation de ce dernier terme banalise l'impact des défauts sur la qualité du logiciel. L'utilisation du terme "défaut" est également associée à des artefacts logiciels tels que les exigences et les documents de conception. Les défauts survenant dans ces artefacts sont également causés par des erreurs et sont généralement détectés dans le processus d'examen.
Les échecs
Une défaillance est l'incapacité d'un système logiciel ou d'un composant à exécuter ses fonctions requises dans les limites des performances spécifiées.
Lors de l'exécution d'un composant ou d'un système logiciel, un testeur, un développeur ou un utilisateur constate qu'il ne produit pas les résultats attendus. Dans certains cas, un type particulier de mauvaise conduite indique qu'un certain type de défaut est présent. On peut dire que le type de mauvaise conduite est un symptôme de la faute. Un développeur/testeur expérimenté aura une base de connaissances sur les cas de pannes/symptômes/pannes (modèles de pannes décrits au chapitre 3) stockés en mémoire. Un comportement incorrect peut inclure la production de valeurs incorrectes pour les variables de sortie, une réponse incorrecte de la part d'un périphérique ou une image incorrecte sur un écran. Pendant le développement, les échecs sont généralement observés par les testeurs et les défauts sont localisés et réparés par les développeurs.
Vous pouvez lire le chapitre complet dans Google Livres, ici .
Il existe différents termes liés aux bogues logiciels. Extrait d'un cours que j'ai suivi:
Erreur: Action humaine ou omission qui entraîne un défaut.
Fault: Fault est un défaut logiciel (étape, processus ou définition de données incorrect) qui provoque une panne.
Bug: Identique à Fault.
Échec: L'incapacité d'un logiciel à exécuter ses fonctions requises dans les conditions de performance spécifiées.
Selon cela, il n'y a pas de différence entre un défaut et un bug. Cependant, certaines personnes soutiennent que le bogue est une erreur qui est trouvée avant de publier le logiciel, tandis que le défaut est celui trouvé par le client.
Je n'ai pas pu résister à poster le fameux "premier cas réel de bug trouvé".
Extrait du glossaire standard de l'IEEE de terminologie du génie logiciel, cité dans le corpus de connaissances en génie logiciel KA pour les tests et la qualité des logiciels:
punaise. Voir: erreur; faute.
erreur. (1) Différence entre une valeur ou une condition calculée, observée ou mesurée et la valeur ou la condition vraie, spécifiée ou théoriquement correcte. Par exemple, une différence de 30 mètres entre un résultat calculé et le résultat correct. (2) Une étape, un processus ou une définition de données incorrect. Par exemple, une instruction incorrecte dans un programme informatique. (3) Un résultat incorrect. Par exemple, un résultat calculé de 12 lorsque le résultat correct est 10. (4) Une action humaine qui produit un résultat incorrect. Par exemple, une action incorrecte de la part d'un programmeur ou d'un opérateur. Remarque: Bien que les quatre définitions soient couramment utilisées, une distinction attribue la définition 1 au mot "erreur", la définition 2 au mot "faute", la définition 3 au mot "échec" et la définition 4 au mot "erreur". Voir a2so: erreur dynamique; erreur fatale; erreur indigène; erreur sémantique; erreur syntaxique; erreur statique; erreur transitoire.
échec. L'incapacité d'un système ou d'un composant à exécuter ses fonctions requises dans les limites des performances spécifiées. Remarque: La discipline de tolérance aux pannes fait la distinction entre une action humaine (une erreur), sa manifestation (une panne matérielle ou logicielle), le résultat de la panne (une panne) et la quantité de résultat incorrect (l'erreur). Voir aussi: crash; défaillance dépendante; exception; mode de défaillance; taux d'échec; échec dur; échec naissant; défaillance indépendante; échec aléatoire; défaillance douce; échec coincé.
faute. (1) Un défaut dans un périphérique ou composant matériel; par exemple, un court-circuit ou un fil cassé. (2) Une étape, un processus ou une définition de données incorrects dans un programme informatique. Remarque: Cette définition est principalement utilisée par la discipline de tolérance aux pannes. Dans l'usage courant, les termes "erreur" et "bug" sont utilisés pour exprimer ce sens. Voir aussi: défaut sensible aux données; défaut sensible au programme; défauts équivalents; masquage des défauts; défaut intermittent.
Je pense que la définition de l'échec est la plus pertinente. Tout commence par une erreur, que ce soit dans les exigences, la conception, la mise en œuvre ou le cas/la procédure de test. Si cette erreur se manifeste dans le logiciel, cela devient une faute. Une panne est causée par l'existence d'un ou plusieurs défauts dans le logiciel.
Cependant, je ne suis pas intéressé par la définition formelle de l'erreur. Je préfère de beaucoup la définition fournie par dukeofgaming dans sa réponse , cependant, celle de cette réponse est la définition standard de l'erreur IEEE.
Oh cher.
Dans le passé - le fonctionnement défectueux d'un ordinateur était dû à toutes sortes de choses - y compris des rats mâchant le câblage et de vrais bugs (bestioles) entrant dans les travaux.
Le terme BUG est resté comme un terme qui signifie que quelque chose ne fonctionne pas comme prévu.
BUG doit être considéré comme un terme de jargon signifiant un défaut.
Un défaut est un terme techniquement correct signifiant que la chose ne fait pas comme elle le devrait.
Dans la mesure du possible, l'utilisation de DEFECT au lieu de BUG entraîne en fait une connotation selon laquelle nous reconnaissons nos échecs (nos défauts, notre manque de compréhension des besoins des utilisateurs ou les choses que nous avons négligées dans la mise en œuvre) au lieu de le déguiser en bogue à consonance plus triviale. ".
Utilisez DEFAUT.
Essayez de ne pas utiliser le terme BUG. C'est idiot, hors de propos, historique et banal.
réponse de Dan McGrath a bien fait les choses.
- Un bug est le résultat d'une erreur de codage
- Un défaut est un écart par rapport aux exigences
Peut-être qu'un exemple le rendrait plus clair.
Exemple: le client souhaitait que le formulaire Web puisse enregistrer et fermer la fenêtre.
Scénario n ° 1: le formulaire Web possède un bouton d'enregistrement et un autre bouton de fermeture. Résultat: défaut, car le client voulait que le bouton 1 enregistre et ferme la fenêtre. Développeur mal compris et créé séparément. Parce que les deux boutons ont rempli leurs exigences, ce n'est pas un bug, mais un défaut car il ne répondait pas aux exigences du client.
Scénario n ° 2: le formulaire Web possède un bouton Enregistrer et fermer, mais enregistre uniquement mais ne ferme pas. Résultat: Bug. Parce que le bouton ne fonctionne pas comme requis/attendu. Le développeur sait qu'il est supposé produire ce résultat, mais ce n'est finalement pas le cas. (peut-être une erreur de codage)
Je ne sais pas si cela le rend plus clair.
p/s: du point de vue du développeur (je l'étais une fois), les défauts et les bugs sont tout aussi importants. Nous allons toujours le réparer.
Nous avons même rencontré des anomalies étranges, que nous avons classées sous les bogues et nous essayons continuellement de comprendre quelle est la cause et comment y remédier. Le qualifier de bogue ne le rend pas trivial par rapport aux défauts.
Voici celui que j'ai fait plus tôt pour mon employeur Q-LEAP basé sur le vocabulaire ISTQB et j'ai également vérifié le vocabulaire IEEE. Prendre plaisir.
Bug et défaut? La même chose même si on peut avoir une discussion sans fin à ce sujet. Nous avons vraiment d'autres choses à craindre, la vie est déjà assez compliquée, etc.
Un exemple de la façon dont le terme est utilisé dans la nature, de "Comment Google teste le logiciel" p. 113. Ouvrez un article de "IEEE Software" et il est utilisé de la même manière. En effet, on rencontre rarement le mot "défaut" dans la vraie vie.
Vie d'un bug
Les bogues et les rapports de bogues sont l'artefact que tout testeur comprend. La recherche de bogues, le tri des bogues, la correction des bogues et la régression des bogues sont le rythme cardiaque et le flux de travail pour la qualité des logiciels. C'est la partie des tests la plus conventionnelle chez Google, mais il y a encore quelques écarts intéressants par rapport à la norme. Pour cette section, nous ignorons les bogues qui sont déposés pour suivre les éléments de travail et utilisons le terme pour identifier le code cassé réel. En tant que tels, les bogues représentent souvent le flux de travail d'une heure à l'autre et au jour le jour pour les équipes d'ingénierie.
Un bug est né. Des bogues sont trouvés et déposés par tout le monde chez Google. Les chefs de produit signalent des bogues lorsqu'ils détectent des problèmes dans les premières versions qui diffèrent de leurs spécifications/réflexions. Les développeurs signalent des bogues lorsqu'ils se rendent compte qu'ils ont accidentellement archivé un problème, ou trouvent un problème ailleurs dans la base de code, ou lors de la création de produits Google. Les bogues proviennent également du terrain, de testeurs issus de la foule, de tests de fournisseurs externes et sont signalés par les gestionnaires de communauté qui surveillent les groupes Google spécifiques au produit. De nombreuses versions internes des applications ont également des moyens rapides en un clic de signaler les bogues, comme Google Maps. Et, parfois, les logiciels créent des bogues via une API.
Selon Fiabilité: concepts de base et terminologie :
Une défaillance du système se produit lorsque le service fourni s'écarte de la fonction du système, cette dernière étant celle à laquelle le système est destiné. Une erreur est la partie de l'état du système qui est susceptible de conduire à une défaillance ultérieure: une erreur affectant le service est une indication qu'une défaillance se produit ou a eu lieu. La cause jugée ou hypothétique d'une erreur est une faute .
Je comprends défaut comme juste un autre nom pour faute.
Bug est déroutant et peut représenter une faute ou un échec selon le contexte.
Notez qu'il n'y a aucune mention de spécification: même une spécification peut être défectueuse.
En dehors de bug/tâche/ticket/défaut/problème/quelque soit l'instance du système de suivi, ces mots n'ont pas de signification exacte et donc discuter de la différence entre eux est inutile. Lorsque vous définissez votre flux de travail, vous devez définir la terminologie et fournir des descriptions.
Dans mon environnement actuel, un "défaut" est n'importe quel élément de Jira. On dirait que Jira lui-même utilise le terme "problème". Nous l'avons peut-être hérité d'un système antérieur. "Bug" est un type de problème lorsque quelque chose ne fonctionne pas comme prévu et décrit dans la documentation. "Demande de fonctionnalité" lorsque quelque chose fonctionne comme prévu mais qu'une amélioration est souhaitée (cela peut être évident et important, mais si le comportement actuel est décrit, il s'agit toujours d'une demande de fonctionnalité). Il y a plus de types mais ces 2 sont utilisés par des personnes extérieures à l'équipe de développement pour leur demander quelque chose.
Si vous choisissez des noms pour les types de problèmes, "bug" et "défaut" sonnent comme moi. La différence entre eux est stylistique. Comme l'anglais n'est pas ma langue maternelle, je ne peux pas vraiment en voir beaucoup et je ne sais pas si ce que je vois est correct.
La différence est que le terme "bug" semble magique. Comme si un programme pouvait contenir des bogues au hasard une fois la programmation terminée. S'il contient des bogues aléatoires, cela signifie que vous n'êtes pas conforme aux spécifications et que votre programme est en erreur.
Un défaut signifie une erreur où le programme n'est pas conforme aux spécifications. Ceci est plus grave et dit essentiellement, tout l'erreur est un problème énorme avec le programme et cela signifie que le programme n'est pas apte à être publié.
La différence réside dans l'attitude des programmeurs qui utilisent les termes. Il y a des millions de programmes qui sont publiés avec des bogues et les gens sont d'accord avec cela parce qu'ils acceptent pour une raison quelconque qu'un bogue est magique et aléatoire et que chaque programme contient au moins un bogue. Cependant, un programmeur qui utilise le terme "défaut" peut devenir mal à l'aise de publier un programme présentant un défaut car le terme implique une gravité plus importante.
Les implications de préférer un terme à l'autre nous affectent quotidiennement.