Comment remonter une anomalie ?

La remontée d’une anomalie, suite à des campagnes de tests sur des sites ou applications, doit être codifiée avec précision. Au-delà de la nécessaire utilisation d’un bugtracker pour gérer les relations entre éditeur, développeur et testeur, de bonnes pratiques sont à mettre en œuvre pour faciliter le travail et les correctifs à effectuer. Explications.

Si mener des campagnes de tests pour des sites ou des applications est un impératif, il ne faut ensuite pas oublier d’accorder toute son importance à la remontée des anomalies auprès des développeurs et de l’éditeur. Il convient donc tout d’abord de définir les rôles et missions de chacun avant d’exécuter le plan de tests, pour faciliter les échanges et être réactif.

La « To do list » reflet du plan de tests

Si toutes les anomalies rencontrées sont répertoriées et décrites dans le bug tracker du client, il convient préalablement de détailler, lors de la conception du plan de tests du site ou de l’application, les niveaux de criticité.

Ensuite, muni, d’un côté, du plan de tests (référençant les différents cas de tests à réaliser : tests fonctionnels, de bout en bout, fonctionnels GUI, de non-régression, etc.) et, de l’autre, d’une liste établissant clairement la typologie des anomalies et le traitement dont elles devront faire l’objet selon leur criticité, les différents intervenants disposent d’une « to do list«  opérationnelle.

Définir la criticité des anomalies !

Cette liste typologique des anomalies est un véritable glossaire, permettant de générer des alertes dans les cas les plus sérieux. Dans cette liste on peut noter :

• Les anomalies critiques : elles affectent la disponibilité, la conformité ou l’intégrité du site ou de l’application et des données qu’ils gèrent. Elles peuvent provoquer l’arrêt ou l’indisponibilité du support digital, rendant indisponible certaines fonctionnalités importantes du système ou produisant un résultat erroné pour au moins une des fonctions importantes.
• Les anomalies majeures: elles affectent la conformité ou la confidentialité du support digital ou des données qu’il gère (en restituant des données erronées par exemple). Elles peuvent également altérer l’utilisation des fonctionnalités du point de vue de l’utilisateur (en dehors des éléments ergonomiques, graphiques ou éditoriaux), ou produire un résultat erroné rendant une fonctionnalité indisponible.
• Les anomalies mineures qui, en dehors des deux précédentes catégories, affectent la conformité du support digital dans ses composantes mineures (fonctionnement dégradé sur des aspects ergonomiques, graphiques ou éditoriaux), sans entacher de manière significative le bon fonctionnement d’une fonctionnalité.

Préciser les conditions d’arrêts des tests

Les éléments préalablement décrits constituent la base permettant de gérer les remontées d’anomalies. Cependant, il convient aussi de préciser et de s’accorder sur les critères d’arrêts du plan de tests. Car, dans le cas de la survenue d’une anomalie majeure, il peut être inutile de poursuivre la campagne, mieux vaut en ce cas la mettre en standby. Ces critères d’arrêts peuvent être :

• Les plateformes, environnements, réseaux ne sont pas disponibles.
• L’atteinte d’une anomalie bloquante nécessitant d’être corrigée avant de poursuivre le plan de tests.
• Le trop grand nombre d’anomalies détectées. Par exemple, chez Testing Digital si nous détectons plus de 20 % d’anomalie au niveau des cas de tests, nous stoppons la campagne en attendant une livraison plus stable.
• La non disponibilités des jeux de données…

Rédiger le rapport de fin d ‘activité

Bien évidemment, en fin de période de tests un rapport d’activité devra reprendre l’ensemble des informations clés de la recette du site ou de l’application. Elle devra lister les anomalies détectées, leur criticité, la qualité de la livraison, en mentionnant les correctifs apportés ou non pour chacun des bugs identifiés.

À lire également | Bug tracker : 8 outils à connaître