Utilisez intelligemment la couverture de code pour maximiser l'effort de test

Intelligemment utiliser des métriques de couverture de code pour concentrer les efforts de test là où ils sont le plus nécessaires en comprenant où de nouveaux tests sont nécessaires et en créant des suites de tests maintenables.

L'un des principes clés d'Agile est d'assurer la qualité livrable des livrables incrémentiels tout en répondant à l'évolution des exigences. Mais le défi d'équilibrer les tests de nouvelles fonctionnalités tout en validant le bon fonctionnement des fonctionnalités existantes entraîne l'enlisement de nombreuses équipes de développement agiles dans la création, la gestion et la maintenance d'une suite de tests en expansion. En fin de compte, il peut devenir très difficile d'accélérer l'agilité et d'avoir confiance à la fois dans la qualité et la sécurité des produits sans la richesse d'informations appropriée.

L'examen de la quantité de code exercé pendant les tests est une mesure utile pour comprendre le niveau d'atténuation des risques en cours, mais il est souvent mal utilisé et, au niveau macro, n'est pas un bon indicateur de qualité. Dans cet article, je vais vous montrer comment utiliser intelligemment les métriques de couverture de code pour concentrer les efforts de test là où ils sont le plus nécessaires, en comprenant où de nouveaux tests sont nécessaires. Nous aborderons également certaines des meilleures pratiques pour créer des suites de tests maintenables.

Comment réfléchir à la couverture de code utile

La couverture de code n'est pas «le» nombre pour déterminer quand vous avez suffisamment de tests, mais c'est «un» nombre qui peut être très utile pour guider les équipes sur où se concentrer.

Malheureusement, il est souvent utilisé de manière incorrecte pour gérer les équipes en se concentrant sur le nombre lui-même et en recherchant un pourcentage spécifique par rapport à la base de code, par exemple, en utilisant des politiques telles que «nous devons avoir une couverture de 80% avant de pouvoir publier» ou «le numéro de couverture doit être identique ou supérieur à la version précédente. "

Le problème avec cette approche est que l'obtention et le maintien d'un numéro de couverture cible est difficile et prend du temps en soi, nous travaillons donc aveuglément vers le numéro et personne ne prend le temps de poser les questions importantes, telles que:

• Laquelle 80% couvrons-nous?
• L'effort de test validera-t-il la qualité et réduira-t-il le risque de livraison de l'application?
• Comment vais-je maintenir les tests au fur et à mesure que le code évolue?

Comme je l'ai discuté dans un précédent article, chaque changement dans la base de code représente une introduction de risque, et il est important de comprendre l'impact spécifique de chaque changement sur le code existant ainsi que de comprendre comment atténuer ce risque.

En identifiant les changements dans la base de code et en utilisant la couverture de code pour corréler les tests à ces changements, un plan de test optimal peut être créé en fonction de l'endroit où un nouveau test est nécessaire (en savoir plus sur les tests basés sur les changements ici).

Mais cela ne couvre pas tous les risques. De toute évidence, nous devons encore créer des tests pour la nouvelle fonctionnalité, mais qu'en est-il du code existant / hérité? De nombreuses organisations avec lesquelles nous parlons ont un objectif couverture de code de 60 à 80%, mais en réalité, du mal à dépasser 50%. Il y a donc de fortes chances qu'une modification du code existant ne soit pas couverte par un scénario de test existant. Se concentrant uniquement sur la préservation ou la croissance incrémentielle, l'objectif de couverture des macros ne protège pas de l'introduction de régressions dans les fonctionnalités héritées qui «fonctionnent depuis des années».

Au lieu de cela, en regardant de plus près les détails de la couverture, les lignes modifiées spécifiques qui n'ont PAS été couvertes peuvent être rapidement identifiées, de sorte que vous pouvez concentrer l'équipe sur les endroits où de nouveaux tests doivent être créés. De plus, en utilisant la traçabilité entre les cas de test et le code spécifique qu'ils exercent, vous pouvez identifier les cas de test potentiels qui peuvent être dupliqués ou étendus pour couvrir les changements.

En se concentrant sur la réalisation d'une couverture de 100% du code modifié, par rapport à un objectif d'équipe arbitraire de «couverture totale de 80%», l'équipe peut être beaucoup plus efficace pour atténuer le risque de nouveau code tout en éliminant les facteurs ayant une incidence sur la stabilité globale du projet (par exemple, les modifications apportées à code hérité.)

Couverture de code modifiée en action

La mesure de cette couverture de code intelligente est possible à l'aide du widget Modified Code Coverage de Parasoft DTP (une «tranche» analytique du Process Intelligence Engine (PIE) de Parasoft DTP). Ici, vous pouvez facilement voir la couverture du code qui a été ajouté ou modifié entre deux versions (par exemple, la version actuelle et une version cible de votre choix). Par exemple, la figure 1 montre un tel widget. Dans cet exemple, 177 lignes de code ont été ajoutées ou modifiées entre les deux builds et 109 de ces lignes ont été testées, soit 61.6%. Cela signifie qu'il y a 68 lignes de code nouveau ou modifié qui ne sont couvertes par aucun test, et n'ont donc pas été validées et représentent un risque dans la base de code.

Derrière ce widget se trouve un rapport de couverture modifié. Le rapport fournit des détails exacts sur le code qui manque les tests appropriés. Ce sont des informations clés dont les développeurs et les testeurs ont besoin pour concentrer leurs efforts. La figure 2 montre un tel rapport, dans lequel les fichiers modifiés peuvent être triés en fonction du nombre de modifications, ou des tests de code manquant, avec des lignes modifiées non couvertes marquées en rouge.

Ce rapport répond à la question "Quels tests me manque-t-il?" Sur la base des informations fournies ici pour chaque build, un plan de test peut être créé.

Quel type de test créer ?

Une fois que vous avez identifié le code où vous manquez des tests, vous devez en fait vous mettre au travail et créer les tests pour combler le vide - mais quel type de tests créez-vous? La Pyramide de Test (telle qu'évangélisée par Martin Fowler et Mike Cohn) explique comment créer un portefeuille de tests efficace, gérable et maintenable. En minimisant les tests de niveau d'interface utilisateur fragiles et se concentrer sur une base solide de tests unitaires (soutenus par des tests complets de niveau Service/API), vous êtes en mesure de créer une stratégie de test évolutive, maintenable et pouvant être exécutée en continu.

Nous n'allons pas entrer dans les détails de la création de tests unitaires ou d'API dans ce blog, mais vous pouvez consulter mon blog précédent sur les tests unitaires et surveillez un blog à venir sur la façon dont Parasoft SOAtest peut être utilisé pour simplifier la création de tests de niveau API / Service.

Conclusion

La couverture du code est une métrique importante, mais elle est souvent surutilisée et mal utilisée, en particulier lorsqu'elle est utilisée pour mesurer la qualité. Pour tirer le meilleur parti de la couverture du code, tirez parti de l'intelligence analytique de Parasoft DTP pour détecter où de nouveaux tests sont nécessaires, atténuer les risques, concentrer vos tests et atteindre de manière optimale vos objectifs de qualité.

Par Marc Lambert

Vice-président des produits chez Parasoft, Mark est chargé de s'assurer que les solutions Parasoft apportent une valeur réelle aux organisations qui les adoptent. Mark travaille chez Parasoft depuis 2004, travaillant avec un large éventail de clients de Global 2000, des implémentations technologiques spécifiques aux initiatives plus larges d'amélioration des processus SDLC.