J’ai récemment lancé un sondage visant à savoir quel sera, d’après les professionnels du test, le futur du test logiciel.
Dans cet article je vais présenter ma vision et expliquer mes choix. Le résultat définitif du sondage sera quant à lui communiqué la semaine prochaine.
Afin de ne pas influer sur ce sondage, je vous demande de ne pas modifier vos réponses suite à la lecture de cet article et de répondre à ce dernier avant de lire cet article si vous souhaitez y répondre.
J’ai personnellement voté pour ces 3 points :
- Les tests non fonctionnels (sécurité, adaptabilité, utilisabilité, performances… (voir ISO 25 010)
- Le rapprochement des méthodes d’IA, BDD et MBT pour faire du test une documentation vivante
- Le shift right (Test en production)
Dans ce sondage j’avais proposé 11 réponses (+ la possibilité d’ajouter d’autres propositions). Toutes font partie intégrante du futur du test. J’avais demandé à chaque participant de choisir jusqu’à 3 réponses afin qu’ils indiquent, selon eux, quelles eront les 3 évolutions majeures du test.
Je vais ici expliquer les raisons de mon vote en décrivant brièvement ma réflexion sur chaque choix proposé initialement :
- L’automatisation
L’automatisation est en plein essor avec le développement des méthodes agiles (itératives). Le besoin d’automatisation est très grand et également toujours plus important. Néanmoins l’automatisation, du moins ses bonnes pratiques, sont de plus en plus connues et maitrisées et reste, selon moi, un outil, une conséquence.
Pour ces raisons (outils/conséquence mais surtout déjà bien présent), je ne pense pas que l’automatisation fera partie des 3 prochaines grandes évolutions du test. L’automatisation fera évidemment partie du futur du test mais je ne vois pas de « révolution » du test engendrée par l’automatisation.
- L’agilité avec l’intégration du test dans les équipes de développement
L’agilité a de plus en plus de place, les dernières études (notamment celle du CFTL en 2017) ont montrées que presque 50% des équipes fonctionnait avec des méthodes agiles et des testeurs déjà intégrés.
Les testeurs font donc dès maintenant partie des équipes de développement et sont considérés généralement considérés comme indispensables (je n’aurais pas dit ça il y a 5 ans !).
Je n’ai donc pas choisi ce point.
- Les tests non fonctionnels (sécurité, adaptabilité, utilisabilité, performances… (voir ISO 25 010)
Lors de mon article sur Agilitest, je remonte que les principaux points améliorés dans l’application sont les aspects non fonctionnels.
Qui consulte un page qui met plus de 10 secondes à s’afficher ? Qui utilise un site qu’il trouve peu ergonomique ? Qui utilise une application qui ne fonctionne que sur une dizaine de portables mais n’est pas adaptable à d’autres ?
Tout cela est encore trop peu testé mais explique le succès de certains produits au détriment d’autres. l’Iphone a eu du succès grâce à son ergonomie ! Android fonctionne grâce à son adaptabilité…
L’adaptabilité qui va devenir de plus en plus importante avec l’IoT.
Sans oublier tous les aspects sécurités avec notamment la multiplication des données.
Pour toutes ces raisons, je suis persuadé, que ces tests vont devenir de plus en plus importants et qu’ils sont une pierre angulaire des prochaines évolutions du test.
- L’IA
L’IA, qui existe depuis longtemps, est un formidable outil. Néanmoins, l’IA « seule » ne veut, à mon sens, pas dire grand-chose. Il faut lui trouver une utilité, savoir quoi en faire, comment en faire autre chose qu’un gadget.
Je pense que le point le plus intéressant de l’IA, à court/moyen terme, est le gain sur la maintenance. Ayant un choix proposant cette utilisation de l’IA je n’ai donc pas choisi « L’IA » mais son application proposée dans le point suivant.
- Le rapprochement des méthodes d’IA, BDD et MBT pour faire du test une documentation vivante
L’énoncé est, je le concède, assez mal formulé. L’idée derrière est, à l’aide du MBT, du BDD et de l’IA, de toujours avoir une documentation et des tests à jour, d’avoir une documentation toujours compréhensible par les membres du projets qu’ils viennent ou non d’arriver sur le projet.
Cela entrainerai également un fort rapprochement entre les exigences et les tests.
J’aime beaucoup un outil comme Yest (MBT et ATDD/BDD), néanmoins cet outil est coûteux (en temps) à mettre en place si on veut modéliser complètement un logiciel complexe déjà existant.
Afin de combler ce problème je pense à l’IA, qui, à partir du code, pourrai proposer des modèles.
Cette fusion reviendrai à une diminution drastique de la maintenance, qui reste à ce jour, de mon point de vue, un des principaux problèmes des tests.
C’est donc pour cela que j’ai choisi ce point pour faire partie des 3 prochaines grandes évolutions
- Les xDD (TDD, BDD…)
Les xDD (TDD, BDD, ATDD, DDD…) sont très utiles, cela permet de tester tôt, d’améliorer la communication, de se concentrer sur l’essentiel et d’avoir potentiellement une documentation vivante.
Néanmoins ce n’est pas seul mais avec d’autres outils qu’il aura son principal impact. Je n’ai donc pas choisi directement ce point.
- Le MBT (Model Base Testing)
Comme expliqué précédemment, le MBT seul ne me semble pas suffisant, il faut aller plus loin, notamment en permettant d’avoir des modèles à partir de logiciels déjà déployés en complexes.
- Le shift right (Test en production)
Le shift right est le pendant du shift left sauf que plutôt en plus de tester tôt on teste aussi (en faisant des mesures) sur la production elle-même.
Le principe est de découvrir le plus tôt possible s’il y a des problèmes en production et, avec la puissance du déploiement continu, pouvoir résoudre le problème très rapidement.
Je pense que le shift right va révolutionner le test et devenir quasiment indispensable car les environnements de production sont de plus en plus complexes de par la multiplicité des partenaires (API, communications…) et des terminaux utilisateurs (IoT).
Cette complexité va devenir de plus en plus cher à modéliser en test et le testeur se verra surement contraint de tester « moins » en phase de test mais en contrepartie faire un meilleur suivi en production.
- Le déploiement continu
Le déploiement continu permet le shift right. Il est donc un maillon essentiel pour ce changement. Faisant partie intégrante de la « révolution » du shift right je ne vois pas de raison de l’ajouter dans les évolutions du test.
- Les tests exploratoires
A l’heure où il y a de plus en plus d’automatisation, des applications de plus en plus complexes, des mises à jour toujours plus fréquentes (donc plus d’exécutions : paradoxe du pesticides) … Avoir uniquement des tests prédéfinis est une grosse limitation.
Les tests exploratoires vont donc avoir un grand rôle à jouer dans les années à venir un rôle primordial car ils permettent, à moindre coût d’avoir une meilleure visibilité sur les aspects non fonctionnels (adaptabilité, ergonomie, stabilité performances…) mais aussi de se concentrer sur les points faibles de l’application (regroupement de défauts) et limiter le paradoxe des pesticides.
Si j’avais pu choisir 4 évolutions j’aurai sûrement pris les tests exploratoires en 4ème.
- Le KDT et l’accès facilité à l’automatisation pour les personnes peu techniques
Le KDT est et continuera à s’avérer essentiel pour les personnes non techniques ou plus simplement pour faire comprendre les tests à des analystes. Néanmoins comme écrit dans ma phrase précédente, c’est déjà le cas et il existe déjà de bons outils de KDT (robot framework, BPT, Agilitest). L’utilisation va donc de plus en plus se démocratiser mais cette évolution est, de mon point de vue, déjà à l’œuvre !
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
