Qu’est-ce que shift left testing ? Et qu’est-ce que cela signifie pour DevOps?

La méthodologie de test de gauche de décalage est une approche aux essais de logiciel qui apporte des exigences de test plus tôt dans le cycle de développement de logiciel.

 

Le développement de logiciels a connu une évolution assez importante au cours des dernières décennies. Aujourd’hui, les ingénieurs de performance et les testeurs peuvent intégrer un nombre illimité d’outils d’automatisation, d’apprentissage automatique et d’IA dans leurs tests. Il n’y a pas si longtemps, lorsque les tests logiciels étaient une note latérale. En fait, le développement précoce de logiciels n’avait même pas de phase de test formelle. L’introduction des tests n’a pas eu lieu jusqu’à ce que le logiciel est devenu plus complexe, où les bugs et les défauts de l’environnement de production ont commencé à avoir un impact sur l’entreprise. Les développeurs ont effectué les tests eux-mêmes, pas une équipe distincte. C’est ainsi que les tests fonctionnels ont vu le jour et sont devenus une partie du modèle traditionnel de cascade, composé d’étapes distinctes (analyse, exigences, conception, codage, essais, acceptation, production et post-production) qui se déplaçaient à travers un chemin linéaire, semblable à une chaîne de montage dans une usine.

Waterfall Model par Paul Hoadley. Utilisé sous la licence Creative Commons.

 

Une fois chaque étape terminée, elle est passée sur le groupe suivant et s’est déplacée vers le bas de la ligne. Il avait l’air bien sur le papier, mais QA n’a pas testé le code jusqu’à ce que la plupart de ces étapes étaient terminées. Par conséquent, cela signifiait qu’il restait très peu de temps pour apporter des modifications au code avant la production. Si le problème ou le bogue était suffisamment grave, cela signifiait la démolition ou le report du projet. En outre, cela signifiait une perte énorme potentielle pour les entreprises, en fonction de l’importance de l’application logicielle.

 

Shift Left Testing – Jeter les bases

Heureusement, les leçons coûteuses tirées des erreurs de développement antérieures ont contribué à inaugurer la méthode du décalage à gauche. Les organisations se sont rendu compte que l’identification des problèmes en fin de match était non seulement trop coûteuse, mais aussi risquée. Un article de TechRepublic de mai 2019 a rapporté que le coût annuel moyen pour corriger les bogues visuels dans les logiciels est de plus de 400 000 $. Pas exactement le changement idiot.

De plus, l’industrie dans son ensemble changeait. Il y a eu une transformation numérique à qui les entreprises ont dû faire face. Les organisations commençaient à se rendre compte qu’elles ne pouvaient plus compter sur un à deux cycles de sortie par année. Les attentes et les demandes des clients étaient élevées. La libération d’un produit mal conçu signifiait perdre des clients à cause de la concurrence. Quelque chose devait changer.

Les organisations ont commencé à décomposer le cycle de développement en blocs plus petits et gérables et à intégrer des tests dans chaque phase. Cela a permis un environnement plus collaboratif, donnant aux équipes la possibilité d’identifier les problèmes plus tôt. Par exemple, en comprenant mieux les exigences logicielles plus tôt dans le processus, les équipes de test pourraient aider à développer de meilleurs cas de test pour corriger les bogues potentiels. C’est aussi ce qu’on appelle « échouer tôt et souvent » ou « échouer rapidement ». La prise en compte des scénarios utilisateur et du comportement logiciel plus tôt dans le processus élimine les bogues potentiels et optimise le code. Cela permet aux équipes de livrer un produit cohérent.

Évidemment, il va y avoir des moments où les tests n’ont tout simplement pas de sens. Par exemple, vous ne pouvez pas effectuer de test d’interface graphique tant que vous n’avez pas d’interface graphique. Cependant, le changement à gauche est plus un état d’esprit, pas seulement un processus de développement. Plus important encore, les équipes devraient toujours réfléchir à ce qui améliorerait l’expérience utilisateur. En fin de compte, c’est l’utilisateur qui va avoir le produit final dans leurs mains. Tout ce qui peut améliorer une application avant qu’elle ne soit poussée dans la production profite à tout le monde.

 

L’essor des tests à gauche par quarts et Agile et DevOps

En raison de l’augmentation des progrès technologiques et de l’accent mis sur l’expérience numérique, un changement de paradigme s’est produit. Les cycles de développement et d’essai sont devenus plus courts et plus fréquents. Cela a entraîné de nouvelles fonctionnalités mises sur le marché plus tôt. Plus important encore, non seulement cela a permis aux entreprises de rester compétitives, mais cela a aussi permis aux clients d’être heureux et engagés. Par exemple, les applications mobiles et Web fonctionnent généralement dans des cycles de sortie de deux semaines. Certaines organisations publient des mises à jour quotidiennement – voire toutes les heures!

L’objectif du développement d’applications et de logiciels est d’être rapide, agile et de réduire les risques. Les organisations relèvent ce défi grâce au développement logiciel Agile et aux pratiques DevOps. Le développement de logiciels agiles est similaire au modèle cascade; cependant, la principale différence est que dans un modèle de chute d’eau, il ya toujours une phase de test après la phase de conception. La méthode Agile décompose le développement en petites itérations, appelées sprints, qui ne durent plus que quatre semaines. Chaque sprint implique des membres de l’équipe interfonctionnels travaillant sur tous les aspects du sprint, avec des tests effectués dans chaque itération. Cela permet une plus grande collaboration entre les membres de l’équipe, des cycles de rétroaction plus courts et un produit de meilleure qualité.

Et c’est un autre facteur important au sujet des tests de gauche par quarts. Dans les tests traditionnels en cascade, la responsabilité de tester et de gérer la qualité du produit incombe à l’équipe qa. Dans les environnements agiles et de testeurs agiles, les développeurs et les testeurs effectuent les tests réels, mais la responsabilité incombe en fin de compte à tout le monde en raison de son approche collaborative et interfonctionnelle pendant le développement. Aujourd’hui, il existe quatre approches différentes pour déplacer les tests à gauche : les tests traditionnels, incrémentiels, agiles/devops et les tests de gauche par décalage basés sur le modèle.

 

Types de tests shift left

Ces dernières années, le terme DevOps est devenu plus un mot à la mode pour le marketing, les produits logiciels, et même les descriptions de travail. En termes simples, DevOps est un cadre alternatif dans l’approche Agile qui vise à réunir les équipes de développement et d’opérations. Historiquement, chaque ministère avait ses objectifs respectifs, parfois contradictoires. Les développeurs créent, conçoivent et innovent. Les équipes opérationnelles se concentrent sur l’infrastructure et « gardent les lumières allumées » avec une surveillance continue pour assurer la disponibilité. De même, DevOps a été spécialement créé pour apporter plus de collaboration, de rétroaction et d’agilité entre ces départements. DevOps est également mentionné lorsque l’on parle de CI/CD (Continuous Integration and Continuous Deployment) et d’automatisation, mais le fait qu’une organisation utilise CI/CD et l’automatisation ne la rend pas automatiquement certifiée DevOps.

 

Tests de charge Meilleures pratiques pour les environnements DevOps

Si vos équipes suivent une approche obsolète de test et de surveillance de la charge, DevOps peut rapidement vous pousser dans un désastre de performance. Les équipes qa doivent faire face à de nouveaux déploiements fréquents de version. Les équipes de DevOps ont besoin d’un moyen facile de gérer leurs tests, en plus d’une surveillance flexible, afin de fournir des informations adéquates.

Essais de charge continue.

Il y a trop de modifications qui peuvent affecter l’interface utilisateur et bloquer votre test de charge. L’objectif initial devrait être d’exécuter des tests API entièrement automatisés et de les programmer pour qu’ils s’exécutent quotidiennement. Une fois que les processus d’affaires clés sont stables, vous pouvez ajouter des tests supplémentaires de bout en bout à votre scénario de test

Partagez des informations précieuses.

Impliquez votre équipe DevOps dans les activités d’analyse des résultats. Ne pratiquez pas la dissimulation d’informations. Partagez tous les tests de charge (y compris les tests de charge Selenium) et les résultats de surveillance avec vos ingénieurs pour déterminer la cause de tous les problèmes.

Surveillance de toutes les couches.

Le déplacement à gauche signifie également avoir une surveillance de la production sur les étapes de développement et d’assurance qualité. Vous n’aurez pas le temps de reproduire en permanence les erreurs dans les pipelines de développement agiles. Assurez-vous de collecter des mesures d’utilisation avant, back-end et d’utilisation de l’infrastructure 24 heures sur 24, 7 jours sur 7 pour les étapes de non-production.

Ligne de base et point de repère.

Les tests de charge continue produisent des tonnes de données. Définissez des lignes de base et utilisez des repères pour détecter les écarts au début du cycle. Plus tôt vous en apprendrez davantage sur les ralentissements, plus votre équipe de développement aura de temps pour résoudre de tels problèmes.

 

Intégration des tests de performance dans la méthodologie Shift Left

Les applications d’aujourd’hui utilisent de multiples technologies, s’appuyant sur de vastes réseaux de fournisseurs tiers et de CDN. Ajoutez au fait que les utilisateurs peuvent accéder à vos applications de n’importe où dans le monde, à partir de n’importe quel nombre d’appareils, le tout avec des vitesses de connexion variables. C’est beaucoup à rendre compte lorsque vous essayez de donner aux utilisateurs une grande expérience tout le temps. Les temps de réponse, la qualité et la disponibilité sont des facteurs critiques qui doivent être pris en compte avant de pousser les applications à la production.

Une fois en production, votre application ou votre site devra tenir jusqu’à des centaines, voire des milliers d’utilisateurs simultanés. De petites modifications incrémentielles au code peuvent affecter les performances, de sorte que plus tôt vous trouverez des bogues liés aux performances, plus il sera facile et moins coûteux de les corriger. Dans la plupart des cas, les équipes devraient être en mesure de résoudre tous les problèmes de performance dans un jour ou deux. Encore une fois, il est beaucoup plus facile d’effectuer ces améliorations alors, par rapport à les découvrir avant le déploiement.

Idéalement, une fois que le code a passé les tests fonctionnels nécessaires, avec des fonctionnalités approuvées et approuvées, les équipes doivent exécuter des tests non fonctionnels, tels que des tests de stress et de charge, pour voir dans quelle mesure les artefacts de test fonctionnels résistent aux utilisateurs virtuels. LoadView fait partie intégrante de l’approche de test de décalage à gauche, permettant aux utilisateurs de consacrer du temps, de l’argent et de fournir du code et des applications optimisés.

 

La plate-forme LoadView : Tests de charge basés sur le Cloud dans les navigateurs réels

La plate-forme LoadView est une plate-forme flexible de test de charge qui peut résoudre le problème des modèles de charge inefficaces, simulant tout, des tests basés sur le protocole aux tests basés sur le navigateur réel. Il est entièrement basé sur le cloud, il n’est donc pas nécessaire de configurer et de déployer des injecteurs de charge internes, de gérer des comptes cloud tiers ou de se soucier des exigences matérielles ou logicielles. Les tests de performance nécessitent généralement une infrastructure et des ressources supplémentaires que certaines organisations peuvent ne pas être en mesure de prendre en charge. LoadView gère cela pour vous via la plate-forme.

LoadView est idéal pour tester le code ou les services Web à un stade précoce afin d’aider à comparer les caractéristiques de performance, car il peut facilement démarrer et simuler des niveaux élevés de charge sur le backend à partir d’un injecteur de charge unique, ce qui vous permet d’économiser du temps et de l’argent par rapport à d’autres outils. Cela le rend idéal pour tester les architectures d’API Web comme JSON, SOAP et REST. En outre, les tests non fonctionnels nécessitent généralement des temps d’installation plus longs et des scripts complexes qui exigent que les développeurs et les ingénieurs aient une connaissance pratique de langages de programmation spécifiques. Cela peut parfois être difficile à automatiser car ils ont tendance à ne fonctionner que dans un écosystème spécifique au fournisseur. Ce n’est pas le cas avec LoadView.

 

Scripting Made Easy: L’enregistreur Web EveryStep

LoadView utilise un enregistreur de script facile à utiliser appelé EveryStep Web Recorder. Les utilisateurs peuvent facilement créer des actions de script avancées qui simulent des actions utilisateur réelles avec vos API, applications Web et sites Web. Pour valider les temps de réponse de bout en bout pour les applications côté client, les utilisateurs peuvent simplement naviguer dans leur cas de test et enregistrer chaque action. Comprendre la charge qu’une API ou une application Web peut gérer au cours de la phase de développement précoce peut aider les développeurs dans ces domaines critiques :

• Déterminer les lignes de base du temps de réponse sous des nombres de charge utilisateur spécifiques
• Identifier les goulots d’étranglement des performances
• Trouver les limites supérieures de vos systèmes actuels de planification de la capacité
• Analyse des performances du serveur (Processeur, mémoire, bande passante, disque I/O) et des temps de réponse à la base de données

L’enregistreur prend également en charge plus de 40 navigateurs et appareils de bureau/mobiles populaires, ainsi que des technologies Web et des langages de programmation, tels que AJAX, HTML5, JavaScript, Flash, Silverlight, et plus encore. LoadView utilise ces scripts pour exécuter des tests de stress et de charge à la demande, à partir de plus de 13 emplacements mondiaux (États-Unis, Canada, Amérique du Sud, Europe et APAC), donnant aux ingénieurs de test des données de performance réelles à partir de navigateurs réels. N’oubliez pas que l’exécution d’un test interne peut vous dire dans quelle mesure votre application ou site gère une augmentation du trafic à partir de votre propre réseau, mais il ne reflétera jamais les conditions réelles. Les applications et les sites qui ne sont pas correctement testés et optimisés peuvent avoir un impact négatif sur les conversions et, en fin de compte, sur les revenus.

 

LoadView : flexibilité pour tester des scénarios réels

LoadView donne aux utilisateurs la possibilité de répartir la charge utilisateur entre les emplacements géographiques en fonction du pourcentage de trafic vers votre site. Par exemple, si vous savez qu’un certain pourcentage de vos clients et utilisateurs proviennent d’un emplacement géographique spécifique, vous pouvez sélectionner ces zones spécifiques à tester. La plate-forme utilise Amazon Web Services (AWS) et Azure Cloud Services pour générer des utilisateurs virtuels. En outre, les utilisateurs peuvent aller plus loin dans leurs tests de charge en personnalisant le type de courbe de charge. Cela offre encore plus de flexibilité pour les ingénieurs d’essai, en fonction de leur scénario unique. Les utilisateurs de LoadView peuvent choisir parmi trois courbes de charge différentes :

Courbe d’étape de charge

• • Commence par un nombre prédéterminé d’utilisateurs simultanés et augmente progressivement la charge pour voir comment votre site web peut gérer une augmentation du trafic et le comparer au trafic prévu.

Courbe basée sur les objectifs

• • Ce type de courbe de charge est utile lorsque vous avez déjà déterminé votre objectif de débit ou le nombre de visiteurs sur votre site pendant un intervalle de temps fixe. Idéal pour valider les exigences SLA ou non fonctionnelles.

Courbe réglable dynamique

• • Ce test permet aux utilisateurs d’ajuster la charge pendant que le test est en cours d’exécution pour découvrir les limites de performances des sites Web ou de la capacité du serveur.

Une fois les tests terminés, LoadView génère automatiquement des rapports qui aident les équipes à mesurer le succès de leurs indicateurs de performance clés ( Indicateurs de performance clés ), tels que le nombre d’utilisateurs simultanés, les erreurs, les temps de réponse moyens, l’utilisation du processeur, le débit, la latence, et plus encore. Ces mesures sont essentielles pour les développeurs, les devops et les équipes d’assurance qualité, car elles aident à découvrir les goulets d’étranglement réels qui pourraient potentiellement affecter les performances des utilisateurs finaux.

 

Après avoir changé à gauche, n’oubliez pas de changer à droite

Avec tout l’accent mis sur les tests de quart à gauche, il est difficile de se rappeler qu’il ya une autre étape extrêmement importante dans le processus qui reçoit moins d’attention. Une fois votre application mise en production, vous devez vous assurer que tout continue à fonctionner sans heurts pour les utilisateurs. Dotcom-Monitor offre de multiples solutions de surveillance pour s’assurer que vos pages et applications continuent d’être performantes et fonctionnent correctement.

Surveillance des services Web

• • Disponibilité et performances des services Web, tels que HTTP/S, SOAP/REST, et plus encore

Surveillance des pages Web

• • Performances des pages Web dans les navigateurs réels, identifiant les éléments les plus lents et les plus rapides au fil du temps

Surveillance des applications Web

• • Surveillez les applications Web complexes, comme AJAX, PHP, Ruby, Flash, et plus encore

Surveillance de l’infrastructure

• • Fonctionnalité et performances des serveurs et protocoles Internet, tels que HTTP/S, e-mail, médias en streaming, VoIP, et plus encore

Ces plateformes permettent aux utilisateurs de mettre en place une surveillance continue basée sur des seuils personnalisés et peuvent alerter des individus ou des équipes spécifiques lorsque des erreurs se produisent afin qu’ils puissent travailler sur la résolution des problèmes avant d’avoir un impact potentiel sur beaucoup plus d’utilisateurs.

 

Shift Left Testing: Bon pour les affaires et la tranquillité d’esprit

En conclusion, les concepts de changement à gauche et de changement à droite peuvent être extrêmement précieux, non seulement dans le cycle de développement de logiciels, mais aussi au sein d’autres ministères et industries. Par exemple, les gestionnaires de produits ou les gestionnaires de l’expérience client « changent de gauche » et sont de plus en plus fréquemment engagés auprès des clients réels pour obtenir des commentaires continus. Cela permet aux entreprises de devenir plus agiles et de se rapprocher de la source d’information et de rétroaction pour mieux comprendre leurs clients. Penses-y. Ne seriez-vous pas plus susceptible de travailler avec quelqu’un ou de continuer à faire affaire avec une entreprise qui apprécie vos commentaires? Donc, maintenant, quand vous entendez quelqu’un dire, «shift left» ou «test tôt et souvent», ce n’est pas seulement un mot à la mode de fantaisie qu’ils jettent autour. C’est une pièce essentielle du puzzle de l’expérience client et que vous devriez toujours garder à l’arrière de votre esprit. Non seulement vos utilisateurs et clients seront heureux, mais vous gagnerez en efficacité, vous obtenirez de meilleurs résultats et vous donnerez, ainsi qu’à votre organisation, la tranquillité d’esprit.