Quelles solutions pour le test fonctionnel en contexte Agile/DevOps ?

La dernière enquête du World Quality Report rapporte que 98% des personnes interrogées rencontrent de réelles difficultés pour tester dans un contexte DevOps/Agile. La démocratisation de ces nouvelles pratiques dans les projets informatiques constitue un défi considérable pour les responsables qualité.

56% d’entre eux soulignent l’absence d’environnement de test appropriés. 50% l’incapacité à appliquer l’automatisation des tests au niveau approprié. 65% buttent sur la difficulté à automatiser une application en cours de développement. Le marché du test logiciel aborde ces défis le marché en ordre dispersé. Plusieurs approches sont explorées par les acteurs du marché.

L’approche IA : On n’y est pas encore

Il y a d’abord l’approche « prioriser et optimiser ». Quelques acteurs commencent à proposer des outils pour rendre les tests plus intelligents grâce à l’intelligence artificielle. Celle-ci pourrait apporter des services tels que l’évaluation des risques en temps réel, la recherche des failles potentielles des applications à tester, des propositions de parcours de test appropriés, voire la réingénierie des référentiels de tests existants. Il s’agit dans ce dernier cas d’analyser des milliers de tests manuels pour les automatiser. Toutefois, selon le World Quality Report, les organisations ne sont pas encore suffisamment matures pour tirer avantage de ces technologies.

L’approche automatisation à tout crin : De sérieux écueils

Une approche plus pragmatique consiste à automatiser le plus possible. Mais cette démarche butte sur plusieurs écueils. D’abord l’application à tester doit être suffisamment stable avant d’envisager l’automatisation. Un deuxième écueil est celui de la double compétence testeur/développeur, difficile à trouver tant ces deux métiers ont des approches contradictoires. Le troisième écueil est la perte de la spécificité de la démarche de test lorsque l’activité du test se retrouve entièrement déportée sur le développement.

Pour contourner ces écueils des acteurs du marché proposent des outils d’aide à la spécification des tests à automatiser. Plusieurs solutions utilisent pour cela la syntaxe Gherkin. Il s’agit d’une façon particulière de formaliser les spécifications de manière à rendre le passage à l’automatisation plus aisé. L’inconvénient de cette approche est qu’elle enferme le testeur dans une démarche de test limitée et axée sur le test unitaire. Une approche end-to-end avec ces outils est inenvisageable. De plus ces outils n’évitent aucun des écueils inhérents à l’automatisation cités plus haut.

L’approche MBT : Ça ne parle pas aux testeurs

D’autres acteurs proposent des outils basés sur le MBT, c’est-à-dire la modélisation graphique des parcours de test. Il s’agit pour le testeur d’établir des organigrammes décrivant le comportement de l’application dans un outil qui, en sortie, produit des tests abstraits, sortes de documents de spécifications repris par les automaticiens pour développer les scripts. Certains acteurs vont plus loin en générant directement les scripts de test. Ces outils sont assez difficiles à appréhender, leur maniement est plutôt complexe et ils nécessitent des compétences de modélisation qui ne sont pas familières aux testeurs.

Il y a enfin les acteurs qui proposent des solutions « codeless », c’est-à-dire une interface de conception des tests accessible au testeur à partir de laquelle la génération du script de test est automatique. Si ces solutions tiennent leurs promesses, c’est-à-dire qu’elles permettent réellement aux testeurs non-informaticiens de produire rapidement et efficacement des tests automatisés, elles devraient rapidement prendre une place significative sur le marché. Cela d’autant plus qu’elles ne sont pas incompatibles avec d’autres approches telles que le MBT ou l’IA.