Testez plus intelligemment, pas plus dur: test de décalage à gauche et à droite avec analyse d'impact des tests

L'analyse d'impact des tests consiste à concentrer les tests spécifiquement sur les modifications apportées au cours de chaque itération et à tester exactement ce qui doit être testé, automatiquement. Les équipes qui tirent parti de cette technologie peuvent optimiser leurs efforts de test en cours de développement avec un retour instantané sur ce qui doit être fait.

Confirmé fréquemment par des enquêtes et des rapports du secteur, les tests logiciels constituent toujours un goulot d'étranglement, même après la mise en œuvre de processus de développement modernes tels que Agile, DevOps et l'intégration / déploiement continu. Dans certains cas, les équipes logicielles ne testent pas suffisamment et doivent faire face à des bogues et des vulnérabilités de sécurité aux étapes ultérieures du cycle de développement, ce qui crée une fausse supposition que ces nouveaux processus ne peuvent pas tenir leurs promesses. Une solution à certaines catégories de problèmes est le test à droite, qui repose sur la surveillance de l'application dans un environnement de production, mais qui nécessite une infrastructure solide comme le roc pour annuler les nouvelles modifications en cas de défaut critique.

En conséquence, les organisations manquent toujours de délais et la qualité et la sécurité en souffrent. Mais il y a un meilleur moyen! Pour tester plus intelligemment, les organisations utilisent une technologie appelée analyse d'impact de test pour comprendre exactement ce qu'il faut tester. Cette approche basée sur les données prend en charge à la fois test de décalage gauche et les tests de décalage à droite.

Agile et DevOps et le goulot d'étranglement des tests

Les tests dans tout processus itératif sont un compromis sur la quantité de tests pouvant être effectués dans un temps de cycle limité. Dans la plupart des projets, il est impossible de faire une régression complète à chaque itération. Au lieu de cela, un ensemble limité de tests est effectué et ce qu'il faut tester est basé sur les meilleures suppositions. Les tests sont également chargés dans le cycle car il n'y a généralement pas assez de nouvelles fonctionnalités terminées à tester. Le graphique d'effort en fonction du temps qui en résulte se termine comme une dent de scie, comme illustré ci-dessous dans la figure 1. Dans chaque cycle, seul un ensemble limité de tests est exécuté jusqu'au cycle final où les tests de régression est effectuée.

Figure 1: Les processus agiles se traduisent par une «dent de scie» de l'activité de test. Seul le cycle de régression complet est capable de faire un test «complet».

Malheureusement, aucun projet n'atteint le cycle final avec zéro bogue et zéro vulnérabilité de sécurité. La découverte de défauts à ce stade ajoute des retards car les bogues sont corrigés et retestés. Et même avec ces retards et tous, de nombreux bogues se retrouvent encore dans le produit déployé, comme illustré ci-dessous.

Figure 2: L'intégration et les tests de régression complets ne sont jamais exempts d'erreurs. Les défauts de stade tardif entraînent des dépassements de délais et de coûts.

Cette situation a abouti à l'adoption de ce qui a été appelé «test de changement de vitesse», dans lequel les organisations continuent de tester leur application dans la phase de déploiement. L'intention des tests shift-right est d'augmenter et d'étendre les efforts de test, avec des tests les mieux adaptés dans la phase de déploiement, tels que la surveillance des API, le basculement des fonctionnalités en production, la récupération des commentaires des opérations réelles.

Qu'est-ce que le test Shift-Right?

Les difficultés à reproduire des environnements de test réalistes et à utiliser des données et un trafic réels dans les tests ont conduit les équipes à utiliser des environnements de production pour surveiller et tester leurs applications. Il y a Flare à cela, par exemple, être en mesure de tester des applications avec un trafic de production en direct prenant en charge la tolérance aux pannes et l'amélioration des performances. Un cas d'utilisation courant est le soi-disant version canari, dans lequel une nouvelle version du logiciel est d'abord distribuée à un petit sous-ensemble de clients, puis déployée dans un groupe de plus en plus grand au fur et à mesure que des bogues sont signalés et corrigés. Roku, par exemple, le fait pour mettre à jour le micrologiciel de son appareil.

Les tests Shift-Right reposent sur une infrastructure de développement qui peut annuler une version en cas de défauts critiques. Par exemple, une faille de sécurité grave dans une version Canary signifie que la version est annulée jusqu'à ce qu'une nouvelle version mise à jour soit prête, comme vous pouvez le voir dans l'illustration ici:

Figure 3: Les tests Shift Right reposent sur une solide infrastructure d'opérations de développement pour annuler les versions face à des défauts critiques.

Mais il y a des risques à utiliser des environnements de production pour surveiller et tester des logiciels, et bien sûr, L'intention des tests shift-right n'a jamais été de remplacer les pratiques de test unitaires, API et UI avant le déploiement! Le test Shift-right est un complémentaire pratique, qui étend la philosophie des tests continus à la production. Malgré cela, les organisations peuvent facilement abuser du concept pour justifier de faire encore moins de tests unitaires et d'API pendant le développement. Afin d'éviter cela, nous devons effectuer des tests pendant les phases de développement pour être plus faciles, plus productifs et produire des logiciels de meilleure qualité.

Tester plus intelligemment, pas plus dur, en ciblant vos tests

La plupart des logiciels ne sont pas entièrement testés, et la décision de ce qu'il faut tester est essentiellement basée sur les meilleures suppositions des développeurs sur ce qui est une fonctionnalité critique. Pendant un sprint SCRUM, ou une itération dans d'autres processus, il est difficile de déterminer ce qu'il faut tester, car, bien sûr, «tout tester» n'est pas une option. Étant donné que les délais sont courts, seules les parties du logiciel qui ont été mises à jour par les dernières fonctionnalités peuvent être testées, mais on ne sait généralement pas exactement quel code est affecté. L'automatisation des tests aide, mais sans comprendre exactement où et quoi tester, la couverture des tests est inadéquate.

Analyse d'impact des tests

Ces lacunes peuvent être surmontées en utilisant analyse d'impact de test, qui est une analyse multivariée de la couverture des tests, des changements de code et des dépendances qui identifie exactement le code à tester. De plus, ces tests exacts peuvent être programmés et exécutés automatiquement.

L'analyse d'impact des tests fonctionne au niveau du développeur dans l'EDI, collectant des informations sur le code exercé par quels tests, et applique ces informations dans l'EDI du développeur lorsque le développeur change de code, permettant au développeur d'identifier et d'exécuter facilement les tests spécifiques qui doivent être exécutés pour vérifier que le code modifié n'interrompt aucun test. En outre, le suivi des tests affectés qui ont été exécutés, de ceux qui ont réussi et de ceux qui ont échoué permet au développeur de déterminer facilement quels tests doivent encore être exécutés ou quels tests ont échoué et doivent être traités. Une fois que tous les tests ont été exécutés et réussis, le développeur sait qu'il est sûr de valider son code et de passer à autre chose.

L'analyse d'impact des tests fonctionne dans un processus CI / CD en s'intégrant de manière transparente dans le système de construction d'un projet tel que Maven ou Gradle, pour obtenir un retour immédiat sur les changements. L'analyse d'impact des tests identifie le code qui a changé depuis la construction de base (c'est-à-dire la dernière version nocturne), détermine quels tests doivent être exécutés pour exercer ce code, puis exécute uniquement ce sous-ensemble de tests. Ce flux de travail permet aux équipes de configurer des travaux CI qui n'exécutent que des tests basés sur les modifications de code les plus récentes, réduisant le temps nécessaire pour exécuter un travail CI de quelques heures à quelques minutes.

L'analyse d'impact des tests offre les avantages clés suivants:

• Comprenez ce que couvre chaque test: En corrélant automatiquement les données d'exécution de test avec les données de couverture de test, l'analyse d'impact des tests fournit un mécanisme permettant d'identifier les tests à exécuter, en fonction du code en cours de développement. Les utilisateurs gagnent du temps sans avoir à exécuter des tests inutiles et les équipes bénéficient d'un retour d'information immédiat pendant le développement et après l'enregistrement du code.
• Comprenez ce qui a changé: Les développeurs ne savent souvent pas quels tests exécuter pour valider les changements de code, donc ils (a) archivent leur code sans exécuter de tests (une très mauvaise pratique), (b) n'exécutent qu'un ou deux tests dont ils ont connaissance ( qui en manque facilement), ou (c) exécuter tous leurs tests (ce qui fait perdre du temps). L'analyse d'impact des tests résout ce problème en identifiant immédiatement quels tests sont liés à quel code change, et va encore plus loin en les exécutant automatiquement. Le code enregistré devient plus stable car il a été soigneusement testé avant l'enregistrement.
• Concentrez-vous sur les tests qui valident les modifications et les dépendances impactées: Identifier et exécuter uniquement l'ensemble de tests nécessaires pour vérifier toutes les modifications de code et les dépendances affectées, qui ont été validées depuis la dernière génération de base (généralement la génération nocturne), réduit considérablement le temps nécessaire à l'exécution de CI. Cela permet aux équipes de bénéficier d'un véritable processus de CI.
• Rétroaction immédiate et continue: En identifiant non seulement les dépendances directes entre les tests et le code, mais également les dépendances indirectes, l'analyse d'impact des tests aide les équipes à comprendre dès que possible après la vérification du code si le code a cassé des tests.

Résumé

Pour réduire considérablement le goulot d'étranglement des tests lors du développement et améliorer l'efficacité de l'effort «en dents de scie» que les testeurs mettent à chaque itération, les équipes de développement peuvent bénéficier de la technologie d'analyse d'impact des tests. L'automatisation des tests avec analyse de l'impact des tests signifie que les tests se concentrent spécifiquement sur les modifications apportées au cours de chaque itération et testent exactement ce qui doit être testé, automatiquement. Ces équipes optimisent leurs efforts de test en cours de développement avec un retour instantané sur ce qui doit être fait, quel code échoue aux tests et quel autre code est affecté par les nouveaux changements.

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.