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

Plus tôt vous découvrez les problèmes dans votre code, moins ils ont d'impact. Cela coûte également moins cher de s'en occuper. Dans ce blog, nous explorons la méthodologie du décalage vers la gauche et comment aborder le décalage vers la gauche dans votre organisation.

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 bogues entrent-ils le code?

La stratégie de test de décalage à gauche est bien illustrée 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 logiciel. la majorité des bogues surviennent pendant la phase de codage, ce qui est prévisible.

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 sont ces bugs trouvé?

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.

Que fait-il sables moins coûteux corriger les 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 vraiment intéressant, car nous voyons une mauvaise progression des coûts qui augmente considérablement plus tard le défaut est détecté. Laisser un bogue se faufiler dans les tests du système coûte 40 fois plus cher que de le trouver pendant le codage, ou 10 fois plus cher que de trouver ce même bogue pendant les tests unitaires. Et cela devient ridiculement cher quand vous regardez le nombre de bogues qui se faufilent dans le 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 (approche de décalage vers la gauche)

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 minimiser la dépendance aux tests de fin de cycle vous avez donc juste assez de tests manuels / d'interface utilisateur 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.

Décalage 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 simplement transférer le fardeau sur 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.

Alors, comment vous déplacez-vous vers la gauche?

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

Appliquer les meilleures pratiques de test 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 bogues, mais de réduire le nombre de bogues (en particulier ceux qui font partie de la version). En fin de compte, créer moins de bogues en premier lieu est bien plus précieux que de trouver plus de bogues - et c'est beaucoup moins cher. C'est pourquoi les normes de codage critiques pour la 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 trouver des bogues plus tôt), pour prendre en charge et tirer le meilleur parti de votre initiative de quart de travail à gauche. 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, ceci est particulièrement important pour réussir à durcir votre logiciel. Vous voulez 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ébut (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 qui peuvent avoir une disponibilité limitée, tels que des mainframes, des frais d'accès, des services tiers ou peut-être des systèmes qui ne sont tout simplement pas encore prêts. En les simulant, vous pouvez effectuer des tests fonctionnels sans que tout le système soit disponible, et vous pouvez déplacer l'exécution des tests vers la 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 vous permet de faire quelque chose d'encore plus intéressant, qui consiste à faire en sorte que les systèmes simulés se comportent mal. Maintenant, vous pouvez VRAIMENT vous lancer dans les tests de sécurité ... Au lieu de simplement fouiller votre système pour des données corrompues et des attaques DDoS, vous pouvez faire en sorte qu'un système vous inonde de paquets, ou envoie des données malformées, ou l'un des nombreux autres exploits couramment utilisés 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.