Ou comment mieux communiquer avec sa moitié lorsqu’on ne parle pas du tout le même langage… Par Marc Rambert, Président de Kalistick.

Le code a changé, ok, mais quels impacts pour les tests ?

Développeurs et testeurs ne parlent pas la même langue. Cela réduit beaucoup 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 est que les équipes de test sont aveugles. Le contenu des versions reçues est une énigme, tout comme les modifications et les impacts. Impossible donc, de diriger la stratégie de test vers les risques… ou alors avec une confiance limitée. Ce problème de langue s’illustre précisément 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 évolutions. Or, leur contenu est soit trop technique pour les testeurs, soit trop général, soit juste déclaratif (et jugé peu fiable). Leur utilité est donc plus que contestable…

Qu’entraînent ces difficultés de compréhension ?

- Des risques de régressions compliqués à évaluer

- La difficulté à trouver les scénarios de test pertinents

- L’impossibilité de garantir que l’on a convenablement couvert les risques de régression

En bref, cette difficulté de communication entre développeurs et testeurs entraine une inefficacité des processus de test. En outre, cela engendre des régressions qui apparaissent ensuite en production.

Une information à chaque livraison, c’est bien.

Pendant la phase de validation d’une version, le risque de régression croît avec chaque nouvelle livraison (estimé à 8 % des bugs trouvés en production).

La possibilité de tester l’application à 100 % devient rapidement irréalisable. Plus le délai est court, plus la sélection des scénarios est limitée, plus les régressions manquées sont nombreuses.

Pour prévenir ce cycle infernal, les testeurs doivent nécessairement avoir une vision claire des transformations 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 essentiel 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 diminuée. 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.), et ainsi atteindre le niveau de fiabilité nécessaire aux tests.

Une information adaptée, 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, 2 niveaux d’information sont utiles :

Une vision métier, pour connaître 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.

Il ressort donc que tester juste s’impose comme une obligation. Un tel processus permettra de combler progressivement le fossé entre le monde du test et du développement et facilitera la mise en production et l’évolution de projets agiles. L’efficacité des tests est donc une composante centrale qu’il convient de traiter dans son ensemble.

Autant de points à détailler que nous aborderons dans de nouveaux points de vue.

Marc Rambert, Président de Kalistick