.svg){kind=logo}
Back
Dans un article publié il y a quelques semaines, nous avons évoqué les défis d'ordre humain auxquels sont confrontés les testeurs.
Le métier de testeur n'est pas seulement d'ordre humain ; il comporte également de nombreux défis liés aux aspects techniques des tests.
Cet article présente certains des défis techniques que nous rencontrons le plus fréquemment.
Tests d'API
Le défi
Les logiciels ne fonctionnent pas en vase clos. Ils communiquent avec d’autres logiciels via des API. Pour qu’un produit soit fonctionnel, il est essentiel de s’assurer qu’il peut interagir avec certains logiciels environnants. Ces interactions logicielles doivent donc être testées.
Ces tests peuvent être déroutants pour les testeurs, car les API ne disposent pas d’interfaces graphiques (les logiciels n’en ont pas besoin pour communiquer entre eux) et nécessitent des outils spécifiques.
De plus, s’il est facile de maîtriser les API de nos propres logiciels, ce n’est pas nécessairement le cas pour les API des logiciels avec lesquels notre produit interagit.
Enfin, ces interactions hautement codifiées peuvent donner lieu à des architectures plus ou moins faciles à comprendre.
- Conseils
Il existe plusieurs raisons pour lesquelles vous ne devriez pas avoir peur des tests d’API et des API en général lorsque vous êtes testeur, même si vous êtes un testeur fonctionnel disposant de peu de compétences « techniques » :
- Il existe de nombreux outils de test d’API, tels que Postman, qui sont accessibles et relativement faciles à prendre en main,
- Les tests d’API ne sont généralement pas particulièrement complexes sur le plan fonctionnel, car il s’agit de messages standardisés dans lesquels des variables sont transmises. Personnellement, j’aime considérer les tests d’API comme des tests de formulaires, dans lesquels on vérifie les différentes valeurs que les champs peuvent prendre,
- Il est facile de multiplier très rapidement les tests d’API. En effet, une fois que vous disposez d’un message, vous pouvez exécuter de nombreux tests (y compris des tests pilotés par les données) à partir de ce même message de base.
Les tests d’API constituent une bonne première étape dans l’univers des tests « techniques », car ils sont assez faciles à maîtriser une fois que l’on s’y est mis. De même, dans un contexte Agile, il est de plus en plus important que les testeurs puissent intervenir dans différents aspects des tests, et les tests d’API sont une compétence de plus en plus recherchée.
Automatisation des tests
Le défi
Ce n’est pas un défi nouveau ! J’entends parler d’automatisation des tests depuis mes débuts professionnels en 2011. En réalité, je suis persuadé que les testeurs en entendent parler depuis bien plus longtemps encore.
À première vue, il semble donc assez surprenant de constater que l’automatisation ne soit pas encore totalement généralisée. En réalité, la part des tests automatisés a eu tendance à se stabiliser plutôt qu’à augmenter ces dernières années.
La raison en est assez simple : il n’est pas facile d’automatiser l’exécution des tests. Les outils sont nombreux, les besoins et les contextes le sont encore plus !
De nombreux projets d’automatisation échouent parce que l’outil d’automatisation n’est pas adapté, que les tests automatisés sont trop chronophages à maintenir, que les objectifs et la stratégie d’automatisation ne sont pas clairement définis ou adaptés, ou encore que les tests automatisés ne sont pas suffisamment fiables.
Pour réussir l’automatisation, il faut choisir le bon outil, former les personnes qui y participeront, déterminer le périmètre de l’automatisation et adapter ce périmètre ainsi que les tests au contexte.
- Conseils
Si vous êtes testeur fonctionnel, l’automatisation des tests peut rapidement vous paraître incompréhensible. En effet, les testeurs non techniciens doivent développer leurs compétences en création de scripts (pour comprendre et écrire des tests automatisés) ainsi que leur capacité à configurer et à surveiller ces tests.
Dans ce cas, je recommande de procéder étape par étape, en commençant par une automatisation « simple ». Cela peut se faire par le biais de tests d’API ou en utilisant un framework KDT (Keyword Driven Testing) déjà développé, comme c’est le cas avec des outils tels que RobotFramework, ou encore en utilisant des outils d’automatisation conçus pour les testeurs fonctionnels, qui leur permettent de se familiariser avec l’automatisation et ses contraintes. Je pense ici à des outils comme Agilitest.
Si vous ne rencontrez pas de difficultés majeures sur le plan technique, il ne reste alors « plus qu’à » relever le défi de la mise en place et de l’exécution du système. La clé réside dans :
- choisir l’outil de test à utiliser de manière à ce qu’il puisse répondre aux différentes exigences de test,
- proposer des tests faciles à maintenir en respectant les bonnes pratiques de codage,
- Assurer la maintenance régulière des tests automatisés,
- Assurer un suivi régulier de ces tests et maintenir la campagne de tests active.
Intégration des tests non fonctionnels appropriés
Le défi
Enfin, on entend de plus en plus parler des tests non fonctionnels. Les plus courants sont les tests d’intrusion (popularisés par le RGPD), les tests de performance, les tests d’adaptabilité (notamment pour les appareils mobiles) et les tests d’accessibilité (popularisés par la RGAA en France et les WCAG dans le reste du monde).
La liste des types de tests non fonctionnels continuera de s’allonger, en fonction des utilisations futures et des normes telles que la RGESN pour l’éco-conception.
Comme vous le savez, il est impossible de réaliser tous ces tests de manière approfondie, et un testeur doit savoir quels tests non fonctionnels effectuer et à quel niveau de détail.
- Conseils
Mon principal conseil ici est de s’appuyer sur les exigences et d’« exiger » que les exigences non fonctionnelles soient testables… ou simplement d’exiger que, sur les points non abordés, il n’y ait pas d’exigences et donc pas besoin de tests !
Je suis conscient que la première partie relève de l’utopie dans de nombreux contextes. Si l’existence de telles exigences ne peut être envisagée, il peut être utile d’aborder directement la question des tests non fonctionnels dans la stratégie de test de l’entreprise, en définissant des critères de sélection des tests non fonctionnels à mettre en œuvre. Cette stratégie peut ensuite être traduite en plans de test (stratégie au niveau du projet/produit). En l’absence d’exigences quantifiées, vous devrez vous inspirer des différentes normes (RGPD, RGAA…) ou de ce que vous observez sur le marché ou en production si le produit est déjà en production.
Conception des tests
Le défi
On pourrait affirmer que la conception de tests n’est pas une activité technique. Il est vrai qu’il n’est pas nécessaire de savoir manipuler ou lire du code pour concevoir de bons tests. Cependant, la conception de tests de qualité constitue un aspect hautement technique du métier de testeur.
Il existe plusieurs méthodes de conception de tests (les plus connues des testeurs sont celles basées sur les spécifications) qui permettent de déterminer, en fonction des conditions de test, quels tests exécuter et avec quelles valeurs.
De même, un testeur doit savoir hiérarchiser et identifier les éléments à tester, ainsi que l’étendue de ces tests, en fonction des risques et des ressources disponibles.
- Conseils
Tout d’abord, vous devez connaître vos techniques de conception, leurs forces et leurs faiblesses, ainsi que la manière de les mettre en œuvre.
Mais les connaissances techniques ne suffisent pas. Il est essentiel de comprendre le contexte et le produit à tester. Cela nous permet de nous adapter au contexte et de proposer une combinaison de techniques qui aboutira à un ensemble de tests aussi efficace que possible.
Il est également essentiel de travailler en profondeur sur les données de test (certaines techniques de conception fournissent des indications précises sur les valeurs à choisir dans certains cas), afin de sélectionner les données qui permettront le mieux de mettre en évidence les différents défauts potentiels du produit.
Gestion des données et environnements de test
Le défi
C'est un problème majeur pour de nombreux testeurs ! Les environnements de test ne sont pas stables, difficiles d'accès ou pas assez proches de l'environnement de production.
Les données ne sont pas représentatives, pas assez nombreuses, inaccessibles ou non anonymisées…
Le problème, c’est que pour tester correctement un produit, il est essentiel de se rapprocher le plus possible des conditions d’utilisation en production, afin de simuler le comportement des utilisateurs de la manière la plus fidèle possible.
Malheureusement, il est pratiquement impossible de disposer d’un environnement aussi vaste que celui de production, tant en termes de volume que d’interaction avec les partenaires. De même, se reposer entièrement sur les tests en production avec une approche « shift right » n’est pas la solution.
- Conseils
Les problèmes liés aux données et à l'environnement sont généralement assez complexes.
Heureusement, il existe aujourd’hui un certain nombre d’outils pour nous aider à gérer ces problèmes. Je pense notamment à la virtualisation des environnements, qui nous permet de créer des environnements à la volée, évitant ainsi les problèmes liés aux environnements partagés par plusieurs équipes ou contenant des données « déjà utilisées ».
En ce qui concerne les données, il existe des outils (proposés par des éditeurs ou développés en interne) qui permettent de les anonymiser et d’en extraire des sous-ensembles à partir de l’environnement de production afin d’obtenir des échantillons représentatifs.
En ce qui concerne les partenaires, une solution parfois incontournable consiste à mettre en place des « plugs », car les partenaires ne disposent pas nécessairement d’environnements de test partagés avec notre produit, ou parce que ce dernier est trop souvent « hors service ».
En résumé, il n’y a pas de solution miracle ici, mais plutôt une recherche de solutions pragmatiques (souvent basées sur des outils) adaptées à chaque contexte. L’essentiel est d’identifier les points les plus problématiques et d’essayer de les résoudre.
Enfin, il arrive également que les problèmes liés à l’environnement et aux données puissent être résolus par une intervention humaine dans les contextes où les environnements de test et les données ne sont pas sous le contrôle des équipes qui les utilisent.
.png)
