« Les » couvertures de test

J’ai il y a longtemps écrit un article sur les couvertures de test. Honnêtement je trouve cet article trop incomplet pour pouvoir être le seul présentant les couvertures de test. Il a néanmoins l’avantage de montrer qu’une couverture de 100% ne veut rien dire, comme je l’ai écrit dans mon récent « coup de gueule« .

Je tiens également à vous conseiller l’excellente série de Benjamin Butel sur la conception des cas de test que vous trouverez ici. Benjamin décrit et explique différentes manières de concevoir des tests à partir de spécifications ainsi que la couverture qui leur est liée!

Définition de la couverture

La définition ISTQB est celle-ci: le degré, exprimé en pourcentage, selon lequel un élément de couverture spécifié a été exécuté lors d’une suite de test.

De mon point de vue, le principal intérêt de cette définition est bien qu’elle montre qu’une couverture se définit toujours en fonction d’un élément bien définit. De plus une couverture se mesure en pourcentage.

De même, cette définition montre également à quel point le concept de couverture est large. Une couverture peut donc inclure énormément de concepts… la seule limite reste donc notre imagination… Et notre capacité à bien faire coprendre l’intérêt de la couverture choisie.

Exemples de couverture:

Parmi les couvertures il y a évidemment les plus classiques déjà décrites dans les différents articles de la taverne:

• La couverture des méthodes (que l’on peut rapprocher d’une couverture des fonctionnalités): mesure un % de fonctionnalités couvertes par au moins un test ors de la campagne
• La couverture des instructions: mesure un % de la couverture des ligne de codes parcourus par les tests de la campagne.
• La couverture de branches (souvent fusionné avec la couverture des décisions): mesure un % de transitions parcourues par les tests de la campagne. Cette couverture est plus complète que la couverture des instructions
• La couverture des chemins d’exécution: c’est pour moi une couverture impossible à mesurer car serait sur l’ensemble des parcours possibles.
• La couvertures des partitions d’équivalence: mesure un % des partitions d’équivalence couvertes par au moins 1 test.
• La couverture des valeurs limites: mesure un % des valeurs limites des partitions d’équivalence parcourues par au moins 1 test
• La couverture des tables de décision: mesure un % des tables de décisions et donc des combinaisons possibles de valeurs.
• Les couvertures de l’ensemble des techniques de conceptions liées aux spécifications…

Mais il est également possible d’imaginer des couvertures totalement différentes. Je pense notamment à:

• Une couverture des risques identifiés par les différents acteurs (par exemple avec un plan de test): mesure un % des risques identifiés couverts par au moins 1 test. On peut également imaginer aller plus loin en proposant une couverture des risques liés à la criticité des risques
• Une couverture des anomalies: mesure un % des anomalies détectées vérifiées par au moins 1 test. Là encore il est possible de lier cela à la criticité des anomalies
• Une couverture des terminaux: mesure un % de terminaux utilisés lors d’au moins 1 test (peut être imaginé en fonction du périmètre définit des terminaux ou du parc possible)
• Une couverture des types de connexion: mesure un % de conditions de connexion utilisées lors d’au moins 1 test
• Une couverture des langues: mesure un % de langues proposées par le logiciel couvertes par les tests (potentiellement intéressant pour des logiciels internationaux)
• Une couverture des Personae: mesure un % de Personae (utilisateur « type ») faisant l’objet d’au moins 1 test
• Toute autre couverture qui aurait du sens en fonction du contexte.

Conclusion

Le principe de couverture est particulièrement intéressant et peut s’avérer particulièrement utile, je le vois personnellement comme un indicateur. Néanmoins le concept de couverture en lui même, tout comme le concept d’indicateurs, est très vaste. Les couvertures se définissant par rapport à un concept ou une technique il est essentiel de bien définir ce qu’elles calculent. De même, au delà de la définition l’intérêt d’une couverture dépend fortement du contexte, il faut donc savoir adapter la/les couverture(s) utilisées en fonction des ses besoins en information. Avoir une couverture des méthodes est inutile lorsque l’on doit tester une fonctionnalité spécifique en profondeur. Cette couverture peut cependant être particulièrement intéressante dans le cadre d’une campagne de tests vitaux.

Au final, les couvertures restent des outils de mesure. Ces outils de mesures permettent d’avoir des informations. Afin d’avoir des informations appropriées il est nécessaire de définir l’information que l’on souhaite, connaitre son besoin. C’est uniquement lorsque le besoin sera identifié qu’il sera possible d’utiliser la/les couverture(s) correspondant le mieux à notre besoin…

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.