La nouvelle approche shifting-left pour l’assurance qualité du développement d’application

Les développeurs sont aujourd’hui propriétaires de leurs applications de bout en bout, si bien qu’en effectuant des tests au début du cycle de vie du produit (à “gauche“ donc) ils détectent les bogues potentiels, font gagner du temps et de l’argent à leur entreprise et créent des produits qui plaisent à leurs clients. Plus récemment, ils ont ajouté à leurs pratiques d’intégration et distribution continues (CI/CD) des tests d’API (interface de programmation d’application) et de simulation dans des navigateurs, étendant ainsi leur périmètre de tests et d’assurance qualité. En testant la performance du code sur différents navigateurs et son interaction avec des sources de données différentes, les développeurs ont ajouté une autre couche de tests de qualité dès les premières étapes de leurs processus. Cela apporte des avantages supplémentaires à d’autres pratiques de shifting left, telles que les tests unitaires et les tests de sécurité, et conduit à une nouvelle conception de l’assurance qualité.

Les tests de qualité traditionnels ne peuvent suivre le rythme du cloud 

Avec leur migration vers le cloud et leur adoption des méthodologies de développement agiles qui s’alignent sur les pratiques DevOps, les entreprises ont été confrontées à des exigences contradictoires entre la publication rapide du code et le maintien du plus haut niveau de qualité pour chaque version. Les techniques de tests manuels traditionnelles n’ont pas été conçues pour les workflows agiles, mais s’appuient plutôt sur les anciennes méthodologies en cascade, dans lesquelles les tests pouvaient être effectués sur une instance intermédiaire avant la mise en production du code. Selon le développement agile, disposer d’une équipe spécifique chargée de tous les tests juste avant la mise en production n’est pas l’approche la plus viable, car elle entrave le rythme rapide de développement qu’autorise le cloud. C’est pourquoi les tests se déplacent vers les premières étapes du processus de développement (à gauche) et que les tests manuels sont effectués par des personnes appartenant à chaque équipe d’ingénierie.

Les équipes cloud native se sont déplacées à gauche 

Dans le cadre de ces méthodologies agiles, les entreprises se sont tournées vers les pratiques CI/CD pour s’assurer que le code est toujours dans un état où il est prêt à être déployé. Les développeurs veulent s’assurer qu’ils sont en mesure de détecter les bogues le plus en amont possible du cycle de développement. Pour ce faire, ils ont décidé de tester plus tôt et plus souvent et reconnaissent de plus en plus la valeur ajoutée des tests de bout en bout, tout au long de leurs conceptions en mode d’intégration continue.

Les tests d’API permettent aux équipes de vérifier les workflows de bout en bout en enchaînant les requêtes HTTP et les appels d’API, et ainsi de valider toutes les couches de leurs systèmes depuis plusieurs localisations dans le monde. Les tests de navigateur capturent la vue de l’utilisateur pendant les transactions critiques, afin que les équipes puissent comprendre l’impact des changements d’interface utilisateur sur les applications web. Déplacer ces deux tests en amont des pipelines CI/CD permet d’économiser du temps et de l’argent, car il est beaucoup moins coûteux de corriger un bogue très tôt dans le cycle de développement que d’essayer de le corriger à la dernière minute, lorsqu’il a gagné en complexité et en portée. Cela signifie également que de nombreux problèmes sont détectés par les développeurs sans nécessiter la validation manuelle de leur travail par un autre ingénieur.

La visibilité sur les métriques, traces et logs est nécessaire pour des tests à valeur ajoutée 

L’exécution de tests de navigateur et d’API dans les pipelines d’intégration continue est particulièrement bénéfique, lorsque les équipes peuvent corréler ces tests avec des données (métriques, traces, logs) provenant de l’ensemble de leur pile logicielle, applications et infrastructure en frontal et en arrière-plan. De telles données facilement accessibles, sans avoir à passer d’un outil à l’autre, procurent aux équipes le contexte complet nécessaire à la détection et à la résolution des tests ratés. La détection des tests qui ont échoué permet de réviser le code défectueux avant qu’il ne soit mis en production, et les données corrélées de la pile logicielle complète peuvent être utilisées pour résoudre et corriger les problèmes qui n’ont pas été identifiés pendant la phase de développement. Cela crée une nouvelle culture de l’assurance qualité, dans laquelle le maintien de la qualité est un processus holistique qui implique chaque étape du cycle de développement et s’appuie sur des données provenant de chaque partie de la pile logicielle.

Une qualité constante exige une collaboration entre les équipes

Cette évolution de l’assurance qualité va au-delà de la pratique du shifting-left et représente un changement fondamental dans la façon dont les équipes d’ingénierie collaborent au sein d’une entreprise. Les tests ont lieu avant la mise en production du code, se poursuivent de façon rigoureuse une fois le code en ligne, impliquent des données provenant de l’ensemble de la pile logicielle et relèvent de la responsabilité d’équipes issues de différents départements de l’entreprise. Avec cette approche collaborative, un ingénieur peut facilement identifier un problème d’intégration de ses dernières modifications à la façon dont les API d’arrière-plan sont structurées. Il peut alors s’engager avec l’équipe backend propriétaire de ce service pour itérer de manière collaborative et trouver la meilleure solution pour résoudre le problème. Cela peut commencer par un shift-left, mais, idéalement, cela se termine par la suppression des silos et l’ouverture de la communication entre les équipes.

Une approche totalement opérationnelle de l’assurance qualité sous-entend que les problèmes sont résolus plus rapidement, voire même qu’ils ne deviennent jamais des problèmes. alors que le code est encore en cours de développement. Cela crée un cercle vertueux car moins de régressions signifie moins de temps d’arrêt et des clients heureux, et surtout, libère les ingénieurs pour la conception de nouveaux produits à valeur ajoutée pour les clients.

The post La nouvelle approche shifting-left pour l’assurance qualité du développement d’application first appeared on ProcuRSS.eu.