Automatiser tout ce que l'on peut

Test automatisé

L’automatisation augmente la fiabilité et la capacité à faire plus

Test automatisé
Agility Maturity Cards > Test automatisé
Automatiser tout ce que l'on peut

Description

Dans le contexte des tests logiciels, lorsqu'il s'agit d'automatisation, la création de scénarios de test est la première stratégie d'automatisation qui émerge.

 "Il est difficile de prétendre que vous êtes Agile, si vous n'écrivez pas beaucoup de cas de test automatisés" [Martin 2007].

Toujours selon Robert C. Martin, non seulement le test manuel est très stressant, fastidieux et sujet aux erreurs, mais il est également immoral car il transforme les humains en machines [Martin 2007]. Si une procédure de test peut être écrite sous forme de script, il est également possible d'écrire un programme pour exécuter cette procédure de test. Cela permet de réaliser des tests moins chers, plus rapides et plus précis que le travail manuel effectué par les humains, et cela libère également les humains pour faire ce qu'ils font le mieux : créer [Salonen 2012].

Ces dernières années, les avantages perçus de l'automatisation des tests ont considérablement augmenté [Sogeti 2020] et les équipes expérimentées essaient certainement d'introduire l'automatisation des tests dans leurs prestations.

Avantages de l'automatisation des tests [Sogeti 2020]

Lorsqu'il s'agit d'automatisation des tests, la maintenance se retrouve toujours sur le chemin. Le test de maintenance est déclenché par des faux positifs, le fameux "flaky tests". Le manque de fiabilité n'a pas seulement un impact sur les tests. Elle a un impact direct sur la confiance de votre équipe dans la livraison des logiciels. Il est donc essentiel de viser cette robustesse à 100% [Craske 2021].

Le Lean management a introduit la prise en charge des actifs automatisés comme un pilier de l'organisation. Le terme utilisé est "Jidoka". Ce terme japonais est un mélange de 2 mots : autonomie et automatisation, d'où la traduction, "autonomation". Dans les lieux où le Jidoka prend place comme les usines (mais pas seulement [Danovaro 2008] [Clinton 2008] [Onetto 2017] [Sridharan 2021] ), les robots sont améliorés pour faire face progressivement aux situations imprévues afin de réduire les interventions manuelles. 

Par conséquent, toute stratégie d'automatisation devrait également inclure un peu de Jidoka [Moustier 2022] pour éviter de perdre la foi dans les tâches automatisées [Craske 2021].

DevOps pousse l'équipe à automatiser les choses autant que possible, c'est pourquoi Google promeut dans son approche SRE de laisser les développeurs contribuer aux nouvelles fonctionnalités la moitié du temps et l'autre moitié devrait être consacrée à l'introduction de l'automatisation qui aiderait les Ops et améliorerait les scripts générés [Beyer 2016]. Non seulement les développeurs doivent soutenir l'automatisation et améliorer les moyens de production, mais aussi les moyens de test pour augmenter la confiance dans la solution, car les moyens de test font aussi partie des actifs de production puisqu'ils participent à leur niveau de qualité.

Impact sur la maturité des tests

En fait, l'automatisation ne commence pas à partir de l'automatisation des scripts de test. Lorsque les testeurs font appel à des outils de gestion des tests tels que Squash, Octane ou ALM, c'est pour remplacer les actions manuelles qui seraient difficiles à maintenir lorsqu'une quantité massive de cas de test est disponible [Bach 2016] [Moustier 2019-1]. Ces outils de gestion des tests permettent déjà d'automatiser des activités telles que

  • le versionnement des cas de test
  • l'exécution de chaque étape dans les cas de test
  • le calcul de la couverture des exigences avec les résultats de l'exécution des tests

Si vos cas de test étaient traités avec de simples fichiers texte ou des feuilles de calcul, ces tâches seront traitées manuellement avec une certaine incertitude due aux interactions humaines avec les actifs de test.

Le testeur devrait toujours rechercher et essayer des outils qui automatisent une partie de son travail afin de permettre un retour d'information plus rapide et fiable [Bach 2016].

Cependant, l'automatisation n'est pas suffisante car les tests sont plus que des scripts répétés. James Bach, l'initiateur des tests exploratoires avec Cem Kaner, démontre une approche de test amusante sur un jouet idiot que les scripts ne pouvaient pas imaginer [Bach 2009]. De plus, par définition, les scripts répètent les mêmes actions sans aucun changement. Cet avantage comporte quelques inconvénients, notamment du point de vue du paradoxe du pesticide [ISTQB 2018]. Après un certain temps, ces scripts deviennent inutiles car bugs devient résistant au pesticide si le même produit chimique est appliqué. La variance est nécessaire pour donner aux tests une chance de trouver des bugs robustes.

Dans cette direction, Spotify introduit un service de dictionnaire de données qui modifie de manière aléatoire les données d'origine afin d'introduire un certain flou et de repousser les limites des scénarios existants [Karl 2013] ; naturellement, les ensembles de données concernés sont enregistrés afin de conserver la trace des tests et de permettre une répétition approfondie. Pour aller plus loin dans la modification des scénarios, le concept de "test de mutation" est une tentative d'automatisation des changements de test pour modifier automatiquement les scripts existants et essayer des chemins de test supplémentaires. Bien qu'il existe quelques heuristiques, cette stratégie conduit à un problème bien connu et indécidable, le "problème du mutant équivalent", une solution entièrement automatisée basée sur la mutation des tests est irréalisable [Kintis 2016]. Essayer de résoudre complètement les tests par l'automatisation est une erreur. Il ne s'agit que d'une heuristique.

Pour éviter une telle erreur, la culture agile a introduit la métaphore du cône de glace des tests automatisés, avec des tests manuels qui complètent l'ensemble des tests automatisés.

Certains tests manuels doivent compléter les tests automatisés effectués à chaque niveau [Scott 2019] [Moustier 2019-1].

Le point de vue d'Agilitest sur cette pratique

Agilitest participe à l'automatisation avec une faible maintenance grâce à une approche #nocode. Ce paradigme participe à réduire la maintenance et donc à laisser plus de temps aux développeurs pour créer de la valeur ajoutée sur d'autres sujets [Forsyth 2021] et les non codeurs pourront également prendre part à l'automatisation des scripts de test.

De plus, Agilitest est doté d'un moteur assez robuste pour s'adapter aux changements d'interface utilisateur. L'outil peut également récupérer des données à partir d'un fichier CSV pour les questions data-driven testing ce qui permet une certaine mutation des données comme Spotify le fait avec les données générées par le pipeline DevOps.

En plus de ces fonctionnalités qui répondent aux grands principes de l'automatisation des tests, Agilitest vous recommande de toujours compléter les scripts Agilitest avec les éléments suivants 

  • beaucoup plus de tests aux niveaux inférieurs( tests d'intégration et tests unitaires)
  • quelques tests manuels, notamment des tests exploratoires pour combler les lacunes entre les scripts et le principe du Paradoxe du pesticide

la mise à jour, l'amélioration et le déclassement des scénarios sur une base régulière dans une approche 5S

Pour découvrir l'ensemble des pratiques, cliquez ici.

Pour aller plus loin

© Christophe Moustier - 2021