Automatisation des tests : Quoi et quand tester ?

L'automatisation des tests (AT) était dans tous les esprits il y a quelques années. Cependant, le niveau moyen d'automatisation n'était que de 16%, selon [Legeard 2017]. Le DevOps est désormais la norme pour 80% des équipes agiles. Cela signifie qu'elles utilisent un outil d'intégration continue comme Jenkins ou Gitlab-ci [Bensten 2019]. L'automatisation des tests est incontournable car elle permet aux développeurs d'avoir un retour d'information rapide.

Qu'est-ce que l'automatisation des tests ?

L'automatisation des tests est plutôt liée aux "vérifications automatisées", car les tests sont en fait un défi intellectuel [Bach 2014]. L'automatisation des tests doit être complétée par des tests manuels pour garantir la qualité des logiciels. Cela est vrai quelle que soit la maturité d'automatisation de votre organisation [Bach 2014]. Les testeurs peuvent se familiariser avec les scripts s'ils se concentrent uniquement sur l'automatisation des tests. Cependant, ils peuvent ne plus comprendre le système sous test (SUT) [Bradshaw 2019-2].

‍

L'automatisation des tests désigne toute activité d'outillage qui rend les tests plus efficaces et moins ennuyeux [Bach 2016]. Il s'agit par exemple d'automatiser la génération de données de test ou de créer des scripts pour "masquer" les tâches manuelles [Bradshaw 2019-2] [Graham 2012]. La vérification automatisée contribue également à faciliter les tests et à les rendre moins ennuyeux.

Les tâches d'automatisation nécessitent des outils spécifiques pour répondre à certains besoins. Les testeurs devraient connaître plusieurs outils. Cela pourrait conduire à renommer l'automatisation des tests en "l'automatisation dans le test" [Bradshaw 2019-2].

L'automatisation des tests, comme on l'appelle, est souvent sujette à des problèmes de maintenance et à un manque de fiabilité. Les scripts automatisés ne sont pas en mesure de faire face à des problèmes inattendus tels que des problèmes d'environnement, des données incorrectes ou des problèmes liés aux scripts de test :

• Les outils ne peuvent pas juger des situations de réussite ou d'échec [Fewster 1999], mais la façon dont le script indique comment vérifier la qualité de l'information est un facteur déterminant pour le succès de l'opération.
• Les scripts peuvent ne pas être adaptés aux nouvelles versions du SUT.

Ces questions imposent de fortes contraintes sur ce qui doit être automatisé au bon moment pour obtenir un assez bon retour sur investissement en matière d'assistance technique.

Que faut-il automatiser ?

Fondamentalement, puisque les vrais tests consistent à apprendre quelque chose sur le SUT, chaque fois que vous n'apprenez rien d'un script de test, vous pouvez l'automatiser [Bradshaw 2019-2]. Mais lorsqu'il s'agit de douzaines de scripts, pour prioriser les scripts de test à automatiser, vous pouvez simplement demander [Graham 2012] :

• Qu'est-ce qui doit être automatisé ?
• Qu'est-ce qui devrait être automatisé ?
• Qu'est-ce qui pourrait être automatisé ?
• Qu'est-ce qui ne sera pas automatisé ?

et garder à l'esprit que tous les tests ne peuvent ou ne doivent pas être automatisés [ISTQB 2016], en particulier si le SUT n'est pas conçu avec une testabilité automatisable qui pourrait être impliquée dans les scripts [Fewster 1999] [ISTQB 2016]. Cette approche MoSCoW est un début simple qui peut être affiné avec des critères tels que [Fewster 1999] [Jones 2018] :

• la fréquence d'utilisation d'une fonctionnalité à tester
• la complexité de l'automatisation du script de test
• l'impact sur la valeur ajoutée perçue de la caractéristique testée
• la rapidité avec laquelle les bugs trouvés par le script de test peuvent être corrigés
• la rapidité avec laquelle le script de test peut être codé
• la fréquence des ruptures et le volume de bugs trouvé dans la zone testée

et aussi :

• les tests peuvent constituer un goulot d'étranglement dans le flux de livraison. Certains tests sont difficiles à exécuter manuellement [Colantonio 2018] [Graham 2012].
• l'automatisation des scripts de test sur un prototype peut ne pas être rentable. Par conséquent, il est important de considérer le coût par rapport à la durée de vie de la fonctionnalité, comme indiqué par [Hage Chahine 2023]. En outre, vous devriez récupérer quelques estimations de la maturité de la fonctionnalité, selon [ISTQB 2016].
• la couverture du script de test [Axelrod 2018] devrait également vous guider pour définir quelles parties non couvertes (fonctionnalités, code, branche et éventuellement couverture de décision) seront protégées en fonction de votre contexte.

Parmi ces critères de sélection, vous pouvez également prendre en compte ces conseils supplémentaires [Axelrod 2018] :

Envisager l'automatisation des tests :

• des parties stables avec un projet de remplacement de certains composants sous-jacents
• les éléments pour lesquels il est nécessaire d'améliorer les performances
• les parties sujettes à des erreurs
• "Test de confirmation" (aka "defect-driven testing) en reproduisant les étapes qui ont permis de reproduire le bug [ISTQB 2016].

Éviter l'automatisation des tests sur :

• les pièces dont le remplacement est prévu
• les pièces très stables sans intention de les toucher prochainement

Lorsque vous commencez l'automatisation des tests, votre organisation peut décider qu'il y aura d'abord une équipe dédiée responsable de l'automatisation des scripts pour plusieurs projets. Cette configuration peut être utilisée comme preuve de concept pour susciter l'adhésion de la hiérarchie et des équipes. Cela contribuera à la diffusion des pratiques d'automatisation des tests. Cependant, ce n'est pas une bonne idée à long terme. Elle peut créer un silo au sein du flux de développement du projet, entraînant des retards et des problèmes de communication.

En ce qui concerne les scripts à automatiser, vous devez :

• choisir les tests les plus utiles dans le parcours client le plus courant [Hage Chahine 2023][ISTQB 2016]. Ces tests doivent avoir une forte valeur ajoutée et affecter à la fois les clients et les actifs de votre organisation. Pour ce faire, impliquez les parties prenantes dans la définition de la valeur ajoutée des tests. Cela créera une adhésion, en particulier si l'automatisation des tests ne fait que commencer [Bradshaw 2019-1].
• planifier une croissance ultérieure pour viser juste assez de couverture de la valeur ajoutée basée sur les fonctionnalités, avant de se lancer dans une couverture de test approfondie [Axelrod 2018], parce que cela peut ralentir votre boucle de rétroaction et augmenter les coûts maintenance trop tôt [Graham 2012] [Fewster 1999].

L'automatisation des tests requiert une certaine maturité qui inclut des compétences telles que la capacité [ISTQB 2016] :

• à automatiser - cela peut être réduit grâce à des plateformes d'automatisation à faible code/no-code 
• pour analyser les résultats des tests - bugs, les faux positifs et flaky tests doivent être traités correctement pour permettre des améliorations tant au niveau de la SUT que de l'automatisation des tests.
• pour répondre aux exigences non fonctionnelles de tests automatisés

Ces défis peuvent être facilités par : 

• un SUT testable avec des environnements de test stables pour avoir des scripts déterministes [Colantonio 2018].
• des petits scripts de test - et donc faciles à maintenir [Axelrod 2018]
• une approche progressive [Graham 2012]

Cela permettra de construire un "fil d'acier" de tests solides comme le décrit [Graham 2012]. Ce fil sera utilisé pour créer progressivement un parcours client au sein des processus métier, comme détaillé dans [Axelrod 2018]. Il permettra également de mettre en place les quadrants de tests au cours du sprint.

‍

Stratégie d'automatisation des tests

N'oubliez pas l'étymologie du mot "stratégie" lorsque vous créez un plan d'automatisation de tests. Le mot "stratégie" vient des mots grecs "stratos" (armée) et "ageîn" (diriger). Cela suggère que vous devriez prendre les avantages de toutes les personnes impliquées dans la livraison du SUT [Graham 2012], et inclure également les développeurs [Segal 2022], notamment pour éviter les silos et améliorer le retour sur investissement. En fait, l'automatisation de tests est une activité à laquelle tout le monde peut participer [ISTQB 2016], même les personnes qui n'ont pas de compétences en codage lorsqu'il s'agit d'analyser les rapports de test.

Étant donné que les tests doivent être effectués le plus tôt possible, conformément à la directive "Shift Left" [ISTQB 2018], le SDLC devrait également être pris en compte par l'automatisation des tests. Culturellement, les testeurs ne voient l'automatisation des tests que du point de vue de l'interface graphique : pour un marteau, le monde est fait de clous !

En fait, l'automatisation des tests offre de nombreuses possibilités à chaque niveau de la pyramide des tests d'automatisation :

• Au niveau de l'intégration - des scripts de test automatisés garantissent que les composants sont capables de fournir une partie d'un service complet. Les mocks et les stubs offrent alors la possibilité d'isoler les scripts de test et d'améliorer la répétabilité et la rapidité.
• Les tests unitaires doivent être automatisés au niveau du code et des composants. C'est à ce niveau que les tests auront le meilleur retour sur investissement, selon [Graham 2012]. Ceci est particulièrement vrai lorsque l'on considère la couverture du code, des branches et des décisions.

La pyramide des tests est un concept bien connu. Elle recommande d'automatiser un grand nombre de tests unitaires, moins de tests d'intégration et quelques tests de bout en bout. Les tests manuels devraient être utilisés pour compléter les scripts automatisés de manière à ce que :

• tous les tests non automatisés peuvent faire partie de la campagne de tests
• certains tests exploratoires devraient également compléter tous les tests scriptés existants

‍

‍

La pyramide a changé depuis la version de Mike Cohn. Elle se décline désormais en différentes saveurs et formes, en fonction du contexte de votre système sous test (SUT). Par exemple, si vous utilisez des frameworks comme Microsoft Dynamics 365 ou Salesforce, les tests unitaires peuvent ne pas être applicables ou pertinents.

Il est important d'exploiter autant que possible les niveaux inférieurs, tout en gardant à l'esprit le retour sur investissement. Vous pouvez promouvoir une pyramide inversée à condition que votre analyse soit transparente. Cela permettra de mettre en place une stratégie d'automatisation des tests durable et d'éviter l'apparition d'un "cône de glace" sauvage. [Craske 2020]

La pyramide de test est une heuristique qui fonctionne la plupart du temps [Crispin 2014] [Bradshaw 2019-2]. En outre, le modèle du fromage suisse peut être utilisé pour soutenir certaines analyses et modifier la forme de la pyramide. Dans ce modèle, chaque vérification provenant de n'importe quel niveau de la pyramide est une tranche de fromage suisse avec des trous (également connus sous le nom d'"yeux") à l'intérieur. Un bug est en fait un alignement de trous que l'utilisateur final peut rencontrer [Moustier 2019]. Par conséquent, l'automatisation des tests peut être considérée comme le repérage de la tranche la plus précoce pour s'assurer automatiquement qu'un trou est comblé.

‍

‍

L'architecture SUT nous permet de couvrir l'interface utilisateur, le modèle commercial et les niveaux de base de données avec des configurations de test. Cela nous permet d'isoler les cas de test des changements de configuration [Axelrod 2018]

• pour un profil d'utilisateur final spécifique
• d'un client spécifique (par exemple une version donnée d'un navigateur Internet)
• juste "sous la peau" pour garantir le modèle d'entreprise sans aucune considération d'interface utilisateur
• au niveau d'un serveur, d'un microservice ou d'un composant - notamment avec les "tests unitaires"

En fait, être capable de suivre les appels entre les couches aide beaucoup à savoir quel test de couche peut et doit être traité [Bradshaw 2019-1].

Les tests exhaustifs sont impossibles, selon le principe de test de [ISTQB 2018]. Par conséquent, la stratégie Shift Left n'est pas suffisante. Il convient également de mettre en œuvre le test Shift Right.

Il est alors extrêmement utile de pouvoir contrôler la santé du produit une fois qu'il est déployé auprès des utilisateurs finaux [CFTL 2021], notamment par le biais de :

• des scripts automatisés pour détecter de manière proactive les problèmes en production lorsque l'on agit en tant que client [Graham 2012], notamment par le biais de smoke tests ou de défauts récurrents bien connus dans le produit
• toute donnée observable qui serait un indicateur de l'état de santé du produit, tout comme une analyse de sang (rapport de tests) révélerait une maladie sous-jacente.

Retour sur investissement de l'automatisation des tests

Comme nous l'avons vu plus haut, la question du retour sur investissement repose sur la question de savoir ce qui doit être automatisé. Une fois que l'organisation a décidé d'opter pour l'automatisation des tests, il apparaît que le choix est vaste, ce qui conduit à l'établissement de priorités et donc à la question du ROI.

La formule classique du retour sur investissement est [Kelly 2004] :

Coût de l'automatisation / Coût des tests manuels

avec : 

• Coût de l'automatisation = coût des outils + coûts de main-d'œuvre pour créer un test automatisé + coûts pour maintenir les tests automatisés
• Le coût d'un test manuel est principalement le coût de la main d'œuvre pour exécuter les tests.

‍

Il n'est pas possible de comparer les tests automatisés et les tests manuels. Les tests automatisés effectuent principalement des tests de régression, et ne fournissent donc pas de bons tests en eux-mêmes. Cependant, l'automatisation des tests (AT) peut être très rentable. Selon [Kelly 2004], elle peut offrir un rendement de 900 % après un an. [Graham 2012] suggère qu'elle peut atteindre le seuil de rentabilité après seulement un mois.

En fait, l'automatisation des tests est principalement profitable aux business des clients [SAFe 2023] parce qu'elle permet une livraison rapide. Ceci est tout à fait pertinent dans le cadre d'un développement itératif, puisque les retards de livraison se traduisent par un coût des retards. Par conséquent, l'automatisation des tests est surtout pertinente en termes de flux de valeur [SAFe 2023].

Cependant, pour améliorer la rentabilité du projet, quelques heuristiques peuvent être utilisées [Graham 2012] :

• les scripts doivent avoir une forte capacité de maintenance à long terme
• les scripts doivent offrir une grande confiance et une grande rapidité dans la recherche des défauts
• Le script doit respecter les critères bien connus de FIRST:

• Rapide
• Isolé
• Répétable
• Auto-évaluation
• En temps utile (voir ci-dessous)

Ceci peut être résumé avec TRIMS [Bradshaw 2019-1] :

• Ciblé - vous devez trouver le point le plus bas à partir duquel vous pouvez atténuer un risque de défaillance.
• Fiabilité - les tests non déterministes génèrent des analyses qui prennent du temps
• Informatif - si un test est réussi, vous devez savoir exactement pourquoi il l'a été et éventuellement contester un message de retour d'information de haut niveau avec d'autres vérifications plus approfondies dans le système.
• Maintenable
• Vitesse - les tests doivent être conçus et exécutés rapidement - plus la couche est élevée, plus le test est lent.

Pour avoir un certain contrôle sur ces aspects, vous pouvez introduire des observables dans l'actif des scripts de test [Colantonio 2018]

• évaluer le "temps moyen de diagnostic" pour savoir combien de temps il faut pour déboguer un script de test défaillant - plus le temps est long, plus les scripts de test sont mauvais
• pour compter les bugs trouvés par l'automatisation - cet indicateur est culturellement très apprécié !
• pour évaluer le "Flaky Rate" en comptant les faux positifs et flaky tests notamment à partir d'une analyse post-exécution - plus le taux est élevé, moins vos scripts de test sont fiables
• évaluer le ratio "automatisé/manuel" des tests afin de rendre la progression de l'automatisation des tests évidente pour les parties prenantes - même si ce comptage n'est pas pertinent en termes de qualité [Bach 2016], il est assez efficace du point de vue des parties prenantes

La hiérarchie qui a d'abord payé pour l'automatisation des tests doit être informée de la qualité ou de la médiocrité de l'automatisation afin de vendre les avantages de l'automatisation [Graham 2012] aux parties prenantes. C'est d'autant plus important au début, lorsque le budget de l'initiative doit être approuvé. Cela peut se faire par le biais de rapports qui montrent notamment les réussites et les échecs avec des graphiques à barres vertes/rouges, de sorte que les gens comprennent les besoins de remaniement des scripts.

Quand automatiser les tests ?

Tout commence lorsque le besoin d'automatisation des tests se fait sentir. À ce moment-là, l'outil d'automatisation doit être sélectionné en fonction de [Colantonio 2018] [ISTQB 2016].

• les technologies impliquées dans le SUT 
• et les compétences disponibles au sein des équipes. 

Certains critères supplémentaires doivent également être pris en compte pour s'assurer que l'outil supportera l'automatisation au-delà des premiers scripts. Les caractéristiques suivantes [Colantonio 2018] sont essentielles :

• Extensibilité de l'outil
• La facilité d'utilisation de l'outil pour démarrer, idéalement avec une formation pour éviter les mauvaises décisions.
• Des capacités de rapport et de débogage pour communiquer et effectuer des analyses de défaillance
• Capacité à reconnaître tous les objets de votre application
• Intégration avec d'autres outils tels que le contrôle de version, les outils de gestion des tests et les outils d'intégration continue.
• Communauté d'utilisateurs actifs avec un large panel de personnes pouvant être embauchées pour créer vos tests automatisés

Rappelez-vous que l'automatisation des tests n'implique pas nécessairement du code, certaines plateformes d'automatisation peuvent fournir des fonctionnalités telles que la technologie "nocode" ou le langage naturel comme gherkin ou l'approche Keyword-Driven Testing [ISTQB 2016] pour permettre aux testeurs fonctionnels purs et aux analystes commerciaux d'automatiser.

Une fois la plate-forme d'automatisation sélectionnée, des pratiques doivent être mises en œuvre pour réduire le nombre de scripts maintenance. Cela signifie que vous allez construire votre propre cadre au-dessus de la plateforme pour améliorer la productivité, et donc le retour sur investissement. Habituellement, les modèles impliqués sont [Colantonio 2018] [Crispin 2014] :

• Arrangement-Acte-Assert [Crispin 2014]
• DRY (Don't Repeat Yourself) Possibilité de modifier les tests à un seul endroit
• Page Object Model - éventuellement sous sa version "SOLID" nommée "Screenplay"
• Presenter First - un modèle de développement appelé Model-View-Presenter qui permet de commencer les tests à partir d'un squelette vide d'un Presenter directement fourni par une User Story en mode ATDD.
• Objectif unique - les tests ne doivent viser qu'un seul objectif. Ils sont plus faciles à déboguer et à modifier en cas de changement des règles commerciales.
• Mise en place et démontage pour effectuer les tests de manière répétée
• Utiliser un DSL (langage spécifique au domaine) pour faciliter la communication sur les tests.
• Séparer le test (le quoi) de l'exécution du test (le comment) - permet de modifier l'automatisation sous-jacente sans affecter les règles de gestion.
• Automatisation à tous les niveaux distincts (fonctionnalités métier / flux de travail de l'interface utilisateur / technique)
• Éviter l'accès à la base de données lorsque cela est possible afin d'augmenter la répétabilité et la vitesse des tests.

Pour commencer, les ingénieurs devraient créer des scripts de test avec des modèles sur le SUT existant sans aucune contrainte de temps. Après avoir acquis de l'expérience, ils peuvent automatiser les User Stories en même temps que le Sprint. Les scripts de test automatisés doivent être capables de gérer les nouvelles fonctionnalités et les fonctionnalités legacy sur le SUT [Axelrod 2018] en mode ATDD [Graham 2012].

Commencer l'automatisation des tests avant de coder le SUT pousse le développement à être testable [Graham 2012], introduisant ainsi des pratiques de qualité intégrées telles que des points d'entrée de test, des journaux, des mécanismes d'alerte et éventuellement une conception Poka Yoke sur le code de production. Lorsque vous démarrez un nouveau projet, commencez par l'automatisation des tests afin d'avoir des tests automatisés prêts à être exécutés dès que possible [Graham 2012]. Cela peut aider à améliorer la qualité du code de production.

Avec le temps, votre cadre se développera et d'autres modèles seront introduits. Cependant, vous serez confronté à des problèmes sur le site legacy . Cela signifie que vous devrez supprimer une partie de la dette technique des scripts de test et des actifs du cadre. Le Lean management appelle cela un "5S". Un 5S doit être effectué régulièrement [Graham 2012] [Crispin 2014] 

• Elle doit impliquer l'ensemble de l'équipe
• La dette technique doit être rendue visible, par exemple au moment de la rétrospective, afin d'obtenir l'adhésion des parties prenantes, car elle nuit à la rapidité et à l'efficacité des tests sur le site maintenance et à la fiabilité.

Dans le contexte DevOps, rappelons que le pipeline d'intégration continue des développeurs doit s'exécuter en moins de 10' [Graham 2012] [Kim 2016]. Cela devrait conduire à une classification de jeux de tests prédéfinis [Moustier 2019] à exécuter à partir de plusieurs pipelines. Par exemple, un au niveau des Devs pour les retours rapides et un autre qui serait exécuté la nuit ou le week-end pour les scripts plus lents.

Principaux enseignements

Pendant l'automatisation de vos tests, n'oubliez pas :

• les contrôles automatisés ne remplacent pas les testeurs - les ordinateurs sont des compléments aux humains, pas des substituts [Colantonio 2018].
• l'automatisation est un travail d'équipe [Bradshaw 2019-1] [Bradshaw 2019-2] [Colantonio 2018] [Graham 2012], et non quelque chose de déconnecté de l'équipe de développement [Axelrod 2018].
• l'automatisation commence avant - ou en même temps que - le code de production, et non à la fin
• les scripts de test doivent être traités comme du code de production [Colantonio 2018].
• ne jamais sous-estimer le temps maintenance dans l'automatisation des tests [Colantonio 2018] et faire du 5S chaque fois que c'est possible
• les scripts de test devraient être aussi "atomiques" que possible plutôt que de grands scénarios de test de bout en bout
• avoir un bon outil n'est pas une stratégie d'automatisation [Graham 2012], ce n'est qu'un début
• améliorer régulièrement les scripts de test et référentiel de test , idéalement à chaque itération

Vous devez également :

• Éviter d'assigner des objectifs irréalistes à l'automatisation des tests [Colantonio 2018] - même si 60 % des personnes témoignent que l'automatisation des tests facilite la chasse au bug [Capgemini 2018], il ne trouve pas plus de nouveaux défauts que les tests manuels.
• Éviter de penser l'automatisation des tests en mode "Big Bang" [Capgemini 2018].
• Évitez de vous fier simplement aux commentaires de l'interface utilisateur, envisagez des tests plus approfondis qui vérifieraient les valeurs réelles plus profondément dans les couches techniques [Axelrod 2018].

Pensez également à suivre les principes de l'automatisation des tests [Bradshaw 2019-2] :

• Soutenir les essais TOUT EN reproduisant les essais
• testabilité JAMAIS d'automatisation
• expertise en matière de tests expertise en matière de codage
• problème AVANT les outils
• risque couverture OVER
• l'observabilité la compréhension

Autres lectures

• [Axelrod 2018] : Arnon Axelrod - 2018 - "Guide complet de l'automatisation des tests : Techniques, pratiques et modèles pour construire et maintenir des projets logiciels efficaces" - isbn:9781484238318
• [Bach 2014] : James Bach & Aaron Hodder - 2017 - "Test Cases Are Not Testing : Vers une culture de la performance des tests" - https://www.satisfice.com/download/test-cases-are-not-testing# 
• [Bach 2016] : James Bach - 2016 - "Une approche contextuelle de l'automatisation des tests" - https://www.youtube.com/watch?v=4vcMddaAzDs 
• [Bensten 2019] : Christine Bensten & Antoine Aymer & Ravikumar Sengodan & Rahul Mitra & Jayant Kumar & Sayantani Das - 2019 - "Rapport sur les tests continus-2019" - https://cdn2.hubspot.net/hubfs/5156294/ES/ES_2019_CT/ES_2019_CT_Assets/ES_CT_Capgemini-Sogeti-Broadcom_CT-Report-2019_V1.pdf.pdf 
• [Bradshaw 2019-1] : Richard Bradshaw - 2019 - "Les pyramides sont anciennes - Parlons stratégie d'automatisation des tests" - https://www.youtube.com/watch?v=83aHKC5C14Q
• [Bradshaw 2019-2] : Richard Bradshaw - 2019 - "Redéfinir l'automatisation des tests" - https://www.youtube.com/watch?v=uIDvGzQdoxc
• [Capgemini 2018] : Capgemini - 2018 - "World Quality Report - 2017 v9 secure" - https://www.sogeti.com/globalassets/global/downloads/testing/wqr-2017-2018/wqr_2017_v9_secure.pdf
• [CFTL 2021] : CFTL - 2021 - "Automatisation des activités de test" - ISBN 978-2-9567490-1-1
• [Colantonio 2018] : Joe Colantonio - 2018 - "Le guide ultime des tests d'automatisation" - https://testguild.com/wp-content/uploads/2018/07/UltimateGuildToAutomation.pdf
• [Craske 2020] : Antoine Craske - The Traditional Test Automation Pyramid, Pitfalls and Anti-patterns" - https://laredoute.io/blog/the-traditional-test-pyramid-pitfalls-and-anti-patterns/ 
• [Crispin 2014] : Janet Gregory & Lisa Crispin - 2014 - "More Agile Testing : Voyages d'apprentissage pour toute l'équipe" - isbn:9780321967053
• [Fewster 1999] : Mark Fewster & Dorothy Graham - 1999 - "Software Test Automation : Utilisation efficace des outils d'exécution des tests" - isbn:9780201331400
• [Graham 2012] : Dorothy Graham & Mark Fewster & Lisa Crispin et al. - 2012 - "Experiences of Test Automation : Études de cas d'automatisation de tests logiciels" - isbn:9780321754066
• [Hage Chahine 2023] : Marc Hage Chahine - 2023 - "Scaling Functional Test Automation for Happy Teams" - https://fr.agilitest.com/scaling-functional-test-automation-for-happy-teams
• [ISTQB 2016] : ISTQB - 2016 - "Certified Tester Advanced Level Syllabus Test Automation Engineer" - https://www.istqb.org/certifications/test-automation-engineer 
• [ISTQB 2018] : ISTQB - 2018 - "Certified Tester Foundation - Level Syllabus" - https://www.istqb.org/downloads/category/2-foundation-level-documents.html 
• [Jones 2018] : Angie Jones - 2018 - "Quels tests devrions-nous automatiser ?" - https://www.youtube.com/watch?v=VL-_pnICmGY 
• [Kelly 2004] : Michael Kelly - 2004 - "Le roi de l'automatisation des tests" - https://www.stickyminds.com/sites/default/files/presentation/file/2013/04STRER_W12.pdf 
• [Kim 2016] : Gene Kim & Jez Humble & Patrick Debois & John Willis - "Le manuel DevOps : Comment créer une agilité, une fiabilité et une sécurité de classe mondiale dans les organisations technologiques" - isbn:9781942788072
• [Legeard 2017] : Bruno LEGEARD - 2017 - Soirée du Test Logiciel - "Les dernières tendances du test Logiciel" - https://fr.slideshare.net/TVALLEY/soire-du-test-logiciel-les-dernires-tendances-du-test-logiciel-b-legeard-cftl
• [Meerts 2019] : Joris Meerts - 2019 - "Testing References - Here Be Pyramids" - https://www.testingreferences.com/here_be_pyramids.php 
• [Moustier 2019] : Christophe Moustier - " Le test en mode agile " - ENI Editions - JUN/2019 - ISBN : 978-2-409-01943-2 - https://www.editions-eni.fr/livre/le-test-en-mode-agile-9782409019432 
• [SAFe 2023] : SAFe - 2023 - "Principe 6 - Faire circuler la valeur sans interruption" - https://scaledagileframework.com/make-value-flow-without-interruptions/ 
• [Segal 2022] : Dvir Segal - 2022 - "Les développeurs doivent-ils écrire des tests d'automatisation ?" - https://medium.com/geekculture/should-devs-write-automation-tests-a23e2e838424 

‍