Whitepaper
Le test en charge à la vitesse Agile

Présentation

Ce livre blanc a pour but de mettre en valeur certains des défis liés aux tests de charge et de performance dans un environnement Agile. Il fournit également de bonnes pratiques clés, telles que la hiérarchisation des objectifs de performance et l’automatisation des tests via des serveurs d’intégration continue. Les responsables des tests, les opérateurs et/ou toute personne impliquée dans les tests de développement Agile ou similaires peuvent bénéficier de ces conseils.

Admettons-le : la stratégie Agile est une réalité de la vie. Vous n’êtes peut-être pas « complètement Agile » et n’exécutez peut-être pas l’intégration continue, ni même ne parlez encore de DevOps, mais le fait est que la pression se fait toujours plus grande pour obtenir un grand nombre des avantages (tels que la qualité et la vitesse) inhérents aux méthodes de développement Agile ou similaires.

Lorsque vous devenez plus Agile, les développeurs rédigent plus de code, plus rapidement, dans le but de prendre en compte autant de tâches et de récits utilisateur que possible avant la fin du sprint, alors que de nombreux testeurs peinent à suivre ce rythme. En outre, les testeurs des équipes Agile sont souvent responsables des tests automatisés, unitaires et de régression, en plus des tests de charge et de performance. Dans cet environnement, vous devez pouvoir suivre le rythme de développement tout en répondant aux attentes accrues de qualité.

Name
Le test en charge à la vitesse Agile
Type

Les avantages techniques qui découlent d’un développement Agile sont bien documentés (vitesse supérieure de mise sur le marché, adaptation aux demandes changeantes des utilisateurs/nouvelles technologies, boucle de feed-back constante, etc.), mais les avantages commerciaux qu’apportent des performances d’application supérieures en raison d’une plus grande rigueur des tests de charge et de performance jouent également un rôle important.

Essayez NeoLoad, la plateforme de tests de performance la plus automatisée pour les entreprises testant APIs et Applications critiques en continue

 

Avantages liés aux tests continus de charge et de performance

Éviter la découverte tardive de problèmes de performance

 

Lorsque les tests de charge et de performance sont repoussés à la fin d’un cycle de développement, les développeurs ont souvent peu ou pas de temps pour apporter des modifications. Cela peut obliger les équipes à retarder la sortie d’un produit, empêchant ainsi la livraison en temps opportun des fonctionnalités nécessaires aux clients. Alternativement, si les problèmes s’avèrent mineurs, les équipes peuvent décider de poursuivre le processus et de lancer l’application en production, en acceptant les risques associés. Si les problèmes de performance sont plus fondamentaux, ils peuvent nécessiter des changements architecturaux douloureux, dont la mise en oeuvre peut prendre des semaines ou des mois.

Apporter des modifications plus tôt, quand leur coût est moindre

 

En incorporant des tests de charge et de performance dans les processus de test d’intégration continue, les entreprises peuvent détecter relativement tôt les problèmes de performance, alors que les coûts des correctifs sont beaucoup plus gérables. Si les développeurs peuvent immédiatement savoir que la nouvelle fonctionnalité de la dernière build a empêché l’application de respecter les contrats de niveau de service (SLA), ils peuvent résoudre le problème avant que son coût augmente de façon exponentielle. Ceci est particulièrement vrai pour les équipes Agile qui découvrent un problème de performance après plusieurs semaines (pour un problème déjà présent dans plusieurs builds antérieures). Cela accentue la difficulté à identifier la cause du problème.

Garantir aux utilisateurs d’obtenir de nouvelles fonctionnalités, et non de nouveaux problèmes de performances

 

Dans certaines organisations Agile, le changement se produit rapidement. Il est possible qu’une nouvelle fonctionnalité ou caractéristique soit vérifiée dans le cadre du contrôle de code source, soit intégrée dans une build d’intégration continue, passe tous les tests automatisés et soit déployée sur le serveur de production, en quelques minutes. Toutefois, si le code n’est pas optimisé pour gérer le nombre d’utilisateurs simultanés observés aux heures de pointe les plus élevées, une défaillance système peut survenir. L’intégration des tests de charge dans le processus avant que ces modifications soient déployées en production peut garantir que vos utilisateurs bénéficieront de tous les avantages offerts par votre marque/technologie, sans aucun compromis. Cela peut éviter à votre entreprise de subir une grosse perte de chiffre d’affaires (chiffrée en milliers voire en millions d’euros) alors que les utilisateurs se tourneraient vers les applications de vos concurrents ou dénigreraient votre marque en raison de problèmes qu’ils auraient rencontrés avec votre application.

Automatisez vos tests de performances d'APIs et d'Applications end-to-end grâce à NeoLoad, la plateforme de test de performance en continue.

 

Défis propres aux tests de performance dans un environnement Agile

De la même manière que l’association d’Agile aux tests de charge peut offrir des avantages uniques, elle peut également présenter des défis majeurs que vos équipes n’ont peut-être encore jamais rencontrés.

Des cycles de développement plus courts nécessitent plus de tests en moins de temps.
Les tests de charge et de performance sont généralement repoussés à la fin d’un cycle de développement. Avec un développement Agile, les cycles sont beaucoup plus courts et les tests de charge et de performance peuvent être retardés jusqu’au dernier jour d’un sprint ou parfois menés dans un mode de sprint différent. Cela peut souvent aboutir à la publication prématurée d’un code insuffisamment testé et/ou au report de récits utilisateur à la prochaine version, une fois testés. Théoriquement, la solution consiste à incorporer les tests plus tôt dans le cycle de développement, mais cela est plus facile à dire qu’à faire quand de nombreuses équipes manquent de ressources et d’outils pour cela.

Un code « opérationnel » n’est pas toujours performant

Les développeurs travaillant dans les équipes Agile mettent fortement l’accent sur la livraison d’un code « opérationnel », mais ce code est-il réellement « opérationnel » s’il échoue en charge ? Les tâches/récits utilisateur doivent-ils être marqués comme « terminés » si le code associé entraîne le blocage de l’application pour 100 utilisateurs ? Qu’en est-il pour 1 000 ? 100,000? La pression pour conclure le développement du code est élevée, mais il en va de même du coût d’un blocage de l’application en production.

Les développeurs ont besoin d’un feed-back en temps opportun … sans délai !

Les développeurs Agile doivent en savoir plus que le simple fait que leur code cause des problèmes de performance : ils doivent savoir quand les problèmes ont commencé et sur quel récit ils travaillaient à ce moment-là. Il est très pénible pour des développeurs d’avoir à revenir en arrière afin de corriger du code pour un récit traité des semaines ou des mois auparavant. Cela signifie également qu’ils ne disposent pas du temps nécessaire pour mettre sur le marché de nouvelles fonctionnalités. La détection des problèmes de performance à un stade précoce du cycle, permettant de fournir rapidement un feed-back important aux développeurs, est essentielle pour réduire les coûts.

Automatiser la livraison du développement aux opérations peut paraître risqué

Alors que DevOps et le déploiement continu sont des pratiques encore assez jeunes, les équipes ops ont toujours craint que de nouveaux changements dans le code ralentiront voire bloqueront l’application lorsqu’elle sera déployée en production. L’automatisation de certains tests dans le processus d’intégration continue permet d’atténuer cette crainte, mais si des tests de performance appropriés ne sont pas inclus, le risque reste réel. Les équipes ops connaissent bien l’énorme impact que les temps d’arrêt des applications peuvent avoir sur l’entreprise.

Commencez à tester avec Neoload, la plus rapide, la plus réaliste, et la plus automatisée des plateformes de test de performance en continue

 

Bonnes pratiques

Les bonnes pratiques suivantes peuvent vous aider à optimiser les avantages tout en surmontant les défis liés aux tests de charge dans un environnement Agile.

Placer les contrats SLA de performances au centre des préoccupations

 

Chaque application a des contrats de niveau de service (SLA) définissant des performances minimales à respecter, mais les équipes Agile sont souvent plus concentrées sur l’ajout de fonctionnalités/caractéristiques que sur l’optimisation des performances de l’application. Les récits utilisateur sont généralement écrits d’un point de vue fonctionnel (p. ex., « En tant qu’utilisateur, je peux cliquer sur le bouton « Afficher le panier » et consulter la page « Mon panier » ») sans spécifier les exigences de performance de l’application (p. ex., « En tant qu’utilisateur, je peux cliquer sur le bouton « Afficher le panier » et consulter la page « Mon panier » » en moins d’une seconde quand il y a moins de 1 000 autres utilisateurs sur le site »).

Ce n’est peut-être pas la meilleure façon d’écrire un récit utilisateur, mais cela illustre l’idée que les performances doivent figurer quelque part sur le tableau des tâches si l’équipe est censée y accorder de l’attention.

Une façon d’afficher les performances sur le tableau consiste à utiliser vos contrats SLA comme des tests d’acceptation pour chaque récit, de sorte qu’un récit ne puisse pas être « terminé » si les modifications entraînent le non-respect de ces contrats SLA par l’application (cela peut nécessiter la définition d’un ou de plusieurs nouveaux contrats SLA pour de nouvelles fonctionnalités/applications, par exemple : toutes les recherches d’une nouvelle fonctionnalité de recherche doivent renvoyer des résultats en moins de 2 secondes). Cette approche fonctionne bien lorsque les modifications apportées au récit affectent une partie relativement restreinte du code et que les problèmes de performance sont, par conséquent, limités à une partie de l’application.

Pour les contrats SLA portant sur l’ensemble de l’application (p. ex., chaque page doit être chargée en moins d’une seconde), les tests doivent être ajoutés à une plus grande liste de contraintes (pouvant inclure des tests fonctionnels) et être testés pour chaque récit, afin de déterminer si ce récit répond à la DoD (Definition of Done) minimale sans manquer à aucune de ces contraintes.

Travailler en étroite collaboration avec les développeurs pour anticiper les changements

 

L’un des avantages pour les testeurs qui travaillent dans un environnement Agile est qu’ils sont généralement informés des mises à jour des tâches de développement au cours d’échanges quotidiens ou de réunions de type scrum similaires. Afin de retirer un bénéfice maximum de ce niveau de collaboration, les testeurs doivent constamment réfléchir à la façon dont les récits en cours de codage seront finalement testés. Exigeront-ils de nouveaux tests de charge ? Provoqueront-ils des erreurs dans les scripts de test actuels ? Pouvez-vous vous permettre de légères modifications des scripts de test actuels si vous planifiez à l’avance ? La plupart du temps, il s’agit de petites modifications, si bien que les testeurs peuvent conserver leur avance s’ils restent en contact avec l’équipe.

Intégrer au serveur de build

 

Même si vous n’avez pas encore complètement adopté les méthodes Agile, vous avez probablement un serveur de build qui lance des tests automatisés, unitaires, de fumée et/ou de régression. De la même manière que les objectifs de performance doivent être ajoutés au tableau des tâches, les tests de performance doivent faire partie des tests récurrents pour chaque build. Cela peut se résumer à la configuration d’un déclencheur pour amener le serveur de build à lancer le test et à afficher les résultats de test dans l’outil de génération en fonction de la sophistication de l’intégration. Dans l’idéal, vous voulez que la personne qui a lancé la génération voie instantanément les résultats et sache quels changements ont été incorporés à cette build afin qu’ils puissent être corrigés en cas de problème de performance.

Intégration continue + Build nocturne + Tests de charge en fin de sprint

 

Il peut y avoir de grandes différences entre des builds d’intégration continue, des builds nocturnes et des builds post-sprint. Nous parlons des différences entre une modification individuelle apportée à un serveur de contrôle de versions, toutes les modifications effectuées dans une journée et toutes les modifications effectuées au cours d’un sprint. Dans cet esprit, vous devez ajuster vos tests de charge au type de build que vous exécutez.

Une bonne pratique consiste à commencer petit et en interne. Pour les builds d’intégration continue qui sont générées chaque fois que quelqu’un apporte une modification, vous voulez que ces tests soient exécutés rapidement, afin de pouvoir présenter au développeur des résultats sur la façon dont ses modifications affectent le système. Pensez à exécuter un petit test de performance avec les scénarios les plus courants, en appliquant à votre application la charge standard produite par vos propres générateurs de charge internes.

Pour les builds nocturnes, augmentez le nombre de scénarios à contraintes multiples et augmentez la charge pour obtenir ce que vous voyez aux heures de pointe, afin de constater si des problèmes de performance sont passés inaperçus durant les tests d’intégration continue. À la fin du sprint, vous voudrez sortir le « grand jeu » : envisagez de générer une charge à partir du cloud pour voir ce qui se passe quand des utilisateurs accèdent à votre application via le pare-feu. Veillez à ce que chaque contrat SLA de la liste des contraintes soit adopté, afin que chaque récit terminé au cours du sprint puisse être marqué comme « terminé ».

Procédure pour choisir une solution de test de charge Agile

 

 

Toute solution de test de charge vous permettra d’effectuer certaines formes de tests de charge dans votre environnement Agile, mais peu vous permettent de suivre toutes les bonnes pratiques indiquées ici tout en suivant le rythme de vos équipes de développement Agile.

Lorsque vous envisagez une solution de test de charge Agile, vous devriez vous poser les questions suivantes :

You have read 47% of the article