Nous avons parlé dans un article paru il y a quelques semaines, des challenges humains auxquels le testeur doit faire face..
Le métier du test n’étant pas uniquement humain il existe également de nombreux défis liés à la technicité du test.
Cet article vous propose quelques-uns de ces défis techniques que nous observons le plus fréquemment.
Les logiciels ne sont pas isolés dans leur environnement. Afin d’échanger avec les autres logiciels ils communiquent au moyen d’API. Afin d’avoir un produit fonctionnel il est essentiel de s’assurer que ce dernier puisse interagir avec certains logiciels environnants. Ces interactions entre logiciel se doivent donc d’être testées.
Ces tests peuvent s’avérer déstabilisants pour des testeurs car les APIs ne proposent pas d’interfaces graphiques (les logiciels n’en ont pas besoin pour communiquer entre eux) et nécessitent des outils spécifiques.
De plus, même s’il est aisé de maitriser les APIs de son logiciel, ce n’est pas forcément le cas pour les APIs des logiciels avec lequel notre produit interagit.
Enfin ces interactions, très codifiées, peuvent générer des architectures plus ou moins faciles à appréhender.
Il ne faut pas être effrayé par les tests d’APIs et les APIs en général lorsque l’on est testeur et ce même quand on est un testeur fonctionnel avec peu de compétences « techniques » et ce pour plusieurs raisons :
Les tests d’APIs sont un bon premier pas dans le monde des tests « techniques » car ils restent assez simples à appréhender dès lors où l’on a commencé à mettre les mains dans le cambouis. De même il est de plus en plus important, dans un contexte Agile, pour les testeurs de pouvoir intervenir sur différents aspects du test et les tests d’API sont une compétence de plus en plus recherchée.
Ce challenge n’est pas nouveau ! J’entends parler d’automatisation des tests depuis que j’ai commencé à travailler en 2011. D’ailleurs, je ne doute pas que les testeurs entendent parler d’automatisation depuis bien plus longtemps.
Il parait donc assez surprenant, au premier abord, de se dire que l’automatisation n’est pas totalement généralisée. D’ailleurs la part de test automatisés tant à se stabiliser plutôt qu’à se développer au cours des dernières années.
La raison est au final assez simple : il n’est pas simple d’automatiser l’exécution de ses tests. Les outils son nombreux, les besoins et contextes le sont encore plus !
De nombreux projets d’automatisation échouent car l’outil d’automatisation n’est pas adapté, les tests automatisés sont trop chronophage au niveau maintenance, les objectifs et la stratégie d’automatisation ne sont pas clairement définis ou adaptés ou encore les tests automatisés ne sont pas suffisamment fiables.
Afin de bien réussir son automatisation il faut donc bien sélectionner son outil, bien former les personnes qui interviendront sur cette automatisation, bien identifier le périmètre d’automatisation et adapter son périmètre et ses tests en fonction du contexte.
Si l’on est un testeur fonctionnel l’automatisation des tests peut vite devenir incompréhensible. En effet, le testeur non technique se doit de monter en compétence en scripting (pour comprendre et écrire des tests automatisés) mais aussi en mise en place et suivi de tests automatisés.
Dans ce cas, je conseille de faire les choses pas à pas en commençant par une automatisation « simple ». Cela peut se faire avec du test API ou en utilisant un framework KDT (Keyword Driven Testing) déjà développé comme on peut le voir avec des outils comme RobotFramework ou encore en utilisant des outils d’automatisation pensés pour des testeurs fonctionnels et qui permettent de se familiariser avec l’automatisation et ses contraintes. Je pense ici à des outils comme Agilitest.
Si l’on n’a pas de difficulté majeure avec la technique alors il n’y a « que » le challenge de mise en place et de réalisation qui est à relever. Il faut alors :
On entend, enfin, de plus en plus parler de tests non fonctionnels. Les plus courants sont les tests de sécurité (popularisés par la RGPD), les tests de performances, les tests d’adaptabilité (notamment pour les mobiles) et les tests d’accessibilité (popularisés par la RGAA en France et WCAG dans le reste du monde).
La liste de types de tests non fonctionnels va d’ailleurs continuer à s’agrandir avec les usages et les normes à venir comme la RGESN pour l’éco-conception.
Comme vous le savez il est impossible de faire tous ces tests en profondeur et un testeur se devra de savoir identifier quels tests non fonctionnels doivent être faits et jusqu’à quelle profondeur ils doivent être poussés.
Mon principal conseil est ici de s’appuyer sur des exigences et « d’exiger » d’avoir des exigences non fonctionnelles testables… ou tout simplement d’exiger que sur les points non abordés il n’y ait pas d’exigence et donc pas de besoin de test !
Je suis conscient que la première partie est utopique dans de nombreux contexte. Si l’existence de ces exigences n’est pas envisageable il peut être intéressant d’aborder le sujet des tests non fonctionnels directement dans la stratégie de test de l’entreprise avec les manières de sélectionner les tests non fonctionnels à implémenter. Puis de décliner cette stratégie dans les plans de test (stratégie au niveau du projet/produit). Dans le cas d’absence d’exigences chiffrées il faudra s’inspirer des différentes normes (RGPD, RGAA…) ou encore de ce que l’on observe sur le marché ou en production si le produit est déjà en production.
On pourrait m’argumenter que la conception de test n’est pas technique. Il est vrai qu’il n’est pas nécessaire de savoir manipuler ou lire du code pour concevoir de bons tests. La conception de tests de qualité est cependant un aspect hautement technique du travail de testeur.
Il existe plusieurs méthodes de conception de tests (les plus connues des testeurs sont basées sur les spécifications) qui permettent d’identifier, en fonction des conditions de test, quels sont les tests à faire et avec quelles valeurs.
De même, un testeur doit savoir prioriser et identifier, quels sont les éléments à tester et jusqu’à quel point en fonction des risques et des moyens dont il dispose.
Il faut tout d’abord bien connaitre ses techniques de conception, connaitre leurs points forts et points faibles et la manière de les implémenter.
Ces connaissances techniques ne sont pas suffisantes. Il est essentiel de bien appréhender le contexte et le produit à tester. Cela permet alors de s’adapter au contexte et de proposer un mixte de techniques qui permettent d’avoir un ensemble de test aussi efficient que possible.
Il est également primordial de faire un travail approfondi sur les données de test (certaines techniques de conception orientent fortement sur les valeurs à choisir pour certains cas) afin de choisir des données qui permettront de trouver au mieux les différentes failles potentielles du produit.
C’est une problématique majeure pour de nombreux testeurs ! Les environnements de test ne sont pas stables ou difficilement accessibles ou pas assez proches de la production.
Les données de sont pas représentatives ou pas assez nombreuses ou non accessible ou non anonymisées…
Le problème est ici que pour être capables de tester correctement un produit il est essentiel de se rapprocher d’usages proche de la production pour simuler aussi fidèlement que possible le comportement qu’auront les utilisateurs.
Malheureusement il est quasiment impossible d’avoir un environnement aussi important que celui de production d’un point de vue volume mais aussi interaction avec les partenaires. De même, tout miser sur du test en production avec du shift right n’est pas la solution.
Les problématiques de données et d’environnements sont généralement assez complexes.
Heureusement il existe actuellement de nombreux outils pour nous aider avec ces problématiques. Je pense notamment à la virtualisation des environnements qui permet de créer des environnements à la volée ce qui évite les problématiques d’environnements partagés par plusieurs équipes ou des environnements avec des données « déjà utilisées ».
Pour les données il existe des outils (éditeurs ou « maison ») qui permettent d’anonymiser et prendre des sous-ensembles de données en production pour avoir des échantillonnages représentatifs.
Pour la partie partenaire, une solution parfois obligatoire, est la mise en place de bouchons car les partenaires n’ont pas forcément d’environnement de test partagés avec notre produit ou que ce dernier est trop souvent « down ».
Bref, ici pas de solution miracle mais plutôt une recherche de solutions pragmatiques (souvent outillées) liées à chaque contexte. Le plus important étant d’identifier les points les plus problématiques afin d’essayer d’y répondre.
Enfin, il arrive également que les problèmes d’environnements et de données puissent se régler avec de l’humain dans des contextes où les environnements et les données de test ne sont pas sous le contrôle des équipes utilisant des environnements et données.