Ou comment apprendre à communiquer avec sa moitié lorsqu’on ne parle pas du tout le même langage…
Le code a changé… hein ?
Les développeurs et les testeurs ne parlent pas la même langue. Cela réduit fortement l’efficacité des équipes de test.
Les développeurs parlent de fichier, de classe et de code ; les testeurs parlent de cas de test, de besoin métier et de scénario fonctionnel. Autrement dit, la communication ne se fait pas.
La conséquence de cette incompréhension, comme évoqué dans l’article concernant l’amélioration de l’efficacité de test, est que les équipes de test sont aveugles.
Le contenu des versions reçues est un mystère, tout comme les changements et les impacts. Impossible donc, d’orienter la stratégie de test vers les risques… ou alors avec une confiance très limitée.
Ce problème de langue s’illustre parfaitement lors des tentatives de clarification des changements de la part des développeurs : les testeurs n’y comprennent rien ! Pourquoi ?
Les releases notes sont censées faire état des modifications. Or, leur contenu est soit trop technique pour les testeurs, soit trop général, soit simplement déclaratif (et jugé peu fiable). Leur utilité est donc plus que contestable…
Mais qu’entraînent ces difficultés de compréhension ?
- Des risques de régressions difficiles à évaluer
- La difficulté à sélectionner les scénarios de test pertinents
- L’impossibilité de s’assurer que l’on a correctement couvert les risques de régression
En bref, l’incompréhension entre développeurs et testeurs est une source d’inefficacité des processus de test. Cela génère des régressions qui apparaissent ensuite en production.
Quoi d’neuf Docteur ?
Une information à chaque livraison c’est bien…
Durant la phase de validation d’une version, le risque de régression augmente avec chaque nouvelle livraison (estimé à 8% des bugs trouvés en production).
La possibilité de tester l’application à 100% devient vite irréalisable. Plus le délai est court, plus la sélection des scénarios est restreinte, plus les régressions loupées sont nombreuses.
Pour éviter ce cycle infernal, les testeurs doivent impérativement avoir une vision claire des changements et de leurs impacts pour chaque livraison.
Une information fiable c’est mieux !
Pour que les équipes de test puissent s’appuyer sur ces informations, il est absolument indispensable qu’elles soient fiables. Or, nos discussions avec les équipes de test font apparaître que lorsque l’information se trouve dans un document écrit par l’équipe de développement, cette confiance est réduite.
Un outil semble donc indispensable pour comparer la version reçue avec la précédente sur l’ensemble de son périmètre (code, configuration, librairies tierces, etc.). Cela permettra d’atteindre le niveau de fiabilité nécessaire aux testeurs.
Une information pertinente, c’est le rêve !
Si avoir les informations est important, il faut encore qu’elles soient exploitables par les équipes de test.
Liste des exigences fonctionnelles traitées, des User Stories traitées… Ces données sont indispensables pour la validation fonctionnelle. Elles sont cependant difficilement exploitables par le responsable des tests pour sa stratégie de test de régression.
En outre c’est rarement exhaustif ! D’autres changements auront été réalisés. Généralement sans traçabilité, avec des exigences fonctionnelles ou des anomalies.
Des tests exploratoires vont chercher à lever les risques associés mais avec une efficacité souvent limitée.
Pour améliorer cette situation, nos clients nous ont aidés à définir les 2 niveaux d’information utiles :
- Une vision métier, pour connaitre les changements et de leurs impacts. Restituer les informations à travers les sous-ensembles touchés de l’application permettra de diriger les efforts de test de non-régression.
- L’impact sur les scénarios, pour identifier les scénarios à rejouer. L’identification de l’empreinte (code exécuté lors de l’exécution d’un cas de test fonctionnel) de chaque test sur le code de l’application permet de définir les cas de tests impactés par un changement.
Si vous pouviez « Tester Juste » ?
Si cette difficulté à communiquer efficacement entre les équipes de développement et de test pouvait être rayée, qu’adviendrait-il des tests ?
C’est ce que nous appelons « Tester juste » (voir notre concept « Smarter Testing Strategies »). La porte vers une stratégie nouvelle qui tend à résoudre l’équation suivante :
Vers des tests plus efficaces et au-delà !
Cette série sur l’amélioration de l’efficacité des tests se poursuivra dans les 2 articles à venir :
- Comment exploiter la couverture de test pour maîtriser et anticiper les risques ?
- Comment définir une stratégie de test de non-régression plus efficace ?
Nous traiterons également dans un prochain article la difficulté de communication inverse : quand les développeurs ne reçoivent pas des testeurs le bon niveau d’information.
Dès lors, comment analyser, diagnostiquer et corriger une anomalie ? Un grand classique qui nourrit les gestionnaires de bugs avec des problèmes classés « non-reproduits ». C’est également la raison pour laquelle le nombre de livraisons nécessaires à la correction d’un problème augmente.
