A5 Std 982

A5 Std 982.2 Couverture des tests fonctionnels ou modulaires.

Application : « Cette mesure est employée pour quantifier un indice de couverture des tests pour une livraison de logiciel. Les primitives comptées peuvent être des fonctions ou des modules (…) ». La norme met en garde à propos du fait que, souvent, les tests font référence à des exigences système et qu’il s’agit donc de les transformer en exigences logicielles et ensuite en modules. Ce qui veut dire qu’il faut avoir des informations (sous forme de tableaux par exemple) permettant de passer des fonctions aux modules. Puisque les fonctions sont définies dans la SES et que les modules sont définis dans les spécifications de conception il faudra que ces dernières contiennent une mise en correspondance entre fonctions et modules, mise en correspondance qui est souvent une relation de type m-n. Donc, en résumé, pour appliquer cette mesure il faut non seulement qu’un document de conception existe mais qu’il contienne la mise en correspondance avec les fonctions présentées dans une forme facile à modifier. Idéalement dans une BD avec une interface de manipulation facile.

Primitives : « FE = nombre d’exigences fonctionnelles pour lesquelles tous les cas à tester ont été complétés de manière satisfaisante.
FT = nombre total d’exigences fonctionnelles. »
Mise en œuvre : « (…) Indice de couverture des tests fonctionnels (modulaires) = FE / FD. » Comment traiter cet indice ? Quelle interprétation donner aux valeurs obtenues ? Imaginons un cas extrême où il y a une seul exigence fonctionnelle avec un seul cas à tester, on aura donc FE/FD = 1 après avoir passé le seul test existant. Donc afin que cet indice veuille dire quelque chose il faut connaître d’autres éléments. Mais pourquoi l’introduit-on ? La réponse est dans le paragraphe suivant.

Interprétation : « L’indice de couverture des tests peut être comparé avec l’état des tests planifiés et l’impact que les changements fonctionnels ont sur les coûts et l’échéancier. » Donc pour retourner à nos considérations sur les cas extrêmes, cet indice nous dit seulement quel est le pourcentage de travail de test qu’on a fait et il nous donne une indication sur ce qu’il reste à faire mais il nous dit pratiquement rien sur la qualité du produit ou du processus de validation. Note : dans une technique jeune comme celle du GL il est très tentant non seulement de définir de nouvelles mesures pour aspirer à la place du Newton[1] du GL mais aussi d’extrapoler l’interprétation. Ce qui est certain, c’est que personne ne connaît une équation qui, en partant de cet indice, donne quoi que ce soit d’universellement valable !

Considérations : Comment compte-t-on le nombre d’exigences lorsqu’on a des fonctions imbriquées ? Par exemple si on a une seule fonction avec trois sous-fonctions, chacune ayant à son tour trois sous-fonctions qui à leur tour ont trois sous-fonctions, doit-on considérer 3³ (27) fonctions ? Est-ce que les fonctions doivent être traitées de la même manière sans souci de leur position dans la hiérarchie ? Si on considère les modules au lieu des fonctions on voit plus facilement que les modules qui sont le plus sollicités (ceux qui ont un plus grand fan-in) devraient, ceteris paribus, être traités différemment.

Pédalogue.

Qualitatif : Donc l’indice de couverture des tests nous donne… l’indice de couverture des tests !

Quantitatif : Oui. Comme quand tu vas du point A au point B le pourcentage de chemin parcouru te dit le pourcentage de chemin parcouru.

Qualitatif : Ce qui ne veut rien dire si je ne connais pas la morphologie du terrain dans la partie de route qui reste, les rivières sans ponts, les fauves que je risque de rencontrer…

Quantitatif : Oui mais dans une situation plus réaliste, si tu vas de Québec à Montréal en voiture et tu as fait le 95 % du trajet tu sais qu’il te reste le 5 % et que donc le temps qui te reste…

Qualitatif : Oui, mais s’il est neuf heures du matin le 5 % peut être énorme en terme de temps et ce qui importe dans un tel voyage c’est souvent le temps, n’est-ce pas ?

Quantitatif : Statistiquement, cela reste quand même utile. Si tu introduis la variable heure de pointe tu peux même calculer avec une grande précision le temps qui te reste.

Qualitatif : Oui mais cela vaut pour Montréal-Québec selon l’heure, la saison, les événements dans la ville, etc. Et puis, est-ce que la « route d’un projet » est comparable au parcours Montréal-Québec ?

Quantitatif : Pour certaines entreprises sans doute. Mais, même si cet indice reste un… indice avec une portée limitée au projet, ce qui est certain c’est que si tu veux un produit de qualité tu ne livres pas si l’indice n’est pas égale = 1.

Qualitatif : Une mesure garde-fou?

Quantitatif : Si tu veux. Mais, en génie logiciel, il y a tellement de fous qu’elle n’est pas inutile.