Les bogues fonctionnels sont liés à la fonctionnalité d'un logiciel. Par exemple, un bouton qui ne soumet pas le formulaire, une fonction de recherche qui ne réagit pas à l'entrée de l'utilisateur, ou encore une application qui plante. Chaque fois que vous effectuez une action et que le site Web ou l'application ne répond pas comme prévu, il peut s'agir d'un problème fonctionnel. Étant donné que nous avons des informations limitées sur les produits de nos clients et que nous ne connaissons pas nécessairement toutes leurs implémentations, il peut être difficile de déterminer si un comportement observé est intentionnel ou s'il s'agit réellement d'un bogue. Faire des suppositions éclairées basées sur l'expérience et analyser le comportement du produit en testant différentes situations peut vous aider à obtenir une réponse.
Comment déterminer si le comportement constaté est un bogue fonctionnel:
Essayez de comprendre si une fonctionnalité est conçue d'une certaine manière ou si elle est réellement défectueuse. Testez-la seule et en combinaison avec d'autres fonctionnalités pour repérer d'éventuelles différences.
Pensez aux intentions du client et considérez que le produit peut fonctionner de la manière dont il a été implémenté.
Trouvez des preuves montrant que quelque chose ne fonctionne pas correctement et étayez votre réclamation.
Exemple: La fonctionnalité d'une boutique en ligne fonctionne différemment des autres boutiques en ligne que vous connaissez. Cela ne signifie pas nécessairement que la fonctionnalité est défectueuse. Les clients peuvent implémenter leurs produits comme bon leur semble.
Exemple : Si vous affirmez qu'un champ de formulaire n'est pas validé et que c'est un bogue, assurez-vous qu'il y a une indication de validation prévue pour ce champ. Vous pouvez fournir cette preuve en montrant qu'il est validé dans certains cas mais pas dans d'autres. Sans preuve, la réclamation est infondée.
Un problème visuel ou de contenu devient un problème fonctionnel lorsqu'il entrave une fonctionnalité et doit donc être signalé comme un bogue fonctionnel.
Si une fonctionnalité fonctionne de manière cohérente dans différents scénarios sans problèmes évidents, elle est probablement prévue (et non un bogue) et vous proposez simplement une modification (une suggestion d'utilisabilité).
Évaluation de la gravité
Lors de l'évaluation de la gravité fonctionnelle d'un bogue, plusieurs facteurs doivent être pris en compte : l'impact fonctionnel du problème, l'étendue du problème, l'existence de solutions de contournement, s'il s'agit d'un blocage, la possibilité de pertes potentielles de ventes notables, et la comparaison de ce bogue avec d'autres bogues de même gravité.
Une approche directe consiste à examiner l'impact fonctionnel du bogue. Réfléchissez à quel point il est grave qu'une fonction ne soit pas disponible. Les fonctionnalités secondaires ne bloqueront pas nécessairement les utilisateurs dans la poursuite de leur objectif, contrairement à une fonctionnalité principale défectueuse. Posez-vous la question de la pertinence de cette fonctionnalité dans le contexte global du produit.
La question de savoir combien de personnes, de produits ou d'éléments sont affectés par un problème fonctionnel est un facteur déterminant pour l'étendue du problème. Par exemple, le bouton "Ajouter au panier" ne réagit-il pas sur toutes les pages de détail de produit d'une boutique en ligne, ou uniquement sur certaines? Un petit groupe d'utilisateurs est-il concerné par le problème, ou tout le monde?
Pensez à la possibilité d'atteindre votre objectif par un autre chemin ou une autre option, ou si une fonctionnalité reste indisponible. Lorsque vous trouvez intuitivement et facilement un moyen de contourner un bogue, ce contournement permet toujours d'atteindre votre objectif. Un bogue avec un contournement reçoit un niveau de gravité inférieur à un bogue équivalent sans contournement. Enfin, lorsqu'il n'y a pas de contournement pour une fonctionnalité principale défectueuse, c'est un blocage.
L'estimation d'une perte potentielle de ventes est une approche secondaire car vous ne pouvez souvent que supposer comment les gens réagiront à un bogue. Néanmoins, prenez en compte l'ampleur potentielle de la perte. Cela fait une grande différence si le prix d'un produit diffère de quelques cents ou de plusieurs centaines de dollars.
En fin de compte, vous pouvez également comparer votre bogue à ceux que le mêmeChef d'Équipe ("Team Leader") a déjà approuvés dans ce test afin de déterminer si votre niveau de gravité est approprié.
Nous avons trois niveaux de gravité pour les bogues fonctionnels:
Faible:
Le produit présente un comportement non intentionnel, mais l'utilisation générale n'est pas affectée.
Peu d'utilisateurs, de produits ou d'articles sont concernés.
Une fonctionnalité/un élément est défectueux ou indisponible, mais un contournement facile résout le problème.
Élevé:
Impact grave sur l'utilisation du produit, mais la fonctionnalité principale est intacte.
Un grand nombre d'utilisateurs, de produits ou d'articles sont concernés.
Une fonctionnalité non triviale est défectueuse ou indisponible, et aucun contournement n'existe pas.
Une fonctionnalité importante est défectueuse ou indisponible, mais un contournement existe (donc ce n'est pas un problème bloquant).
Critique:
Le bogue empêche la fonctionnalité essentielle de l'application/site web.
Un problème bloquant empêche l'utilisateur de poursuivre le processus principal, par exemple, le processus de paiement.
Le bogue entraîne une perte potentielle et notable de ventes pour le client.
Évaluations courantes
Nous disposons d'une liste de cas avec des niveaux de gravité prédéfinis. Le schéma d'évaluation mentionné précédemment ne s'applique pas à ces cas. Étant donné que cette liste sera régulièrement mise à jour, nous vous encourageons à la consulter fréquemment.
Bogues de cas limite
Les bogues de cas limite surviennent lorsqu'une fonctionnalité est utilisée de manière inhabituelle. La fonctionnalité n'est pas défectueuse lorsqu'elle est utilisée avec des données et des actions d'utilisateur typiques. Voici quelques exemples:
Actions instantanées, telles que la réduction d'une application après avoir cliqué sur un bouton.
Répétition de la même action, par exemple ouvrir et fermer des menus.
Tout bogue qui ne survient qu'après une série d'actions inhabituelles.
Chaque cas doit être évalué séparément. Les bogues de cas particuliers qui sont pertinents pour nos clients sont transmis en tant que bogues de faible gravité. Les cas non pertinents, qui représentent la plupart des bogues de cas particuliers, seront rejetés.
Bogues forcés
Forcer un bogue par un comportement non typique ou des conditions spéciales est généralement hors du champ d'application, car de tels bogues ne sont pas pertinents pour nos clients. Le comportement non typique ne reflète pas le comportement normal de l'utilisateur. Exemples de comportement non typique ou de conditions spéciales :
Appuyer sur plusieurs éléments en même temps.
Appuyer de manière aléatoire sur un bouton.
Cliquer rapidement plusieurs fois sur un bouton.
Réduire la taille de votre fenêtre à des tailles non typiques.
Utilisation de versions non officielles, bêta ou modifiées du système d'exploitation.
Une mémoire RAM ou une mémoire interne pleine entraînant un comportement inattendu.