Lorsque j’évoque le test avec des agilistes, ceux-ci me répondent souvent que « la qualité est une responsabilité collective ». Admettons ! Cela signifie-t-il que le test est une responsabilité collective ? C’est en tout cas ce que semble dire mes interlocuteurs.
Le principe de l’agilité est de supprimer les cloisonnements et les hiérarchies qui entravent le processus créatif. L’idée fondatrice est de mettre ensemble le métier et les développeurs. En quelque sorte le rêveur et l’artisan pour faire jaillir des possibles que ni l’un ni l’autre n’aurait imaginé seul. Mais quelle est la place du testeur dans cet attelage ?
Le test, une incongruité dans l’agilité
Alors qu’il trouvait sa place dans le cycle en V, le test est une incongruité dans l’agilité. C’est un cube qu’il faut faire entrer dans un rond. Certes la théorie lui réserve une place de choix mais cela reste au niveau des discours. L’idée selon laquelle on enchaine dans un sprint la conception, le développement et le test relève de la pensée magique. C’est oublier la particularité du test. A chaque sprint il est nécessaire de tester bien plus que les seules évolutions. En conséquence la charge du test augmente inexorablement au fur et à mesure que l’application s’enrichit. Le cube ne rentre plus dans le rond.
Et les tests fonctionnels dans tout cela, où sont-ils ? Ces tests de sprint sont-ils des tests fonctionnels ? Pour rappel les tests fonctionnels ont pour but de valider le fonctionnement de l’application dans son ensemble. Or les tests d’un sprint ne vérifient que les modifications apportées par le sprint. Ce sont majoritairement des tests de composant ou d’intégration de composant.
Afin d’atténuer l’effet goulot d’étranglement le test manuel est rapidement exclu et le recours à l’automatisation systématique. Exit les quelques tests fonctionnels du testeur. Les développeurs se chargent de l’automatisation et intègrent les tests de sprint dans leur chaine d’industrialisation DevOps. Le rôle du testeur se réduit à donner des indications de tests de bas niveau.
Sauf qu’inévitablement, l’impensé refait surface. Les mises en prod hasardeuses, les retours clients négatifs révèlent un grand vide. L’application n’est pas suffisamment testée. En fait elle ne l’a jamais été en situation réelle.
Le test a toujours été le parent pauvre du développement logiciel. C’était déjà le cas du temps du cycle en V, c’est encore plus vrai avec l’agilité. Le cœur du métier du testeur c’est le test fonctionnel. C’est-à-dire se mettre à la place de l’utilisateur final jusqu’à en épouser les compétences et les tares. C’est aussi être en phase avec les objectifs marketing de l’entreprise. Son génie c’est de prendre en compte toutes ces dimensions pour concevoir des tests fonctionnels pertinents. C’est-à-dire des tests qui valident les attentes des utilisateurs mais aussi celles de l’entreprise.
L’agilité a émergé en réponse à certaines déficiences du cycle en V, notamment l’effet tunnel. Elle a apporté de substantielles améliorations dans la gouvernance des projets informatiques. Elle stimule la créativité et l’engagement des acteurs. Elle favorise les approches transverses. Toutes ces avancées sont précieuses. Reste que le test fonctionnel manque à l’appel. C’est une carence qui sape la confiance de vos clients dans votre capacité à mener à bien le projet informatique.
Ce manque de validation des processus métiers est pointé à maintes reprises d’année en année dans les enquêtes du World Quality Report : « Absence d’environnement de test approprié », « Incapacité à appliquer l’automatisation des tests au niveau approprié », « Difficultés à identifier les bons domaines sur lesquels les tests doivent se concentrer » sont les réponses les plus fréquentes à la question « Défis actuellement rencontrés dans l'application des tests en développement agile »
En résumé les testeurs se plaignent d’un manque d’outil adapté à l’agilité. Ils ne savent pas quoi tester et se demandent comment prioriser les tests.
On aurait pu s’attendre à ce que les acteurs du marché du test leur apportent des réponses. Il n’en est rien. Leurs offres se focalisent souvent sur l’automatisation des couches basses des applications. Avec pour horizon le test en continu intégré dans une chaine CI/DevOps. Les quelques acteurs qui sortent de cette logique proposent des solutions contraignantes pour le testeur. On peine à discerner la plus-value de ceux qui font étalage d’intelligence artificielle.
La solution Scapin
Dans ce paysage, l’offre Scapin se démarque nettement. Scapin est une plateforme de qualification qui rassemble tout ce dont le testeur a besoin pour le test fonctionnel en contexte agile. Il apporte des réponses originales qui changent la donne.
Des tests hyper faciles et rapides à automatiser par le testeur lui-même.
Une stratégie de test pilotée par le métier grâce aux objectifs de test attachés aux cas de test.
Les experts métier testent l’application dès la phase de conception.
Pas de code abscond, tout est transparent. Les tests comme les résultats d’exécution sont accessibles à tous les acteurs du projet
Une gestion simple et efficace des changements pour accompagner les évolutions de l’application à tester, tout en préservant l’historique du projet.
Cette liste n’est pas exhaustive. Scapin est un outil complet, puissant et riche qui couvre l’ensemble des activités du test.
Comments