Le test fonctionnel : Un impensé de l’agilité

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 ?
Agilité vs Tests fonctionnels ! Comment vivez-vous cette situation ?
Le test est 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 prive le projet informatique des compétences du testeur. Ce manque de test de validation du processus métier de bout en bout est pointé à maintes reprises dans l’édition 2020 du World Quality Report.
Aucun produit du marché n’aborde le test fonctionnel comme le fait Scapin
L’Atelier de Qualification Scapin comble ce manque. Il réunit tout ce dont le testeur à besoin et tout ce qui est nécessaire pour le test fonctionnel en contexte agile. Il apporte des réponses originales qui changent la donne. Par exemple les tests exploratoires. Ils permettent aux équipes métier de réaliser des itérations de test fonctionnels avant de lancer les développements. C’est un gain de temps considérable, surtout en début du projet. Ces tests évitent d’incessants aller-retour MOA-MOE et deviennent des tests automatisés dès que l’application est livrée.