Description

Le test end-to-end (E2E) est une technique utilisée pour vérifier si une application (site web, application mobile...) se comporte comme prévu du point de vue de l'utilisateur final. Cette technique permet de valider le fonctionnement du front-end. Mais aussi de vérifier son intégration avec les nombreux composants connexes et les services de back-office.

Les tests E2E sont un terme générique qui couvre de multiples aspects :

• Tests fonctionnels: A été imaginé par le premier William Howden en 1978 qui décrit une approche du test fonctionnel dans laquelle la conception d'un programme est considérée comme une collection intégrée de fonctions [Meerts 2012].
• Test de système: Un niveau de test qui se concentre sur la vérification qu'un système dans son ensemble répond aux exigences spécifiées. Ces exigences doivent inclure des exigences fonctionnelles et non fonctionnelles (NRF) [ISO 25010 2011].
• Test d'acceptation: Un niveau de test qui se concentre sur la détermination de l'acceptation du système. Ces exigences comprennent également les exigences fonctionnelles et les exigences non fonctionnelles [ISO 25010 2011] et peuvent être définies lors d'une session des 3 Amigos et automatisées selon la méthode ATDD.

C'est parce que les tests E2E se produisent dans les 3 types de tests. Ils impliquent à la fois la vérification et la validation (V&V). La V&V répond à la fois aux questions "construisons-nous le bon produit ?"et "construisons-nous le bon produit ?"[Boehm 1984].

Les tests E2E contribuent à la validation et au contrôle du système et des tests d'acceptation. Il permet également de réaliser des tests d'intégration en mode " big bang " [Parmar 2014] [Moustier 2019-1]. Il offre également quelques perspectives sur différentes NFR telles que le pentesting ou le test de charge sur plusieurs environnements.

Les tests E2E peuvent être envisagés d'un point de vue horizontal notamment avec 

• les multiples applications (alias "points de contact") présentes dans l'ensemble d'un système d'information (SI)
• interfaces humaines multiples (navigateurs, mobiles, applications lourdes)
• usages multiples avec des personae différents [Hendrickson 2013] [Moustier 2019-1]. 
• plusieurs processus commerciaux
• environnements multiples et gestion des données

L'E2E peut également être considéré verticalement d'un point de vue technique avec différentes technologies qui représenteraient également un test E2E.

Pour ajouter un peu plus de confusion sur ce que recouvre cette notion d'E2E, il faut également faire attention à ce à quoi se réfère le terme "Système". Lorsque le point de contact est le Système sous test (SUT), il est alors considéré comme un composant d'un SI entier. Par conséquent, tester cette partie est littéralement un test de composant/unité. Bien que, du point de vue de l'équipe, le test de ce composant entier soit également un test de système...

V&V vs tests E2E

Cette multitude est couverte par de nombreuses techniques de test notamment enseignées avec les techniques standards de l'ISTQB (partitionnement par équivalence, par paire, table de décision, ...) [Beizer 1990] [Otsuki 2012] [ISTQB 2015], mais Il faut garder à l'esprit que ce n'est qu'une " école de test " basée sur des analyses et des heuristiques [Moustier 2021-2] ; les autres sont [Pettichord 2007] :

• Standard School : les tests comme moyen de mesurer les progrès, notamment sur la base de normes coûteuses et reproductibles.
• École de la qualité : met l'accent sur les processus et les contrôles
• École axée sur le contexte : met l'accent sur les compétences humaines, le contexte et la recherche du site bugs qui intéresse les parties prenantes.
• École Agile : met l'accent sur les tests automatisés et s'assure que le développement est complet.

Dans un état d'esprit Shuhari, il apparaît que le test moderne ne consiste pas seulement à vérifier que le produit est conforme aux exigences [Bach 2019] et sortir des sentiers battus est majeur améliorer le test E2E par exemple avec l'approche du test moderne qui implique également l'amélioration continue à la fois du produit et du système qui le construit à la manière Kaizen.

Impact sur la maturité des tests

Dans les organisations de type Waterfall, les tests E2E sont effectués.

• au niveau des parties - éventuellement avec des services basés sur la livraison effectués par des contractants
• après le niveau d'intégration - avec des propriétaires d'entreprise (BO) qui connaissent bien le SI pour effectuer des tests E2E sur plusieurs points de contact.

Cette configuration est sujette à des problèmes de communication dus aux silos. Un autre problème visible est celui de l'analyse de bugs rencontré au niveau du BO où des problèmes systémiques émergent [Appelo 2010] en raison de la complexité de l'environnement [Snowden 2007] qui déprécie le prédicat de causalité : un effet n'a pas une cause unique et l'analyse formelle de la cause première (RCA) peut revenir sur un problème déjà rencontré dans un 5 Whys.

Pour éviter ce dernier facteur, il est essentiel d'adopter des approches itératives avec de petits incréments [SAFe 2021-04]. Chez Google, chaque jour, 800 000 builds et 150 millions de tests sont exécutés sur 13 000 projets [Soto-Sánchez 2021]. Pour faire face à une telle production, l'état d'esprit agile guidé par les tentatives de tout faire en même temps, l'automatisation, la cadence [SAFe 2021-07] et des pratiques telles que le Poka-Yoke est inévitable. SAFe fournit quelques réponses à travers ses principes et démonstrations à tous les niveaux de l'organisation (équipe, programme, solution). SAFe introduit également un élément intéressant, le Program Board.

Le Program Board est un outil généré au moment de la planification de l'incrément de programme [SAFe 2021-32] qui montre les dépendances entre les équipes et les livraisons attendues.

Conseil du programme [Moustier 2020]

Nous avons déjà remarqué que l'E2E était quelque chose de relatif au SUT à tester. Il est alors simple de voir que des tests E2E très locaux seront effectués sur la première partie livrée, et que les tests E2E augmenteront progressivement avec l'accumulation des livraisons [CFTL 2019].

Pour faciliter la cadence et les incréments courts, les pratiques DevOps telles que le Dark Launch sont les plus utiles pour maintenir un flux de livraison élevé et des tests E2E. Un tel contexte de livraison implique la coexistence de plusieurs versions d'un même composant ; dans ce contexte, le principe d'ouverture et de fermeture sera également utile ; par exemple, en ce qui concerne les API, les API existantes ne doivent pas être modifiées (fermées aux modifications) mais de nouvelles API doivent être ajoutées (ouvertes aux ajouts). De cette façon, la compatibilité est maintenue et la livraison est plus résistante aux problèmes de synchronisation. Cet exemple illustre un environnement de test E2E spécifique traité par Shift Right Testing.

‍

Il est également possible d'appliquer un Poka-Yoke aux tests E2E afin de réduire les problèmes systémiques susmentionnés. Il semble qu'il soit possible d'utiliser la loi de Conway [Conway 1968] dans le sens inverse pour concevoir des équipes de sorte que l'architecture émerge [Skelton 2019]. Ces équipes et leur mode de communication devraient ensuite être conçus pour faciliter les tests E2E, notamment avec des équipes de test à long terme composées d'experts fonctionnels et métier, et éventuellement avec des harnais de test faisant partie de la communication entre les équipes. La gestion des dépendances peut être optimisée en prenant en compte les relations entre les équipes à l'aide d'une carte contextuelle issue de la conception pilotée par le domaine [Evans 2004] et de PanTesting. Cela permet aux managers de participer aux tests à leur niveau. 

Le point de vue d'Agilitest sur cette pratique

Agilitest fournit un outil d'automatisation des tests E2E #nocode capable d'utiliser des applications web, mobiles et MS Windows pour interagir avec différents types de points de contact. L'outil englobe également les tests de performance grâce au plugin Octoperf.

Cependant, les testeurs E2E ne doivent pas se fier à cette seule vision du test. Les testeurs devraient également promouvoir une approche holistique, au moins pour faciliter les tests E2E et pousser le système à éviter le syndrome du cône de glace.

‍

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

‍