Stratégie d’automatisation de tests: par où commencer…?

Le laisser passer A38 est par ici ….

Quel que soit la raison pour laquelle vous voulez mettre en place des tests automatisés fonctionnels, que ce soit pour:

• Améliorer la qualité de votre produit
• Vérifier la stabilité des fonctionnalités de base
• Gagner du temps sur l’exécution des tests manuels
• Intégrer les tests dans la chaine l’Intégration Continue
• Etc…

cet article est fait pour vous!

Quand on veut mettre en place la partie automatisation des tests, on se pose toujours la question : par où commencer?

Quel Framework de test choisir?

Petit rappel, un framework est une boite à outils facilitant un travail de developpement.

Je ne pense pas qu’il existe un Framework parfait. Chacun d’eux répond à des problématiques spécifiques. Le mieux c’est de choisir celui qui répondra au maximum à votre besoin. Pour cela, il vous faut poser les bonnes questions.

• Faut il tester une application Mobile/Web/Desktop?…
• La cible des tests est-elle un Back-Office (interface administrateur pour la création de catalogues produits e-commerce) ou un Front Office (exploitation des données créés depuis le Back Office)?

A ne pas confondre avec:

=> le Back End: la partie non visible du site comme la base de donnée, le serveur, les API, etc…

=> le Front End: éléments qui composent un site que ce soit un Front Office ou un Back Office comme les champs à remplir, les boutons, les sélections, etc…

• Faut-il tester plusieurs navigateurs en même temps?
• Y a-t-il un budget alloué pour acheter un framework ou se contenter d’un qui est gratuit?
• Faut-il utiliser un langage de programmation précis; utilisation d’un Framework Codebased (i.e qu’il faut programmer) ou Framework Codeless (i.e qu’on n’a pas besoin de compétences en développement)?
• Y a-t-il une suite logique à choisir un framework en particulier par rapport à ce que l’entreprise a déjà en place? (Ex: suite HP, suite SmartBear, etc…)
• Etc…

En répondant à ces questions, le choix de votre Framework pourra se dessiner d’elle même. Un essaie ou une démonstration du Framework pourra affiner votre choix.

NB: Quelques tendances sur les téléchargements des frameworks gratuits coté web: https://www.npmtrends.com/cypress-vs-nightwatch-vs-webdriverio-vs-puppeteer-vs-selenium-webdriver

On sait quand est ce que les techs sont en vacances …

Dans cet article, je vais vous proposer 3 stratégies de base pour commencer à mettre en place des tests automatisés fonctionnels.

Les stratégies

Maintenant que vous avez choisi votre arme (Selenium, Cypress, Katalon Studio, UFT, TestComplete, Ranorex, etc…), il faut définir comment l’exploiter correctement. Je vais vous montrer à travers des exemples, quelques stratégies que je trouve simples et efficaces.

1- Les parcours classiques d’un client

On le sait tous, un produit est destiné à un client ou un utilisateur final.

De ce fait, on devrait être capable de savoir les parcours les plus classiques et les plus répétitifs d’un client.

Juste avec ce constat, il devient logique que si un élément de ce parcours est défaillant, alors ça devient un bloquant pour le client.

Exemple

Prenons le cas d’un site e-commerce. Le parcours classique d’un client serait le suivant:

1. Se loguer sur le site
2. Choisir des articles
3. Ajouter les articles dans le panier
4. Valider le panier
5. Payer
6. Confirmer le paiement
7. Recevoir un mail de validation

Une fois ce parcours couvert, on peut continuer à broder autour en rajoutant petit à petit des scénarios classiques notamment:

• Retirer des articles du panier
• Se loguer à la fin du parcours
• Passer une commande puis l’annuler
• etc…

C’est une stratégie bien adaptée pour les Front Office, les Mobiles, là où on doit se focaliser sur l’exploitation des données.

Les limites

• Il y a des parcours qui risque de n’être jamais testé car on se focalise sur les parcours les plus connus.
• Il peut arriver que, dans un parcours, il y ait une interdépendance entre les tests. Exemple: Le paiement nécessite l’ajout préalable d’un article minimum dans le panier.

2- Les scenarios et modules critiques

Quel que soit le produit, il existe toujours des parties plus sensibles que d’autres. Une fois qu’on arrive à les identifier et à les classer par ordre de priorité, il est plus facile d’ordonner une stratégie d’automatisation.

• Sur quels modules du produit y a-t-il plus de régressions ?
• Quels sont les modules les plus sensibles en terme de sécurité ou de performance ?
• Quelles fonctionnalités sont les plus pertinentes pour le client?
• Etc…

Exemple

Si je prend le même cas e-commerce que précédemment, les scénarios critiques peuvent être:

• Sur le module de paiement : test de différents types de paiement (CB/PAYPAL…) + authentification de paiement + annulation
• Sur le module d’inscription pour pouvoir faire les relances et le suivi des commandes : réception d’un mail d’inscription, double authentification du client, etc…
• Sur le module de gestion des stocks : mise à jour en temps réel des stocks pour ne pas faire acheter des articles qui ne sont plus disponibles

C’est une stratégie adaptée pour les Front Office et/ou les Back Office, surtout quand on a suffisamment de retours des clients et de connaissance sur le produit.

Les limites

• Il y a des parcours qui risquent de n’être jamais testé car on se focalise sur des parcours les plus connus.
• La mise en place peut être compliqué car il faut mettre le logiciel dans un contexte précis avant de débuter un scenario de test (cf. exemple d’interdépendance entre le paiement et l’ajout d’un article dans un panier).

3- Le fameux CRUD

Source wikipedia:

L’acronyme informatique anglais CRUD (pour create, read, update, delete) (parfois appelé SCRUD avec un “S” pour search) désigne les quatre opérations de base pour la persistance des données, en particulier le stockage d’informations en base de données. Plus généralement, il désigne les opérations permettant la gestion d’une collection d’éléments.

Le CRUD est surtout connu du coté des développeurs. Les tests de CRUD sont souvent effectués au niveau des tests unitaires Back End.

Maintenant qu’on sait cela, pourquoi ne pas l’exploiter d’une façon plus globale dans un test de bout en bout (End To End Test)?

Exemple

Toujours sur le même cas, cela va donner quelque chose de ce type:

• Create: Créer un produit en remplissant les champs: catégorie*, prix, description, nombre de stock
• Read: Voir que le produit qui a été créé est visible sur le site et que les valeurs visibles correspondent bien à ce qu’on a renseigné
• Update: Mettre à jour le produit en modifiant son prix et vérifier que la modification a été prise en compte
• Delete: Supprimer le produit qui ne devrait plus être visible pour le client dans le catalogue

Maintenant, vous avez vu que j’ai mis en obligatoire(*) le champs CATÉGORIE pour la création d’un produit. Cela signifie qu’il faut créer une catégorie avant de pouvoir créer un produit.

Vous avez compris l’idée, on va donc créer toutes les interdépendances de chaque éléments du logiciel et créer un enchainement de tests.

C’est une stratégie adaptée pour les Back Office et les Back End, là où on doit se focaliser sur la création et la gestion des données.

Les limites

• Il faut suivre un enchainement de tests déjà prédéterminé
• Les tests de ce type ne servent pas à tester en profondeur une fonctionnalité mais de vérifier sa bonne intégration dans un processus complet.

Conclusion

Les tests automatisés sont des projets de développements à part entière. C’est pour cela qu’il faut mettre en place une stratégie de test qui s’adapte avec votre produit et vos besoins. L’idéal c’est de faire un audit de qualité afin d’établir une stratégie d’automatisation de tests adapté à votre structure et aux technologies que vous utilisez.

Là où on doit se focaliser sur l’exploitation des données, le test d’un parcours classique d’un client est une stratégie simple et bien adaptée. Les scenarios et modules critiques peuvent s’ajouter à cette stratégie si on a suffisamment de retours des clients ou de connaissance sur le produit. L’utilisation de la stratégie du CRUD est bien adaptée pour les Back Office et les Back End, là où on doit se focaliser sur la création et la gestion des données.

Pour une meilleure couverture de test, il serait intéressant de combiner ces stratégies qui peuvent être complémentaires.

C’est toujours mieux de commencer par une stratégie simple au départ et l’améliorer par la suite que de procrastiner en attendant une stratégie idéale!

Que pensez-vous de cet article ?

Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !

À bientôt 😊