Se servir des anomalies pour établir sa stratégie de test

Les anomalies sont une mine de connaissance sur le logiciel. Néanmoins, comme toute mine il faut arriver à extraire ce qu’elle contient.

Pour se servir des anomalies il faut être capable de les classer :

Pour cela il y a 2 possibilités :

–         Faire tout manuellement… Ce qui est très compliqué

–         S’aider de la puissance des ALM en ajoutant des informations dans ces anomalies.

Grâce aux ALM on peut faire beaucoup de liens et en tirer des informations. On peut relier des anomalies à leur type comme fait dans le schéma ci-dessous :

Vous noterez que les anomalies fonctionnelles ne sont qu’une petite partie des anomalies possibles.

Il est également important que toutes les personnes engagées dans le projet jouent le jeu et remplissent correctement ces données. Cela fait donc, à court terme, un travail supplémentaire pour les équipes de support.

N’hésitez pas à consulter le glossaire ISTQB si vous voulez savoir à quoi correspondent certains termes.

Il est évidemment possible d’avoir moins, d’autres ou plus de types d’anomalies.

Après le classement vient l’utilisation des données !

Lorsque cela est fait on peut facilement (à l’aide de tri ou d’une BI) savoir quels sont, en fonction de leur criticité les anomalies remontées sur notre application.

Ces anomalies sont-elles concentrées sur des problèmes fonctionnels, des problèmes de portabilités ou de maintenabilité ?

Dans le cas où les anomalies sont principalement des problèmes de portabilité, il est inutile de multiplier les tests fonctionnels mais il faudrait plutôt accentuer ses tests sur une multiplication des environnements de tests. Si on travaille sur une application mobile cela peut revenir à multiplier les mobiles de test, par exemple en faisant appel à une ferme de mobiles.

Par contre, si les anomalies, toujours sur la même application sont des défauts liés à l’efficacité, multiplier les mobiles ne sera pas particulièrement efficace. Mettre en place des campagnes de test sur les performances de l’application, avec des KPI bien définis sera beaucoup plus efficace.

Toutes ces informations sont accessibles dès lors où elles sont convenablement remplies. Il est alors beaucoup plus simple, à l’aide de ces précieuses données que seul les testeurs peuvent fournir, d’établir une stratégie axée sur les faiblesses de l’application et donc sur les risques avérés et objectifs.

On peut alors, lors du lancement d’une nouvelle version :

–         Exécuter les tests de régression et des tests exploratoires ciblés sur les points faibles de l’application

–         Concevoir des tests pour compléter les campagnes

–         Prioriser différemment les tests

Conclusion :

Il ne faut jamais perdre de vue que le but des tests c’est d’avoir une visibilité sur la qualité de l’application (donner un indice de confiance) et que cette visibilité doit être donné dans un temps et un budget imparti.

Lorsque l’on teste une partie du logiciel c’est toujours au détriment d’une autre. Dès lors, connaitre les points faibles de l’application permet d’améliorer cette efficacité.

Enfin, cette visibilité sur les points faibles de l’application, ne peut être fournie que par les testeurs. C’est une plus-value du métier mais elle est encore trop peu utilisée.

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