Tests logiciels: améliorer la qualité et réduire les délais

Une équipe de 15 testeurs de logiciels est chargée de vérifier les versions d’un gros logiciel de traitement de feuilles de soins. Les clients identifient 15% des défauts du logiciel. 23% de ces défauts, non corrigés du 1^er coup, sont encore identifiés par ces clients qui ne sont pas contents. Lors de ses campagnes de tests, l’équipe n’arrive pas à exécuter l’intégralité des tests qu’elle prévoit.

Les causes observées

Au vu de ces problèmes, je conduis un atelier avec le leader de l’équipe et quelques-uns de ses collègues. Ils apprennent des techniques du Lean Management : la voix du client, la qualité, la variabilité, les standards de travail, mais aussi des méthodes d’observation d’un processus de travail.

Ensuite, lors d’observations de leurs collègues au travail, nous identifions certaines causes des problèmes :

• Le processus de test utilisé génère des gaspillages. Les testeurs écrivent d’abord un grand nombre de tests pendant plusieurs semaines. Ensuite ils démarrent l’exécution de ces tests mais se retrouvent à les modifier à nouveau face à des spécificités du logiciel à tester qu’ils découvrent à la dernière minute.
• Les testeurs ne connaissent pas bien les règles métier. Certains testeurs ont des difficultés à écrire les cas de test par manque de connaissances fonctionnelles. L’observation montre une couverture de test insuffisante et des étapes de test manquants.
• Il n’y a pas de méthode partagée pour récupérer les jeux de données. En effet, chacun, à sa manière, récupère les jeux de données nécessaires. Certains y mettent 4 fois plus de temps que leurs collègues, d’autres sont bloqués. Pour plusieurs tests, l’observation montre des jeux de données manquants ou inadaptés.
• Les tests, ainsi que la manière de tester, n’évoluent pas. Un défaut identifié par les clients ne donne lieu, ni à une évolution de la manière de tester, ni à une mise à jour du patrimoine de test. De ce fait, les clients continuent d’identifier des défauts non corrigés du 1^er coup.

Les actions menées

Consternés par ce qu’elle a vu, mais formés à certains outils du Lean Management et avec une nouvelle vision de ce qu’ils peuvent réussir ensemble, les testeurs décident, avec mon aide en tant que Coach Lean, d’exécuter le plan d’action suivant :

1. Rendre visible le flux des tests qu’elle produit et exécute en temps réel.

   Pour cela, l’équipe crée un management visuel. Il montre le processus de test, avec le nombre de tests à chaque étape. Il porte aussi la cible en nombre de tests à exécuter chaque jour. Il contient de plus une zone dédiée où chaque testeur indique l’identifiant de tout test en souffrance. Ainsi en un coup d’œil, l’équipe comprend sa situation et a la possibilité de réagir en conséquence.

2. Changer son processus de test.

   Le management visuel montre des tests en attente de façon récurrente. Cette situation pousse les testeurs à travailler désormais par itérations avec les développeurs qui leur fournissent une 1^ère version du logiciel au plus tôt. Grâce aux livraisons journalières du logiciel, les testeurs exécutent des tests tout au long des développements.

3. Adapter la stratégie de test après chaque problème de qualité.

   Tester plus tôt fait voir des défauts plus rapidement et fait émerger des typologies de défauts associées à certaines fonctions et règles métiers. Les testeurs ont alors l’idée de toujours rechercher les causes de tout défaut, y compris ceux vus par les clients, dans le but de mettre à jour systématiquement les tests. Pour cela, je leur apprends une approche structurée de résolution de problème « PDCA » pour partir de tout défaut jusqu’à l’évolution des pratiques de développement et de test associées.

4. Gérer la performance de façon collective.

   Pour voir l’impact des actions précédentes, j’accompagne l’équipe sur la mise en place d’indicateurs de performance. Nous créons, de façon visuelle, sur le mur :

   • La satisfaction de leurs clients.
   • Les défauts vus par les clients, y compris ceux non corrigés du 1^er coup.
   • Leur productivité en nombre de tests exécutés par jour pour toute l’équipe.

   Cette dernière mesure oblige l’équipe à se battre pour une cible de productivité journalière qui vient en réalité du nombre de tests qu’elle doit exécuter au total avant la date butoir de livraison du logiciel au client.

   Les testeurs tiennent de plus un point journalier, rapide de 15mn. Chacun y partage l’avancement de son travail, mais surtout les difficultés qu’il rencontre. L’équipe aide à les résoudre au plus vite.

   Le leader met regard la performance journalière et les points de blocage rencontrés par ses collègues. Je lui propose alors la mise en place d’un mécanisme de réaction rapide : dès qu’un testeur rencontre une difficulté, il fait immédiatement appel à un expert fonctionnel, toujours présent, qui vient de suite le voir à son poste. Ils travaillent ensemble pour résoudre le blocage de sorte que le testeur continue ses tests normalement et le plus rapidement possible. Ce mécanisme vient d’un outil Lean appelé le « andon ».

5. Former différemment, par la pratique et de façon adéquate.

   Avec l’expérience du « andon », l’expert fonctionnel identifie chez certains testeurs des insuffisances sur des savoir-faire précis. En suivant mon conseil, il planifie alors des formations individuelles au jour le jour. Il s’installe avec chaque testeur concerné, au poste de celui-ci, pour, pendant 20 minutes au plus, lui montrer le bon geste. C’est ainsi qu’il montre aux testeurs, de façon précise, comment faire la bonne requête SQL pour toujours récupérer les bonnes données pour les tests.

Les résultats

Au bout de 2 mois, les clients expriment leur satisfaction car ils identifient seulement 1% des défauts. Ceux non corrigés du 1^er coup n’en représentent plus que 10%. De plus, les tests sont faits maintenant dans les délais.

Les prochaines étapes

Ensemble avec l’équipe et son management, nous prenons 2h pour revenir sur ce qui s’est passé. Mon objectif est de les aider à clarifier les prochaines étapes, au vu des nouvelles pratiques mises en œuvre et des résultats obtenus. Lors de nos discussions, deux points retiennent mon attention :

• Créer une admissibilité aux tests. Il s’agit de toujours exécuter de façon automatisée quelques tests bien choisis vis-à-vis de toute nouvelle version du logiciel à tester. En cas d’absence de défauts, les tests peuvent alors démarrer. L’équipe évite ainsi des situations où elle se retrouve bloquée en milieu de journée suite à la découverte d’un défaut bloquant.
• Expérimenter pour apprendre à exécuter au plus tôt les tests qui permettront de trouver des défauts. Une idée serait d’essayer d’atteindre une cible en nombre de défauts à trouver chaque jour, ce qui pousserait à développer de nouvelles stratégies de test.

Contactez-nous pour échanger sur ce retour d’expérience ou être informé de nouveaux sujets.