L’étendue du périmètre de test
Le périmètre de test d’une application peut rapidement s’approcher de « l’infini » ou en tout cas être trop grand pour être vérifié dans des délais et budgets raisonnables.
Par exemple pour l’achat d’un billet de train, on pourrait tester :
- L’achat d’un billet pour sa gare favorite, en aller-retour avec un adulte, un bagage et un animal, en place confort et en payant avec CB et voucher
- L’achat d’un billet pour son trajet favori, en aller-retour, avec un enfant voyageant seul, son accompagnant, avec option SMS, carte favorite et en payant avec CB
- L’achat d’un billet en aller simple, avec un adulte, deux militaires, un enfant, huit bagages, deux poussettes, en places prises et en payant avec CB et voucher
Pourquoi ces trois cas de test et pas d’autres ? Comment choisir le bon périmètre de test ? (Dans l’exemple ci-dessus on pourrait faire des milliers de cas, voire beaucoup plus.)
Tester des cas d’utilisation métier
Un bon test est avant tout une simulation d’une future utilisation de la solution.
Les logiciels étant très paramétrables ou permissifs, on peut toujours tester des situations ne correspondant pas forcément à une situation réelle. On arrive donc à faire trop de tests sur une situation non existante en production et pas assez sur une future utilisation. Ceci entraine un coût prohibitif des tests pour une qualité non optimale, entrainant une perte de confiance dans le processus de qualité logicielle.
Un bon test est avant tout centré sur une utilisation du logiciel. Il faut donc pour cela référencer les utilisations possibles de la solution.
Les cas d’utilisation
Un cas d’utilisation d’une fonctionnalité est une façon d’interagir avec elle dans un contexte métier. Par exemple pour l’achat d’un billet de l’exemple précédent, les choix suivants sont des cas d’utilisations :
- Acheter un billet pour un adulte
- Acheter un billet pour un militaire
- Acheter un billet avec une carte d’invalidité
En général les cas d’utilisation s’enchainent dans une logique métier. Par exemple on va prendre un billet adulte avec une carte d’invalidité.
Le fait de référencer séparément les cas d’utilisation permet de les lister plus facilement, pour ensuite les regrouper au sein d’un cas de test simulant une utilisation probable du métier.
Un cas d’utilisation prend nécessairement une valeur au sein d’un cas de test simulant un contexte métier. Par exemple pour la carte d’invalidité, le passager en a une ou pas. C’est forcément une des deux valeurs. Donc on a un cas d’utilisation « carte d’invalidité » avec la variabilité « oui ou non ».
De la même manière sur la base de l’exemple précédent :
Attention à ne pas confondre les cas d’utilisations avec les données. Les cas d’utilisations sont souvent portés directement ou indirectement par une ou plusieurs données, par contre toutes les données ne représentent pas des cas d’utilisation.
On voit bien sur la base de cet exemple la multiplicité des cas de test potentiels. En prenant seulement les cas d’utilisations « Type de voyage », « Nb adulte » et « Nb enfant », on atteint déjà le nombre de 96 cas :
- Aller simple, 1 adulte, 0 enfant / Aller simple, 2 adultes, 0 enfant / Aller simple, 3 adultes, 0 enfant / Aller simple, 4 adultes, 0 enfant / Aller simple, 5 adultes, 0 enfant / Aller simple, 6 adultes, 0 enfant / Aller simple, 7 adultes, 0 enfant / Aller simple, 8 adultes, 0 enfant /
- Aller simple, 1 adulte, 1 enfant / Aller simple, 2 adultes, 1 enfant / Aller simple, 3 adultes, 1 enfant / Aller simple, 4 adultes, 1 enfant / Aller simple, 5 adultes, 1 enfant / Aller simple, 6 adultes, 1 enfant / Aller simple, 7 adultes, 1 enfant / Aller simple, 8 adultes, 1 enfant /
- (…)
Le simple fait d’ajouter le cas d’utilisation « Nb bagages » fait passer le nombre de cas total à 1 440, sur la base de 7 passagers en moyenne pour simplifier le calcul, soit 15 possibilités de nombre de bagages en moyenne. En ajoutant les autres cas d’utilisation unitaires, on peut atteindre des dizaines de milliers de situations possibles, voire plus.
Même si certains cas ne sont pas forcément cohérents ou représentatifs, de nombreux cas sont possibles, et l’ensemble de ces situations à un impact sur le prix final, le placement des voyageurs dans le train et le nombre de billets émis par exemple. Donc chacune de ces situations globales peut générer une anomalie distincte. Mais alors comment choisir les bons cas à tester parmi ces dizaines de milliers de cas ?
Cet exemple est particulier, mais pas autant que l’on peut le croire. Dans quasiment chaque système d’information il y a au moins une fonctionnalité qui portent une complexité telle que celle-ci. Complexité qu’il faut gérer si on veut atteindre la qualité voulue en production. Sachant qu’en général cette fonctionnalité complexe est souvent au cœur du système d’information, et peut donc déporter cette complexité sur de nombreux processus l’utilisant.
La mise en place d’une conception des tests basée sur les cas d’utilisation, permet de fournir un outil d’aide à la décision pour avoir un périmètre de test efficace et efficient.
De manière générale, et par simplicité de conception, on va tester un achat de billet pour un adulte, puis pour un enfant, puis…, alors que la réalité est qu’un enfant voyage avec 2 adultes par exemple, et que ce cas représente X% de la production. On voit tout de suite dans cet exemple qu’un cas de test métier à plus de pertinence que deux cas d’utilisation « unitaire ». L’effort de test est deux fois moindre, et en même temps plus adéquat.
Sachant que quand on teste un achat de billet pour un adulte, intrinsèquement on teste 0 enfant, 0 militaire…, donc on passe nécessairement sur les autres cas d’utilisation. Il faut avoir à l’esprit qu’une fonctionnalité est un tout, et que sauf cas d’utilisation à part, il faut tous les enchainer pour atteindre la finalité de la fonctionnalité et donc pouvoir vérifier son résultat attendu.
L’approche de test
Une bonne approche de test doit contenir l’effort de test, tout en simulant les différentes utilisations d’une fonctionnalité. Pour une fonctionnalité avec 1 ou 2 cas d’utilisation, il est facile d’avoir une couverture large des tests. Pour une fonctionnalité avec de nombreux cas d’utilisation, il est difficile de mixer l’ensemble des cas d’utilisation représentatifs de la variété des utilisations. Une approche de test basée sur les cas d’utilisation devient donc indispensable.
L’approche de test définit, sur la base des cas d’utilisations, le périmètre de test qu’il faut vérifier pour atteindre la qualité requise. Ce périmètre donne une volumétrie de tests qui permet sur la base d’abaque de chiffrer la phase de test. Sur la base de ce chiffrage et des contraintes projet, on peut définir un planning des tests. Ce travail est essentiel pour budgétiser une phase de test, la dimensionner et donc la piloter. Notamment, ceci permet aussi de ne pas spécifier des tests que l’on n’aura pas la capacité ou l’intérêt d’exécuter, comme c’est souvent le cas.
L’approche de test peut prendre plusieurs formes :
- Soit on référence des utilisations globales, caractéristiques de la production
- Soit on fait des choix représentatifs de mixage des cas d’utilisation, avec l’aide d’expert fonctionnel ou métier
Pour la seconde forme, avec l’exemple de besoin fonctionnel suivant :
« Le client a le choix de souscrire avec la signature en ligne. La souscription peut intervenir sur plusieurs contrats et plusieurs prêts. Au choix les mails seront envoyés au partenaire et au client. »
Les cas d’utilisations et variabilités seraient :
Une approche de test sans mixage des cas d’utilisations, mais en passant sur l’ensemble des variabilités, donnerait 2 cas de test, et avec un mixage on attendrait 32 cas de test.
Aujourd’hui, c’est souvent le testeur tout seul qui fait ce choix. Il va se baser sur son expérience ou son instinct et va choisir 8 cas de test, ou alors 12 et certains testeurs vont en choisir 18. Il n’y aura pas forcément de validation de ce périmètre, ou une validation basée sur une liste de cas de test ou un cahier de test, qui ne permet pas de valider aisément la couverture. Pour l’avoir déjà fait, je peux vous en dire toute la complexité. Cela tient souvent de l’impossible d’identifier un périmètre de test sur la base de la lecture d’un cahier de test détaillé.
On fait porter une grande responsabilité au testeur. Le choix du périmètre qu’il va faire, outre les aspects budgétaires, définit la future qualité de la production. Par son travail unitaire et souvent isolé, il va définir bien malgré lui le budget de maintenance corrective, de support, l’image client ou autres aspects directement liés à la qualité. La qualité engage l’entreprise, et donc le périmètre de test doit être validé par une instance adéquate. De la même façon que le périmètre fonctionnel est en général validé par une instance spécifique.
Une approche de test convenable pourrait être la phrase suivante : « On veut tester le mixage des cas d’utilisation contrat et prêt en passant par tous les autres cas d’utilisation », ce qui donnerait 4 cas de test :
- Mono contrat / Mono prêt / avec / avec / avec
- Multi contrat / Mono prêt / avec / avec / avec
- Mono contrat / Multi prêt / avec / avec / avec
- Multi contrat / Multi prêt / sans / sans / sans
Avec ces 4 cas on a une bonne couverture de la complexité applicative, et surtout la phrase définissant l’approche de test, même si elle est un peu « technique », est plus facile à valider par un acteur externe aux tests, qu’un cahier de test détaillé qui pourrait faire 1 à 2 pages voire plus.
Conclusion
S’ils ne sont pas cadrés, les tests peuvent parfois couter cher et sans apporter les résultats escomptés. Comme tous les projets, le projet de test nécessite une phase de réflexion initiale pour bien l’orienter. Souvent les équipes spécifient voire exécutent directement un périmètre de test, pour se rendre compte par la suite qu’elles n’ont pas la capacité de le faire. Comme tous les projets, le projet de test nécessite une phase de conception avant de réaliser les spécifications de test. Cette conception permet de choisir et définir un périmètre de test par rapport à l’ensemble des contraintes fonctionnelles et projet.
Au-delà du besoin unitaire lié à une phase de test / niveau de test, la conception de test via les cas d’utilisation permet plus aisément le dialogue, l’échange et la complémentarité entre les tests réalisés par les différentes équipes projet. Les tests sont toujours faits par de multiples acteurs (MOA, AMOA, AMOE, MOE, …) qui, par manque de grille de lecture commune, réalisent de nombreux tests redondants.
À propos de l’auteur: Arnaud Verin
Officiant depuis maintenant 20 ans dans la qualité logicielle, Arnaud est intervenu sur quasiment tous les rôles. De testeur fonctionnel, technique et automaticien, en passant par responsable d’équipe et chef de projet, il tient aujourd’hui un double rôle :
• D’un côté directeur de projet, il met en place des stratégies de test pour de gros programmes, des centres d’excellence test ;
• De l’autre réalisant des missions de conseil, audit, diagnostic, mentoring et formation pour accompagner les entreprises à optimiser leur processus de test manuel et automatique.
