Qu’est ce que l’ingénierie de la performance ?

L'ingénierie des performances consiste à tester et à surveiller les performances des applications de manière proactive, continue et de bout en bout. Elle permet une collaboration transparente entre les équipes, les outils et les processus grâce à des boucles de rétroaction continues. Ici, ce ne sont pas seulement les testeurs qui sont responsables de l'assurance qualité, mais aussi les développeurs, les ingénieurs de performance, les product owners et les data analyst.

 

 

Les tests de performance classiques sont en fait un sous-ensemble de l'ingénierie de la performance. Ils consistent généralement en une seule série de tests de charge dans le cadre du cycle d'assurance qualité (QA) post-développement. Les tests de performance consistent à vérifier la vitesse, la fiabilité, l'évolutivité, la stabilité, le temps de réponse et l'utilisation des ressources d'une application en fonction de la charge de travail prévue.

Comment fonctionnent les tests de performance classiques ?

Les tests sont considérés de manière isolée et traités comme une réflexion après coup qui ne commence qu'à la fin des tests fonctionnels.

Le fait de travailler en silos entraîne d'importants écarts de communication entre les sous-équipes du projet et empêche la collaboration nécessaire à la livraison d'un produit de haute qualité.

Au moment où les tests de performance commencent, l'organisation a déjà consacré beaucoup de temps, d'efforts et de moyens financiers à la conception, au développement et à la promotion de l'application.

Les tests de performance sont souvent traités comme une réflexion après coup et ne sont pas inclus dans les critères d'achèvement précédant la mise en production. Ainsi, à ce stade, l'entreprise a besoin de l'application en production de toute urgence et n'attend aucun retard. Dans ce contexte, le retour d'information de l’équipe QA arrive trop tard pour que les problèmes puissent être corrigés avant la mise en production. Inévitablement, un grand nombre de problèmes de performance se retrouvent inutilement dans l'environnement de production, juste pour que le lancement se fasse dans les temps. La correction d'un défaut en cours de production est beaucoup plus coûteuse et perturbatrice que celle effectuée au début du développement.

Les tests de performance traditionnels étaient peut-être parfaits pour le modèle Waterfall, mais ils n'ont plus leur place dans le monde actuel, centré sur DevOps. DevOps réduit le taux d'échec des nouvelles versions en raccourcissant le délai entre le moment où une modification est apportée au système et celui où elle est mise en production. L'intégration continue et la livraison continue (CI/CD) permettent de s'assurer que le logiciel est toujours en état d'être publié tout au long de son cycle de vie. DevOps se concentre également sur le réalignement de l'organisation pour soutenir la collaboration de bout en bout entre les parties prenantes, les fonctions et les outils. Pour répondre aux exigences de livraison rapide de DevOps, le développement logiciel a besoin d'une approche plus évoluée des tests de performance. Cette nouvelle approche est l'ingénierie des performances.

Quelles sont les principales différences entre l'ingénierie des performances et les tests de performances ?

Les tests de performance sont un contrôle de qualité de la gestion de la charge et de la réactivité de l'application. Ils déterminent dans quelle mesure le système supportera une charge de production et anticipent les problèmes qui pourraient survenir dans des conditions de charge élevée. L'ingénierie des performances vise à concevoir l'application dès le départ en tenant compte des mesures de performance et à faciliter la découverte des problèmes dès le début du développement.

Les tests de performance sont un processus d'assurance qualité qui a généralement lieu lorsqu'un cycle de développement de logiciel est terminé. L'ingénierie des performances est un processus continu qui s'inscrit dans toutes les phases du cycle de développement du logiciel, de la conception au développement et à l'expérience de l'utilisateur final.

Les tests de performance sont menés par l'équipe QA alors que l'ingénierie de la performance implique le RND et l'assurance qualité.

Qu’est ce que l’ingénierie de la performance ?

L'ingénierie de la performance est un vaste ensemble de processus, et c'est aussi une culture.

Ces pratiques définissent une culture qui permet aux équipes de fournir des systèmes rapides, efficaces et réactifs, conçus pour des populations importantes de clients, d'employés, de régulateurs, de gestionnaires, etc.

Mais passer des tests de performance à l'ingénierie de la performance n'est pas un processus facile. L'équipe doit être prête à passer de a) la simple exécution d'un script de test de performance à cases à cocher et à se concentrer sur les parties, à b) l'étude de la façon dont toutes les parties du système fonctionnent ensemble. Ces éléments englobent le matériel, les logiciels, la configuration, les performances, la sécurité, la convivialité, la valeur commerciale et le client. Le processus consiste à collaborer et à itérer sur les éléments à plus forte valeur ajoutée, et à les livrer rapidement, avec une qualité élevée, afin de dépasser les attentes de l'utilisateur final.

Comment passer des tests de performance à l'ingénierie de la performance ?

Définir une culture

Le succès d'une équipe dépend fortement de la manière dont les dirigeants entretiennent l'environnement professionnel et permettent aux individus de collaborer. La création de ce type d'environnement inspirera la formation d'équipes interfonctionnelles et la pensée logique.

Constituer une équipe

Une équipe d'ingénierie des performances signifie que les équipes tech et business travaillent ensemble. Ils se concentrent sur la nature performante de tout ce sur quoi ils travaillent et déterminent ensemble comment ils peuvent intégrer ces capacités. Ils doivent savoir sur quel domaine spécifique se concentrer en premier lieu, ainsi que sur la manière de mesurer les résultats en cours de route. Ils doivent se mettre d'accord sur le résultat souhaité. Ils doivent constamment se rappeler que l'objectif final de l'adoption de l'ingénierie de la performance est de bénéficier à l'organisation et à l'utilisateur final.

Ajouter une technologie

L'ingénierie de la performance exige une nouvelle façon de penser, liée à l’infrastructure existante, y compris les outils et les capacités existants.

Il faut définir la portée de ses outils et découvrir les capacités technologiques dont on dispose déjà.

Mesures de performance

Par exemple, comment saisir les données APM (surveillance des performances des applications) de la production et de la pré-production ?

Commencer à examiner ces résultats et à mieux comprendre les modèles de comportement de ses utilisateurs, systèmes et transactions.

Rechercher des mesures indirectes

Il existe des centaines d'indicateurs qui peuvent être utilisés pour estimer le succès d'une nouvelle capacité ou d'une nouvelle fonctionnalité. Au fur et à mesure que les systèmes jouent un rôle plus important au sein d'une entreprise, les mesures de suivi des performances deviennent plus disponibles, ce qui permet de commencer à travailler en partenariat avec ses homologues pour savoir quelles mesures ils surveillent et comment ils obtiennent ces résultats.

Créer des environnements stables

L'un des premiers défis à relever sera de doter les équipes des capacités dont elles ont besoin. Cela se fera en partie au fur et à mesure de la constitution de ces équipes et de la mise en place des outils, des capacités et des compétences associées. Mais au début, il est essentiel de disposer d'un environnement "similaire à la production" pour l'ingénierie des performances.

Commencer tôt

L'ingénierie des performances fonctionne mieux lorsque l'équipe commence à y réfléchir dès le début. Plus tôt l'équipe commence à s'intéresser aux performances dans le cycle de vie du produit, plus le système final a de chances de fonctionner rapidement, sans heurts et efficacement. Mais s'il n'est pas possible de le faire dès le début, il est toujours possible d'ajouter le processus au travail de re-conception et de ré-ingénierie effectué pour développer l'itération ou la génération suivante d'un produit.