Petit guide des tests fonctionnels automatisés

Les centres de services SQLI maintiennent un patrimoine applicatif conséquent : plus de 300 applications web et mobiles sont maintenues en condition opérationnelle.

La plupart d’entre elles nécessitent une mise en place de tests automatisés afin de répondre à plusieurs exigences fortes des clients, tel que le time to market. Nous avons ainsi mis en place un dispositif industrialisé de tests fonctionnels automatisés.  Bien entendu, avant de se lancer dans un chantier d'automatisation qui reste une activité qui peut être chronophage, il est préférable d’analyser la situation. Voici les règles et conseils issus de nos différents retours d’expérience en la matière. 

Toute l’organisation des tests automatisés tourne autour de deux principales réflexions, à savoir : 

  • L’intérêt d’automatiser des tests 
  • La stratégie de test qui permettra de guider l’activité de test, de déterminer ce qui doit être automatisé, de déterminer ce qui peut l’être, de déterminer ce qui sera réellement embarqué dans les campagnes de tests automatisées.

Les fondamentaux  

  • Tous les tests manuels ne sont pas automatisables ; 
  • Point de vigilance : 
    • Investissement : coût du développement initial + coût de maintenance
    • S’assurer de faire vivre les tests en même temps que le produit évolue 
  • L’automatisation se réalise sur une application STABLE et MATURE ;
  • Le choix de l’outil d’automatisation doit être adapté au type de tests ciblés.  

Pourquoi passer aux tests fonctionnels automatisés ?

C’est la première question à se poser. Les raisons peuvent être de plusieurs ordres : 

  • Passer un maximum de tests (contrôle de surface, ergonomie, navigation, CRUD, métier) dans un délai court ; 
  • Permettre des cycles de maintenance plus court ; 
  • Maîtriser la non-régression ; 
  • Optimiser la couverture des tests ;
  • Optimiser la qualité des livraisons ;
  • Concentrer les efforts sur des activités à plus forte valeur ajoutée, l'exécution des tests étant automatique. 

Afin de guider la réflexion, nous avons identifié les règles suivantes permettant de s’assurer de « l’éligibilité à l’automatisation » de nos projets : 

  • La faisabilité technique ; 
  • La fréquence d’exécution des tests ; un ROI est possible à partir de 6 voire 7 itérations d'exécution sur un périmètre donné. On compte bien entendu des phases de maintenance des tests ;
  • La réutilisabilité des scripts développés ; 
  • Le degré de réutilisabilité des composants de test ; 
  • La complexité des cas de test ;
  • Le temps nécessaire à l’exécution des tests ; 
  • La fréquence d’utilisation de la fonctionnalité par les utilisateurs ; l'effort de test va être accru sur les fonctionnalités les plus utilisées ;
  • L’impact financier lié à la fonctionnalité ;
  • Sommes-nous en mesure de garantir l’idempotence de nos scénarios de test : l’Nième exécution du test doit avoir le même résultat que la N-1ème exécution du même test. 
  • La régularité des exécutions (ordonnancement) : journalière, hebdomadaire, avant chaque livraison ? 
  • La maîtrise des jeux de données avant de démarrer une exécution de test ; 
  • Le moyen de suivre et d’analyser les résultats des tests exécutés automatiquement. 

 Autant d’éléments à prendre en compte avant de se lancer dans ce chantier qui peut vite devenir lourd de conséquences s’il n’est pas un minimum structuré.