L’utilisation de l’Analyse des Écarts Dans le Processus de Test Pour Aligner les Développeurs et les Testeurs

Est une croyance largement répandue selon laquelle les développeurs et les testeurs s’entendent comme de la craie et du fromage. Les développeurs regardent souvent les testeurs, les considérant comme un frein inflexible et inutile au développement de nouveau code qui ne fournissent pas de détails clairs dans leurs tickets de bogues. De même, les testeurs voient souvent les développeurs avec irritation pour ne pas les tenir informés des modifications de code et pour pousser de nouvelles modifications pendant les cycles de test. C’est pourquoi l’analyse des écarts dans le processus de test d’assurance qualité peut être particulièrement bénéfique pour aligner les développeurs et les testeurs.

Bien que cette vue puisse être apocryphe, il est souvent vrai que les développeurs et les testeurs ne communiquent pas bien. Souvent, la communication se fait uniquement via la direction (chefs de projet et responsables hiérarchiques) ou via des tickets dans Jira. Le résultat est que les tests s’avèrent souvent inadéquats. En particulier, trop souvent, le nouveau code est mal testé ou pas testé du tout. Des recherches ont montré que ce nouveau code non testé est la plus grande source de bogues et d’échecs futurs. C’est là que le concept d’Analyse des écarts de test entre en jeu.

Dans ce blog, nous allons explorer ce qu’est l’analyse des écarts de test, montrer comment elle peut aider à identifier le code qui doit être testé et explorer si cette approche est la panacée qui peut combler le fossé entre les développeurs et les testeurs.

Qu’est-ce que l’analyse des écarts de test?

Lorsque vous développez pour la première fois un système logiciel, il est facile d’être sûr que vous testez l’ensemble du système. Les testeurs sont capables de prendre les spécifications du code et d’utiliser une combinaison de tests planifiés et exploratoires pour s’assurer qu’ils testent chaque partie mobile de la base de code. Cependant, la plupart des logiciels ne sont pas statiques. Les entreprises produisent des versions périodiques monolithiques de code à longue durée de vie ou emploient un certain niveau d’intégration et de déploiement continus (CI / CD). Dans les deux cas, la base de code change constamment. Cependant, trop souvent, les cas de test ne sont pas mis à jour au même rythme. Parfois, les testeurs ne savent tout simplement pas qu’un changement de code a été effectué. D’autres fois, le changement de code est poussé juste après l’exécution d’un ensemble particulier de tests. Ces tests semblent avoir réussi, mais le changement de code peut les avoir brisés.

L’analyse des lacunes de test est le processus d’identification de ces lacunes là où un nouveau code a été déployé mais n’a pas encore été testé. Cela nécessite une combinaison d’analyse statique de toutes les modifications de code et d’analyse dynamique de tous les tests en cours. En comparant ces deux analyses, vous pouvez facilement voir où se trouvent les lacunes. C’est-à-dire des domaines du nouveau code qui ont été testés de manière adéquate. En règle générale, cela se fait en traçant le code à l’aide d’une forme de diagramme arborescent où le code est divisé en blocs fonctionnels, en dessous de chaque bloc se trouvent les classes constitutives, en dessous de celles-ci se trouvent les méthodes et fonctions réelles. À chaque niveau de la hiérarchie, la taille relative du bloc indique la quantité de code. En superposant l’arborescence montrant les changements de code avec l’arborescence montrant l’état actuel des tests, il est facile de repérer les zones où il manque une couverture de test.

Une carte arborescente montrant le code inchangé (gris), le code révisé / nouveau testé (vert), le code révisé non testé (orange) et le nouveau code non testé (rouge).

Pourquoi l’analyse des écarts de test pourrait-elle être importante dans le processus de test?

Dans un article de 2013, des chercheurs de l’Université technique de Munich ont mené une étude pour examiner la corrélation entre le nouveau code non testé et les futurs bogues logiciels. Ils ont travaillé avec Munich Re (une grande compagnie d’assurance), surveillant leur système informatique de longue durée à travers 2 versions. Lors de la publication, ils ont établi quel code était nouveau et ont également examiné quel code avait été testé et quel code avait été publié non testé. Après cela, ils ont surveillé le système pendant une longue période et ont suivi tous les bogues signalés jusqu’à la source d’origine. Ils ont découvert deux choses clés. Premièrement, environ un tiers de tout le code était publié sans avoir été testé. Deuxièmement, lorsqu’ils ont retracé les bogues qu’ils ont découverts dans l’ensemble, entre 70 et 80% de tous les bogues étaient dans du code non testé. Le graphique ci-dessous le montre plus clairement.

Comme vous pouvez le voir, l’ancien code testé n’avait aucun bogue. Le nouveau code testé avait entre 22 et 30% des bogues et les bogues restants étaient répartis assez uniformément entre le nouveau code non testé et l’ancien code non testé. Cependant, comme le nouveau code ne représentait que 15% du code global, vous pouvez voir que le nouveau code non testé représentait un nombre disproportionné de bogues.

L’analyse des écarts de test est conçue pour identifier ce nouveau code non testé. Cependant, cela peut également vous aider d’autres manières. Par exemple, parce qu’il surveille ce que vous testez, il peut identifier des zones de code existant qui sont obsolètes (par exemple, elles sont toujours testées, mais ne sont réellement appelées par aucun code). Il peut également mettre en évidence les domaines sur lesquels vous devez concentrer vos ressources de test. En l’exécutant régulièrement, les gestionnaires peuvent améliorer la planification des tests, en se concentrant sur le test du nouveau code et en essayant d’assurer une couverture uniforme des tests.

Devs et Testeurs alignés grâce à l’Analyse des écarts de test

L’analyse des écarts de test est clairement un concept puissant. Mais il est également clair que toutes les équipes n’en bénéficieront pas également. Les équipes qui en bénéficieront le plus sont celles qui maintiennent des bases de code à longue durée de vie avec des versions monolithiques périodiques. Dans les bases de code à longue durée de vie, les développeurs travaillent souvent sur du code écrit par d’autres personnes. Les testeurs peuvent s’appuyer sur des plans de test produits plusieurs versions auparavant. Pris en combinaison, ces facteurs peuvent signifier que personne ne sait très clairement quel code est testé ou comment ce code interagit avec d’autres parties du système. Ici, TGA peut permettre aux testeurs de voir exactement quel code a changé, ce qui leur permet de se concentrer sur cela. Ils peuvent également identifier le code dans le système existant qui n’est pas testé.

Les équipes utilisant CI / CD peuvent également bénéficier de cette approche car elle permettra aux testeurs d’identifier rapidement exactement quel code est modifié et ainsi de se concentrer sur cela. Il peut également éviter le problème mentionné ci-dessus où un morceau de code est modifié immédiatement après avoir été testé, puis est publié avec les modifications non testées.

D’autre part, les équipes qui travaillent sur un code nouveau ou de courte durée en bénéficieront moins, car, par définition, la plupart des codes ne seront pas testés au début. Ici, il est important d’utiliser des méthodologies de test standard pour vous assurer que vos tests sont bons. Il peut cependant être utile pour ces équipes de commencer à surveiller la couverture des tests à l’aide de TGA car cela leur permettra d’éviter de futurs problèmes.

Quels sont les problèmes potentiels?

Il y a quelques problèmes avec TGA. L’un des plus importants concerne le fait qu’il ne peut pas vous dire quel code est activement appelé dans la base de code. Les développeurs ajoutent souvent du nouveau code en préparation des versions futures, mais comme il est inactif, la suite de tests ne peut pas l’appeler. En conséquence, ce code apparaîtra toujours comme un nouveau code non testé. De même, de nombreuses bases de code volumineuses contiennent des blocs de code ancien ou orphelin. Ceux-ci doivent être nettoyés périodiquement, mais encore une fois, ils déformeront l’image pour l’analyse des écarts de test.

Une autre observation importante est que ce n’est pas parce qu’un morceau de code est testé que ce code déclenche des bogues ailleurs. Certains des pires bogues sont ceux où un petit changement dans un morceau de code provoque l’échec d’une fonction ou d’une méthode dans un bloc de code totalement indépendant. Il est donc essentiel de continuer à faire des tests exploratoires et des tests de régression. Ce que TGA peut faire, c’est identifier les zones de votre base de code existante qui ne sont pas correctement testées lors de vos tests de régression.

Quelles autres alternatives aident à combler le fossé?

L’analyse des écarts de test est certainement un outil utile pour certaines équipes. Cependant, il existe d’autres moyens d’éviter un décalage entre ce que vos testeurs testent et ce que vos codeurs codent. Une façon est d’utiliser une automatisation de test plus intelligente capable d’identifier où et quand les choses ont changé, à la fois sur le frontend mais aussi, ce qui est important, dans le backend. Chez Functionize, nos tests utilisent la prise d’empreintes digitales intelligente associée à l’apprentissage automatique et à l’auto-guérison pour réduire la maintenance des tests. Cela permet aux tests de s’adapter de manière proactive aux modifications du frontend ainsi que de surveiller des éléments tels que les appels au serveur, les temps de réponse et si les boutons / fonctions sont réellement visibles. Cela signifie que vos testeurs ne seront pas surpris par les modifications apportées au code backend ou aux modifications de conception / CSS qui modifient la disposition du frontend.

Notre système intelligent peut également créer des tests en surveillant la façon dont les utilisateurs interagissent avec le système. Cela permet de s’assurer qu’il y a moins d’écarts dans la couverture du test. L’un de nos outils les plus récents vous permet d’écrire de nouveaux tests en anglais simple. Ceux-ci sont analysés par notre outil de traitement du langage naturel et convertis en tests utilisables. Cela signifie que pendant le développement, les développeurs peuvent simplement spécifier ce qui devra être testé en anglais normal, réduisant ainsi davantage l’écart entre les deux disciplines.

Conclusions

L’analyse des écarts de test vous aide à identifier le code qui est publié non testé et peut donc vous aider à concentrer vos ressources de test plus efficacement. Sans surprise, il s’avère que le code non testé est beaucoup plus susceptible de contenir des bogues et que tout outil pouvant aider à s’assurer que ce code est correctement testé est utile. Cependant, comme nous l’avons vu, la TGA ne peut que compléter les meilleures pratiques existantes. Il est essentiel de poursuivre vos tests de régression et vos tests exploratoires. De nombreux avantages de la TGA peuvent également être obtenus en utilisant des outils de test intelligents. Mais dans l’ensemble, la principale chose à éviter est d’isoler votre équipe de test du travail de vos développeurs. Pour citer à tort un vieil adage, vous devez vous assurer que la main gauche sait ce que fait la main droite!