Les bogues fonctionnels sont liés à la fonctionnalité d'un élément logiciel. Exemples : Un bouton ne soumet pas le formulaire, la recherche ne réagit pas à la saisie utilisateur, l'application plante. Chaque fois que tu effectues une action et que le site web/l'application ne répond pas comme tu t'y attendais, cela pourrait être un problème fonctionnel. Nos informations limitées sur les produits de nos clients et le manque de connaissance de leurs implémentations rendent difficile de déterminer si un comportement observé est intentionnel ou réellement un bogue. Faire des suppositions éclairées basées sur l'expérience et analyser le comportement du produit en testant différents scénarios peut t'aider à trouver une réponse.
Comment déterminer si le comportement d'une application est un bogue fonctionnel:
Essaie de déterminer si une fonctionnalité est conçue d'une manière particulière ou si elle est réellement cassée. Teste-la seule et en combinaison avec d'autres fonctionnalités pour repérer d'éventuelles différences.
Réfléchis à ce que pourraient être les intentions du client et considère que le produit pourrait simplement fonctionner comme il a été implémenté.
Trouve des preuves que quelque chose ne fonctionne pas comme il le devrait. Étaie ton affirmation.
Exemple: Une fonctionnalité de boutique en ligne fonctionne différemment que dans d'autres boutiques en ligne que tu connais. Cela ne signifie pas que la fonctionnalité est cassée. Le client peut implémenter son produit comme il le souhaite.
Exemple: Tu prétends qu'un champ de formulaire n'est pas validé et que c'est un bogue. Y a-t-il une indication qu'ils avaient l'intention que le champ soit validé ? Fournis des preuves en montrant que le champ est validé dans certains cas mais pas dans d'autres. Si tu ne fournis pas de preuve, c'est une affirmation non prouvée.
Un problème visuel ou de contenu devient un problème fonctionnel quand il entrave une fonctionnalité et doit donc être signalé comme un bogue fonctionnel.
Un élément de fonctionnalité fonctionne de manière cohérente de la même façon dans différents scénarios et sans problèmes évidents? Alors c'est probablement intentionnel (pas un bogue) et tu suggères juste un changement (suggestion d'utilisabilité).
Évaluation de la gravité
Lors de l'évaluation du niveau de gravité fonctionnelle d'un bogue, plusieurs facteurs doivent être considérés : l'impact fonctionnel du problème, l'étendue du problème, l'existence de solutions de contournement ou s'il s'agit d'un obstacle majeur, s'il y a des pertes potentielles et notables de ventes, et si tu peux comparer ce bogue à d'autres bogues de même gravité.
Une approche directe est de regarder l'impact fonctionnel du bogue. Pense à quel point il est grave qu'une fonction ne soit pas disponible. Une fonctionnalité subordonnée ne bloquera pas les utilisateurs dans la poursuite de leur objectif – contrairement à une fonctionnalité principale cassée. Demande-toi à quel point cette fonctionnalité est pertinente dans le contexte de l'ensemble du produit.
La question de combien de personnes, produits ou éléments sont affectés par un problème fonctionnel est un facteur déterminant pour l'étendue d'un problème. Est-ce que, par exemple, le bouton "Ajouter au Panier" ne réagit pas sur toutes les pages de détails de produits d'une boutique en ligne ou seulement sur une en particulier? Est-ce qu'un petit groupe d'utilisateurs est concerné par le problème, ou tout le monde?
Considère si tu peux atteindre ton objectif via une route ou une option alternative ou si un élément de fonctionnalité reste indisponible. Quand tu trouves intuitivement et facilement un moyen de contourner un bogue, cette solution de contournement t'permet encore d'atteindre ton objectif. Un bogue avec une solution de contournement reçoit un niveau de gravité plus bas qu'un bogue équivalent sans solution de contournement. Enfin, quand il n'y a pas de solution de contournement pour une fonctionnalité principale cassée, c'est un obstacle majeur.
Estimer une perte potentielle de ventes est une approche secondaire car tu ne peux souvent qu'assumer comment les gens pourraient réagir à un bogue. Néanmoins, prends en compte à quel point une perte potentielle est élevée. Cela fait une énorme différence si le prix d'un produit diffère de centimes ou de centaines de dollars.
Après tout, tu peux aussi comparer ton bogue à ceux que le même chef d'équipe a déjà approuvés dans ce test afin de découvrir si ton niveau de gravité est approprié.
Nous avons trois niveaux de gravité pour les bogues fonctionnels:
Faible:
Impact minimal sur l'utilisation du produit.
Le produit montre un comportement non intentionnel, mais l'utilisation générale n'est pas affectée.
Peu d'utilisateurs, de produits ou d'éléments sont concernés.
Une fonctionnalité est cassée ou indisponible, mais une solution de contournement facile résout le problème.
Élevé:
Impact sérieux sur l'utilisation du produit, mais la fonctionnalité principale est intacte.
Un grand nombre d'utilisateurs, de produits ou d'éléments est concerné.
Une fonctionnalité non triviale est cassée ou indisponible et aucune solution de contournement n'existe.
Une fonctionnalité importante est cassée ou indisponible mais une solution de contournement existe (donc pas un obstacle majeur).
Critique:
Le bogue empêche la fonctionnalité centrale de l'application ou du site web.
Un obstacle majeur empêche l'utilisateur de continuer un processus principal, par exemple le processus de commande.
Le bogue cause une perte potentielle et notable de ventes pour l'entreprise qui gère l'application ou le site web.
Évaluations communes
Nous avons une liste de cas qui ont des niveaux de gravité fixes. Le schéma d'évaluation ci-dessus ne s'applique pas aux cas sur cette liste. Comme la liste sera mise à jour au fil du temps, vérifie-la régulièrement.
Bogues de cas limites
Les bogues de cas limites se produisent quand un élément de fonctionnalité est utilisé d'une manière inhabituelle. La fonctionnalité n'est pas cassée quand elle est utilisée avec des données typiques et des actions utilisateur typiques. Voici quelques exemples:
Actions instantanées, comme minimiser une application après avoir cliqué sur un bouton
Faire répétitivement la même chose, par exemple ouvrir et fermer des menus
Tout bogue qui ne se produit qu'après un ensemble d'actions peu communes
Chaque cas doit être évalué séparément. Les bogues de cas limités qui sont pertinents pour nos clients sont transmis comme bogues Faibles. Les cas non pertinents, qui représentent la plupart des bogues de cas limites, seront rejetés.
Bogues forcés
Forcer un bogue par un comportement non typique ou des conditions spéciales est généralement hors périmètre car de tels bogues ne sont pas pertinents pour nos clients. Un comportement non typique ne reflète pas un comportement utilisateur normal. Exemples de comportement non typique ou conditions spéciales:
Taper sur plusieurs éléments en même temps
Appui aléatoire sur des boutons
Clic rapide sur un bouton plusieurs fois
Réduire la taille de ta fenêtre à des tailles non typiques
RAM complète ou mémoire interne menant à un comportement inattendu
Utiliser des versions OS non officielles, bêta ou modifiées