Petits et Gros bugs: Leurs rôles dans votre projet de site web

Cependant, tous les bugs ne sont pas tous nocifs également. Certains bugs peuvent être simplement de petites piqûres, presque indécelables dans le travail de votre site Web. D’autres bugs sont capables de mordre et de grignoter une part importante du succès de votre entreprise. Examinons de plus près la façon dont les bugs se différencient par leur importance dans les pratiques d’assurance de la qualité, pourquoi ils ne sont pas toujours évidents et ce que l’on fait habituellement à leur sujet.

Bugs dans le développement web: des plus grands aux plus petits

Habituellement, les bugs sont classés selon deux aspects: leur gravité et la priorité de leur correction. La gravité est le degré de leur effet négatif sur le fonctionnement du site web. La priorité est l’ordre dans lequel les bugs doivent être corrigés. Regardons de plus près. 

1) Bugs par Gravité

Cela peut varier selon les organisations ou les projets, mais la gradation de gravité la plus largement acceptée va de «Critique» à «Mineure». Beaucoup utilisent également un degré «Bloqueur» supplémentaire, ce qui signifie que les tests sont impossibles.

• Bugs critiques (S1): Le bug bloque des fonctionnalités critiques ou provoque même la défaillance d’un site Web. Il n’y a aucun moyen de contourner ce bug.
• Bugs majeurs (S2): Le bug entrave des fonctionnalités moins critiques mais importantes et il existe quelques moyens de les contourner.
• Bugs mineurs (S3): Le bug affecte les fonctionnalités mineures et il est facile à contourner.
• Bugs triviaux (S4): Le bug ne touche aucune fonctionnalité mais présente quelques inconvénients.

2) Bugs par Priorité

La priorité des corrections de bugs varie de cette manière:

• Haute: Le bug doit être corrigé dès que possible.
• Moyen: La correction du bug peut attendre un court instant.
• Faible: La correction du bug peut attendre plus longtemps.

De nombreux ingénieurs d’assurance qualité utilisent également un niveau de priorité supplémentaire; « Immédiat ».

Gravité du bug Vs Priorité du bug

À première vue, il semble que la gravité soit la priorité. Cependant, ils ne sont pas interchangeables.

La gravité est déterminée par un ingénieur en assurance qualité et constitue un facteur plus objectif. La gravité du bug a des explications techniques claires. Elle est guidée par des normes de développement et/ou des aspects évidents du comportement du site Web.

La priorité revient au propriétaire du produit ou au chef de projet. C’est une définition hautement subjective et elle est souvent liée aux circonstances actuelles, au budget du projet, aux exigences et aux attentes des clients.

Prenons un exemple: une page Web a une faute de frappe. Objectivement, c’est un bug mineur. Cependant, le client donne une présentation sur le site le lendemain. Dans ce cas, un bug mineur doit être corrigé dès que possible. Cela illustre bien la différence entre gravité et priorité.

Un exemple opposé pourrait être un bug critique dans la fonctionnalité de paiement. C’est grave, mais cela n’apparaît pas dans les calendriers des développeurs simplement parce que les fonctionnalités de paiement de ce site Web ne sont pas encore en production.

Les petits bugs doivent-ils toujours être corrigés ?

Il y a aussi un autre aspect à étudier concernant les petits bugs. Il peut arriver que réparer un petit bug entrave certaines fonctionnalités importantes. L’opinion sur les petits bugs divise les ingénieurs d’assurance qualité en perfectionnistes et rationalistes.

Les premiers insistent pour réparer les plus infimes bugs en toutes circonstances. Les autres décident qu’il vaut mieux ne pas les toucher à certains moments. En fin de compte, c’est souvent le client a le dernier mot.

En tout état de cause, il est connu en matière d’assurance qualité que «combattre le mal» est plus efficace quand il est petit. Plus tôt un bug est corrigé, moins il peut causer de dommages et moins il peut coûter cher de le réparer.

Pour finir

Les subtilités des bugs et leur influence sur le projet sont au cœur de la vie des ingénieurs QA. L’expérience et l’intuition professionnelle les aident à déterminer la gravité du bug et à conseiller les responsables et les clients sur la priorité du bug.
Maintenant vous comprendrez pourquoi il arrive très souvent qu’un client ne comprends pas pourquoi un développeur ne s’occupe pas rapidement d’un bug qu’il trouve important, c’est justement car il y a une mauvaise compréhension de ces deux notions différentes de gravité et de priorité.

Au final une bonne communication entre les deux parties peut dissiper tous désaccords à ce sujet, la finalité des deux parties est commune.

Et vous ? Qu’en pensez-vous ?