Cet article a été écrit pour et publié initialement dans le magazine Programmez! d’avril 2019
Collaboration entre testeur et développeur dans une équipe agile
Les équipes agiles – et plus généralement les équipes pluridisciplinaires – ont comme atout principal de regrouper un grand nombre de compétences en leur sein. Les tests étant une spécialité du logiciel à part entière il est fortement recommandé d’avoir au moins 1 testeur de métier dans chacune de ces équipes.
Le testeur agile, membre à part entière de l’équipe, est là pour plusieurs raisons, la principale est d’apporter une vision qualité à l’ensemble de l’équipe en mettant en place des processus, une stratégie et une prise de conscience de l’équipe sur le fait d’atteindre la juste qualité, c’est-à-dire une qualité d’un niveau satisfaisant pour les utilisateurs sans faire de sur-qualité.
Pour être vraiment efficace le testeur agile ne peut agir seul, la qualité est l’affaire de toute l’équipe ! Le testeur agile collabore avec l’ensemble des membres de l’équipe de développement sur l’ensemble des points liés à la qualité. Il doit alors les convaincre de l’importance et l’apport de valeurs de ces propositions. Cela commence avec un travail fait conjointement avec l’équipe pour savoir comment on valide les nouvelles fonctionnalités (par exemple au moyen de Definition of Done et de plans de test ou de revues), savoir comment on valide que les nouvelles fonctionnalités n’ont pas engendré des régressions trop importantes (quels tests automatiser et comment ?), savoir quel est le niveau de qualité pour les différents livrables ou encore comment optimiser le coût de l’ensemble de ces tests avec l’ajout de processus pour, par exemple, tester tôt (ex : revues). Tout cela n’est possible qu’avec une bonne connaissance du produit, du contexte, des risques engendrés avec les nouveaux changements. Afin d’avoir accès de la manière la plus efficiente à l’ensemble de ces informations le testeur doit échanger, discuter et surtout travailler de concert avec les développeurs (qui connaissent les risques techniques) et les analystes métier (qui connaissent les risques fonctionnels). Les approches BDD (Hiptest, cucumber…) ou ATDD visuel (Yest, CA ARD, MaTeLo) ont d’ailleurs pour but (en plus de faire des tests une documentation vivante) de faciliter les échanges entre les personnes de ces différents métiers en proposant un langage compréhensible par tous et en limitant les barrières d’incompréhensions. Le BDD et l’ATDD permettent aussi de synthétiser le besoin en amont et donc d’éviter de développer des fonctionnalités non désirées.
Enfin, il est bon de rappeler que le testeur agile doit également collaborer avec l’équipe en faisant autre chose que du test. Il peut collaborer en travaillant sur des spécifications ou des tâches de développement à travers des revues ou même de l’écriture. Un testeur agile est avant tout un membre de l’équipe agile et il doit faire ce pour quoi il est le plus utile à l’équipe à l’instant t. Cela se traduit dans la majorité des cas par du test mais pas lorsqu’il y a une baisse de charge inhérente sur ce point.
Collaboration entre testeur et développeur sur une chaine d’intégration continue
Dans une chaine d’intégration le travail de collaboration entre les testeurs et les développeurs (et idéalement les opérationnels) est encore plus important. Il faut tout d’abord afin de définir quels seront les tests ajoutés à la chaine d’intégration continue tout en s’assurant que ces tests ne rendent pas les merge trop long.
Les différents niveaux d’intégration continue sont l’intégration continue, la livraison continue et le déploiement continu et peuvent être résumés avec ce schéma :
A chaque niveau d’intégration continue certains tests sont nécessaires (plus d’informations à ce sujet dans l’article dédié du livre édité par le CFTL : Les tests en Agile).
Voici un processus « standard » de déploiement :
- Intégration continue
Avoir de l’intégration continue revient à impacter toute l’équipe de développement il faut donc, au minimum, automatiser l’exécution des tests unitaires ainsi que les tests de qualité de code. Ici le testeur n’a pas beaucoup à apporter à part rappeler cette nécessité et potentiellement suggérer l’ajout de tests « vitaux ». Un autre apport potentiel important du testeur à ce niveau-là est la mise en place des rapports automatiques suite à l’exécution des tests. Pour faire de l’intégration continue il est nécessaire d’avoir des outils de développement adaptés. On peut penser à des outils comme Git (gestion de versions), GitlabCI ou Jenkins pour l’ordonnancement d’exécution des scripts. C’est au niveau de l’’ordonnancement que se décide l’ajout des tests avec par exemple l’exécution des tests unitaires ou le déclenchement d’outils comme Sonarqube. De même, la phase de Construction (Build) fait également parti de l’intégration continue et doit être automatisée. On peut alors avoir différents binaires compilés et conditionnés en paquet debian, .jar, image docker ou n’importe quel autre format.
- Livraison continue
Avoir une chaine d’intégration continue allant jusqu’à la livraison continue, c’est-à-dire proposer le packaging automatique. Le binaire créé précédemment est envoyé dans un dépôt comme Artifactiry ou Nexus afin qu’il devienne installable. La livraison impacte également les opérationnels (s’ils ne font pas partie de l’équipe). De plus l’avancement étant plus important, les tests à exécuter sont plus nombreux. Dans le cas de la livraison continue, il faut également implémenter des tests d’installabilité (il n’y a pas d’intérêt d’avoir un .exe, .jar ou .apk… s’il n’est pas installable) et des tests d’intégration (les tests unitaires, isolés, n’étant plus suffisants). Ici le testeur est là pour rappeler l’intérêt d’avoir ces tests et de les implémenter et bien sûr d’aider l’équipe à les implémenter. Dans cette étape le testeur est beaucoup plus important que pour une intégration continue classique car, avec la livraison continue, arrivent de nombreuses problématiques comme le temps d’exécution des tests (expliqué par leurs nombre) ou encore la nécessité d’avoir des environnements de test ainsi que des données de test adaptés (les tests d’installabilité demandent un environnement de test). C’est généralement à partir de ce moment-là que l’on commence de parler de technologies comme Docker et de parallélisation des tests.
- Déploiement continu
Enfin, il y a le déploiement continu qui va jusqu’au déploiement en production. Il y a donc des impacts clients. Il est alors nécessaires d’avoir des tests fonctionnels avec notamment des tests IHM mais aussi des tests non-fonctionnels comme les tests de performances, les tests de sécurité d’adaptabilité… Pour les tests IHM il existe de nombreux outils.
L’outil le plus en vogue pour les tests web étant Selenium, il existe néanmoins d’autres solutions comme des solutions d’éditeur permettant de faire des tests sur clients lourds (UFT de HP, TestComplete de Smartbear…) mais aussi des solutions de KDT (Keyword Driven Testing) permettant de simplifier l’automatisation pour les testeurs fonctionnels. On peut citer par exemple RobotFramework HP BPT ou encore Agilitest comme solution de KFT.
Pour les tests de performances il existe de nombreux outils mâtures comme Jmeter ou Neolaod, néanmoins il existe également d’autres outils sur le marché comme WebPageTest ou encore Greenspector qui s’est spécialisé dans les tests de performances (temps de réponse mais aussi consommation de batterie) pour mobiles.
Les tests de sécurité ont comme principal représentant Fortify qui à l’image d’un Sonar va inspecter le code pour détecter des failles de sécurité. Je recommande d’ailleurs de l’ajouter dès la phase d’intégration continue.
Enfin, il n’y a pas d’outils spécifique pour des tests d’adaptabilité, je ne peux cependant que conseiller d’avoir des tests utilisant des variables (par exemple le navigateur ou la version de l’OS) ceci permet de limiter le nombre de test à maintenir mais aussi utiliser des outils comme Docker afin d’avoir des environnements de test adaptés.
C’est dans cette étape que le testeur prend le plus d’importance. Tout comme pour la livraison continue il y a des problématiques de temps d’exécution des tests qui sont dans ce cas encore plus importants, la nécessité d’avoir des environnements et données de tests fiables ainsi que des bilans facilement lisibles et compréhensibles encore plus nécessaires. Pour répondre à toutes ces problématiques le testeur apporte son savoir au niveau des outils de test (notamment pour les outils de test IHM), sur la parallélisation des tests, sur la sélection des tests à exécuter (réussir à prendre le minimum de test tout en assurant la qualité souhaitée). A ce moment, le testeur ne peut plus faire l’économie de l’étude des mesures en production. Quelles sont les anomalies les plus fréquemment remontées ? Quelles sont les faiblesses du produit ? Comment adapter les tests afin de les rendre plus efficace tout en ne prenant pas plus de temps. Tout cela ne peut se faire qu’en étroite collaboration avec l’ensemble des personnes travaillant sur le produit.
Conclusion
Le testeur agile est amené à collaborer étroitement avec l’ensemble des membres de son équipe par la mise en place de processus comme les revues et l’utilisation de plan de tests. De même, le testeur agile se doit également de faire autre chose que du test pour le bien de l’équipe, cette pratique lui permet d’ailleurs d’avoir une meilleure compréhension des problématiques des membres de son équipe et des faiblesses du produit.
Néanmoins, la plupart des processus peuvent être mis en place de manière « unilatérale ». De même un développeur peut écrire son code sans connaître à l’avance les tests qui seront exécutés. Dans ce cas on ne peut pas dire que le testeur et le développeur collaborent cela se ressent malheureusement sur la qualité du produit et de l’environnement de travail ce qui fait émerger les problématiques des méthodes de développement classiques réapparaissent. Les nouvelles approches comme le BDD et l’ATDD sont de très bons outils pour limiter ces écueils.
Cette nuance est inexistante avec une chaine d’intégration continue pour la simple et bonne raison qu’un développeur seul ne peut pas mettre en place une chaine efficace sans l’expertise d’un testeur et que l’inverse est vrai également. Si l’on veut faire de la livraison ou même du déploiement continu il est nécessaire d’avoir les connaissances des exploitants, des développeurs, des analystes métier et des testeurs car ces chaines nécessitent de fortes compétences techniques, la connaissance de nombreux outils mais aussi énormément de savoir sur les tests et leur sélection.
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
Une réponse