top of page

Face à l’agilité, la douloureuse mutation des tests fonctionnels


Autrefois, disons avant que les pratiques Agile/devOps ne se démocratisent, les tests fonctionnels intervenaient à la fin du cycle en V. Les testeurs avaient le temps nécessaire pour préparer leurs tests puis celui nécessaire pour les exécuter. (Encore que, trop souvent des retards et des contraintes de time-to-market amputaient ce temps dévolu aux tests).

Aujourd’hui ce n’est plus le cas. Fini les cycles de développement qui se déroulent sur plusieurs mois. Ce sont des sprints de quelques jours, généralement une quinzaine. Intenable pour les testeurs d’assurer à la fois le test des nouvelles fonctionnalités et la non-régression.



Le test fonctionnel est délaissé parce qu’il reste manuel

Le test fonctionnel, celui réalisé par le testeur avec le souci de l’utilisateur, est souvent manuel. Or rédiger des tests manuels n’a rien d’une partie de plaisir. Il faut que le test fonctionnel puisse être exécuté par quelqu’un d’autre que soi. Cela implique d’être à la fois explicite, concis et rigoureux dans la description des étapes de test. L’exécution ensuite de ces tests est une activité rébarbative. Pour ne rien arranger, ces deux activités peu valorisantes sont chronophages.

C’est pourquoi, très vite, après seulement quelques sprints, soit les tests fonctionnels deviennent le goulot d’étranglement du projet, soit ils sont allégés au maximum. Par ailleurs, de plus en plus souvent, les développements sont répartis sur plusieurs équipes. Parfois ils concernent non pas une mais plusieurs applications fonctionnant en symbiose au sein d’un même écosystème. Ces contextes rendent plus que jamais nécessaires les tests fonctionnels, réalisés de bout en bout. Ils sont pourtant notoirement insuffisants et souvent peu représentatifs de la vraie vie des applications.

Les clés de la mutation

Dans ce contexte il apparaît clairement que les pratiques de test fonctionnel sont inadaptées au contexte agile/DevOps. Les organisations contournent le problème en intégrant des tests automatisés dans leur processus de fabrication. Elles assurent ainsi un minimum de qualité de leurs livraisons. Mais cela est loin d’être suffisant et ne répond pas à la nécessité grandissante de tester des parcours utilisateur complets, de bout en bout. Des parcours passants, non-passants, avec interruption et reprise, parfois même des parcours au long cours pouvant s’étaler sur plusieurs jours ! Tout cela nécessite de repenser de fond en comble les activités de test fonctionnel. Elles doivent être résolument tournées vers le métier et non pas déportées sur le développement comme c’est la tendance actuellement. Elles doivent aussi s’adapter aux changements incessants inhérents aux pratiques Agile/DevOp et doivent le faire rapidement pour rester en phase avec le rythme des sprints.


Force est de constater que les acteurs du marché font l’impasse sur cette mutation.

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 d'automatisation des tests SCAPIN

Dans ce paysage la Plateforme de Qualification SCAPIN détonne. Aucun produit du marché n’aborde le test fonctionnel comme le fait SCAPIN. Entièrement vouée au test fonctionnel automatisé, elle en organise toutes les activités: Définition des objectifs de test (requirements), cas de tests automatisés, campagnes de test, serveur d’automatisation, reporting. C’est une véritable plateforme d’industrialisation de qualification fonctionnelle. C’est aussi une « qualithèque » qui met à disposition de tous l’ensemble du patrimoine de test.




12 vues0 commentaire

Commentaires


bottom of page