Klemsy - Fotolia
Ces petits pas pour diminuer réellement la redondance des tests
Bien qu’une couverture complète des tests soit indispensable, les équipes logicielles doivent faire des efforts constants pour éviter que leurs suites ne soient surpeuplées par un nombre excessif de tests redondants.
La redondance des tests logiciels se produit lorsque plusieurs d’entre eux se chevauchent partiellement ou complètement pour servir des objectifs similaires. Cela signifie que les mêmes segments de code, fonctionnalités et caractéristiques sont inutilement testés plus d’une fois. Sans moyen de configurer les suites de tests de manière à réduire ces redondances, les équipes s’exposent à des inefficacités qui peuvent finalement perturber la vélocité du développement.
Dans ce conseil, nous examinons comment les équipes peuvent prendre des décisions intelligentes concernant les éléments de vérifications logicielles à conserver, à mettre à jour, à archiver ou à supprimer dans le but de cultiver un inventaire gérable de scripts de test, tout en assurant une couverture efficace.
Prendre des décisions pour éviter les tests redondants
Il n’y a pas de secret. La clé pour atténuer la redondance des tests est l’optimisation continue. Elle commence par la conception de tests atomiques (un test par cas) et autonomes (aucun test n’est dépendant d’un autre). L’objectif de cette méthodologie est de tirer le maximum de valeur du minimum de cas de test. Cela implique d’évaluer à la fois individuellement chaque cas et de considérer la suite dans son ensemble.
Cela implique un examen minutieux de la pertinence de chaque test unitaire pour les opérations actuelles et de la valeur pour l’organisation. En fin de compte, des décisions difficiles doivent être prises concernant la suppression, l’archivage, la réécriture, la mise à jour ou la dépriorisation d’un ou de plusieurs éléments d’une suite.
Bien que des situations spécifiques puissent influer sur la décision, voici quelques lignes directrices générales que les équipes logicielles peuvent utiliser pour déterminer le meilleur plan d’action :
- Réécriture/mise à jour. Les cas de test qui couvrent plus d’un objectif de test, qui dépendent d’autres tests pour s’exécuter correctement ou qui durent trop longtemps sont généralement ceux qu’il faut remédier en premier lieu.
- Suppression. Les cas de test qui renvoient systématiquement des résultats incohérents, incorrects ou non informatifs doivent être complètement supprimés. Cependant, il faut s’assurer que ces cas de test ne sont pas des candidats valables pour une réécriture ou une mise à jour.
- Archivage. Certains tests peuvent devenir obsolètes lorsque les composants ou fonctionnalités associés sont retirés de la base de code d’une application. Cependant, les équipes devraient envisager de les archiver plutôt que de les supprimer ; il est possible que ces composants ou fonctionnalités soient réintroduits, auquel cas ces tests pourraient être réutilisés avec un minimum de mises à jour. Cela s’applique souvent aux cas de test associés à des fonctionnalités héritées ou à usage peu fréquent.
- Dépriorisation. En fonction de la criticité de la fonctionnalité associée, les équipes peuvent choisir de simplement déprioriser certains tests dans l’ensemble de la suite. Par exemple, ceux qui s’exécutent dans des environnements complexes ou qui couvrent des caractéristiques liées à des processus commerciaux cruciaux sont bien évidemment prioritaires par rapport à ceux ciblant des fonctionnalités simples.
Les meilleures pratiques pour réduire la redondance des tests
L’optimisation des tests est un processus dynamique. Les équipes doivent continuellement auditer leurs suites afin de maintenir la redondance des tests à un niveau minimum. Par exemple, les procédures d’essai de régression doivent être optimisées après chaque version. Malheureusement, elles changent au fur et à mesure que le logiciel évolue. Effectuer une revue de l’ensemble d’une suite de tests après la sortie d’une version – en particulier un harnais consacré à la régression – peut prendre beaucoup de temps que les équipes n’ont pas.
Cependant, les développeurs peuvent réduire ces temps de revue au minimum en traitant activement les tests défaillants et les segments de code obsolètes au fur et à mesure qu’ils les rencontrent. Des outils tels que Hexawise et Ranorex DesignWise peuvent y contribuer – en particulier si les applications nécessitent des routines de test complexes – en permettant aux équipes de saisir des scénarios de test et d’exécuter des algorithmes qui identifient les cas de test redondants. En outre, ces outils fournissent généralement des rapports sur la couverture qui s’avèrent utiles lors de l’audit de l’ensemble de la suite de tests.
Les outils de revue et d’analyse de code, la mise en place de pratique d’annotations, une documentation fournie et des processus établis permettent d’obtenir cette maîtrise.
