Fusion des écocycles de développement / automatisation des tests

Description

Pour améliorer les tests automatisés, la question "qui doit automatiser le script de test" émerge avec les organisations à faible maturité. La réponse évidente à cette question consiste à appliquer la pyramide des tests automatisés avec [Segal 2022] : 

• beaucoup de tests unitaires effectués par les développeurs
• quelques tests d'intégration également effectués par les développeurs
• moins de tests de bout en bout (E2E) effectués par les QA au niveau de l'interface utilisateur.

‍

Ensuite, des outils tels que : 

• Postman ou SOAPUI qui facilite les tests d'intégration

• Fitnesse facilite les tests unitaires

Fournir certaines couches d'abstraction qui rendent l'automatisation des tests techniquement abordable pour les non-développeurs. Dans ce contexte, l'automatisation des tests est quelque chose qui peut en fait être piloté par : 

• les compétences des gens pour laisser les équipes matures s'organiser elles-mêmes
• ou la structure des équipes décidée par une certaine hiérarchie.

Quel que soit le driver de l'organisation, la question porte sur l'interaction entre les personnes qui développent le code de production et celles qui écrivent les scripts de test. Cette question peut être couverte par 4 stratégies principales [Axelrod 2018]

• Stratégie A: Promouvoir les testeurs manuels ou les programmeurs inexpérimentés en tant que développeurs d'automatisation pour commencer.
• Stratégie B: Disposer d'une équipe dédiée à l'automatisation, dotée de solides compétences en matière de développement.
• Stratégie C: Donner aux développeurs la propriété de l'automatisation avec le code de production.
• Stratégie D: Partager la propriété au sein de l'équipe

‍

Dans les graphiques ci-dessous, la taille de chaque zone fournit des plages de préoccupations possibles qui dépendent de la maturité agile.

Ces stratégies peuvent s'appuyer, ou non, sur un cadre de test partagé qui permettrait une appropriation collective de l'automatisation (par exemple, KDT, low-code, fitness-like ou #nocode). Cela contribue grandement au partage des préoccupations liées aux tests et aux questions de codage.

‍

‍

‍

‍

Stratégie A: 

Cette approche opportuniste conduira à la création de scripts de test mal maintenables si ces testeurs n'ont pas de formation de développeur. Le code produit n'introduira ni modularité ni réutilisabilité et les corrections de script devront être propagées à l'ensemble des scripts de test.

Stratégie B :
L'équipe chargée de l'automatisation dispose de suffisamment de ressources pour développer et exécuter des scripts automatisés, mais cette équipe et les développeurs du code de production utilisent des bibliothèques et des modèles de conception différents. De toute évidence, dans ce cas, un silo a été introduit et tombe généralement dans le piège de la loi de Conway [Conway 1968] avec un syndrome du cône de glace et des goulots d'étranglement dans le processus de livraison.

Bien que cette configuration soit censée répondre au biais cognitif de la cécité d'inattention avec l'ingénierie de test des équipes de développeurs et de testeurs avec des tests possibles en double. En conséquence, des tests inutiles au niveau des AQ émergent avec 4 règles proposées [Cruden 2015] :

1. Ne travaillez sur l'automatisation des tests que si vous avez les compétences nécessaires pour travailler sur le code de production si nécessaire.
2. Ne travaillez sur le code de production que si vous avez les compétences nécessaires pour travailler sur l'automatisation des tests si nécessaire.
3. Dans le cas où 1) ou 2) n'est pas vrai, couplez avec quelqu'un qui répond aux exigences de 1) et 2) jusqu'à ce qu'il le soit. 
4. C'est l'équipe qui doit s'approprier et contribuer au code de test, et non pas certaines personnes ou disciplines en son sein.

‍

Ces problèmes devraient amener l'organisation à passer à des stratégies plus matures.

Stratégie C :
L'intérêt des développeurs pour les scripts de test est d'éviter les problèmes de la stratégie B ; par conséquent, s'il peut sembler à première vue qu'il serait plus pratique pour les développeurs de créer de nouvelles fonctionnalités et de laisser les testeurs produire les tests, les inconvénients susmentionnés conduisent le développeur qui a écrit la fonctionnalité à être la meilleure personne pour écrire l'automatisation [Segal 2022]. Les développeurs sont naturellement " câblés " pour gérer les scripts comme du code de production en appliquant des modèles de conception aux scripts avec le "PageObject Model" (POM) ou mieux encore avec le "ScreenPlay" qui est un principe SOLID appliqué au POM [Kutz 2022]. Le point de vue des développeurs sur les scripts est très structurant [Axelrod 2018].

Pourtant, cette stratégie amène les développeurs à croire que les AQ savent ce qu'ils doivent tester au niveau supérieur et les AQ à croire que les développeurs testent les "bonnes choses" au niveau inférieur. Là encore, les AQ se concentrent sur leurs tâches et oublient naturellement d'aider les développeurs pour se tourner vers les analystes métier.

Stratégie D :
D'après les stratégies précédentes, il apparaît que les développeurs et les testeurs ont besoin des conseils de leurs collègues pour fournir une automatisation des tests efficace [Axelrod 2018]. Ces conseils deviennent particulièrement pertinents lorsque

• ATDD est impliqué dans les critères d'acceptation générés notamment dans une session 3 Amigo.
• Le TDD est piloté par les scripts ATDD.

Même si l'ATDD et le développement pouvaient être répartis entre les équipes de développement et d'automatisation, une communication forte sera nécessaire pour aligner les scripts et le code de production, mais des équipes séparées empêcheront définitivement cette combinaison promue par SAFe [SAFe 2021-27], LeSS [Yin 2022] et DAD [Ambler 2012].

Dans ces circonstances, l'indépendance des tests [ISTQB 2018] peut s'appuyer sur des testeurs qui vérifieraient les scénarios de haut niveau et les scripts de défi pour...

• demander aux développeurs d'introduire un peu de Jidoka dans les scripts de test 
• ajouter quelques cas particuliers qu'ils trouveraient éventuellement pertinent d'automatiser avec l'aide des développeurs.

Dans le prolongement de cette stratégie, les testeurs devraient également prendre en charge les tests unitaires notamment.

• à l'aide d'outils tels que Fitnesse pour permettre aux testeurs de fournir des données de test
• ou le testeur pourrait laisser les développeurs expliquer le contexte et les actions effectuées sur leurs tests unitaires afin qu'une telle amélioration puisse survenir dès que possible selon l'approche de test Shift Left.

Cela permet de créer une appropriation partagée des tests et de l'automatisation au sein de l'équipe.

‍

Cependant, il ne suffit pas d'appliquer cette stratégie, cela dépend aussi de la façon dont l'équipe applique certaines pratiques de test agiles, d'où le large spectre de cette stratégie lors du partage de l'automatisation avec différentes équipes en l'absence d'outil.

Cette cohésion peut être facilitée notamment par une analyse du modèle "fromage suisse" par les membres de l'équipe :

• définir les possibilités d'essais selon le modèle du fromage suisse
• sauter les tranches les plus à droite qui ne peuvent être traitées (par exemple, les parties non testables d'un contexte donné, notamment en raison d'un moyen de test inaccessible tel qu'une API privée).
• sauter les opportunités de test les plus à droite sur les moins risquées (domaine/entreprise) à quitter
• introduire éventuellement plusieurs contrôles sur la même prémisse pour tester les parties les plus critiques (en fonction du domaine/de l'activité) afin de permettre des tests à partir de différents contextes.

Le résultat de cette stratégie est que la collaboration est essentielle [Laurent 2018].

Le besoin sous-jacent est la "testabilité sociale" avec la capacité de partager les connaissances en matière de testabilité à partir d'un niveau supérieur par rapport à une connaissance intime des internes de l'application, à laquelle les testeurs peuvent ne pas avoir accès [Segal 2022].

Alors que la stratégie C s'appuie sur le développeur comme bon candidat pour écrire des tests automatisés car 

• ils ont déjà une connaissance intime des éléments internes de l'application
• ils peuvent rapidement adapter la testabilité pour permettre les tests

Mais comme il ne devrait pas y avoir d'équipe à l'intérieur de l'équipe selon le guide Scrum [Schwaber 2020] pour éviter les goulots d'étranglement [Segal 2022]. Par conséquent, la stratégie D repose sur l'objectif de T-Shape people. Pour permettre cette approche, le SRE de Google propose une forte collaboration entre Devs & Ops et une limitation de 50% du temps dédié aux nouvelles fonctionnalités afin de renforcer une appropriation partagée [Beyer 2016], les profils orientés test peuvent alors également être pris en compte de manière similaire.

Impact sur la maturité des tests

Bien que la stratégie B semble se conformer aux conseils de l'ISTQB concernant l'indépendance des testeurs [ISTQB 2018], il apparaît que tant que la maturité des tests n'est pas assez élevée, l'indépendance de l'organisation créerait plus de problèmes que les tests indépendants ne pourraient en découvrir. D'une part, la dépendance pousse l'organisation à forcer intrinsèquement à multiplier les types de tests sur la solution mais la dépendance n'est pas seulement une question d'équipes séparées mais en réalité une question de pensée critique qui propose d'établir la distance nécessaire avec le sujet [Bolton 2017]. Bien qu'il ait été prouvé que les tests indépendants améliorent les tests de 16% [Sunyaev 2015], il apparaît également que les opportunités de Shift Left telles que les auto-tests intégrés (BIST) sont manquées ; ainsi, la connaissance des tests de niveau inférieur est également manquée [Segal 2022]. De plus, l'article de Sunyaev ne prend pas en compte les pratiques de test agiles, qui visent à prévenir bugs au lieu de tester le produit ; par conséquent, il ne prouve pas que cette amélioration de 16 % ne serait pas plus élevée avec des tests collaboratifs, mais cela impliquerait également des indicateurs clés de performance extrêmement complexes et multifactoriels. Enfin, même si l'ingénierie redondante semble introduire une plus grande fiabilité [Chen 1978], une étude a montré qu'il s'agit d'une erreur puisque les équipes introduisent en fait les mêmes problèmes [Knight 1986].

En fait, pour améliorer les résultats des tests, les stratégies B et D doivent être combinées comme pour les tests de sécurité. Cette approche propose d'impliquer des équipes internes et externes qui ont une connaissance totale, partielle ou nulle du système à attaquer, c'est-à-dire à tester.

‍

Lorsqu'il s'agit de mettre la coordination des questions de développement et d'automatisation à l'échelle, PanTesting pourrait vous fournir certains outils pour fusionner progressivement les deux (éco)cycles et finalement remodeler l'organisation pour utiliser la tendance naturelle à suivre la loi de Conway et à se diriger vers la stratégie D [Skelton 2019].

Le point de vue d'Agilitest sur cette pratique

‍

Agilitest est capable d'adresser les tests E2E au niveau de l'interface utilisateur sur les navigateurs, les applications mobiles et MS Windows ou plus près du niveau de l'intégration grâce aux appels REST API. Comme Agilitest est une technologie #nocode, toutes les stratégies décrites ici peuvent être utilisées.

Lorsqu'il s'agit d'automatiser des scripts à l'échelle, Agilitest peut être branché à un serveur de contrôle de la source Git et à une chaîne d'outils basée sur Jenkins sans frais puisque le gestionnaire de script est un composant open source . Ces capacités permettent aux organisations de faire face aux combinaisons de toutes les stratégies et de soutenir la croissance de l'entreprise.

‍

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

‍