Le document aborde la stratégie d'automatisation des tests logiciels, en détaillant les critères d'évaluation, les bénéfices de l'automatisation et les différents modes d'automatisation. Il présente également des concepts techniques tels que la gestion des environnements, le codage, et la validation des tests automatisés. Enfin, il met en lumière l'importance de la planification et de la maintenance des tests dans le cycle de développement logiciel.

1. 1
Commission
Test et Qualité Logiciel
18 mai 2017
Animateurs
Julien Van Quackebeke / CEO ALL4TEST
Oliver Garrigues / QA manager Crossknowledge

2. Automatisation du Test des I.H.M
1. Contexte, évaluation et décision, stratégie d’automatisation du test
2. Concepts, modes enregistrement / exécution / rejeu / modulaire
3. Gestion des environnements, des données et paramétrage
4. Codage, exécution, validation, fiabilisation
Présentation de tests automatisés, code, exécution, résultat
5. Planification, évolutivité, maintenance, obsolescence
6. Campagnes de tests automatiques, statut, progrès, indicateurs
7. Outils, environnements, configurations d’automatisation
8. Profils et compétences, certification ISTQB, méthodologie
9. Retours d’expériences, quelques chiffres, conclusions
Un bref exercice d’automatisation, et retour sur investissement
Jean-Luc ARMAGNACQ Architecte Industrialisation Test Logiciel
Sophia Antipolis – 18 mai 2017 certifié ISTQB

3. 3
1. Contexte, évaluation et décision d’automatisation des tests
▌ Contexte
- Application IHM avec important volume écrans / pages > 10
- Fonctionnalités > 10 et Use cases / User stories > 20
- Développement incrémental des nouveautés fonctionnelles
- Faible taux de modification de l’existant, longue vie des tests avec faible maintenance < 10%
- Multiplicité des environnements (plate-formes, systèmes d’exploitation, navigateurs)
- Répétitivité des tests, existence de séquences communes
- Campagnes de tests de non-régression fréquentes, journalières, hebdomadaires
- Itérations et pilotage des tests avec données
- Maximisation de la couverture de test, couverture combinatoire, systématisation des tests
Evaluation de l’automatisation
- Selon l’effectivité des critères présentés ci-avant.
Décision d’automatisation des tests
- O U I si > 3 critères sont effectifs.
- NON dans le cas contraire; c’est aussi une décision acceptable.

4. 4
1.1 Stratégie d’automatisation des tests
▌ Stratégie, définie selon…
- Couverture du périmètre du test par l’automatisation
- Priorité des tests à automatiser
- Complexité des tests
- Disponibilité des fonctionnalités à tester
- Disponibilité des environnements de test
Tests automatisables, par type
- Fonctionnel Positif : déroulement nominal de l’application
- Fonctionnel Négatif : déroulement avec traitement des erreurs
- Performance : capacités de l’application
- Stress : résistance aux sollicitations intenses
- Endurance : stabilité au cours du temps
- Sécurité : résistance aux malveillances
Objectifs
- Couverture : maximisée
- Fiabilité : respect du déroulement spécifié
- Régularité : absence de fatique humaine
- Exploitabilité : exécution 24h/24
Tests non automatisables
- Fonctionnalité trop évolutive
- Complexité trop grande
- Développements applicatifs spécifiques lourds
- Environnements spécifiques coûteux
- Limites techniques de l’outil d’automatisation

5. 5
1.2 Bénéfices de l’automatisation des tests
▌ 4 contributions de l’automatisation au test logiciel industrialisé
Précision
- Traçabilité de la couverture de test, définition et connaissance du périmètre testé et non testé
- Fiabilité du périmètre testé, aucun risque de simplification dans l’exécution des tests
Régularité
- Répétition systématique des scénarios de test, aucune improvisation dans l’exécution des tests
- Absence de distorsion dans la couverture de test, comparaisons strictes des exécutions des tests
Productivité
- Maximisation de l’utilisation des ressources machines 24H/24
- Absence de baisse de vigilance, rigueur constante au cours des exécutions des tests
Qualité
- Délégation des tâches répétitives et fastidieuses aux machines
- Affectation des tests intrusifs et tâches gratifiantes aux humains

6. 6
2. Concepts, modes enregistrement, exécution, rejeu, modulaire
▌ Concepts des tests automatiques
Capacités des outils
- Enregistrement et exécution du script de test
- Reconnaissance des objets de l’IHM et de leur organisation statique et dynamique (création, modification, suppression)
- Acquisition des actions effectuées
- Acquisition des données utilisées
- Définition des états de l’IHM
- Activation des objets de l’IHM
- Vérification des états de l’IHM
Mode enregistrement
- Acquisition des actions sur l’IHM par l’utilisateur : menus, boutons, entrées clavier, déplacements pointeur.
- Définition des états attendus des composants de l’IHM : activation, couleur, texte, image...
Mode exécution
- Déclenchement des actions sur l’IHM : menus, boutons, entrées, déplacements.
- Vérification des états effectifs des composants de l’IHM / états attendus.

7. 7
2. Modes d’automatisation, mode rejeu, mode modulaire
Automatisation en mode rejeu cible : Quelques dizaines de tests très stables
- Exécution des actions avec les données enregistrées.
- Facilité de création du script des actions et des vérifications.
- Impossibilité de réutilisation des actions et des vérifications , nécessité de réenregistrer.
- Difficulté de gestion des objets dynamiques.
- Difficulté importante de maintenance des actions et des données, nécessité de réenregistrer.
- Fiabilité faible face aux aléas d’exécution (délais, temps de réponse applicatifs…).
Automatisation en mode modulaire cible : Plusieurs centaines de tests potentiellement évolutifs
- Exécution du code des actions avec les données enregistrées ou paramétrées.
- Facilité de création et accessibilité au code enregistré des actions et des vérifications.
- Réutilisation du code des actions et des vérifications.
- Gestion efficace des objets dynamiques
- Flexibilité du code, paramétrage des données, injection de données, pilotage par les données.
- Facilitation de la maintenance des actions, des vérifications et des données.
- Fiabilité assurée par gestion des délais et des temps de réponse applicatifs.
- Complexité de gestion accrue pour le code et les données.
cible : quelques dizaines de tests très stables
cible : plusieurs centaines de tests potentiellement évolutifs

8. 8
3. Gestion des environnements, des données, paramétrage
▌ Les environnements applicatifs
- Plateformes : PC, Mac, tablette, téléphone…
- Systèmes d’exploitation : Windows, Unix, Linux, MacOS, Androïd…
- Navigateurs internet : Chrome, Internet Explorer, Firefox, Safari…
Gestion des données
- Script statique : déroulement prédéfini, utilisateur des données.
- Script dynamique : déroulement flexible, piloté par des données.
Paramétrage des scripts
- Séparation des données, paramétrage des valeurs utilisées dans les actions, initialisation au début du code.
- Utilisation des jeux de données : URL de connexion, noms d’utilisateurs, mots de passe…
Un même script est exécuté avec des valeurs différentes
- Itération sur les données : tableaux de valeurs
Un même script est exécuté avec toutes les valeurs possibles
- Pilotage par les données : différents comportements selon les valeurs des données
Un même script est exécuté de manière différente suivant les données

9. 9
4. Codage, exécution, validation, fiabilisation
▌ Codage pour l’automatisation en mode modulaire
- Composants réutilisables, actions, données, vérifications.
- Indispensable quand des tests partagent des séquences identiques.
- Effort important à la création pour une structuration du code.
- Maintenance facilitée par l’efficacité au plus haut niveau des modifications de bas niveau.
4 niveaux de codage, du niveau 1 - natif au niveau 4 - test
1. Action : activation des composants de l’IHM
Clic bouton, sélection menu déroulant, entrée clavier, couper, coller, glisser, déplacer...
Vérification : comparaison entre état attendu et état effectif de l’IHM
État, couleur, position, valeur d’un champ de saisie, d’un menu, d’un bouton...
2. Opération : actions sur l’IHM + vérifications éventuelles.
Connexion = entrée d’un nom d’utilisateur, du mot de passe, activation de la connexion + vérification de connexion
Déconnexion = activation de la déconnexion + vérification de déconnexion
3. Séquence : suite d’opérations, d’actions et de vérifications.
Changement mot de passe = activation du changement + entrée ancien mot + entrée nouveau mot + validation
4. Test : suite de séquences , d’opérations, d’actions et de vérifications.
Modification mot de passe = Connexion + Changement mot de passe + Déconnexion

10. 10
4.1.1 Codage, règles de développement
▌ Règles de codage
- Langage de script automatique généralement faiblement typé, devenant confus si mal organisé !
- Règles indispensables pour la création et la maintenance du code.
– Objets nom préfixé selon le type pour identifier à première lecture son type et les méthodes applicables
en lettres minuscules + soulignement
• objet IHM : obj_button
• descripteur de propriétés : dsc_button
• nombres : i, j, k, index_row, nb_columns, total_amount
• chaines caractères (strings) : str_user, str_password
• tables : tab_flights
• structures (records) : rec_flight
• fichiers (files) : fil_products
• base de données (data base) : dba_customers
– Conséquences sur le code applicatif IHM :
• nécessité impérative d’ identifiants définis pour les objets IHM statiques et dynamiques
• pour la reconnaissance des objets à l’enregistrement des actions et des vérifications
• pour l’ utilisation des objets à l’exécution du script

11. 11
4.1.2 Codage, règles de développement
– Méthodes nom préfixé par le type d’objet et suffixé par l’opération sur l’objet
en lettres majuscules et minuscules sans soulignement
• DepartureCityMenuSelect()
• SearchButtonActivate()
– Scripts nom du script selon une nomenclature, par exemple <code>_<type>_<priorité>_<scénario>
• fonctionnel positif priorité 1 / élevée 100_FPS_1_VoyageRéservation
• fonctionnel positif priorité 2 / moyenne 110_FPS_2_VoyageAnnulation
• fonctionnel négatif priorité 3 / faible 120_FNG_3_VoyageErroné
pour faciliter :
• l’identification des scripts par type, fonctionalité, priorité, etc…
• l’ordonnancement automatisé dans les outils de gestion des scripts
• la construction et l’exécution des campagnes de tests selon périmètre défini
▌ Nécessité des règles de codage
Complexité faible ou moyenne du code de chaque script
Volume important et en expansion du code total de tous les scripts

12. 12
4.2 Codage, architecture et indépendance des scripts
▌ Architecture de script automatique
- Un script doit être indépendant
• Ne pas dépendre du résultat d’un script précédant (exécution précédante non garantie)
• Ne pas fournir de résultats pour un script suivant (exécution courante non garantie)
- Mais pas toujours réalisable ou souhaitable, et celà augmente la complexité des campagnes
Initialisation
- Prérequis, acquisition des données d’entrée des paramètres depuis tables, fichiers, base de données
- Lancement de l’application
Exécution
- Déroulement des instructions d’action et de vérification
- Utilisation des valeurs initialisées et calculs intermédiaires éventuels
- Productions des données de sortie dans tables, fichiers, base de données
Conclusion
- Libération des ressources, fermeture de fichiers, bases de données
- Sortie de l’application

13. 13
4.3 Exécution, validation, fiabilisation
▌ Exécution
- Sur configuration native phase de mise au point initiale
- Sur autres configurations plateformes, systèmes, navigateurs phase de mise au point finale
Validation
- Identification des objets éventuellement dépendante des configurations
- Exécution des actions
- Vérification positive et négative des états éventuellement dépendante des configurations
Fiabilisation
- Gestion des délais et temps de réponse avec durées fixes
- Gestion des absences des éléments IHM avec durées variables asservies aux objets
- Exécutions multiples avec divers jeux de données pour atteindre la stabilité
Performances d’exécution
- Fortement dépendantes des temps de réponse de l’application parfois décevant… 
- Légèrement supérieures à celles d’un opérateur humain sans erreur, sans fatique, toujours rassurant ! 

14. 14
Présentation de tests automatisés 1/5
▌ Projet SiNOP
Tests
- arborescence
- par domaine
- nomenclature
- données paramètres
- codage niveau 4
96 tests
58 tests automatisés
75 minutes d’exécution

15. 15
Présentation de tests automatisés 2/5
▌ Projet SiNOP
Fonctions utilitaires
- arborescence
- par domaine
- nomenclature
- codage niveau 1, 2, 3

16. 16
Présentation de tests automatisés 3/5
▌ Projet SiNOP
Objets de l’ IHM
- arborescence
créée automatiquement
par enregistrement
- classe de l’objet
- identifiant de l’objet

17. 17
Présentation de tests automatisés 4/5
▌ Projet SiNOP
Résultat d’exécution
- test exécuté
- paramètres instanciés
- expansion du code
- statut passé / échoué

18. 18
Présentation de tests automatisés 5/5
▌ Projet SiNOP
Campagne de tests
- synthèse de l’exécution
- graphe de statut de la campagne
- durées d’exécution des tests
- statut d’exécution des tests

19. 19
5. Planification, évolutivité, maintenance, obsolescence
▌ Planification
- Origine des tests automatiques : tests manuels automatisés / tests spécifiques d’automatisation
- Agrégation de tests simples / exécution optimisée
- Segmentation de tests complexes / compréhension et exécution faclilitées
- Cycle de vie du test automatique avec utilisation d’états : conception, prêt, maintenance, obsolète
Evolutivité
- Anticipation des évolutions de l’IHM de l’application
=> La méthode modulaire est seule garante d’une gestion à coût maîtrisé
Maintenance
- Sur modification de fonctionnalité dans la conception de l’IHM et dans son fonctionnement
- Préventive : notification des modifications permettant une évolution anticipée des tests
- Curative : notification déficiente des modifications induisant une évolution tardive des tests
Obsolescence
- Fonctionnalité supprimée : tests inutiles pour les campagnes ultérieures.
- Fonctionnalité remaniée : maintenance plus coûteuse que la création de nouveaux tests.

20. 20
5.1 Exemple de maintenance
Fonctionalité de connexion : utilisateur + mot de passe
Niveau 2 Opération : Connexion
entrée d’un nom d’utilisateur, du mot de passe, activation de la connexion + vérification de connexion
Niveau 4 Test : Modification mot de passe = Connexion + Changement mot de passe + Déconnexion
Fonctionalité de connexion modifiée : utilisateur + domaine + mot de passe
Niveau 2 Opération : Connexion avec séquence d’actions modifiée
entrée d’un nom d’utilisateur, du domaine, du mot de passe, activation de la connexion + vérification de connexion
Niveau 4 Test : Modification mot de passe = Connexion + Changement mot de passe + Déconnexion
- Une seule opération modifiée (Niveau 2)
- Aucun test n’est modifié (Niveau 4)
- Tous les tests utilisant cette opération bénéficient de la nouvelle version de l’opération

21. 21
5.2 Gestion du développement des test automatiques
▌ Automatisation = développement de code !
Développement
- Cycle de vie avec états des tests automatiques
- Ordonnancement du développement des tests, par type, catégorie, priorité, complexité, fonctionnalité…
Tableaux de bord
- Statut du périmètre des tests développés selon leur état.
- Progression des test développés par état.
- Analyse des états selon type, catégorie, complexité, priorité, environnement, fonctionnalité…
Indicateurs
- Stabilité des scripts sur versions successives de l’application.
- Aide à la décision pour livraison des scripts permettant la construction et l’exécution des campagnes.
• Conception
• Prêt
• Maintenance script / données / environnement
• Obsolète

22. 22
5.3 Tableau de bord de développement de tests automatiques
Progression Statut ( jour 11 )

23. 23
6. Campagnes de tests automatiques, statut, progrès, indicateurs
▌ Gestion des campagnes, organisation des tests, exploitation des résultats
- Optimisation des diverses phases selon les ressources, consolidation progressive, décisions sur résultats
Construction des campagnes automatiques
- Ordonnancement des tests, par type, catégorie, priorité, complexité, fonctionnalité…
- Périmètre réduit (vérifications préliminaires) ou périmètre total (validations complètes)
Exécution des campagnes automatiques
- Allocation de machines
- Programmation des campagnes par créneaux horaires
Tableaux de bord
- Statut des tests exécutés : passés, échoués, incomplets, bloqués.
- Progression des test exécutés par statut d’exécution.
- Répartition des résultats selon type, catégorie, complexité, priorité, environnement , etc…
Indicateurs
- Stabilité des campagnes sur versions successives de l’application sans anomalie grave.
- Aide à la décision pour livraison de l’application IHM : accord / opposition

24. 24
6.1 Exécution des campagnes de tests automatiques
▌ Séquencement et initialisation des phases d’exécution des tests
Sélection
- Tests prêts avec scénario, données, environnements
- Périmètre testé : total ou partiel selon priorité, complexité, fonctionnalité…
- Type de test : fonctionnel positif, négatif, performance, endurance, stress, sécurité…
• Statut Non exécuté : initialisation pour l’exécution
Exclusion
- Tests bloqués par anomalies non corrigées
• Statut Bloqué : initialisation excluant l’exécution
- Tests temporairement inutilisables, maintenance ou fonctionnalités, données, environnements indisponibles
• Statut Non applicable : initialisation excluant l’exécution
Exécution
- Lancement manuel d’une campagne de plusieurs tests
- Lancement programmé de plusieurs campagnes 24h/24
Exploitation des statuts d’exécution des tests
• Statut Passé : aucune anomalie selon les vérifications définies dans le script
• Statut Echoué : anomalie détectée par une vérification définie dans le script
• Statut Incomplet : interruption imprévue hors des vérifications définies dans le script

25. 25
6.2 Tableau de bord d’exécution de tests automatiques
Progression Statut ( jour 2 )

26. 26
6.3 Analyse des campagnes de tests automatiques
▌ Résultats des exécutions, analyse des anomalies et conséquences
Exécution sans anomalie
- C’est déjà un résultat !
- Certitude de bon fonctionnement du périmètre applicatif testé
- Incertitude hors du périmètre testé
=> Extension nécessaire du périmètre testé pour augmenter les probabiltés de détection d’anomalies
Exécution avec anomalies
- Des régressions ont été introduites dans le périmètre testé
- Efficacité avérée du périmètre défini pour la détection d’anomalies
- Incertitude hors du périmètre testé
=> Extension prévisionnelle du périmètre testé pour augmenter les probabiltés de détection d’anomalies
Analyse des anomalies
- Détection de non-conformités par rapport aux comportements nominaux attendus par les tests
- Validation d’une réelle anomalie de l’application
- Evolution application, données, environnement non intégrée dans les tests : maintenance curative des tests
- Evaluation d’un suivi des anomalies des tests automatiques (scripts, données, environnements) avec tableau de bord

27. 27
7. Outils, environnements, configurations d’automatisation
▌ Quelques caractéristiques communes
- Expérience sur du long terme
- Evolution permanente des capacités (plateformes, systèmes, navigateurs)
- Support technique et réactivité
- Couplage avec outils de gestion de tests et leurs diagrammes et rapports de suivi
- Forums d’utilisateurs
- Coût d’utilisation non négligeable
U.F.T + A.L.M www8.hp.com/fr/fr/software-solutions/unified-functional-automated-testing
TestComplete + QAComplete smartbear.com/product/testcomplete/overview
Quality First Software QF-Test www.qfs.de
Squish www.froglogic.com/squish

28. 28
7.1.1 Outils et environnements d’automatisation
▌ HP U.F.T
Caractéristiques
• Enregistrement des actions sur l’IHM, Reconnaissance objets IHM, Accès aux propriétés des objets
• Contrôles textes, d’images, états, Synchronisation et délais
• Bibliothèques de composants, Paramétrage des données, Interface Excel et bases de données
• Exécution de tests en séquence, Pilotage par outil en mode 24h / 24
• Android, iOS, Windows
• Chrome, Firefox, Internet Explorer, Safari
• VBScript
Commentaires
+ intégration avec HP-ALM
+ gestion code et données partagées
- support multi-navigateur restreint
- quelques lourdeurs à l’usage

29. 29
7.1.2 Outils et environnements d’automatisation
▌ Smartbear TestComplete
Caractéristiques
• Enregistrement des actions sur l’IHM, Reconnaissance objets IHM, Accès aux propriétés des objets
• Contrôles textes, d’images, états, Synchronisation et délais
• Bibliothèques de composants, Paramétrage des données, Interface Excel et bases de données
• Exécution de tests en séquence, Pilotage par outil en mode 24h / 24
• Desktop, Mobile, Web
• Chrome, Edge, Firefox, Internet Explorer, Opera, Safari
• C++Script, C#Script, DelphiScript, Jscript, JavaScript, Python, VBScript
Commentaires
+ intégration avec QAComplete
+ support multi-navigateur étendu
- rigueur d’utilisation requise

30. 30
7.1.3 Outils et environnements d’automatisation
▌ Quality First Software QF-test
Caractéristiques
• Enregistrement des actions sur l’IHM, Reconnaissance des objets IHM, Accès aux objets par Jython
• Contrôles textes, d’images, états, Synchronisation et délais
• Bibliothèques de composants, Paramétrage des données, Interface Excel et bases de données
• Exécution de tests en séquence, Pilotage par commande
• Unix / Linux, Windows
• Chrome, Edge (2016), Firefox, Internet Explorer, Safari (2016)
• QF script (pour fonctions basiques) + Jython ( pour fonctions complexes)
Commentaires
+ initiation aisée mais des limitations
- support multi-navigateur restreint
- scripting QF + Jython peu pratique et confus

31. 31
7.2 Configuration de la plateforme d’automatisation
▌ Poste de développement
Caractéristiques générales
• Similaires aux postes de développement logiciel applicatif
• Puissance CPU pour gestion simultanée
 application
 outil développement de test
 outil de gestion des tests
• Bi-écran pour gestion des multiples fenêtres
• application
• code de test
• arborescence et propriétés des objets IHM
• paramètres de test
▌ Machine d’exécution
Configuration classique
• Minimum : postes de développement license développement utilisation nuit et week-end
• Optimum : machines d’exécution license d’exécution utilisation 24h / 24
Bonus
• 2 machines / développeur de script automatique pour utilisation parallèle développement / exécution / debug
(L’exécution des scripts automatisés interdit l’utilisation clavier et pointeur sur l’IHM en cours de test)

32. 32
8. Profils et compétences, certification ISTQB, méthodologie
▌ Automatisation de test : c’est une activité spécifique
- Automatiser les tests, c’est développer du code !
- Développement “léger” spécifié dans un plan de test rigoureusement documenté.
- Complexité engendrée par le nombre des tests et leur maintien en condition opérationelle.
Profils
- « Testautomaticien » = développement 80% + fonctionnel 20%
Compétences
- Maîtrise architecture des IHM et les hiérarchies, les propriétés et les méthodes des objets.
- Codage modulaire VB, C#, Java…
Certification ISTQB
- Foundation
- Advanced / Automation
- Facultative : structurante dans les pratiques et qualifiante pour les profils.

33. 33
8.1 Méthodologie : séquencement en 3 phases
▌ Phase 1 - Audit
- Analyse de l’existant : tests manuels, campagnes de test, outils de suivi et métriques associées
- Définition de la stratégie : périmètre initial, périmètre final, priorités, calendrier, jalons
- Proposition de solution d’automatisation et outillage
- Préconisation d’architecture de la plateforme (machines d’automatisation et d’exécution)
▌ Phase 2 - Concept Probatoire (P.O.C)
- Définition d’un périmètre réduit de tests significatifs
- Expérimentations des capacités, contraintes et limites des outils d’automatisation pour l’ IHM
- Paramétrage des outils, configurations, personnalisations
- Elaboration du suivi de l’activité, indicateurs, graphes, tableaux de bord, rapports…
- Evaluations en multi-navigateur, en multi-système
- Prototypes des plateformes :
• pour développement et maintenance des tests
• pour exécution des campagnes
- Validation de la stratégie, évaluation des profils requis
- Validation de la solution technique et de son suivi

34. 34
8.2 Méthodologie
▌ Phase 3 - Industrialisation
- Installation de la plateforme (machines d’automatisation et d’exécution)
- Déploiement de la solution selon la stratégie et extension progressive au périmètre complet
- Migration de l’existant (exigences, tests, données de test, environnements de test, campagnes de tests…)
- Création progressive des nouveaux éléments de test directement dans le nouvelle solution industrialisée
- Suivi des indicateurs de progression du déploiement de la solution
- Formation des profils à la solution technique
- Accompagnement et suivi de la stratégie

35. 35
▌ 5 projets / 10 années
- Forte volonté d’automatisation du test, sans expérience ou expérience peu concluante.
- Déploiement stratégie modulaire.
- Réussite opérationnelle validée par d’intensives campagnes de non-régression.
IN7 2001
- 50 scripts / 150 tests, IHM Java, 3 systèmes X11-Unix, X11-VMS, Windows Segue SilkTest
e-Travel 2003 - 2007
- 350 scripts / 800 tests, IHM web, 1 navigateur, 3 environnements (GDS) Mercury WinRunner
Wallaby & Hotel Portal 2011
- 50 + 20 scripts / tests, IHM web, 1 navigateur HP Quick Test Pro (Q.T.P)
PlantstruXure 2011 - 2013
- 300 scripts / tests, IHM Java, 2 systèmes Windows 7, Windows 8 SmartBear TestComplete
eCommerce 2015
- 50 scripts / 300 tests, IHM web, 2 navigateurs, 3 portails, Windows HP Unified Functional Testing (U.F.T)
9. Retours d’expériences, quelques chiffres

36. 36
Abaque effort ( jour.homme / nombre de scripts )
▌ L’effort de d’automatisation diminue avec l’augmentation de la couverture de test.

37. 37
Abaque charge ( jour.homme / script )
▌ La charge unitaire d’automatisation diminue par capitalisation et réutilisation.

38. 38
9. Conclusions pour l’automatisation des tests I.H.M
▌ Comment réussir l’automatisation…
Gestion de l’automatisation comme un projet, avec ses propres ressources techniques et humaines.
Sélection d’un outil approprié au contexte de l’application.
Allocation de ressources pour le développement et la maintenance des tests automatiques.
Définition des responsabilités de conception, développement, maintenance des tests automatiques.
Spécificité des profils d’automaticiens de tests différents des testeurs et des développeurs.
Utilisation de l’automatisation pour pallier les déficiences de l’exécution des tests manuels.
Définition de tests automatiques raisonnablement complexes.
Minimisation du nombre de tests automatiques défectueux (simplicité, maintenabilité).
Début de l’automatisation dès la disponibilité d’une version relativement stable de l’application.
Anticipation de la maintenance des tests pour assurer leur fiabilité et leur réutilisation.
Incapacité de l’automatisation à remplacer tous les tests manuels.

39. 39
▌ Application I.H.M
Réservation de voyages sur internet :
- comportant de 1 à 3 éléments Avion Hôtel Voiture
- pour 3 navigateurs internet i.explorer chrome firefox
Couverture de test prévue
- Tests positifs : scénarios de voyages élaborés par association de 1à 3 éléments, tous séquencements possibles.
• 3 scénarios avec 1 élément : A H V
• 6 scénarios avec 2 éléments : AH AV HV HA VA VH
• 6 scénarios avec 3 éléments : AHV AVH HVA HAV VAH VHA
- Tests négatifs : destinations invalides ou indisponibles, dates erronées, séquences de dates invalides ou indisponibles.
• 3 scénarios avec destinations : A H V
• 3 scénarios avec dates : A H V
- Totalité des scénarios sur les 3 navigateurs ie cr fx
- Couverture totale nécessite la définition de 63 tests = 21 scénarios x 3 navigateurs
Un bref exercice d’automatisation 1/3

40. 40
▌ Stratégies de test
tests manuels
- selon fréquence d’occurrence, exclusion des similarités, minimisation de la sollicitation des ressources humaines
- Tests positifs : 7 scénarios avec 1 à 3 éléments A H V AH AV HV AHV
- Tests négatifs : 6 scénarios avec destinations et dates A H V
13 scenarios sur les 3 navigateurs ie cc fx
39 tests manuels = couverture de 60 %
avec capacité d’exécution = 5 tests / h durée = 8 heures / 1,0 jour début j0 / matin fin j0 / soir
63 tests manuels durée = 12 heures / 1,5 jour début j0 / matin fin j0 + 1 / midi
tests automatiques
- sans a priori de fréquence, ni sur les similarités, et maximisation de l’exploitation des ressources machines
- Tests positifs : 15 scénarios avec 1 à 3 éléments A H V
AH AV HV HA VA VH
AHV AVH HVA HAV VAH VHA
- Tests négatifs : 6 scénarios avec destinations et dates A H V
21 scenarios sur les 3 navigateurs ie cr fx
63 tests automatiques = couverture de 100%
avec capacité d’exécution = 5 tests / h durée = 12 heures / 1,0 nuit début j0 / soir fin j0 + 1 / matin
Un bref exercice d’automatisation 2/3

41. 41
Un bref exercice d’automatisation 3/3
▌ Analyse de l’automatisation du test
Bilan manuel / automatique
- Tests manuels couvrent une combinatoire partielle des 3 éléments pour une couverture raisonnable.
- Tests automatisés couvrent la combinatoire complète des 3 éléments pour une couverture exhaustive.
- Avec des ressources machines utilisées 24h/24.
- Supériorité de l’automatisation après l’effort de codage des scripts avec retour sur investissement avéré.
Optimisation de l’automatisation
- Fusion des tests négatifs avec les destinations et dates : réduction de 6 tests à 3 tests de thèmes similaires.
- Création d’un seul script piloté par les données, instancié 15 fois pour les 15 scénarios positifs.
script_A (aéroport_départ, aéroport_arrivée, date_aller, date_retour) /* test avion par script spécifique */
script_H (ville_séjour, date_arrivée, date_départ) /* test hôtel par script spécifique */
script_V (agence_location, date_début, date_fin) /* test voiture par script spécifique */
script_G (E, lieu_départ, lieu_arrivée, date_initiale, date_finale) /* script générique de voyage */
script_G (A, aéroport_départ, aéroport_arrivée, date_aller, date_retour) / * test avion, instance du script générique */
script_G (H, ville_séjour, 0, date_arrivée, date_départ) / * test hôtel, instance du script générique */
script_G (V, agence_location, 0, date_début, date_fin) / * test voiture, instance du script générique */

42. F i N
jean-
luc.armagnacq@thalesgroup.com
+33 6 31 84 78 04

43. 43
www.telecom-valley.fr
Merci de votre attention !
▌ Telecom Valley : Commission Test & Qualité Logiciel
▌ Meetup : Software Testers Club - Test et Qualité Logiciel
▌ Hub Linkedin : Test & Qualité Logiciel de Telecom Valley