Les challenges du testeur d'un point de vue technique

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 tests API

Les challenges

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.

  • Mes conseils

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 :

  • Il existe de nombreux outils de test d’APIs accessibles et relativement simples à prendre en main comme Postman,
  • Les tests d’APIs ne sont généralement pas particulièrement complexes fonctionnellement car ce sont des messages normés dans lesquels ont fait passer des variables. Personnellement, j’aime voir les tests APIs comme des tests de formulaires dans lesquels on vérifie différentes valeurs que peuvent prendre les champs,
  • Il est simple de multiplier les tests d’APIs très rapidement. En effet, dès le moment où l’on a un message, on peut faire de nombreux tests (avec des tests pilotés par les données) basés sur ce même message de base.

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.

Automatisation des tests

Les challenges

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.

  • Mes conseils

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 :

  • Bien sélectionner l’outil de test à utiliser afin que celui-ci permette de gérer les différents besoins des tests,
  • Proposer des tests maintenables en utilisant les bonnes pratiques de code,
  • Assurer une maintenance régulière des tests automatisés,
  • Assurer un suivi régulier de ces tests, faire vivre la campagne de test.

L’intégration des bons tests non fonctionnels

Les challenges

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.

  • Mes conseils

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.

La conception des tests

Les challenges

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.

  • Mes conseils

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.

La gestion des données et environnements de test

Les challenges

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.

  • Mes conseils

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.

Add below a CTA if need be (webinar, case study, interview, etc.)

A propos de l'auteur

Marc Hage Chahine est facilitateur de tests au sein de l'équipe d'experts de QESTIT. Créateur du blog français "La taverne du testeur" et membre actif de la communauté des testeurs en tant que conférencier, auteur de livres, organisateur et conférencier lors d'événements sur les tests de logiciels - il fait partie du comité de la JFTL (Journée Française du Test Logiciel).

Envie d'en savoir plus ?