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

La méthodologie de test Shift Left

Le mouvement de «décalage vers la gauche» consiste à déplacer les pratiques de test critiques plus tôt dans le cycle de vie du développement. Ce terme se retrouve en particulier dans les initiatives Agile, Continuous et DevOps. Alors, pourquoi avez-vous besoin d'effectuer des tests logiciels précoces?

De nombreuses activités de test ont lieu à la fin du cycle, où il faut plus de temps pour déterminer ce qui n'a pas fonctionné et coûte plus cher à réparer. Déplacer vers la gauche consiste à déplacer l'identification et la prévention des défauts plus tôt. Lorsque vous ne le faites pas et que vous attendez d'effectuer des tests plus tard dans le cycle de développement, vos exigences commerciales non fonctionnelles en particulier (c'est-à-dire les tests de sécurité et de performance) sont si fondamentalement ancrées dans votre code que tout ce que vous pouvez vraiment faire est de les corriger. plutôt que de les réparer correctement.

Quand les bugs entrent-ils dans le code ?

Votre partenaire déplacer la stratégie de test vers la gauche est bien illustré dans le graphique quelque peu célèbre de Capers Jones, qui montre le coût croissant des bogues/défauts introduits dans le logiciel, à chaque phase du développement du logiciel. La première partie du graphique montre que la grande majorité des bugs surviennent lors de la phase de codage, ce qui est normal.

Qu'ils commettent de véritables erreurs, qu'ils comprennent mal les exigences ou qu'ils ne réfléchissent pas aux ramifications d'un morceau de code particulier, les développeurs introduisent des défauts au fur et à mesure que le code est produit.

Des défauts sont également introduits dans l'application lorsqu'il est temps d'assembler les pièces, en particulier si plusieurs équipes sont impliquées (et à mesure que les architectures modernes telles que les microservices deviennent plus complexes).

Quand ces bugs sont-ils détectés ?

Cela commence à devenir intéressant lorsque nous superposons la ligne qui montre où se trouvent les défauts trouvéen haut du graphique des bogues introduits.

Notez qu'il s'agit essentiellement d'un inverse de la première ligne:

Bien sûr, ce n'est pas surprenant, car généralement vous trouvez des bogues lorsque vous commencez à tester, et il peut être difficile sans une infrastructure appropriée de commencer les tests avant que tout soit prêt (nous en reparlerons plus tard). Ce que nous voyons ici, c'est que les bogues sont principalement introduits lors du codage, mais presque jamais trouvé à cette phase.

Combien coûte la correction des bugs ?

Étant donné que la majorité des bogues sont introduits pendant le codage, mais ne sont découverts qu'à une phase ultérieure, il devient important de comprendre la différence qu'il en coûte pour corriger les défauts à chaque phase de développement. Ceci est représenté ci-dessous:

Maintenant, cela commence à devenir intéressant, car nous constatons une progression brutale des coûts qui augmente considérablement à mesure que le défaut est découvert tardivement. Laisser un bug se faufiler jusqu'aux tests du système coûte 40 fois plus cher que de le trouver lors du codage, ou 10 fois plus cher que de trouver le même bug lors des tests unitaires. Et cela devient ridiculement cher quand on regarde le nombre de bugs laissés passer jusqu'au déploiement réel.

Il y a des raisons à cette augmentation des coûts, notamment:

• Le temps et les efforts nécessaires pour dépister le problème. Plus le cas de test est complexe (gros), plus il est difficile de déterminer quelle partie est le véritable fauteur de troubles.
• Le défi de reproduire les défauts sur le bureau d'un développeur, lorsque des systèmes dépendants tels que des bases de données ou des API tierces sont introduits (il est courant pour les organisations de connaître un décalage de plusieurs semaines entre la détection des défauts et la correction des défauts dans ces situations)
• L'impact du changement nécessaire pour corriger un défaut. Si c'est un simple bug, peu importe. Mais si vous l'avez fait à de nombreux endroits, ou si vous avez utilisé le mauvais framework, ou si vous avez créé du code qui n'est pas suffisamment évolutif pour la charge attendue, ou qui ne peut pas être sécurisé ...

Testez tôt, testez souvent : l'approche Shift-Left

Maintenant, regardez la ligne orange ajoutée au graphique ci-dessous, car elle illustre un cycle de détection de défaut proposé basé sur des tests antérieurs (décalé vers la gauche):

Vous pouvez regarder la courbe de détection orange devenir plus grande du côté bon marché et plus petite du côté cher, ce qui nous donne une réduction de coût assez significative.

Le décalage-gauche repose sur une pratique de développement plus mature, par exemple basée sur la pyramide de test de logiciels (développeurs création d'un ensemble de tests unitaires qui couvrent raisonnablement bien le code, et les testeurs fonctionnels et les testeurs d'API font tout ce qu'ils peuvent et minimisent la dépendance aux tests de fin de cycle afin que vous ayez juste assez de tests manuels/UI pour prouver que tout fonctionne). De cette façon, les tests de fin de cycle sont là pour prouver la fonctionnalité, pas pour trouver des bogues. Test-tôt, test-souvent est le mantra du shift-lefter.

Se déplacer encore plus à gauche

Certaines organisations se déplaçant vers la gauche s'arrêtent à ce stade. Mais vous obtenez encore plus de valeur lorsque vous poussez encore plus à gauche, dans le codage lui-même. Après tout, c'est là que les bogues sont introduits - commençons donc à les rechercher pendant que le développement est toujours en cours. C'est là que nous bénéficions de l'analyse de code statique - en trouvant des défauts encore plus à gauche, là où les défauts sont les moins chers à corriger:

Avec l'analyse statique, vous pouvez commencer à trouver des bogues pendant la phase de codage proprement dite, lorsque le coût de recherche de bogues est aussi bas que possible.

Comme vous pouvez le voir clairement, trouver des éléments avant le début des «tests» est la solution la plus rentable. C'est également le plus efficace en termes de temps, car cela ne laisse aucun problème aux développeurs pour essayer de reproduire les bogues ou de comprendre les échecs. Être capable de réduire un cycle de correction des défauts de quelques jours ou semaines à quelques heures ou minutes est extrêmement utile.

Méfiez-vous de déplacer le fardeau vers le développeur

Mais il y a un danger dans cette étape, qui impose accidentellement trop de charge de test aux développeurs de logiciels. La chose importante à retenir lorsque vous regardez le graphique, c'est que si le coût de la correction des défauts augmente considérablement à mesure que vous allez à droite, les ressources sur la gauche ont peut-être le coût le plus élevé du cycle de vie du logiciel - sans parler du fait que vous les empêchent de se concentrer sur le développement de fonctionnalités.

Vous devez donc faire ce qu'il faut et faire passer tout cela au niveau supérieur. Vous ne voulez pas seulement trouver des défauts plus tôt, vous voulez en fait réduire le nombre de défauts que vous mettez dans l'application en premier lieu. Voir le graphique ci-dessous, avec la jolie bulle réduite sur la gauche.

Mais attendez, il y a un piège! Si vous récompensiez les gens pour avoir trouvé et corrigé des bogues, ils en trouveront maintenant moins, ce qui est en fait ce que vous voulez, mais seulement si vous avez vraiment réduit le nombre de bogues que vous introduisez en premier lieu. Mesurer le nombre de défauts qui se produisent sur le terrain est probablement une mesure plus utile.

Comment décaler vers la gauche ?

Ok, donc c'est au cœur même de tout ce que nous faisons chez Parasoft. Mais par souci de concision, approche de test de décalage vers la gauche se décompose en deux activités principales.

Appliquer les meilleures pratiques en matière de tests de développement

La mise en œuvre de pratiques de développement à un stade précoce, telles que l'analyse de code statique et les tests unitaires, permet à la fois d'identifier et de prévenir les défauts plus tôt dans le processus.

Il est important de se rappeler que le but n'est pas de trouver des bugs mais de réduire le nombre de bugs (surtout ceux qui arrivent dans la version). En fin de compte, créer moins de bogues en premier lieu est bien plus précieux que trouver plus de bogues, et c'est beaucoup moins cher. C'est pourquoi les normes de codage critiques en matière de sécurité reposent sur une approche proactive et préventive en signalant le code qui peut « fonctionner » mais qui n'est toujours pas sûr.

Les normes de codage sont l'équivalent logiciel des normes d'ingénierie, et elles sont essentielles pour réduire le volume de bogues (en plus de détecter les bogues plus tôt), pour prendre en charge et tirer le meilleur parti de votre initiative Shift Left. Les normes de codage sont l’incarnation des connaissances en génie logiciel qui vous aident à éviter le code mauvais/dangereux/non sécurisé. Pour les utiliser, vous appliquez une analyse de code statique.

Pour la sécurité des logiciels, il est particulièrement important de réussir à renforcer votre logiciel. Vous souhaitez intégrer la sécurité dans votre code, pas le tester. Les normes de codage vous permettent de créer une application plus sécurisée dès le départ (c'est-à-dire sécurisée par conception), ce qui est à la fois une bonne idée et une exigence. si vous êtes soumis à des réglementations comme le RGPD.

Tirez parti de la virtualisation des services pour permettre des tests continus

Ensuite, vous devez prendre les tests qui ont été créés à toutes les étapes, y compris les étapes ultérieures, du processus de développement, et les exécuter en continu à l'avenir. Ceci est essentiel pour les équipes qui adoptent des pratiques de développement agiles afin de fournir un retour d'information continu tout au long du processus de développement. Les tests unitaires peuvent facilement être exécutés en continu, mais le déplacement vers la gauche de l'exécution des tests fonctionnels ultérieurs est souvent difficile en raison des dépendances du système externe, et c'est là que vous pouvez tirer parti de la virtualisation des services pour permettre des tests continus.

La virtualisation des services vous permet de simuler des systèmes dépendants dont la disponibilité peut être limitée, tels que les mainframes, les frais d'accès, les services tiers ou peut-être les systèmes qui ne sont tout simplement pas encore prêts. En les simulant, vous pouvez effectuer des tests fonctionnels sans disposer de l'ensemble du système, et vous pouvez déplacer l'exécution des tests de gauche jusqu'au bureau de développement.

Sur le plan de virtualisation des services dans les tests de performance, la virtualisation des services vous permet de tester avant que tout soit prêt, et sans disposer d'un laboratoire complet de tout dans le système. Vous pouvez même exécuter toutes sortes de scénarios de simulation, comme si le serveur d'applications était rapide et la base de données lente (quelque chose de difficile à réaliser dans le monde réel). Ou que se passe-t-il si mon serveur commence à lancer des erreurs amusantes comme une erreur 500 ? Comment cela affectera-t-il les performances du système ?

Vous pouvez pousser le système aussi fort que vous le souhaitez et au-delà, et le faire le plus tôt possible. (En savoir plus sur la façon de shift-left vos tests de performance.)

De même, vous pouvez commencer à effectuer vos tests de sécurité plus tôt. Le découplage des systèmes physiques permet de faire quelque chose d’encore plus intéressant, c’est-à-dire de faire en sorte que les systèmes simulés se comportent de manière perverse. Vous pouvez désormais VRAIMENT vous lancer dans les tests de sécurité… Au lieu de simplement fouiller votre système à la recherche de données corrompues et de DDoS, vous pouvez demander à un système de vous inonder de paquets, d'envoyer des données mal formées ou de tout autre exploit couramment utilisé par les attaquants. Ainsi, non seulement vous pouvez tester plus tôt (à gauche), mais vous pouvez également tester beaucoup plus profondément que ce qui est possible avec un laboratoire de test ou un système de production.

Résumé

Les processus d'assurance qualité qui se sont avérés efficaces pendant de nombreuses décennies peuvent être utilisés pour améliorer considérablement la qualité tout en économisant du temps et de l'argent.

Lorsque vous passez à gauche en tirant parti des technologies de test logiciel modernes, vous pouvez obtenir un logiciel sûr, fiable et sécurisé. En déplaçant les tests vers la gauche, vous pouvez réduire le coût des tests en trouvant les bogues plus tôt, quand c'est moins cher, tout en réduisant le nombre de bogues que vous insérez dans le code en premier lieu.