5 conseils pour bien démultiplier vos tests de non régression

Publié le : 1 janvier 2024

L’amélioration de la qualité d’un logiciel passe, forcément, par l’augmentation du patrimoine de tests de non régression à exécuter. C’est l’un des éléments clés de l’amélioration. Pour réussir ce tour de force il y a deux solutions (si vous en connaissez d’autres nous sommes preneurs) :

1. Augmenter le nombre de personnes qui exécutent les tests.
2. Réussir à démultiplier l’exécution par l’industrialisation de l’automatisation.

C’est votre besoin qui devrait vous guider vers l’une ou l’autre des solutions et pour les plus avancés dans leur réflexion : Identifier les 4 moments clés où l’automatisation des tests devient pertinente.

Mais tout cela amène à une question : est-ce qu’un scénario de test est multipliable autant de fois que l’on souhaite ?

 1 – Définissez le parcours d’achat des utilisateurs.

Pour accompagner notre réflexion tout au long de cet article nous allons nous appuyer sur un exemple : les tests de non régression d’un tunnel d’achat pour un site e-commerce, avant une nouvelle mise en production. L’objectif est de vérifier la validité du parcours d’achat des utilisateurs et pour cela on va définir ce parcours en différentes étapes :

« Test Tunnel d’Achat »

1. Sélection d’un produit (pantalon, ref. 123456)
2. Sélection d’une taille
3. Sélection d’une couleur
4. Sélection d’un mode de livraison
5. Sélection d’un mode de paiement
6. Paiement

2 – Variabilisez le parcours défini en injectant les jeux de données.

Une fois le parcours identifié il est possible de le variabiliser en injectant des jeux de données : 6 tailles, 4 couleurs, 3 choix de livraison, 3 modes de paiement. Nous venons, à l’instant, de démultiplier le nombre de tests de non régression à exécuter de manière quasi exponentielle car :

1 pantalon x 6 tailles x 4 couleurs x 3 choix x 3 modes de paiement = 216 tests à exécuter pour mon scénario.

Et encore on vous fait grâce de l’exécution de ces tests sur plusieurs navigateurs, a minima FireFox, Chrome et Edge, ce qui multiplierait par 3 le volume de tests à exécuter, approchant les 1000 tests … On pourrait bien sur aussi envisager de variabiliser la sélection du produit …

Nous venons d’étoffer le patrimoine de tests mais ce n’est pas pour autant que nous venons d’améliorer la qualité du livrable, au contraire …

3 – Épreuve de déchiffrage des résultats des tests.

Après l’exécution de ces tests de non régression il va falloir interpréter les résultats et là, en attendant un système d’IA ;-), il n’y a pas d’autres solutions que de le faire manuellement. Et nous souhaitons bonne chance aux équipes qui auront à déchiffrer les résultats de ces 216 tests pour obtenir des données précises et utiles aux équipes de développement pour analyser les éventuels « défauts ». C’est mission impossible.

Il est donc “techniquement” possible de démultiplier le nombre de tests à exécuter mais “humainement” impossible de les interpréter si on cherche à le faire en une seule fois.

 4 – Bonne méthode : utiliser les scénarios « pas à pas ».

Pour notre exemple, la bonne méthodologie c’est d’utiliser « pas à pas » les scénarios de tests puis, idéalement, de les tester tous ensemble.

On créera un scénario pour tester les tailles, un scénario pour tester le choix d’une couleur etc. … Puis on utilisera les scénarios comme des « Legos » pour les assembler et aboutir à l’exécution de toutes les étapes, combinés avec tous les jeux de données, décrit dans notre exemple.

Le plan de tests sur l’environnement d’homologation/recette, pour cet exemple, serait :

1 – Test fonctionnel : « Vérification de la sélection d’un produit précis »
Scénario utilisé « Sélection du produit »
JDD : pantalon, ref. 123456

SI test 1 Valide alors on réalise le test 2 :
2 – Test fonctionnel : « Vérification des sélections de taille »
Scénario utilisé « Sélection du produit » <– JDD pantalon, ref.123456
Scénario utilisé « Sélection d’une taille » <– JDD taille 42,43,44,45,46,47

SI test 2 Valide alors on réalise le test 3 :
3 – Test fonctionnel : « Vérification sélection de couleurs »
Scénario utilisé « Sélection du produit » <– JDD pantalon, ref.123456
Scénario utilisé « Sélection d’une taille » <– JDD taille 42,43,44,45,46,47
Scénario utilisé « Sélection d’une couleur » <– JDD Couleur Noir, Blanc, Bleu, Gris

SI test 3 Valide alors on réalise le test 4 :
3 – Test fonctionnel : « Vérification sélection des points de livraison »
Scénario utilisé « Sélection du produit »  <– JDD pantalon, ref.123456
Scénario utilisé « Sélection d’une taille »  <– JDD taille 42,43,44,45,46,47
Scénario utilisé « Sélection d’une couleur  <– JDD Couleur Noir, Blanc, Bleu, Gris
Scénario utilisé « Sélection d’un mode de paiement <– JDD CB, Chèque, PayPal

SI test 4 Valide alors on réalise le test 5 :
4 – Test fonctionnel : « Vérification sélection mode de livraison »
Scénario utilisé « Sélection du produit » <– JDD pantalon, ref.123456
Scénario utilisé « Sélection d’une taille » <– JDD taille 42,43,44,45,46,47
Scénario utilisé « Sélection d’une couleur <– JDD Couleur Noir, Blanc, Bleu, Gris
Scénario utilisé « Sélection d’un mode de livraison » <– JDD Adresse perso, Point de livraison (affichage carte)

SI test 5 Valide alors on réalise le test 6 :
6 – Test fonctionnel : « Vérification sélection d’un mode de livraison »
Scénario utilisé « Sélection du produit » <– JDD pantalon, ref.123456
Scénario utilisé « Sélection d’une taille » <– JDD taille 42,43,44,45,46,47
Scénario utilisé « Sélection d’une couleur <– JDD Couleur Noir, Blanc, Bleu, Gris
Scénario utilisé « Sélection d’un mode de livraison » <– JDD Adresse perso, Point de livraison (affichage carte)
Scénario utilisé « Sélection d’un mode de paiement <– JDD CB, Chèque, PayPal

SI test 6 Valide alors on réalise le test 7 :
7 – Test fonctionnel « Vérification paiement » (très rarement possible)
Scénario utilisé « Sélection du produit » <– JDD pantalon, ref.123456
Scénario utilisé « Sélection d’une taille » <– JDD taille 42,43,44,45,46,47
Scénario utilisé « Sélection d’une couleur <– JDD Couleur Noir, Blanc, Bleu, Gris
Scénario utilisé « Sélection d’un mode de livraison » <– JDD Adresse perso, Point de livraison (affichage carte)
Scénario utilisé « Sélection d’un mode de paiement <– JDD CB, Chèque, PayPal
Scénario utilisé « Paiement » <– CB tests, Compte Tests Paypal

La règle d’or des tests de non régression (même automatisés) : tester fonctionnalité par fonctionnalité !

Le Graal : à l’issue de la MEP exécuter le test 6 :
Test fonctionnel « Vérification sélection d’un mode de livraison ».

La réalisation de ce test « Tunnel d’achat » est bien sûr conditionné par l’utilisation d’une base de données de tests « peuplées » correctement, pour éviter des « faux négatifs ». N’hésitez pas à prendre connaissance de notre article sur La complexité des mises en œuvre des jeux de données.

 5 – Pensez à vos capacités d’interpréter les résultats de tests avant de les multiplier.

Il est donc possible de démultiplier le nombre de tests de non régression à exécuter en automatisant ses scénarios « découpés » par fonctionnalité et c’est d’ailleurs le rôle premier de l’industrialisation de l’automatisation des tests.

Pour autant, il faut corréler le nombre de tests à exécuter à votre capacité à interpréter les résultats. Un scénario doit être composé d’étapes nécessaires au test d’une fonctionnalité.

À chaque mise en production vous pourrez alors lancer l’exécution automatique de tous vos scénarios, qui viendront valider une par une vos fonctionnalités. Et cas d’erreur, la fonctionnalité étant isolée, il vous sera plus facile et rapide de remonter le « bug » constaté à vos équipes de développement en leur donnant le contexte précis du dysfonctionnement constaté.

En pratiquant de la sorte vous aurez trois bénéfices considérables :
– L’amélioration de la qualité de vos livrables,
– Une productivité accrue, réduisant vos coûts,
– Une augmentation de la fréquence de vos livraisons.

Pour aboutir à cela la condition sine qua none : le MCO (*) de votre environnement de tests !

(*) Maintien en Condition Opérationnelle