L’automatisation des tests consiste en la mise en place d’outils qui simulent et mesurent des actions que réaliserait manuellement un testeur. Cela implique de parfaitement maîtriser tous les paramètres de fonctionnement au risque de faire face à des coûts de développement, maintenance et analyse de résultats supérieurs aux gains espérés.
Dans la phase de tests fonctionnels, l’automate permet uniquement de gérer la non régression. Dans les phases amont, l’automatisation reste la plus pertinente des réponses lors d’un développement en « TDD ».
L’automatisation des tests peut être réalisée à deux niveaux, au travers de :
- Interface homme/machine (IHM) : l’automate simule les évènements clavier et souris nécessaires au contrôle de l’application.
- Interface de programmation (API) : l’automate s’appuie sur les mêmes principes que les tests unitaires avec des langages tels que python, ruby, tcl, perl, etc.
Selon les acteurs du marché, les avantages de l’automatisation des tests sont :
- Sécuriser les livraisons par des tests de non régression (TNR),
- Faciliter les vérifications ciblées,
- Enrichir les tests de non régression à budget constant (ou presque),
- Augmenter la confiance dans les nouvelles versions produit.
Cela dégage 80 % de réduction du temps d’exécution et nécessite 3 à 4 campagnes pour atteindre un Retour Sur Investissement.
Critères de rentabilité d’un automate de test
L’automatisation de tests est un développement à part entière. À ce titre, il doit suivre les mêmes préceptes et règles de suivi et gestion que tout autre développement.
L’automate fonctionnel rencontre les mêmes contraintes qu’un testeur manuel enrichi d’une difficulté majeure supplémentaire : « ne pas savoir prendre de décision en cas de comportement inattendu ». Il convient de trouver un juste équilibre entre l’effort de prédictibilité et adaptabilité à une situation non prévue, l’investissement à anticiper des cas rares, et analyser les dysfonctionnements de l’automate.
| Élément | Explication |
| Critères généraux | |
| Ratio d’utilisation de l’automate | Utilisation quotidienne, hebdomadaire, trimestrielle, etc. Durée d’exécution.
À relier avec le nombre de livraison de l’application et le risque à tester en détails cette fonctionnalité (qui peut ne pas évoluer pendant plusieurs versions) |
| Risque d’erreur humaine (répétibilité) | |
Stabilité de l’environnement1
|
Capacité à avoir systématiquement les mêmes conditions de départ (initialisation, création, anonymisation de données), pilotage et simulation des systèmes externes (bouchons/pilotes), |
| Modularité fonctionnelle | Capacité à reprendre le traitement/test à un endroit consistant et efficient avec l’objectif en cas de dysfonctionnement. Ex. Traitement de 6 heures qui est en erreur au bout de 4 heures 45. Reprise au début du traitement ou capacité à reprendre à l’issue d’une partie stable (par exemple : 4 heures 30). |
| Coût de gestion de l’automate | |
| Développement | Licence éventuelle, formation, normes de codage (factorisation, externalisation de variables, « niveaux d’abstraction », autocontrôle de l’automate |
| Maintenance du code/outil | Connaissance technique, documentation minimale, normes de codage, |
| Maintenance des données | Péremption des données, volatilité, capacité à les créer/réinitialiser, externalisation dans des fichiers externes (CSV, Excel, XML, base de données) |
| Exécution | |
| Fréquence d’évolution de version du coeur technique | Gestion et impact d’une montée de version de python, QTP, Fitnesse, Cucumber, etc. |
| Pérennité de l’outil ou éditeur (même si open-source) | |
| Gestion de version de l’automate / application | L’automate de test doit rester synchrone avec l’application. Evaluation de la capacité sur une période à positionner la version d’automate face à la version de l’application. |
| Pérennité de la partie testée (prédictibilité des résultats) | Afin d’assurer une prédictibilité constante dans le temps, il est nécessaire de maîtriser les entrées/sorties des ensembles testés |
| Maîtrise technique de développement | |
| Gains attendus | |
| Délai de livraison
Exécution en parallèle Exécution en dehors des heures ouvrées |
Génération, puis livraison de l’application en fin de journée, puis réalisation de tests (dont fonctionnels) durant la nuit, et analyse des résultats en début de journée pour corrections si nécessaire. |
| Exécution multi-systèmes | Validation d’une application Web avec Iexplore (6, 7, 8), Firefox, Safari avec les 3 dernières versions java compatibles avec ces navigateurs.Validation sur différentes versions de serveur (Linux, Redhat, etc.) |
| Multiplicité des jeux de données | Capacité à dériver différents cas (limite, passants ou non passants) sur la base d’un même scénario. |
Tableau 1 : critères de rentabilité d’automatisation
Exemples de calcul de rentabilité
Les exemples ci-après permettent à chacun d’appréhender des cas pratiques de calcul de rentabilité.
L’utilisation d’automates de gestion d’environnement (préambule et postambule) permet d’assurer une intégration continue sans intervention manuelle, délai ou contrainte horaire.
Cas 1 – Calcul d’équivalence en charge manuel (hors risque d’erreur)
Exemple de la validation des habilitations d’une application (plusieurs profils et/ou utilisateurs : lecteur simple, gestionnaire partiel, gestionnaire complet, support fonctionnel, support applicatif, client, etc.). Il faut généralement noter la charge d’exécution d’un tel test se répartit en création (30%) et contrôles (70%) [écrans, liste, base de données, etc.]
| Opération | Valeur |
| Création manuelle d’un utilisateur dans l’application (en secondes) | 120 |
| Création automatisée d’un utilisateur dans l’application (en secondes) | 14 |
| Gain par création grâce à l’automate | 106 |
| Nombre d’utilisateurs à créer pour assurer l’exhaustivité des tests | 50 |
| Nombre d’utilisateurs minimum à créer pour couvrir les cas nominaux (matrice de risque) | 6 |
| Charge minimale de test manuelle (en secondes) | 720 |
| Charge minimale de test automatisée (en secondes) | 84 |
| Charge maximale de test manuelle (en secondes) | 6000 |
| Charge maximale de test automatisée (en secondes) | 700 |
Conclusion : hormis tout autre critère, la totalité des tests seront réalisés par un automate pour une charge équivalente au périmètre réduit manuel.
Cas 2 – Mise en place d’environnement de test
Exemple de préparation de jeux de données de tests après un rafraîchissement quotidien et nocturne de l’environnement de test par copie des données de production.
| Opération | Valeur |
| Création manuelle via les écrans des données dans l’application (en secondes) | 1800 |
| Création automatisée des mêmes données (via batch) dans l’application (en secondes) | 120 |
| Gain par création grâce à l’automate | 1680 |
| Nombre de fois où l’environnement de test sera réellement utilisé dans l’année | 40 |
| Charge totale de création manuelle (en heures) | 20 |
| Charge totale de création manuelle (en heures – 5 jours ouvrés par 52 semaines) | 8,67 |
Conclusion : La création automatisée limite l’effort manuel, offre un service plus réactif (30 mn versus aucun délai) et est « toujours » valide du fait d’une exécution quotidienne. La procédure automatisée peut d’ailleurs être déléguée au CEI ou au service en charge de préparer l’environnement de test.
Quelques erreurs à éviter lors de l’automatisation des tests
| Cause | Raison |
| Choix de l’outil | Utiliser un outil connu (adhésion technologique des développeurs / contexte) au détriment de l’outil qui traite le mieux la problématique. |
| Confusion maquette (POC) et prototype/outil | La maquette (ou Preuve du Concept) permet de valider la solution au meilleur coût, hormis toute considération de maintenabilité (règles de développement, exploitabilité). Le prototype est un outil qui peut et pourra être utilisé tout en évoluant de façon itérative. |
| Sous-estimation de la difficulté à maîtriser l’environnement | La maîtrise de l’environnement (préambule, postambule, bouchon/simulateur et jeux de données) constitue un enjeu clé pour limiter l’effort d’exécution et d’analyse des automates. Toute divergence entraînerait un résultat erroné ou incertain qui inhiberait tout intérêt de l’automatisation. |
| Double codage de l’application | L’objectif de l’automatisation est de plus rapidement et aisément comparer un résultat attendu et constaté. Il est nécessaire de travailler en mode « boîte noire » plutôt que « boîte blanche », c’est-à-dire piloter les entrées et mesurer les sorties plutôt que comprendre et reproduire le comportement du logiciel. |
| Couverture de tous les cas « possibles » | Le calcul de rentabilité doit limiter le développement d’automates qui n’auraient que peu de valeur et entraînerait des coûts de maintenance et exécution disproportionnés. |
Tableau 2 : erreurs types lors de l’automatisation
Cas d’étude : automatisation de tests d’IHM
Ce tableau reprend les différentes règles à l’implémentation efficiente d’un framework de test. Ces règles sont transposables à d’autres outils de tests automatisés ; elles sont les cas particuliers des règles générales à toute programmation d’un socle commun technique d’une application (framework),
Les exemples sont basés sur QuickTestPro (ou QTP) qui est l’outil HP d’automatisation de tests d’IHM, principalement utilisé pour les tests fonctionnels de non régression.
| Numéro | Règles |
| 1 | Externaliser les variables dans un unique fichier (Ex. « environnement XML ») pour assurer une isolation adéquate aux changements (chemin d’accès, connexion base de données, URL, noms des serveurs, timeout, constantes, messages techniques ou applicatifs…) |
| 2 | Développer des actions réutilisables fonctionnellement cohérentes et consistantes (création d’un compte utilisateur, sélection d’un article dans un panier…). Le scénario de test consiste alors en un enchaînement de ces primitives fonctionnelles enrichies des jeux de données. |
| 3 | Décorréler les actions réutilisables des actions graphiques de navigation (cliquer sur un bouton, sélectionner un menu…) afin de permettre une adaptation simplifiée de la cinématique de l’application. |
| 4 | Développer un framework (Ex. « FWK.vbs) de fonctions techniques appelées dans chacune des autres actions afin d’isoler celles-ci du langage basique ou de la technologie sous-jacente (comparaison d’objets, écriture de logs, synchronisation, contrôles génériques). |
| 5 | Définir une seule bibliothèque (Ex. « object repositiory ») de correspondance d’objets graphiques (IHM) et objets logiques utilisés par les actions réutilisables ou fonctions technique. |
| 6 | Normaliser le codage (nommage, indentation, cartouches, structures…) afin de permettre une relecture statique efficace par un pair, voire outillée. |
| 7 | Versionner tous les éléments, au même titre que tout autre développement. |
| 8 | Calculer systématiquement le retour sur investissement de tout développement d’automate de tests. |
| 9 | Utiliser des scénarios de tests et jeux de données pour valider votre framework (robustesse, exhaustivité de code). |
| 10 | Documenter votre architecture d’automate et implémenter une auto-documentation du framework. |
Tableau 3 : règles générales d’automatisation d’IHM
Approche PROJET
L’automatisation de tests répond à un besoin rentable défini et validé par l’équipe; il peut s’agir de gain en :
- Qualité, en limitant les risques d’erreurs humaines,
- Délai, en exécutant plus rapidement, et/ou en parallèle des actions dévolue à des utilisateurs,
- Coût, en transportant la charge d’un expert vers un automate.
Pour identifier les possibilités d’automatisation, il convient de se poser quelques questions avec les différents acteurs. Les réponses (plutôt) positives incitent à automatiser, une valorisation de ces réponses permet de quantifier le gain potentiel de l’automatisation.
Questionnement
Est-ce que ….
- Description et conception
- Je réalise souvent cette opération (création, contrôle, etc..) ?
- Je sais (saurai) décrire les étapes reproductibles ?
- Je sais (saurai) définir des données de référence valable AU MOINS une année (afin de limiter l’effort de gestion de jeux de données) ?
- Je sais définir les prérequis et points de contrôle du scénario attendu ?
- Des phases de réalisation / contrôles manuels peuvent être (partiellement) industrialisées , tel la création de données, contrat, etc.. ?
- La partie d’application testée est stable dans le temps (absence de développement / évolutions majeures en cours ou prévision) ?
- Utilisation et efficience
- L’application est disponible aux moments souhaités (notamment hors heures ouvrés) sur les environnements de test ?
- Je peux utiliser ces automates dans plusieurs environnements (intégration, tests, UAT, …) ?
- Je suis faiblement / pas dépendant d’un expert d’automatisation pour connaître le résultat d’exécution des automates ?
- Je suis faiblement dépendant pour identifier le problème relevé par un automate (erreur d’application, données, …) – savoir ce qu’il devait faire / a fait ?
- Un automaticien est disponible et engagé à analyser en priorité les anomalies relevées (budget et disponibilité) ?
- Un automaticien est disponible et engagé à appliquer les évolutions pour suivre les versions ? (planning)
Démarche
- Cadrage
- Identification des scénarios METIER
- Evaluation de la charge de mise en oeuvre (abaques)
- Identification fonctionnelle
- Double exécution manuelle dans l’environnement dédié pour valider fonctionnement le choix
- Enregistrement vidéo des scénario ou sous-ensemble retenu
- Chiffrage de la mise en oeuvre de la solution / réalisation de POC dédié / planning
- Validation du chantier d’automatisation
- Réalisation
- Développement
- Mise sous gestionnaire de source
- Tests unitaires
- Validation via erreur (détection d’anomalies)
- Déploiement
- Formation et documentation
- Déploiement sur les environnements cibles
- Planification d’exécution
- Support
- Analyse des exécutions
- Remontée et analyse des anomalies