C’est l’histoire d’une équipe de développement de logiciels qui fournit des versions successives à son client avec des défauts ! Je les appelle un « problème » pour cette équipe, car, bien entendu, son client voudrait zéro défaut.
Pour sortir de cette situation, l’équipe conduit des résolutions de problème, en utilisant en particulier la technique PDCA[1].
Elle en ressort avec trois changements, à mettre en place désormais pour réduire les défauts de façon durable :
- Toujours coder avec l’approche TDD.
- Mieux écrire les User Stories. Il s’agit en particulier d’y mentionner les critères d’acception de façon explicite. Ces derniers étant très importants pour les testeurs.
- Introduire les tests automatisés au plus tôt et tout au long de son cycle de développement de logiciels. Pour cela il faut un choisir un outil approprié.
Introduire les tests automatisés
Pour ce choix d’un outil d’automatisation des tests, l’équipe se pose trois questions :
- Qui va l’utiliser ? l’équipe décide que ce sont les Testeurs et les Product Owners[2]. En effet, ces derniers sont les représentants du client. Ils connaissent parfaitement la vision client du logiciel. De plus ils sont impliqués dans l’écriture des exigences (ici représentées sous forme de User Stories). Ainsi ils ont une réelle légitimité à vérifier si le logiciel fonctionne comme attendu.
- Quel type d’outil choisir ? En restant sur leur situation spécifique où les Product Owners vont aussi faire des tests, l’équipe choisit un outil « no code[3] ». Il permettra, de plus, d’embarquer rapidement les testeurs dont la plupart n’ont pas d’expérience en langage de programmation. De façon plus précise, l’équipe veut un outil qui ne requiert pas de savoir programmer, mais qui offre aussi la possibilité à ceux qui s’y connaissent, de coder leurs tests. Elle estime que cette opportunité est cruciale lorsqu’il s’agira de personnaliser l’outil.
L’équipe veut également un outil ouvert aux extensions car elle fait partie d’une grande organisation qui utilise une multitude d’autres logiciels. L’idée est de pouvoir se connecter si besoin aux autres outils déjà présents. Ainsi, il sera nécessaire de rajouter des modules spécifiques (gestion des exigences, des versions, génération de rapport, intégration et livraisons en continue) de façon simple.
Pour finir, les testeurs de l’équipe veulent un outil disposant d’un fort soutien communautaire. Ils pourront ainsi bénéficier de l’expérience d’autres utilisateurs de l’outil avec une bonne réactivité et sans enjeux commerciaux. Ils pensent qu’un fort soutien communautaire est un gage de qualité et permet de garantir une pérennité des usages et des apprentissages.
- Comment démarrer l’automatisation ? Ils décident de conduire un pilote. Un Product Owner et un testeur utiliseront l’outil sur un périmètre fonctionnel restreint pendant trois mois.
Approche pour un pilote
L’équipe délivre un site e-commerce. De ce fait, elle se retrouve avec des cas de test dont les complexités sont différentes (par exemple: formulaires avec des champs conditionnels, systèmes de paiements, gestion de litiges).
Pour mieux appréhender l’outil dans son contexte, l’équipe recrute un expert. Elle veut s’appuyer sur son expertise pour créer des modules spécifiques réutilisables (chargement des paramètres utilisateurs, connexion au système de test pour les paiements, chargement des variables via une base de données).
L’équipe définit aussi les critères d’évaluation du pilote : elle suit les gains de productivité en nombre de tests par jour pendant la durée du pilote ; elle mesure les gains en jour-homme et la qualité des tests de régression ; elle consigne les irritants remontés au jour le jour; elle valide l’intégration avec les autres outils qu’elle utilise déjà ; elle mesure la pertinence et la réactivité du support ; elle crée son plan de montée en compétence ; elle évalue les coûts d’acquisition, de renouvellement de licences et de formation.
Des enseignements de cette expérience
De cette expérience, je retiens des points clés tout au long du cheminement de cette équipe :
- Avoir un problème spécifique à son contexte : quel problème essayez-vous de résoudre ? il peut s’agir de délai, de satisfaction client. Ici, l’équipe veut améliorer sa qualité, et donc réduire ses défauts. Elle a conduit des résolutions de problème au lieu de répliquer une solution existante.
- Prendre conscience des apports de l’automatisation et de son périmètre : en effet, elle n’était ici qu’une partie de la solution. De plus l’équipe introduit le TDD et les critères d’acceptation sur les User Stories.
- S’intégrer dans son environnement : vérifier l’interconnexion avec les outils existants, dont certains peuvent être très anciens. De plus il peut y avoir des contraintes systèmes et réseaux.
- Démarrer avec un pilote : bien défini en termes de délai et critères d’évaluation. Recourir à une expertise pour réussir ce pilote. Les questions récurrentes ici sont la définition du pilote, son délai, ses objectifs et ses conditions de fin. Que faut-il mesurer, suivre ou évaluer pendant ce pilote ? A quelles conditions considérer que le pilote est terminé ? avec quels critères de succès ? Ces éléments sont indispensables pour des décisions pertinentes.
- Tenir compte des compétences de l’équipe : en particulier en programmation. Jusqu’à quel point faut-il savoir coder? En réalité, il faut identifier les écarts de compétences et en tenir compte. En considérant l’outil que vous visez, quels types de compétences les testeurs doivent ils développer ?
- Personnaliser : recenser les spécificités de ses objets à tester (types : par exemple interfaces utilisateurs ; technologies : javascript, Cobol, etc), et recourir, si besoin, à une expertise pour y voir clair.
- Valider le support : aurez-vous le support qu’il vous faut ? il faut prendre la peine de découvrir et tester le support disponible pour l’outil. C’est à cette étape qu’il faut rechercher l’existence d’une communauté, de formations ou de documentations accessibles
- Se poser la question des moyens. Il ne s’agit pas seulement de coût de licences, mais aussi de formation, de montée en compétences et de ses impacts, d’achat de consulting ou de coûts de développement additionnel pour les personnalisations.
Passer à l’automatisation des tests c’est se donner les moyens de mieux tester, et donc apporter encore plus de valeur à l’organisation et aux clients. Pour le testeur se posent alors des questions de maintenabilité et d’évolution des tests.
Discutons de l’approche pour automatiser vos tests[1] Le PDCA (Plan, Do, Check, Act) suit les étapes de la méthode scientifique. Partant d’un problème formulé comme un écart de performance : « Plan » élabore une hypothèse de cause et une approche de résolution expérimentale ; « Do » mène l’expérience ; « Check » recueille les mesures ; « Act » interprète les résultats et pérennise les actions désormais appropriées pour éradiquer le problème.
[2] Ou « Directeur de produit ». C’est un rôle clé dans les équipes qui travaillent selon la méthode Scrum
[3] Elle renvoie à un mode de développement logiciel qui masque la complexité du code source de l’application. Elle fait référence aux outils de développement sans code.
Laisser un commentaire