Description

L'Automated Testing Ice Cream Cone (ATICC) est un anti-modèle qui trouve son origine dans le principe du "Shift Left".

Il est préférable d'aborder les problèmes de test le plus tôt possible, car plus les tests sont effectués tardivement, plus il est difficile de détecter bugs et plus les corrections sont coûteuses.

‍

‍

‍

Cette évolution vers l'ingénierie des exigences a un certain impact en termes de stratégies de test...

‍

Selon l'ISTQB, il existe 3 niveaux de test [ISTQB 2018] :

• Test de composants/unités (UT): cela couvre quelque chose comme 24 définitions différentes [Fowler 2014] à propos du test de bas niveau de petites parties, généralement écrites par les développeurs et plus rapides à exécuter que les niveaux supérieurs - pour assurer l'isolation des unités, des doubles de test sont ajoutés.
• Test d'intégration (IT): une fois que chaque partie fonctionne comme défini grâce aux UT, l'IT s'assure que ces parties sont capables de fonctionner ensemble grâce à des doubles de test qui délimitent une zone dans laquelle l'IT a lieu [Fowler 2018] ; par conséquent, ces tests nécessitent toujours des artefacts techniques.
• Test du système/de bout en bout (E2E) : une fois que chaque doublon de test a été supprimé, le système entier peut alors être évalué.

‍

La pratique des tests à tous les niveaux révèle que plus les tests sont isolés, plus ils sont proches du code, plus ils sont rapides et plus tôt ces tests peuvent être mis à disposition. Ensuite, dans une perspective de Shift Left, il devient clair qu'il devrait y avoir principalement des UT, puis plus le niveau est élevé, moins il y a de tests, cela dessine alors une pyramide.

‍

‍

‍

Lorsqu'elle est appliquée à l'automatisation des tests, la pyramide se présente de la même manière, sauf qu'au sommet de la pile, il doit y avoir des tests manuels pour compléter les scripts existants avec des situations imprévisibles qui seraient découvertes notamment par les tests exploratoires afin de faire face au principe de test du " paradoxe du pesticide " qui stipule que les scripts de test deviennent inefficaces pour trouver plus de bugs après un certain temps s'ils sont laissés inchangés [ISTQB 2018].

‍

‍

La pyramide devient un modèle qui peut être décliné de nombreuses manières différentes [Meerts 2019] et l'ATICC se produit si la pyramide est inversée. Ce phénomène apparaît lorsque l'automatisation des tests se concentre principalement sur les tests E2E avec moins d'informatique et encore moins d'UT.

L'ATICC est un anti-modèle notamment parce que

• la plupart des scripts de test sont réalisés en mode réactif - ils ne doivent être adaptés qu'au moment de la sortie de la version.
• Les tests E2E sont généralement fragiles car ils dépendent de l'interface utilisateur, sont coûteux à écrire et longs à exécuter [Fowler 2012] en raison de la dépendance du réseau et de la base de données.
• beaucoup de bugs sont cachés du point de vue de l'E2E en raison d'une mauvaise testabilité des couches inférieures de l'application, ce qui génère une faible confiance dans le produit.
• il aurait été plus facile de détecter bugs au fur et à mesure de son introduction, sans aller-retour entre le développement, la livraison et les tests du système.
• cela réduirait le coût de livraison si l'on s'occupait des tests de niveau inférieur avant l'E2E.
• cela aggraverait le rendement dela première passe.
• la plupart des problèmes passent inaperçus pendant le processus de livraison, ce qui fait perdre des occasions de retour d'information et entraîne une réduction du budget des essais pour rattraper le calendrier [Cohn 2009].
• elle révèle généralement certains silos entre les niveaux de test et génère une mini cascade [Pereira 2014].

‍

‍

Parfois, l'anti-modèle ATICC est également surnommé " Testing Cupcake Antipattern " parce que les équipes de développement fournissent une quantité importante d'UT ; par conséquent, il y a une grande base, mais l'automatisation est encore axée sur des niveaux de test plus élevés avec beaucoup de tests manuels [Pereira 2014].

‍

‍

On dit souvent que l'idée de la pyramide d'automatisation des tests a été créée grâce à l'ouvrage de Mike Cohn intitulé "Succeeding With Agile : Software Development Using Scrum", qui met l'accent sur l'intégration des tests au cours du processus plutôt que de les faire plus tard [Cohn 2009] ; cependant, le plus ancien artefact remonte à 2006 [Gheorghiu 2006], bien que Martin Fowler mentionne une conversation avec Lisa Crispin vers 2003-2004 [Fowler 2017] [Moustier 2019-1].

‍

En fait, l'idée stupide d'attendre que le produit soit prêt vient de l'article de Winston Royce [Royce 1970] qui a essayé de trouver une solution organisationnelle pour faire face aux besoins massifs de développement. Son idée simple découle de la croyance selon laquelle "on ne peut pas construire le toit avant les fondations".

• avec le développement de logiciels, le rendu de la maison (l'interface utilisateur) peut être fait avant les fondations (les sous-niveaux de l'application).
• même si Royce a mentionné que cette façon de travailler serait risquée et entraînerait des échecs.

‍

‍

‍

L'industrie a dû attendre la publication de Takeuchi & Nonaka [Nonaka 1986] et Mike Cohn en 2009 pour que cette erreur de paradigme "fondation-toit" devienne évidente pourpresque tout le monde.

‍

Pour éviter l'ATICC, il existe de nombreuses recettes qui permettent d'éviter cet anti-modèle ; elles font principalement appel aux techniques de construction de la qualité [SAFe 2021-27] [Cohn 2009] telles que :

• Harnais de test 
• Collaboration notamment à travers 3 Amigos [Pereira 2014] ou PanTesting
• TDD
• ATDD
• Automatisation des observables
• Definition of Done (DoD)
• Living Documentation
• Programmation en binôme / Programmation en groupe
• Testabilité au plus tôt
• Testabilité du Backlog Produit

Impact sur la maturité des tests

L'un des inconvénients des tests automatisés de l'interface utilisateur est la latence due au navigateur ; heureusement, il est possible d'exécuter des tests "headless" (alias "tests sous-cutanés") [Fowler 2017], c'est-à-dire qu'au lieu de dépendre d'un Selenium driver qui interagit avec le rendu HTML, le robot interprète directement le HTML, ce qui peut économiser 10% du temps d'exécution [SauceLabs 2019].

Mais certaines situations nécessitent quelque chose d'un peu plus différent, notamment lorsque l'architecture implique des microservices. Par exemple, chez Spotify, ils utilisent une forme en nid d'abeille [Fowler 2021].

‍

En effet, depuis la création de la pyramide d'automatisation des tests, le concept a été affiné en fonction du contexte. Cette vision originale semble trop simpliste et peut donc être trompeuse [Vocke 2018]. Par exemple, dans l'industrie aéronautique, l'approche de la pyramide de test est le référentiel du processus de certification. Ce processus est classiquement basé sur le matériel existant précédemment certifié. Malheureusement, ce processus de certification prend beaucoup de temps, notamment parce que les sous-structures de propriétés matérielles ne sont pas en corrélation avec des structures plus grandes. Aujourd'hui, les gens ont généré une tendance connue sous le nom de "Breaking the Pyramid" qui consiste à appliquer le "Virtual Testing" [You 2019]. Des simulateurs réalistes de pièces matérielles sont fournis pour accélérer les développements. Ce test virtuel revient simplement à fournir un talon pour permettre un "développement piloté par contrat". Il est appelé "Model-Based System Engineering" (MBSE) [Galiber 2019] [SAFe 2021-19] et tire parti de l'agilité du projet.

Dans l'industrie du e-commerce, le modèle pyramidal traditionnel peut également être abordé lorsqu'un accent particulier est mis sur l'expérience des clients [Craske 2020]. Plus généralement, ce modèle peut être définitivement repensé grâce au modèle du fromage suisse [Reason 2006] en considérant le Context-Driven Testing (CDT), par exemple lorsque les développements sont basés sur des composants ou des progiciels prêts à l'emploi parce que les tests unitaires ne sont pas applicables.

‍

‍

‍

L'anti-modèle ATICC est souvent perçu d'un point de vue fonctionnel ; cependant, les tests des exigences non fonctionnelles (ENF) doivent également être pris en compte. Si ces tests n'interviennent qu'à la fin du processus de livraison, le même problème se posera dans une autre situation. Seul un CDT avec des logiques partagées peut conduire à des versions réussies et optimales. 

‍

‍

Le point de vue d'Agilitest sur cette pratique

Agilitest étant une technologie #nocode, il est très facile de subir l'antipattern ATICC, surtout lorsqu'il est combiné avec l'effet de la loi de Conway avec des équipes de scripting indépendantes. C'est pourquoi il est particulièrement important de porter une attention particulière à cette question et d'avoir une vision claire du contexte de votre projet afin de limiter les impacts des changements fréquents sur l'UI ou les problèmes de silos comme expliqué précédemment.

‍

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

‍