Comment optimiser les tests de performance avec une approche Shift-Left

Apprenez à effectuer des tests de performance à gauche dans votre organisation.

Chaque sprint est critique et les décisions prises pour aller de l'avant sont ultra-rapides. Afin de faciliter le processus de rétroaction rapide, les équipes de test doivent valider minutieusement leurs applications, de bout en bout, dans un délai très court. Pour maximiser cet effort, les équipes de test peuvent moderniser leur approche des tests, afin d'obtenir le meilleur retour sur investissement possible dès les premières étapes possibles des tests logiciels.

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

Déplacer les tests de performances vers la gauche signifie permettre aux développeurs et aux testeurs de réaliser des tests de performances dès les premières étapes des cycles de développement. Traditionnellement, le test de performance est une tâche effectuée à la fin des cycles de développement car il nécessite un ensemble d'outils et de compétences spécialisés, c'est-à-dire du matériel coûteux dans des environnements dédiés par des ingénieurs de test de performance formés. À la place, une stratégie de test des performances par décalage vers la gauche permet aux testeurs d'effectuer des tests de performances plus petits et ad hoc sur des composants individuels au fur et à mesure de leur développement.

Pour ce faire, les équipes doivent commencer à créer des tests de performances ainsi que des tests unitaires et fonctionnels, lorsque la fonctionnalité est implémentée, et configurer ces tests de performances pour qu'ils s'exécutent automatiquement et produisent des rapports de manière à vous avertir des baisses de performances. Pour exécuter les tests automatiquement, l'exécution des tests de performance doit être étroitement intégrée dans le cadre du processus CI / CD, dans lequel, après chaque enregistrement de code, des tests de performance sont exécutés dans des environnements locaux avec des tests fonctionnels et unitaires.

Ce processus permet aux organisations de comprendre l'impact subtil de l'ajout de nouveaux composants sur les performances globales de leur application, et permet en fin de compte de détecter les défauts liés aux performances beaucoup plus tôt dans le cycle de vie de la livraison. Du point de vue de la culture d'entreprise, déplacer les tests de performance vers la gauche signifie également impliquer davantage les développeurs. Dans la plupart des cas, les équipes de développement peuvent apporter des améliorations d'optimisation dans la journée suivant la découverte de la dégradation des performances, au lieu d'attendre que l'application entière soit créée.

Que doit faire l'organisation pour que la performance Shift-Left se produise?

1. Tout d'abord, vous avez besoin d'une adhésion organisationnelle bien établie. Aborder la qualité en tant que processus et non en tant que réaction est essentiel pour déplacer les tests de performance vers l’ensemble de l’entreprise. Les principaux acteurs de ce processus sont les chefs de produit car les tests de performance et le temps de développement associé ont un coût de mise en œuvre, ce qui peut ralentir le cycle de développement. Les équipes de PM doivent comprendre pourquoi ce processus se déroule et comprendre que la valeur réside dans la réduction des correctifs et l'optimisation des performances.
2. Ensuite, définir les SLA au niveau des composants en plus de le niveau application permet un retour d'information à un stade précoce et aide les développeurs à comprendre l'impact de la modification du code sur les composants individuels qu'ils développent. Ces tests de performances granulaires permettent aux parties prenantes de savoir plus facilement où se trouvent les hotspots.
3. Il est important de migrer autant de vos pratiques de test hors des tests centrés sur l'interface utilisateur vers des tests automatisés tels que les tests d'API et de base de données. Ces types de pratiques de test, en plus d'être plus maintenables et évolutifs, peuvent être immédiatement exploités dans les tests de performances, peuvent identifier la cause première des problèmes de performances et sont très résistants au changement.
4. Enfin, les organisations doivent intégrer les tests de performances dans le processus de construction afin que les tests de performances de base des tests de fumée soient exécutés lors de l'enregistrement du code et qu'un ensemble complet de tests de performances soient exécutés tous les soirs. Pour ce faire, vous devez prendre en compte le matériel. Les tests de performance automatisés nécessitent plus de ressources informatiques que les tests fonctionnels, les équipes de développement doivent donc s'y préparer. Examiner si l'infrastructure de performance existante correspond à l'approche shift-gauche ou nécessite des modifications (c'est-à-dire des agents cloud) serait également l'une des principales considérations lors de la transition vers l'automatisation des tests de performance.

Rôles de développeur et de testeur dans les performances Shift-Left

Les développeurs possèdent les performances de leurs applications. Les développeurs doivent créer des applications prêtes pour les tests de performances à l'aide de microservices, d'API REST / SOAP et d'architectures de conception modulaires de sorte que les éléments individuels puissent être testés en charge au fur et à mesure de leur développement.

Les testeurs peuvent aligner leurs cas de test sur les flux de travail clés de l'application afin qu'ils puissent être exploités dans le processus de test des performances. Le fait de se concentrer sur les couches API de l'application rend cela plus résilient au changement et plus gérable. Les deux équipes utilisent des rapports qui ne respectent pas les SLA pour que l'application identifie les zones problématiques en fonction de l'enregistrement récent du code afin de les aider à identifier les composants à optimiser.

Comment intégrez-vous les outils pour activer les performances Shift-Left?

Il est important de sélectionner les bons outils pour un processus de test de performance de quart de travail à gauche, mais pas aussi important que de les utiliser ensemble dans des flux de travail automatisés. Les premiers tests de performances se déroulent souvent dans des poches, où des testeurs et des développeurs expérimentés conçoivent des techniques utilisant une variété d'outils open source et disponibles dans le commerce, mais cela est finalement négligé car il n'est pas intégré dans l'ensemble du processus automatisé.

Au lieu de cela, les testeurs devraient utiliser des outils commerciaux spécialisés qui leur permettent de créer des tests de performance de manière automatisée. Les développeurs peuvent utiliser des outils similaires pour optimiser leurs efforts ou pour créer des scripts de bas niveau pour piloter l'automatisation et la charge. Alors de quels outils avez-vous besoin?

Les outils suivants simplifient la maintenance, peuvent être gérés de manière centralisée et fournissent une interface utilisateur facile à utiliser pour comprendre les résultats.

• Outil de test fonctionnel

  Les tests fonctionnels devraient déjà faire partie de votre stratégie de tests continus. L'outil que vous sélectionnez pour l'automatisation des tests fonctionnels doit se concentrer à la fois sur la couche API de l'application (pour simplifier l'action d'exécution et la maintenance du scénario de test) ainsi que sur la couche d'interface utilisateur (pour les tests de bout en bout et d'expérience utilisateur). Les outils de test fonctionnel sont utilisés pour créer des chemins d'exécution de base (réutilisation), que ce soit au niveau de l'interface utilisateur ou au niveau de l'API. Ces chemins d'exécution correspondent aux user stories, il y aura donc une corrélation entre le résultat du test de performance et la user story impactée.

• Outil de test de performance

  Plus précisément, vous avez besoin d'un outil de test des performances capable de consommer les artefacts de test fonctionnel et de les exécuter sous charge. Ces outils doivent avoir une variété de paramètres de contrôle de charge tels que le nombre d'utilisateurs virtuels ou de transactions au fil du temps. Ces outils doivent ensuite être rapportés dans un tableau de bord centralisé pour agréger les résultats.

• Outil de virtualisation des services

  Les outils de virtualisation des services traitent les composants manquants des applications monolithiques dans les premières étapes des tests de performances de décalage gauche. L'un des principaux défis auxquels vous serez confronté lors des premiers tests de performances est le manque d'infrastructure de support, par des efforts de développement parallèles ou des composants tiers. En établissant la ligne de base de ces systèmes dépendants et en les modélisant dans des services virtuels, vous pouvez créer des conditions de base d'application similaires à celles de la production et vous concentrer sur les performances des composants individuels pendant votre test.

• Outil d'intégration continue

  Les tests de performances de décalage gauche fonctionnent mieux lorsqu'il s'agit d'un processus automatisé. Si l'automatisation est déployée, le «test de performance» signifie simplement l'examen / la maintenance des tests de performance automatisés, ce qui réduit le temps d'exécution des tests sur le long terme puisque le processus est automatisé et non manuel.

  En alignant votre stratégie de test de performance avec votre stratégie de test continu et en intégrant des outils tels que Jenkins, Bamboo, Microsoft VSTS, etc., vous pouvez créer un processus entièrement automatisé. Vos outils CI doivent vous permettre d'exécuter les tests de performances en fonction de l'archivage de code afin que des tests de performances cohérents puissent s'exécuter tous les soirs.

  De plus, vos outils CI doivent s'intégrer à votre tableau de bord de reporting et d'analyse, et publier automatiquement les résultats afin que vous puissiez comprendre rapidement les données de tendance.

• Tableau de bord centralisé pour agréger les résultats

  En parlant de votre tableau de bord de reporting et d'analyse… Un tableau de bord centralisé est important car il permet aux utilisateurs de comprendre l'impact incrémentiel des tests de performance des composants en affichant des informations sur les tendances par projet, composant, API, etc.

  Votre tableau de bord centralisé doit permettre d'automatiser les tests de performances, de définir des SLA qui transforment les tests de performances en indicateurs de réussite / échec et de voir les tendances historiques. En outre, le tableau de bord des rapports doit fournir des détails qui relient les tests de performance à leurs exigences initiales afin que l'entreprise puisse correctement prioriser les problèmes qui surviennent, ainsi que la vue de haut niveau réussite / échec et, en même temps, chaque petit détail, de sorte que vous peut déterminer les causes des pannes après leur détection.

  L'approche de décalage vers la gauche ajoute des développeurs en tant qu'utilisateurs de tableau de bord (en plus des gestionnaires et des testeurs), de sorte que le tableau de bord doit avoir les détails de bas niveau que les développeurs recherchent pour enquêter efficacement et établir les causes des échecs de SLA ou des tendances historiques.

Résumé

Les consommateurs sont épuisés par les correctifs à chaud constants et les mises à jour d'optimisation des performances. Ils ont soif de nouvelles fonctionnalités et fonctionnalités. Étant donné que les tests de performance sont traditionnellement effectués à la fin du cycle, ils ont inévitablement un impact sur les délais de livraison et, en tant que tels, ils sont examinés à travers une lentille négative. En fédérant le processus de test de performance et en permettant aux équipes agiles de test de décalage à gauche avec une approche itérative, les problèmes peuvent être identifiés tôt. Non seulement cela garantit que les décisions technologiques prises peuvent être facilement évaluées pour la dégradation des performances, mais fournit en fin de compte un produit plus performant dans son ensemble en optimisant chaque zone individuelle et laser en se concentrant sur les performances.