La taverne du testeur

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 :

anomalies-ISO.png

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

3 réponses

  1. Questions peut être un peu bête mais je n’ai pas un grande culture des outils, peux-tu fournir quelques références d’ALM qui font ça ou que tu préconiserais?

    1. Bonjour,
      Xstudio, Refertest, HP ALM que je connais gèrent les anomalies.
      De même QA Complete et si je ne me trompe pas Spira et Squash TM le propose aussi.
      Sinon, il existe des logiciels spécialisés dans la gestion d’anomalie comme Mantis.
      Chaque outil a des points forts et faibles.

      1. Je suppose que le plus gros travail est la contrainte du classement (mis en place et abandonné plusieurs fois chez nous 😉 )..mais un outil qui retournerait aussi les termes les plus employés pourrait permettre d’affiner ou confirmer les tendances.
        Dans tous les cas c’est clairement une bonne optique de concentrer ou cibler ses efforts sur les parties qu’on sait fragiles.
        Merci pour la liste 🙂

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

culture générale

A la recherche de la qualité perdue: les plages de velours et les rocks éternels

Rappels des chapitres précédents L’application « New Soft » autrefois reconnue pour sa grande qualité n’est maintenant plus que l’ombre d’elle même et est envahie de bugs. Afin de retrouver la qualité perdue les représentants de l’application on nommé une communauté (les fameux Antoine le Berserker (surnommé BA), Délphine la Valkyrie (surnommée

Lire la suite »
culture générale

Duel: vocabulaire ISTQB vs vie réelle

Attention, cet article ne fait pas le tour de tous les éléments liés au vocabulaire de l’ISTQB mais uniquement les éléments partant de la politiques de tests et allant jusqu’à la campagne de test. Intro Un des objectifs de l’ISTQB est d’harmoniser les termes liés au test. Si cela fonctionne

Lire la suite »
Agilité

Fiche métier: Testeur Agile (réflexion)

Dans mon article sur les évolutions dans les métiers du test, je n’utilise que des fiches métiers CFTL à l’exception du métier « Testeur Agile ». Si j’ai mis ce métier à part c’est justement parce qu’il a certaine particularité. Je me suis donc essayé à l’exercice de construire une fiche métier

Lire la suite »