Ces 2 concepts sont souvent confondus. Il existe néanmoins des différences importantes entre ces 2 notions.
Lorsque l’on découvre un bug et que l’on créé ce dernier il existe généralement 2 champs qui sont les champs Criticité et Priorité.
La criticité propose 3 ou 4 champs. J’utilise généralement mineur, majeur et critique.
La priorité quant à elle propose généralement aussi 3 ou 4 champs. Prenons P1, P2, P3 par ordre de priorité.
La criticité :
Pour rappel, la criticité s’évalue grâce à un tableau semblable à celui ci-dessous (plus d’informations sur ce lien) :
· Une criticité Mineure correspond à un bug peu gênant pour l’application et ses utilisateurs et facilement contournable
· Une criticité Majeure correspond à un bug plus important, détériorant significativement l’utilisation de l’application sans la bloquer complètement
· Une criticité Critique quant à elle correspond à un bug bloquant totalement l’utilisation de l’application ou d’une de ses fonctionnalités importante.
La criticité évalue donc l’impact sur l’application.
La priorité :
La priorité s’évalue sur d’autres critères. Le critère principal est un critère marketing et/ou de rentabilité. Quel est l’impact « financier » de ce bug.
· Une priorité P1 correspond à un bug qui doit être corrigé le plus rapidement possible (à la prochaine release ou même faire une release spécialement pour le corriger)
· Une priorité P2 correspond à un bug qui doit être corrigé mais qui peut attendre une nouvelle version mineure.
· Une priorité P3 correspond quant à elle à un bug qui doit être corrigé mais qui peut attendre une nouvelle version majeure. Potentiellement cela peut être un bug qui ne sera jamais corrigé.
La priorité indique quand le bug doit être corrigé (ou une fonctionnalité implémentée, la priorité n’est pas liée aux défauts)
La corrélation entre la priorité et la criticité :
Bien évidemment, un bug critique est quasiment tout le temps associé à une priorité P1 et un bug majeur quasiment jamais à un P3 (ou alors sa criticité doit être réévaluée).
Par contre, il est possible qu’un bug mineur est une priorité P3, P2 voir P1. De même un bug majeur peut avoir une priorité P2 ou P1. Un bug mineur peut donc avoir une priorité supérieure au bug majeur.
La raison ? Elle est simple, l’impact sur l’application n’est pas forcément l’impact sur les revenus (ou l’image) de celle-ci !
Voici 1 exemple pour vous convaincre :
Comparaison avec une maison
Date : Mai 20XX
Bug 1 : Problème d’isolation dans la maison.
Bug 2 : Un gros Tag sur la porte d’entrée.
Le Bug 1 est majeur. Il doit être corrigé avant le prochain hiver (novembre) afin de ne pas avoir froid dans la maison. Sa priorité n’est donc pas urgente (ne doit pas forcément être réparé dans la semaine ou le mois) et peut être décalée de quelques mois. Si l’on était en septembre la priorité serait évidemment autre.
Le bug 2 est mineur (cela n’affecte aucunement l’intégrité de la maison ni de ses habitants). Par contre la porte d’entrée est la « vitrine » de la maison et on ne peut se satisfaire de la voir à chaque fois que l’on rentre chez soi ou que l’on reçoit des invités. Il est donc urgent de réparer ce bug. Dans ce cas-là la priorité est P1.
Nous avons donc :
· Le Bug 1 Majeur, priorité P2.
· Le Bug 2 Mineur, priorité P1.
Et donc bien un bug mineur plus prioritaire qu’un bug majeur.
Dans la vie de tous les jours, on cache rapidement un tag à l’aide de peinture et on fait faire des devis pour l’isolation avant d’en valider un et de faire les travaux.
Article intéressant sur le sujet.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
5 Responses
C’est du top la différence est claire.
Merci beaucoup
Ah… Malheureusement, pour avoir ete en contact avec les gens qui payent pour utiliser l application, et qui du coup payent le salaire des testeurs (je sais, c est sale, mais c est la verite), c est beaucoup plus complexe, surtout la criticite
– Un trou de sécurité ou une non conformité légale ne bloque personne, mais c est majeur
– Un bug qui bloque totalement la nouvelle fonctionnalité qui sort demain matin sur le marché mais ne bloque personne aujourd hui, c est comme le tag sur la porte
– Un bug qui bloque un peu le plus gros client, ou un client qu on signe demain matin, ou un client qui en est a son 50e probleme de la journee est plus important que le bug qui bloque totalement un client mineur
Mais le pire c est quand le bug n est pas un bug car « ca a ete developpé comme ca a été spécifié/designé ». Mais il y a aussi des bugs de design et des fautes/erreurs de spécification ! Il n y a pas que les bug techniques de développement
Cette porte entrouverte est un sujet majeur de conflit entre les testeurs et les parties de l entreprise qui sont en contact avec le marché (support, vente, marketing, finance, …)
Mais je connais aussi la propension inverse de ces derniers a tout considérer comme la priorité majeure, mais a qui ca finalement , dans 20% des cas, n importe plus 2 ou 3 jours apres que le bug soit résolu…
Finalement, c est plus de l humain que du technique…
Bonjour,
merci pour ce commentaire.
Oui, dans les faits le contexte est primordial.
De même, au final c’est plus de l’humain qu’autre chose car l’humain est à l’origine de l’erreur qui engendre un défaut puis potentiellement une anomalie: https://latavernedutesteur.fr/2020/06/15/erreur-defaut-et-defaillance/
Pour tout ce qui est non fonctionnel, cela reste des anomalies/bugs/défaillances qui peuvent s’avérer critique même si cela « ne bloque personne ».
Enfin, une défaillance n’est pas forcément liée au code et son origine encore moins. Les trous ou erreurs dans les expressions de besoin ou les spécifications sont une cause très fréquentes… Ces bugs demeurent néanmoins des défaillances à corriger dont la priorité et la criticité devront être évaluées
Bonjour Marc
D’expérience, le fait d’avoir un nombre de paramètre impair mème à devoir prendre des décisions plus poussées plus tard car les cloches graphiques représentatives sont trop aplaties et larges sur le chiffre du milieu. Il vaut mieux utiliser un nombre pairs de paramètres de décision qu’impairs. 4 est un bon exemple. Les personnes ne donneront pas dans la plus grande partie 2 s’il y a un choix sur 3, ou 3 s’il y en a 5. Lorsqu’il y en a 4 on choisit entre 2 ou 3. C’est mathématique et psychologique.Maintenant effectivement c’est beaucoup plus complexe que cela comme à pu le faire remarquer Gilles VALLI. Il faut donc inclure un paramètre complémentaire ou plus qui rendront parfois une correction prioritaire, comme pour le RBT. De toute façon les bugs ou autre concerné par ce type de concepts ne sont pas regardés que par une personne, mais un ensemble qui donnera son avis, et certainement que d’autres infos seront à utiliser pour mettre une priorité ou une criticité.
Bonjour Lionel
Oui, un paramètre ayant 3 valeurs peut dériver avec une valeur « neutre » (2) fourre-tout.
Avoir 4 valeurs ou un nombre pair est alors plus pertinent.