C’est une constante : toutes les applications comportent des bugs et aucune n’échappe à cette règle. Le but d’une étape d’assurance qualité qualifiée plus vulgairement de tests consiste à identifier un maximum de bugs en vue de leur correction avant la distribution ou la mise en production d’un logiciel. Dans les rapports de bugs signalés par l’équipe d’assurance qualité à l’équipe de développement du logiciel, un paramètre important apparaît : la classe du bug identifié. Si la classification du bug trouvé répond à une certaine part subjective laissée à la discrétion des divers intervenants, on se base généralement sur une base objective pour qualifier les bugs les plus graves des bugs les plus anodins.

Bug de classe A

Description

Crash ou blocage du logiciel empêchant son utilisation.

Priorité

Un bug de classe A doit être corrigé en priorité absolue.

Conséquences

L’application ne peut être distribuée ou mise en production avec même un seul bug de classe A connu.

Exemples

Voici quelques exemples de bugs de classe A :

• dans une calculatrice, plantage suite à la division par zéro ;
• dans un logiciel de dessin, plantage suite à l’ouverture de certains fichiers légitimes ou corrompus ;
• sur un site web, plantage du serveur.

Bug de classe B

Description

Comportement aberrant empêchant le bon fonctionnement des fonctionnalités essentielles de l’application.

Priorité

Un bug de classe B doit être corrigé en priorité.

Conséquences

Les conséquences d’un bug de classe C sont les suivantes :

• l’application ne devrait pas être distribuée ou mise en production même avec un unique bug de classe B connu ;
• l’application ne peut être distribuée avec de nombreux bugs B connus.

Exemples

Voici quelques exemples de bugs de classe B :

• dans un traitement de texte, presser le bouton de justification du paragraphe le recentre, au lieu de le justifier ;
• dans un jeu vidéo de course de voitures, doubler un adversaire ne met pas systématiquement à jour le classement des joueurs, empêchant parfois à tort le joueur de gagner une course ;
• sur une boutique en ligne, la saisie des informations de paiement se fait sur une page web non sécurisée.

Bug de classe C

Description

Comportement inapproprié gênant rendant le fonctionnement des fonctionnalités secondaires de l’application difficile.

Priorité

Un bug de classe C doit être corrigé.

Conséquences

Les conséquences d’un bug de classe C sont les suivantes :

• l’application ne devrait pas être distribuée ou mise en production avec de nombreux bugs de classe C connus ;
• si l’application est distribuée ou mise en production avec des bugs de classe C connus, ceux-ci devraient être corrigés dans les éventuelles futures mises-à-jour de l’application.

Exemples

Voici quelques exemples de bugs de classe C :

• dans un traitement de texte, l’enregistrement du document dans un format communément usité fait perdre l’essentiel de sa mise en page ;
• dans un jeu vidéo, une action simple non initialement prévue permet d’immobiliser les ennemis rendant le jeu trop facile, réduisant ainsi l’essentiel de son intérêt ;
• sur un forum en ligne, une grande quantité de spammeurs inondent les discussions de publicités parasites.

Bug de classe D

Description

Comportement inapproprié peu gênant sans conséquence importante sur le fonctionnement habituel de l’application.

Priorité

Même s’il est préférable de corriger un bug de classe D, un tel bug peut être ignoré.

Conséquences

Les conséquences d’un bug de classe C sont les suivantes :

• l’application ne devrait pas être distribuée ou mise en production avec de très nombreux bugs de classe D connus ;
• si l’application est distribuée ou mise en production avec des bugs de classe D connus, ceux-ci peuvent être corrigés dans les éventuelles futures mises-à-jour de l’application.

Exemples

Voici quelques exemples de bugs de classe D :

• dans un traitement de texte, une erreur d’orthographe dans une boîte de dialogue ;
• dans un jeu vidéo, l’utilisation d’un fond sonore ne correspondant pas à l’action du jeu ;
• sur un site web, le clignotement parasite d’un bouton au survol de la souris.

Remarques

La qualification de la classe d’un bug comporte une part subjective, ce qui permet à certains chefs de projet de déclasser certains bugs en fonction de leurs priorités. Cela arrive notamment dans le cas de bugs de classe B qui sont déclassés en bugs de classe C, de sorte à permettre à une application de sortir dans les délais, quitte à promettre la correction de ces bugs via un patch ultérieur. Il est primordial alors d’accorder un réel pouvoir à l’équipe d’assurance qualité pouvant faire face aux priorités à très court terme d’une équipe de développement pressée d’en finir afin de chasser les bugs les plus gênants d’une application avant sa mise en production, réduisant ainsi le travail de maintenance, toujours plus difficile une fois que le produit est « parti dans la nature ».

Suivant cette classification, il n’est pas rare qu’une application d’une certaine envergure ait jusqu’à plusieurs milliers de bugs identifiés. Jamais tous les bugs connus d’une application ne sont corrigés. En effet, la modification d’un logiciel peut elle-même entraîner l’apparition de nouveaux comportements inattendus. Aussi, il est bon de rester pragmatique et d’accorder toute l’importance aux bugs de classes prioritaires, critiques, quitte à laisser passer des bugs de classes secondaires, accessoires.